ai-agents-for-beginners
AI агенти в продукция: Наблюдаемост & Оценка
С преминаването на AI агентите от експериментални прототипи към приложения в реалния свят, става важно да се разбира тяхното поведение, да се следи тяхната производителност и системно да се оценяват техните резултати.
Цели за учене
След завършване на този урок, ще знаете как да/ще разберете:
- Основните концепции за наблюдаемостта и оценката на агенти
- Техники за подобряване на производителността, разходите и ефективността на агентите
- Какво и как да оценявате вашите AI агенти систематично
- Как да контролирате разходите при пускане на AI агенти в продукция
- Как да инстрментирате агенти, изградени с Microsoft Agent Framework
Целта е да ви дадем знанията да трансформирате вашите „черни кутии“ агенти в прозрачни, управляеми и надеждни системи.
Бележка: Важно е да се пускат AI агенти, които са безопасни и надеждни. Вижте и урока Създаване на надеждни AI агенти.
Траквания и спанове
Инструментите за наблюдаемост като Langfuse или Microsoft 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 спанове към инструмент за наблюдаемост. 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"):
# Agent execution is traced automatically
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 агенти в продукция:
Използване на по-малки модели: Малките езикови модели (SLMs) могат да се представят добре при определени агентски случаи на употреба и значително ще намалят разходите. Както беше споменато по-рано, изграждането на система за оценка, която да определи и сравни представянето спрямо по-големи модели, е най-добрият начин да разберете колко добре ще се представи SLM във вашия случай на употреба. Помислете за използването на SLM за по-прости задачи като класификация на намерения или извличане на параметри, като същевременно запазите по-големи модели за сложни разсъждения.
Използване на маршрутизиращ модел: Подобна стратегия е да се използва разнообразие от модели и размери. Можете да използвате LLM/SLM или безсървърна функция за маршрутизиране на заявките в зависимост от сложността към най-подходящите модели. Това също ще помогне за намаляване на разходите, като същевременно осигурява изпълнение на правилните задачи. Например, насочвайте прости заявки към по-малки, по-бързи модели и използвайте скъпи големи модели само за задачи със сложни разсъждения.
Кеширане на отговори: Идентифицирането на често срещани заявки и задачи и предоставянето на отговорите преди те да преминат през вашата агентска система е добър начин да намалите обема на подобни заявки. Можете дори да реализирате поток за идентифициране на това колко сходна е една заявка с вашите кеширани заявки, използвайки по-прости AI модели. Тази стратегия може значително да намали разходите за често задавани въпроси или обичайни работни потоци.
Нека видим как това работи на практика
В примерния бележник на този раздел ще видим примери за това как можем да използваме инструменти за наблюдение, за да следим и оценяваме нашия агент.
Имаш още въпроси за AI агентите в продукция?
Присъедини се към Microsoft Foundry Discord, за да се срещнеш с други учащи се, да посещаваш консултации и да получиш отговори на въпросите си за AI агенти.
Предишен урок
Дизайнерски модел Метакогниция
Следващ урок
Отказ от отговорност: Този документ е преведен с помощта на AI преводачески услуга Co-op Translator. Въпреки че се стремим към точност, моля имайте предвид, че автоматизираните преводи могат да съдържат грешки или неточности. Оригиналният документ на неговия роден език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Ние не носим отговорност за каквито и да е недоразумения или неправилни тълкувания, произтичащи от използването на този превод.