ai-agents-for-beginners

AI Агенти в Производство: Наблюдаемост и Оценка

Когато AI агентите преминават от експериментални прототипи към реални приложения, способността да се разбира тяхното поведение, да се следи тяхната производителност и систематично да се оценяват техните резултати става от съществено значение.

Цели на обучението

След завършване на този урок, ще знаете как да/разбирате:

• Основни концепции за наблюдаемост и оценка на агентите
• Техники за подобряване на производителността, разходите и ефективността на агентите
• Какво и как да оценявате вашите AI агенти систематично
• Как да контролирате разходите при внедряване на AI агенти в производство
• Как да инструментализирате агенти, изградени с AutoGen

Целта е да ви предоставим знания, които да трансформират вашите “черни кутии” агенти в прозрачни, управляеми и надеждни системи.

Забележка: Важно е да внедрявате AI агенти, които са безопасни и надеждни. Вижте урока Създаване на Надеждни AI Агенти за повече информация.

Трейсове и Спанове

Инструменти за наблюдаемост като Langfuse или Azure AI Foundry обикновено представят изпълненията на агентите като трейсове и спанове.

• Трейс представлява цялостна задача на агента от начало до край (например обработка на потребителски запитване).
• Спанове са отделни стъпки в рамките на трейса (например извикване на езиков модел или извличане на данни).

Без наблюдаемост, AI агент може да изглежда като “черна кутия” – вътрешното му състояние и разсъждения са непрозрачни, което затруднява диагностицирането на проблеми или оптимизирането на производителността. С наблюдаемост, агентите се превръщат в “стъклени кутии”, предоставяйки прозрачност, която е жизненоважна за изграждането на доверие и гарантирането, че те работят според очакванията.

Защо Наблюдаемостта е Важна в Производствени Среди

Преминаването на AI агенти към производствени среди въвежда нов набор от предизвикателства и изисквания. Наблюдаемостта вече не е “добре да се има”, а критична способност:

• Диагностика и Анализ на Причините: Когато агентът се провали или произведе неочакван резултат, инструментите за наблюдаемост предоставят трейсовете, необходими за идентифициране на източника на грешката. Това е особено важно за сложни агенти, които могат да включват множество извиквания на LLM, взаимодействия с инструменти и условна логика.
• Управление на Закъснения и Разходи: AI агентите често разчитат на LLM и други външни API, които се таксуват на база токен или извикване. Наблюдаемостта позволява прецизно проследяване на тези извиквания, помагайки за идентифициране на операции, които са прекалено бавни или скъпи. Това позволява на екипите да оптимизират промптове, да изберат по-ефективни модели или да преработят работните потоци, за да управляват оперативните разходи и да осигурят добро потребителско изживяване.
• Доверие, Безопасност и Съответствие: В много приложения е важно да се гарантира, че агентите се държат безопасно и етично. Наблюдаемостта предоставя одитна следа на действията и решенията на агента. Това може да се използва за откриване и смекчаване на проблеми като инжектиране на промптове, генериране на вредно съдържание или неправилно боравене с лична информация (PII). Например, можете да прегледате трейсовете, за да разберете защо агентът е предоставил определен отговор или е използвал конкретен инструмент.
• Цикли за Непрекъснато Подобрение: Данните от наблюдаемостта са основата на итеративния процес на разработка. Чрез наблюдение на това как агентите се представят в реалния свят, екипите могат да идентифицират области за подобрение, да събират данни за фина настройка на моделите и да валидират въздействието на промените. Това създава обратна връзка, при която производствените прозрения от онлайн оценката информират офлайн експериментирането и усъвършенстването, водейки до прогресивно по-добра производителност на агентите.

Основни Метрики за Проследяване

За да наблюдавате и разбирате поведението на агентите, трябва да се проследява набор от метрики и сигнали. Въпреки че специфичните метрики могат да варират в зависимост от целта на агента, някои са универсално важни.

Ето някои от най-често срещаните метрики, които инструментите за наблюдаемост следят:

Закъснение: Колко бързо отговаря агентът? Дългите времена за изчакване влияят негативно на потребителското изживяване. Трябва да измервате закъснението за задачи и отделни стъпки чрез проследяване на изпълненията на агента. Например, агент, който отнема 20 секунди за всички извиквания на модел, може да бъде ускорен чрез използване на по-бърз модел или чрез паралелно изпълнение на извикванията на модела.

Разходи: Каква е цената на изпълнение на агента? AI агентите разчитат на извиквания на LLM, които се таксуват на база токен или външни API. Честото използване на инструменти или множество промптове може бързо да увеличи разходите. Например, ако агентът извиква LLM пет пъти за минимално подобрение на качеството, трябва да оцените дали разходът е оправдан или дали можете да намалите броя на извикванията или да използвате по-евтин модел. Мониторингът в реално време може също да помогне за идентифициране на неочаквани пикове (например, грешки, причиняващи прекомерни API цикли).

Грешки при заявки: Колко заявки е провалил агентът? Това може да включва грешки в API или неуспешни извиквания на инструменти. За да направите агента си по-устойчив в производството, можете да настроите резервни варианти или повторни опити. Например, ако доставчикът на LLM A е недостъпен, можете да преминете към доставчик B като резервен вариант.

Обратна връзка от потребители: Внедряването на директни оценки от потребители предоставя ценни прозрения. Това може да включва явни оценки (👍положителна/👎отрицателна, ⭐1-5 звезди) или текстови коментари. Постоянно отрицателната обратна връзка трябва да ви алармира, тъй като това е знак, че агентът не работи според очакванията.

Непряка обратна връзка от потребители: Поведенията на потребителите предоставят индиректна обратна връзка, дори без явни оценки. Това може да включва незабавно преформулиране на въпроси, повтарящи се запитвания или натискане на бутон за повторен опит. Например, ако виждате, че потребителите многократно задават един и същ въпрос, това е знак, че агентът не работи според очакванията.

Точност: Колко често агентът произвежда правилни или желани резултати? Определенията за точност варират (например, правилност при решаване на проблеми, точност при извличане на информация, удовлетвореност на потребителите). Първата стъпка е да дефинирате как изглежда успехът за вашия агент. Можете да проследявате точността чрез автоматизирани проверки, оценки или етикети за завършване на задачи. Например, маркиране на трейсове като “успешни” или “неуспешни”.

Автоматизирани Метрики за Оценка: Можете също да настроите автоматизирани оценки. Например, можете да използвате LLM за оценка на изхода на агента, например дали е полезен, точен или не. Съществуват и няколко библиотеки с отворен код, които помагат за оценка на различни аспекти на агента. Например, RAGAS за RAG агенти или LLM Guard за откриване на вреден език или инжектиране на промптове.

На практика, комбинация от тези метрики предоставя най-добро покритие на здравето на AI агента. В примерния ноутбук в тази глава ще ви покажем как изглеждат тези метрики в реални примери, но първо ще научим как изглежда типичен работен процес за оценка.

Инструментализирайте Вашия Агент

За да събирате данни за трейсове, ще трябва да инструментализирате вашия код. Целта е да инструментализирате кода на агента, за да излъчва трейсове и метрики, които могат да бъдат събрани, обработени и визуализирани от платформа за наблюдаемост.

OpenTelemetry (OTel): OpenTelemetry се утвърди като индустриален стандарт за наблюдаемост на LLM. Той предоставя набор от API, SDK и инструменти за генериране, събиране и експортиране на телеметрични данни.

Съществуват много библиотеки за инструментализация, които обгръщат съществуващи рамки за агенти и улесняват експортирането на OpenTelemetry спанове към инструмент за наблюдаемост. По-долу е пример за инструментализиране на AutoGen агент с библиотеката OpenLit:

import openlit

openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)

Примерният ноутбук в тази глава ще демонстрира как да инструментализирате вашия AutoGen агент.

Ръчно Създаване на Спанове: Докато библиотеките за инструментализация предоставят добра основа, често има случаи, когато е необходима по-подробна или персонализирана информация. Можете ръчно да създавате спанове, за да добавите персонализирана логика на приложението. По-важното е, че те могат да обогатят автоматично или ръчно създадените спанове с персонализирани атрибути (известни също като тагове или метаданни). Тези атрибути могат да включват бизнес-специфични данни, междинни изчисления или всякакъв контекст, който може да бъде полезен за диагностика или анализ, като user_id, session_id или model_version.

Пример за ръчно създаване на трейсове и спанове с Langfuse Python SDK:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

Оценка на Агента

Наблюдаемостта ни предоставя метрики, но оценката е процесът на анализиране на тези данни (и извършване на тестове), за да се определи колко добре се представя AI агентът и как може да бъде подобрен. С други думи, след като имате тези трейсове и метрики, как ги използвате, за да прецените агента и да вземете решения?

Редовната оценка е важна, защото AI агентите често са недетерминистични и могат да се развиват (чрез актуализации или промяна в поведението на модела) – без оценка, няма да знаете дали вашият “умен агент” всъщност върши добре работата си или дали е регресирал.

Съществуват две категории оценки за AI агенти: оценка офлайн и оценка онлайн. И двете са ценни и се допълват взаимно. Обикновено започваме с офлайн оценка, тъй като това е минималната необходима стъпка преди внедряване на агент.

Офлайн Оценка

Това включва оценка на агента в контролирана среда, обикновено с тестови набори от данни, а не с живи потребителски запитвания. Използвате подбрани набори от данни, където знаете какъв е очакваният резултат или правилното поведение, и след това тествате агента върху тях.

Например, ако сте създали агент за решаване на математически задачи, може да имате тестов набор от данни от 100 задачи с известни отговори. Офлайн оценката често се извършва по време на разработката (и може да бъде част от CI/CD процеси), за да се проверят подобренията или да се предотвратят регресии. Предимството е, че тя е повторяема и можете да получите ясни метрики за точност, тъй като имате истински данни. Може също да симулирате потребителски запитвания и да измерите отговорите на агента спрямо идеални отговори или да използвате автоматизирани метрики, както беше описано по-горе.

Основното предизвикателство при офлайн оценката е да се гарантира, че вашият тестов набор от данни е изчерпателен и остава релевантен – агентът може да се представя добре на фиксиран тестов набор, но да срещне много различни запитвания в производството. Затова трябва да поддържате тестовите набори актуализирани с нови крайни случаи и примери, които отразяват реални сценарии​. Смес от малки “тестове за дим” и по-големи набори за оценка е полезна: малки набори за бързи проверки и по-големи за по-широки метрики за производителност​.

Онлайн Оценка

Това се отнася до оценка на агента в жива, реална среда, т.е. по време на действителна употреба в производството. Онлайн оценката включва наблюдение на производителността на агента при реални взаимодействия с потребители и непрекъснат анализ на резултатите.

Например, може да проследявате проценти на успех, оценки за удовлетвореност на потребителите или други метрики върху живия трафик. Предимството на онлайн оценката е, че тя улавя неща, които може да не предвидите в лабораторна среда – можете да наблюдавате промяна в модела с времето (ако ефективността на агента се влошава, когато моделите на входните данни се променят) и да засичате неочаквани запитвания или ситуации, които не са били в тестовите ви данни​. Тя предоставя истинска картина за това как агентът се държи в реалния свят.

Онлайн оценката често включва събиране на непряка и пряка обратна връзка от потребители, както беше обсъдено, и евентуално провеждане на тестове в сянка или A/B тестове (където нова версия на агента работи паралелно за сравнение със старата). Предизвикателството е, че може да бъде трудно да се получат надеждни етикети или оценки за живи взаимодействия – може да разчитате на обратна връзка от потребители или на метрики надолу по веригата (например дали потребителят е кликнал върху резултата).

Комбиниране на д

Често срещани проблеми и решения

Проблеми с производителността

Проблем	Решение
Моделът не се справя добре със сложни задачи	- Използвайте по-голям модел, специализиран за задачи, изискващи разсъждения.
Инструментите на AI Agent не работят добре	- Тествайте и валидирайте резултатите от инструмента извън системата на агента. - Прецизирайте дефинираните параметри, подканите и имената на инструментите.
Мулти-агентната система не е последователна	- Прецизирайте подканите, дадени на всеки агент, за да гарантирате, че са специфични и различни една от друга. - Изградете йерархична система, използвайки “рутиращ” или контролиращ агент, за да определите кой агент е правилният.

Много от тези проблеми могат да бъдат идентифицирани по-ефективно, ако има внедрена наблюдаемост. Следите и метриките, които обсъдихме по-рано, помагат да се определи точно къде в работния процес на агента възникват проблеми, което прави отстраняването на грешки и оптимизацията много по-ефективни.

Управление на разходите

Ето някои стратегии за управление на разходите при внедряване на AI агенти в продукция:

Използване на по-малки модели: Малките езикови модели (SLMs) могат да се справят добре с определени задачи и значително да намалят разходите. Както споменахме по-рано, изграждането на система за оценка, която да сравнява производителността спрямо по-големи модели, е най-добрият начин да разберете колко добре SLM ще се справи с вашия случай. Помислете за използване на SLM за по-прости задачи като класификация на намерения или извличане на параметри, докато запазвате по-големите модели за сложни задачи, изискващи разсъждения.

Използване на рутер модел: Подобна стратегия е да използвате разнообразие от модели с различни размери. Можете да използвате LLM/SLM или безсървърна функция, за да насочвате заявки въз основа на тяхната сложност към най-подходящите модели. Това също ще помогне за намаляване на разходите, като същевременно гарантира производителност за правилните задачи. Например, насочвайте прости заявки към по-малки, по-бързи модели и използвайте скъпи големи модели само за сложни задачи, изискващи разсъждения.

Кеширане на отговори: Идентифицирането на често срещани заявки и задачи и предоставянето на отговори, преди да преминат през вашата агентна система, е добър начин за намаляване на обема на подобни заявки. Можете дори да внедрите процес за идентифициране на това колко подобна е дадена заявка на кешираните заявки, използвайки по-основни AI модели. Тази стратегия може значително да намали разходите за често задавани въпроси или обичайни работни потоци.

Нека видим как това работи на практика

В примерния ноутбук от тази секция ще видим примери за това как можем да използваме инструменти за наблюдаемост, за да наблюдаваме и оценяваме нашия агент.

Имате още въпроси относно AI агенти в продукция?

Присъединете се към Azure AI Foundry Discord, за да се срещнете с други обучаващи се, да присъствате на консултации и да получите отговори на вашите въпроси за AI агенти.

Предишен урок

Дизайнерски модел за метакогниция

Следващ урок

Агентни протоколи

---

Отказ от отговорност:
Този документ е преведен с помощта на AI услуга за превод Co-op Translator. Въпреки че се стремим към точност, моля, имайте предвид, че автоматизираните преводи може да съдържат грешки или неточности. Оригиналният документ на неговия роден език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Ние не носим отговорност за недоразумения или погрешни интерпретации, произтичащи от използването на този превод.

This site is open source. Improve this page.