Когато AI агентите се преместват от експериментални прототипи към реални приложения, способността да се разбира тяхното поведение, да се наблюдава тяхната производителност и систематично да се оценяват техните изходи става важна.
След завършване на този урок ще знаете/разберете:
Целта е да ви предостави знанията, необходими да трансформирате вашите „черни кутии“ агенти в прозрачни, управляеми и надеждни системи.
Забележка: Важно е да внедрявате AI агенти, които са безопасни и надеждни. Вижте и урока Изграждане на надеждни AI агенти.
Наблюдателни инструменти като Langfuse или Microsoft Foundry обикновено представят изпълненията на агента като трейсове и спанове.
Без наблюдаемост AI агентът може да се усеща като „черна кутия“ — неговото вътрешно състояние и разсъждения са непрозрачни, което затруднява диагностицирането на проблеми или оптимизацията на изпълнението. С наблюдаемост агентите се превръщат в „стъклени кутии“, предлагайки прозрачност, която е жизненоважна за изграждане на доверие и гарантиране, че те работят както се очаква.
Преместването на AI агенти в продукция въвежда нов набор от предизвикателства и изисквания. Наблюдаемостта вече не е „удобство“, а критична способност:
За да наблюдавате и разберете поведението на агента, трябва да проследявате набор от метрики и сигнали. Докато специфичните метрики могат да варират в зависимост от предназначението на агента, някои са универсално важни.
Ето някои от най-често срещаните метрики, които инструментите за наблюдаемост следят:
Латентност: Колко бързо отговаря агентът? Дългите времена на изчакване негативно влияят на потребителското изживяване. Трябва да измервате латентността за задачи и отделни стъпки чрез проследяване на изпълненията на агента. Например агент, който отнема 20 секунди за всички извиквания на модел, може да бъде ускорен чрез използване на по-бърз модел или чрез паралелно изпълнение на извикванията.
Разходи: Какъв е разходът на изпълнение на агента? AI агентите разчитат на извиквания на LLM, таксувани на токен, или външни API. Честата употреба на инструменти или множество подсказки може бързо да увеличи разходите. Например, ако агент извиква LLM пет пъти за минимално подобрение в качеството, трябва да оцените дали разходът е оправдан или можете да намалите броя на извикванията или да използвате по-евтин модел. Мониторинг в реално време може също да помогне да се идентифицират неочаквани скокове (напр. бъгове, причиняващи прекомерни API цикли).
Грешки при заявки: Колко заявки са се провалили? Това може да включва грешки от API или неуспешни извиквания на инструменти. За да направите агента си по-устойчив в продукция, можете да добавите резервни варианти или повторни опити. Например ако доставчикът на LLM A е недостъпен, превключете на доставчик B като резервен.
Обратна връзка от потребителите: Имплементирането на директни потребителски оценки предоставя ценни прозрения. Това може да включва явни оценки (👍thumbs-up/👎down, ⭐1-5 звезди) или текстови коментари. Последователната негативна обратна връзка трябва да ви алармира, тъй като това е признак, че агентът не функционира както се очаква.
Неявна обратна връзка от потребителите: Поведението на потребителите дава индиректна обратна връзка дори без явни оценки. Това може да включва незабавно преформулиране на въпрос, повторни запитвания или натискане на бутон за опит отново. Например ако виждате, че потребителите повтарят един и същи въпрос, това е знак, че агентът не работи както се очаква.
Точност: Колко често агентът произвежда правилни или желани резултати? Дефинициите за точност варират (например правилност при решаване на проблеми, точност при извличане на информация, удовлетвореност на потребителя). Първата стъпка е да дефинирате как изглежда успехът за вашия агент. Можете да проследявате точността чрез автоматизирани проверки, оценъчни резултати или маркиране на изпълнения като завършени задачи. Например маркиране на трейсове като “succeeded” или “failed”.
Автоматизирани метрики за оценка: Можете също да настроите автоматизирани оценки. Например можете да използвате LLM за оценка на изхода на агента, напр. дали е полезен, точен или не. Съществуват и няколко отворени библиотеки с код с които можете да оцените различни аспекти на агента. Например RAGAS за RAG агенти или LLM Guard за откриване на вреден език или prompt injection.
На практика комбинация от тези метрики дава най-добро покритие на здравето на 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 процесите) за проверка на подобрения или за предпазване от регресии. Предимството е, че е повторима и можете да получите ясни метрики за точност, тъй като имате ground truth. Можете също да симулирате потребителски запитвания и да измерите отговорите на агента спрямо идеални отговори или да използвате автоматизирани метрики, описани по-горе.
Ключовото предизвикателство при офлайн оценката е да осигурите, че вашият тестов набор е пълен и остава релевантен – агентът може да се представя добре на фиксиран тестов набор, но да среща много различни запитвания в продукция. Следователно трябва да поддържате обновяване на тестовите множества с нови крайни случаи и примери, които отразяват реални сценарии. Смес от малки „smoke test“ случаи и по-големи оценъчни множества е полезна: малки множества за бързи проверки и по-големи за по-широки метрики за представяне.

Това се отнася до оценяване на агента в жива, реална среда, т.е. по време на реална употреба в продукция. Онлайн оценката включва наблюдение на представянето на агента при реални потребителски взаимодействия и непрекъснат анализ на резултатите.
Например можете да проследявате нива на успех, оценките за удовлетвореност на потребителите или други метрики на жив трафик. Предимството на онлайн оценката е, че тя улавя неща, които може да не предвидите в лабораторна обстановка – можете да наблюдавате дрейф на модела с течение на времето (ако ефективността на агента намалява, докато моделът среща различни входни модели) и да хванете неочаквани запитвания или ситуации, които не са били в тестовите ви данни. Тя предоставя истинска картина за това как агентът се държи в реални условия.
Онлайн оценката често включва събиране на неявна и явна потребителска обратна връзка, както бе обсъдено, и евентуално провеждане на shadow тестове или A/B тестове (където нова версия на агента работи паралелно за сравнение с предишната). Предизвикателството е, че може да бъде трудно да получите надеждни етикети или оценки за живи взаимодействия – може да разчитате на обратната връзка на потребителите или на производни метрики (например дали потребителят е кликнал резултата).
Онлайн и офлайн оценките не са взаимно изключващи се; те се допълват взаимно. Прозренията от онлайн мониторинга (напр. нови типове потребителски запитвания, където агентът се представя слабо) могат да се използват за обогатяване и подобрение на офлайн тестовите множества. Обратно, агенти, които се представят добре в офлайн тестове, могат по-уверено да бъдат внедрени и следени онлайн.
Всъщност много екипи възприемат цикъл:
оценявайте офлайн -> внедрявайте -> наблюдавайте онлайн -> събирайте нови случаи на грешки -> добавяйте към офлайн набора -> усъвършенствайте агента -> повтаряйте.
Когато внедрявате AI агенти в продукция, може да срещнете различни предизвикателства. Ето някои общи проблеми и техните потенциални решения:
| Проблем | Възможно решение |
|---|---|
| AI Agent not performing tasks consistently | - Прецизирайте подсказката, дадена на AI агента; бъдете ясни относно целите. - Идентифицирайте къде разделянето на задачите на подзадачи и обработката им от няколко агента може да помогне. |
| AI Agent running into continuous loops | - Уверете се, че имате ясни условия за прекратяване, за да знае агентът кога да спре процеса. - За сложни задачи, изискващи разсъждение и планиране, използвайте по-голям модел, специализиран за задачи с разсъждение. |
| AI Agent tool calls are not performing well | - Тествайте и валидирайте изхода на инструмента извън системата на агента. - Прецизирайте дефинираните параметри, подсказките и именуването на инструментите. |
| Multi-Agent system not performing consistently | - Прецизирайте подсказките, дадени на всеки агент, за да сте сигурни, че са специфични и различни един от друг. - Изградете йерархична система, използвайки „routing“ или контролиращ агент, за да определите кой агент е правилният. |
Много от тези проблеми могат да бъдат идентифицирани по-ефективно с налична наблюдаемост. Трейсовете и метриките, които обсъдихме по-горе, помагат точно да се посочи къде в работния поток на агента възникват проблемите, което прави отстраняването на грешки и оптимизацията много по-ефективни.
Ето някои стратегии за управление на разходите при внедряване на AI агенти в продукция:
Използване на по-малки модели: Малките езикови модели (SLMs) могат да работят добре при определени агентни случаи на употреба и значително да намалят разходите. Както беше споменато по-рано, изграждането на система за оценка, която да определя и сравнява представянето спрямо по-големите модели, е най-добрият начин да разберете колко добре SLM ще се представи за вашия случай на употреба. Помислете за използване на SLMs за по-прости задачи като класификация на намеренията или извличане на параметри, като запазите по-големите модели за сложни задачи за разсъждение.
Използване на маршрутизиращ модел: Подобна стратегия е да използвате разнообразие от модели и размери. Можете да използвате LLM/SLM или serverless функция, за да маршрутизирате заявките въз основа на сложността към най-подходящите модели. Това също ще помогне за намаляване на разходите, като същевременно гарантира представяне при правилните задачи. Например, маршрутизирайте простите заявки към по-малки и по-бързи модели, и използвайте скъпите големи модели само за сложни задачи за разсъждение.
Кеширане на отговори: Идентифицирането на често срещани заявки и задачи и предоставянето на отговорите преди те да преминат през вашата агентна система е добър начин за намаляване на обема на подобните заявки. Можете дори да имплементирате поток за определяне колко сходна е дадена заявка с кешираните ви заявки, използвайки по-прости AI модели. Тази стратегия може значително да намали разходите за често задавани въпроси или общи работни потоци.
В примерния бележник от този раздел, ще видим примери за това как можем да използваме инструменти за наблюдаемост, за да наблюдаваме и оценяваме нашия агент.
Присъединете се към Microsoft Foundry Discord, за да се срещнете с други участници, да посещавате консултации и да получите отговори на въпросите си за AI агенти.
Дизайнерски шаблон за метакогниция
Отказ от отговорност: Този документ е преведен с помощта на AI преводаческа услуга Co-op Translator. Въпреки че се стремим към точност, имайте предвид, че автоматизираните преводи могат да съдържат грешки или неточности. Оригиналният документ на оригиналния език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Не носим отговорност за каквито и да е недоразумения или погрешни тълкувания, произтичащи от използването на този превод.