ai-agents-for-beginners
AI Agents in Production: Опсервабилност и Евалуација
Како AI агенти прелазе из експерименталних прототипова у реалне примене, постаје важно разумевање њиховог понашања, праћење перформанси и систематска евалуација њихових излаза.
Циљеви учења
Након завршетка ове лекције, знаћеш како/ћеш разумети:
- Основне концепте опсервабилности и евалуације агената
- Технике за побољшање перформанси, трошкова и ефикасности агената
- Шта и како систематски евалуирати своје AI агенте
- Како контролисати трошкове при продукцијском коришћењу AI агената
- Како instrument-овати агенте изграђене помоћу Microsoft Agent Framework
Циљ је да те опремимо знањем које ће трансформисати твоје „црне кутије“ агенте у транспарентне, управљиве и поуздане системе.
Напомена: Важно је деплојовати AI агенте који су безбедни и поуздани. Погледај и лекцију Building Trustworthy AI Agents.
Трејсови и спанови
Алати за опсервабилност као што су Langfuse или Microsoft Foundry обично представљају покрете агента као traces и spans.
- Trace представља комплетан задатак агента од почетка до краја (нпр. обрада корисничког упита).
- Spans су појединачни кораци унутар trace-а (нпр. позив ка language моделу или преузимање података).
Без опсервабилности, AI агент може деловати као „црна кутија“ — његово унутрашње стање и разлогање су непрозирни, што отежава дијагностику проблема или оптимизацију перформанси. Са опсервабилношћу, агенти постају „стаклене кутије,“ пружајући транспарентност која је кључна за изградњу поверења и осигурање да раде како је предвиђено.
Зашто опсервабилност значи у продукцијским окружењима
Прекид увођења AI агената у продукциона окружења уводи нови скуп изазова и захтева. Опсервабилност више није „пожељна“ већ критична способност:
- Дебаговање и анализа коренског узрока: Када агент не успе или произведе неочекиван излаз, алати за опсервабилност пружају trace-ове потребне да се прецизно одреди извор грешке. Ово је посебно важно у сложеним агентима који могу укључивати више LLM позива, интеракција са алатима и условну логику.
- Управљање латенцијом и трошковима: AI агенти често зависе од LLM-ова и других спољних API-ја који се наплаћују по токену или позиву. Опсервабилност омогућава прецизно праћење тих позива, помажући у идентификацији операција које су прекомерно споре или скупе. То омогућава тимовима да оптимизују prompt-ове, одаберу ефикасније моделе или редизајнирају токове рада ради управљања оперативним трошковима и обезбеђивања бољег корисничког искуства.
- Поверење, безбедност и усаглашеност: У многим апликацијама важно је осигурати да се агенти понашају сигурно и етично. Опсервабилност пружа ревизиони траг акција и одлука агента. Ово се може користити за детекцију и ублажавање проблема као што су prompt injection, генерисање штетног садржаја или неправилно руковање лично идентификовљивим информацијама (PII). На пример, можете прегледати traces да бисте разумели зашто је агент дао одређен одговор или користио специфичан алат.
- Континуирани циклуси побољшања: Податке из опсервабилности представљају основу итеративног развојног процеса. Праћењем перформанси агената у реалном свету, тимови могу идентификовати области за побољшање, прикупити податке за дофајновање модела и валидацију утицаја промена. То ствара петљу повратне информације где утицаји из продукције добијени кроз online евалуацију информишу offline експериментисање и дораду, водећи до прогресивног побољшања перформанси агента.
Кључне метрике које треба пратити
За праћење и разумевање понашања агента, потребно је пратити низ метрика и сигнала. Иако специфичне метрике могу варирати у зависности од сврхе агента, неке су универзално важне.
Ево неких од најчешћих метрика које алати за опсервабилност надгледају:
Latency: Колико брзо агент одговара? Дуге чекања негативно утичу на корисничко искуство. Треба мерити латенцију за задатке и појединачне кораке праћењем покрета агента. На пример, агент који троши 20 секунди на све позиве модела може се убрзати коришћењем бржег модела или извршавањем позива модела паралелно.
Costs: Колико кошта по покретању агента? AI агенти зависе од LLM позива који се наплаћују по токену или спољних API-ја. Честа употреба алата или више prompt-ова може брзо повећати трошкове. На пример, ако агент позове LLM пет пута за минимално побољшање квалитета, мораћете оценити да ли је трошак оправдан или да ли можете смањити број позива или користити јефтинији модел. Надгледање у реалном времену такође може помоћи у идентификацији неочекиваних пораста (нпр. багови који изазивају прекомерне API циклусе).
Request Errors: Колико захтева је агент не успео да обради? Ово може укључивати API грешке или неуспеле позиве алата. Да бисте свој агент учинили робуснијим у продукцији, можете онда поставити fallback-ове или покушаје поново (retries). Нпр. ако LLM провајдер A није доступан, пребаците се на LLM провајдера B као резерву.
User Feedback: Имплементирање директних корисничких евалуација пружа вредне увиде. Ово може укључивати експлицитне оцене (👍thumbs-up/👎down, ⭐1-5 звездица) или текстуалне коментаре. Конзистентно негативне повратне информације треба да вас упозоре јер су знак да агент не ради како се очекује.
Implicit User Feedback: Понашања корисника пружају индиректну повратну информацију чак и без експлицитних оцена. Ово може укључивати тренутно преписивање питања, понављање упита или кликање на дугме за поновни покушај. Нпр. ако видите да корисници понављају исто питање, то је знак да агент не ради како се очекује.
Accuracy: Колико често агент производи исправне или пожељне излазе? Дефиниције тачности варирају (нпр. исправност решавања проблема, тачност извлачења информација, задовољство корисника). Први корак је дефинисање како изгледа успех за вашег агента. Можете пратити тачност помоћу аутоматизованих провера, оценских скалa или ознака завршетка задатка. На пример, означавање trace-ова као “succeeded” или “failed”.
Automated Evaluation Metrics: Такође можете поставити аутоматизоване евалуације. На пример, можете користити LLM да оцењује излаз агента нпр. да ли је користан, тачан или није. Постоје и неколико open source библиотека које помажу да оцените различите аспекте агента. Нпр. RAGAS за RAG агенте или LLM Guard за детекцију штетног језика или prompt injection.
У пракси, комбинација ових метрика даје најбоље покриће здравља AI агента. У овом поглављу example notebook, показаћемо вам како ове метрике изгледају у реалним примерима али прво ћемо научити како изгледа типичан процес евалуације.
Instrumentујте свог Агента
Да бисте прикупили податке за праћење (tracing), потребно је instrument-овати свој код. Циљ је instrument-овати код агента да емитује traces и метрике које може да ухвати, обради и визуелизује платформа за опсервабилност.
OpenTelemetry (OTel): OpenTelemetry се појавио као индустријски стандард за опсервабилност LLM-ова. Он пружа скуп API-ја, SDK-ова и алата за генерисање, прикупљање и експортирање телеметријских података.
Постоји много библиотека за instrument-овање које обмотавају постојеће оквире за агенте и олакшавају извоз OpenTelemetry span-ова у алат за опсервабилност. Microsoft Agent Framework се интегрише са OpenTelemetry-ом нативно. Испод је пример instrument-овања 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
The example notebook in this chapter will demonstrate how to instrument your MAF agent.
Manual Span Creation: Док библиотеке за instrument-овање пружају добру основу, често постоје случајеви где су потребне детаљније или прилагођене информације. Можете ручно креирати spans да бисте додали прилагођену апликациону логику. Још важније, они могу обогатити аутоматски или ручно креиране spans прилагођеним атрибутима (познатим и као тагови или метаподаци). Ови атрибути могу укључивати пословно-специфичне податке, међукораке обртања или било који контекст који би могао бити користан за дебаговање или анализу, као што су user_id, session_id, или model_version.
Пример руског креирања traces и spans ручно са Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
Евалуација Агента
Опсервабилност нам даје метрике, али евалуација је процес анализе тих података (и извођења тестова) да се утврди колико добро AI агент ради и како се може побољшати. Другим речима, када имате те traces и метрике, како их користите да бисте судили о агенту и донели одлуке?
Редовна евалуација је важна јер су AI агенти често недетерминистички и могу еволуирати (кроз ажурирања или drifting понашања модела) – без евалуације, не бисте знали да ли ваш „паметни агент“ заправо ради свој посао добро или је деградирао.
Постоје две категорије евалуација за AI агенте: online евалуација и offline евалуација. Оба су вредна и допуњују се. Обично почињемо са offline евалуацијом, јер је то минимални неопходни корак пре деплоја било ког агента.
Offline евалуација
Ово подразумева евалуацију агента у контролисаном окружењу, обично користећи test скуп података, а не живе корисничке упите. Користите куриране скупове података где знате који је очекивани излаз или исправно понашање, и онда покрећете свог агента на тим скуповима.
На пример, ако сте направили агента за решавање математичких задатака у речима, можда имате test dataset од 100 задатака са познатим одговорима. Offline евалуација се често ради током развоја (и може бити део CI/CD цевовода) да би се проверила побољшања или спречиле регресије. Предност је што је поновљиво и можете добити јасне метрике тачности пошто имате ground truth. Такође можете симулирати корисничке упите и мерити одговоре агента у односу на идеалне одговоре или користити аутоматизоване метрике као што је описано горе.
Кључни изазов са offline евалуацијом је осигурање да је ваш test скуп података свеобухватан и да остаје релевантан – агент може добро радити на фиксном test скупу али наићи на веома различите упите у продукцији. Стога треба држати скупове тестова ажурним са новим ивица случајева и примерима који одражавају реалне сценарије. Корисна је комбинација малих „smoke test“ случајева и већих евалуационих сетова: мали сетови за брзе провере и већи за ширу метрику перформанси.
Online евалуација
Ово се односи на евалуацију агента у живом, реалном окружењу, тј. током стварног коришћења у продукцији. Online евалуација укључује праћење перформанси агента на стварним корисничким интеракцијама и континуирано анализирање исхода.
На пример, можете пратити стопе успеха, оцене задовољства корисника или друге метрике на живом саобраћају. Предност online евалуације је што ухвата ствари које можда не предвидите у лабораторијском окружењу – можете уочити drift модела током времена (ако се ефикасност агента смањи како се обрасци уноса мењају) и ухватити неочекиване упите или ситуације које нису биле у вашим тест подацима. Она пружа истинску слику како се агент понаша у дивљини.
Online евалуација често укључује прикупљање имплицитних и експлицитних повратних информација корисника, као што је описано, и евентуално покретање shadow тестова или A/B тестова (где нова верзија агента ради паралелно да би се упоредила са старом). Изазов је што може бити тешко добити поуздане ознаке или оцене за живе интеракције – можда ћете се ослањати на повратне информације корисника или downstream метрике (нпр. да ли је корисник кликнуо резултат).
Комбинација оба
Online и offline евалуације нису узајамно искључиве; оне се снажно допуњују. Увид из online праћења (нпр. нови типови корисничких упита где агент слабо ради) може се користити за допуну и побољшање offline тест скупова. Насупрот томе, агенти који добро пролазе offline тестове могу тада бити са више самопоуздања деплојовани и праћени online.
Заправо, многи тимови усвајају петљу:
evaluiraj offline -> deploy -> мониториши online -> прикупи нове случајеве неуспеха -> додај у offline скуп -> унаприједи агента -> понављај.
Уобичајени проблеми
Када деплојујете AI агенте у продукцију, можете се сусрести са разним изазовима. Ево неких уобичајених проблема и потенцијалних решења:
| Проблем | Могуће решење |
|---|---|
| AI Agent не извршава задатке конзистентно | - Префинишите prompt дат агенту; будите јасни у погледу циљева. - Идентификујте где деоба задатака на подсегменте и обрада од стране више агената може помоћи. |
| AI Agent упада у континуиране петље | - Осигурајте да имате јасне услове за прекид и заустављање процеса тако да агент зна када да заврши. - За сложене задатке који захтевају закључивање и планирање, користите већи модел који је специјализован за задатке расуђивања. |
| Pozivi алата AI агента не раде добро | - Тестирајте и верификујте излаз алата ван система агента. - Префинишите дефинисане параметре, prompt-ове и именовање алата. |
| Multi-Agent систем не ради конзистентно | - Префинишите prompt-ове дате сваком агенту како бисте осигурали да су специфични и различити међу собом. - Изградите хијерархијски систем користећи „routing“ или контролер агента да одреди који агент је исправан. |
Многи од ових проблема могу се ефикасније идентификовати уз увођење опсервабилности. Trace-ови и метрике које смо раније описали помажу да се прецизно одреди где у току рада агента настају проблеми, чинећи дебаговање и оптимизацију много ефикаснијим.
Управљање трошковима
Ево неких стратегија за управљање трошковима развоја AI агената у продукцији:
Користите мање моделе: Small Language Models (SLMs) могу добро да раде у одређеним агентским случајевима употребе и значајно смање трошкове. Као што је раније поменуто, израда система за евалуацију који одређује и упоређује перформансе у односу на веће моделе најбољи је начин да се схвати колико ће добро an SLM функционисати у вашем случају употребе. Размислите о коришћењу SLMs за једноставније задатке као што су класификација намере или издвајање параметара, док остављате веће моделе за сложено размишљање.
Користите модел рутирања: Слична стратегија је коришћење различитих модела и величина. Можете користити LLM/SLM или безсерверску (serverless) функцију за усмеравање захтева на најприкладније моделе у складу са сложеношћу. Ово ће помоћи и смањењу трошкова, а истовремено обезбедити перформансе за одговарајуће задатке. На пример, усмерите једноставне упите ка мањим, бржим моделима и користите скупе велике моделе само за задатке сложеног резоновања.
Кеширање одговора: Идентификација уобичајених захтева и задатака и пружање одговора пре него што прођу кроз ваш агентски систем је добар начин да се смањи обим сличних захтева. Можете чак имплементирати ток који ће одредити колико је захтев сличан кешираним захтевима користећи основније AI моделе. Ова стратегија може значајно смањити трошкове за често постављана питања или уобичајене токове рада.
Хајде да видимо како ово функционише у пракси
У пример бележнице ове секције, видећемо примере како можемо користити алате за опсервабилност (observability) да пратимо и оцењујемо нашег агента.
Имате још питања о AI агентима у продукцији?
Придружите се Microsoft Foundry Discord да упознате друге учеснике, присуствујете консултативним сатима и добијете одговоре на питања о вашим AI агентима.
Претходна лекција
Следећа лекција
Одрицање од одговорности: Овај документ је преведен помоћу сервиса за превођење вођеног вештачком интелигенцијом Co-op Translator. Иако настојимо да превод буде тачан, имајте у виду да аутоматски преводи могу да садрже грешке или нетачности. Оригинални документ на његовом изворном језику треба сматрати званичним извором. За критичне информације препоручује се ангажовање професионалног преводиоца. Не сносимо одговорност за било какве неспоразуме или погрешна тумачења која произилазе из употребе овог превода.