С преминаването на AI агентите от експериментални прототипи към приложения в реалния свят, способността да разбираме тяхното поведение, да следим тяхната ефективност и систематично да оценяваме техните резултати става важна.
След като завършите този урок, ще знаете как да/ще разберете:
Целта е да ви предоставим знанията да превърнете “черната кутия” агенти в прозрачни, управляеми и надеждни системи.
Забележка: Важно е да внедрявате AI агенти, които са безопасни и надеждни. Вижте също урока Създаване на надеждни AI агенти.
Инструментите за наблюдаемост като Langfuse или Microsoft Foundry обикновено представят изпълненията на агенти като следи и обхвати.
Без наблюдаемост AI агентът може да се усеща като “черна кутия” - вътрешното му състояние и разсъждения са непрозрачни, което затруднява диагностицирането на проблеми и оптимизирането на ефективността. С наблюдаемост агентите стават “стъклени кутии”, предлагайки прозрачност, която е от съществено значение за изграждане на доверие и гарантиране, че работят както е замислено.
Прехвърлянето на AI агенти в производствени условия въвежда нов набор от предизвикателства и изисквания. Наблюдаемостта вече не е “хубаво да имаш”, а критична възможност:
За да наблюдавате и разбирате поведението на агента, трябва да проследявате набор от метрики и сигнали. Въпреки че конкретните метрики могат да варират според предназначението на агента, някои са универсално важни.
Ето някои от най-често наблюдаваните метрики от инструментите за наблюдаемост:
Латентност: Колко бързо отговаря агентът? Дългите времена на изчакване влияят негативно на потребителския опит. Трябва да измервате латентността за задачи и отделни стъпки чрез проследяване на изпълненията на агента. Например, агент, който отнема 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 обхвати към инструмент за наблюдаемост. Microsoft Agent Framework се интегрира с OpenTelemetry по подразбиране. По-долу е пример за инструментализация на MAF агент:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# Изпълнението на агента се проследява автоматично
pass
В примерната тетрадка в тази глава ще демонстрираме как да инструментализирате вашия MAF агент.
Ръчно създаване на обхвати: Въпреки че библиотеките за инструментализация осигуряват добра основа, често има случаи, в които е необходима по-подробна или персонализирана информация. Можете ръчно да създавате обхвати, за да добавяте персонализирана логика на приложението. По-важното е, че те могат да обогатяват автоматично или ръчно създадени обхвати с персонализирани атрибути (известни още като тагове или метаданни). Тези атрибути могат да включват бизнес-специфични данни, междинни изчисления или контекст, който може да бъде полезен за отстраняване на грешки или анализ, като 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 агенти в продукция може да срещнете различни предизвикателства. Ето някои чести проблеми и потенциални решения:
| Проблем | Потенциално решение |
|---|---|
| AI агентът не изпълнява задачите последователно | - Прецизирайте подадената към AI агента подкана; бъдете ясни по отношение на целите. - Идентифицирайте къде деленето на задачата на подзадачи и обработката им от няколко агента може да помогне. |
| AI агентът попада в непрекъснати цикли | - Осигурете ясни условия за прекратяване, за да знае агентът кога да спре процеса. - За сложни задачи с разсъждения и планиране използвайте по-голям модел, специализиран за такива задачи. |
| Извиквания на инструменти от AI агента не работят добре | - Тествайте и валидирайте изхода на инструмента извън системата на агента. - Прецизирайте дефинираните параметри, подкани и наименованието на инструментите. |
| Мултиагентната система не работи последователно | - Прецизирайте подкана към всеки агент, за да са ясни и отличителни помежду си. - Създайте йерархична система с “рутиращ” или контролиращ агент, който определя кой агент е правилният. |
Много от тези проблеми могат да бъдат по-ефективно идентифицирани с внедрена наблюдаемост. Следите и метриките, които обсъдихме по-рано, помагат да се локализира точно къде в работния поток на агента възникват проблеми, което прави отстраняването на грешки и оптимизацията много по-ефективни.
Ето няколко стратегии за управление на разходите при внедряване на AI агенти в продукция:
Използване на по-малки модели: Малките езикови модели (SLM) могат да се представят добре при определени агенцки сценарии и значително намаляват разходите. Както беше споменато по-рано, изграждането на система за оценка за определяне и сравняване на представянето спрямо по-големи модели е най-добрият начин да се разбере колко добре ще се представи SLM за вашия случай на употреба. Обмислете използването на SLM за по-прости задачи като класификация на намерения или извличане на параметри, като същевременно запазвате по-големите модели за сложни разсъждения.
Използване на рутер модел: Подобна стратегия е да използвате разнообразие от модели и размери. Можете да използвате LLM/SLM или безсървърна функция, за да маршрутизирате заявките според сложността към най-подходящите модели. Това също ще помогне за намаляване на разходите, като същевременно осигури добро представяне при правилните задачи. Например, маршрутизирайте прости заявки към по-малки, по-бързи модели и използвайте скъпите големи модели само за сложни задачи за разсъждения.
Кеширане на отговори: Идентифицирането на често срещани заявки и задачи и предоставянето на отговорите им преди те да преминат през вашата агенцка система е добър начин да се намали обемът на подобни заявки. Можете дори да реализирате поток за идентифициране на степента на сходство на дадена заявка с кешираните ви заявки, използвайки по-базови AI модели. Тази стратегия може значително да намали разходите за често задавани въпроси или обичайни работни процеси.
В примерния ноутбук от този раздел ще видим примери за това как можем да използваме инструменти за наблюдение, за да следим и оценяваме нашия агент.
Присъединете се към Microsoft Foundry Discord, за да се срещнете с други учащи, да участвате в часове и да получите отговори на въпросите си за AI агенти.
Отказ от отговорност: Този документ е преведен с помощта на AI преводачески услуга Co-op Translator. Въпреки че се стремим към точност, моля имайте предвид, че автоматизираните преводи могат да съдържат грешки или неточности. Оригиналният документ на неговия роден език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Ние не носим отговорност за каквито и да е недоразумения или неправилни тълкувания, произтичащи от използването на този превод.