Как да оценявате AI агенти: тестови набори, оценители и регресионни проверки

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

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

Какво означава да оцените ИИ агент?

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

Представете си ИИ агент за снабдяване в производствен завод, който проверява наличността на резервни части и подготвя заявки за попълване на запасите. Ако одобрена част не е налична или информацията за доставчика е остаряла, дали агентът ще сигнализира за проблема, или ще препоръча неодобрен заместител?

А ако промените системния му промпт, за да отстраните този проблем, как да сте сигурни, че не сте създали нов?

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

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

• Качеството на крайния резултат
• Информацията, която агентът е използвал
• Инструментите, които е извикал
• Дали е спазил правилата, които уреждат поведението му

Често използвани метрики за оценяване на ИИ агенти

Оценките работят с качествени и количествени данни. Качественото оценяване ви помага да разберете какво се случва и защо, включително чрез ръчен преглед на решенията на агента. Количественото оценяване превръща тези наблюдения в измерими сигнали – например преброяване колко често се срещат конкретни типове грешки или изчисляване на процента успешно изпълнени задачи.

Ето списъка с основните метрики за оценяване на ИИ агенти:

• Успешността на задачата измерва дали агентът е постигнал желания резултат; обикновено се изразява като процент от изпълненията, които дават валидни резултати.
• Коректността на действията измерва дали агентът е използвал инструментите по подходящ начин, избрал е валидни аргументи и е спазил разрешенията.
• Качеството на отговора оценява дали крайният резултат е точен, пълен и полезен. То може да включва фактическа точност, спазване на инструкциите и дали агентът обосновава решенията си с наличната информация.
• Надеждността измерва последователността при повторни опити, различни входни данни и гранични случаи.
• Цената и латентността измерват ресурсите, необходими за постигане на успешен резултат, включително времето за изпълнение, потреблението на токени и извикванията на инструменти.

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

Стъпка 1: Определете как изглежда успешното изпълнение на агента

Първо, опишете изрично какво трябва да постигне агентът – продуктовите изисквания. Звучи очевидно, но може да се окаже изненадващо трудно. Дори има име за това: пропастта в спецификацията.

Ето как да подходите според Andrey Khomutov, старши специалист по данни в нашия екип:

„Започнете с два въпроса: „Какво би се считало за свършена работа?“ и „Какво би направило едно привидно успешно изпълнение неприемливо?“

При агентите, от техническа гледна точка, това означава да се проверява както резултатът, така и начинът, по който агентът е стигнал до него.“

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

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

След това включете експерт в съответната област, който да валидира критериите ви за успех. Хората с практически познания в областта могат да преценят дали условията, които сме поставили на ИИ агента, отразяват успешен резултат.

Стъпка 2. Създайте тестов набор от реални задачи и грешки

Разгледайте реалното поведение на агента, за да разберете как изглежда доброто и лошото представяне. Устоявайте на изкушението да започнете с генериране на десетки тестове, базирани единствено на предположенията ви какво може да се обърка.

Hamel Husain, ML инженер в Parlance Lab, и Shreya Shankar, изследовател в областта на ML системите и оценките на приложния ИИ, препоръчват да се започне с анализ на грешките – техника, заимствана от машинното обучение и науката за данните. Процесът започва с качествен анализ на трасетата на изпълнение на агента – записи, които показват входа от потребителя, извикванията на инструменти, извлечената информация и изхода на агента.

1. Прегледайте отделните трасета и анотирайте грешките (отворено кодиране). Нека експерт в областта прегледа изпълненията на агента и запише кратки наблюдения за това какво се е объркало. Съсредоточете се върху първата съществена грешка.
2. Групирайте наблюденията по типове грешки (аксиално кодиране). След като съберете достатъчно бележки, използвайте LLM, който да предложи категории за сходните грешки. Те могат да включват препоръки за несъвместими части, неточно извличане на данни за наличностите и неуспешно предаване на случая на човек.
3. Пребройте случаите. Отнесете всяко наблюдение към категория, след което използвайте електронна таблица или обобщена таблица, за да изчислите колко често се среща всеки тип грешка.
4. Приоритизирайте какво да отстраните, като вземете предвид както честотата, така и сериозността.
5. Превърнете важните грешки в тестови случаи. Запазете съответните входни данни, началните условия, очаквания резултат и критериите за оценяване, така че агентът да може да бъде тестван отново по същия сценарий.

Колко трасета трябва да прегледате? Приблизително 100, но няма магическо число. Спрете по-рано, щом достигнете теоретично насищане: момента, в който прегледът на допълнителни трасета вече не разкрива съществени нови модели на грешки.

Все още не сте пуснали приложението? Синтетичните примери могат да помогнат за изграждането на първоначален тестов набор, но реалните потребителски данни трябва да се използват за него веднага щом станат налични.

Използването на бенчмаркове при оценяването на ИИ агенти

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

Но бенчмарковете не са безпогрешни. Одитите на SWE-bench, прегледите на бенчмаркове от Epoch AI и верните отговори, първоначално отхвърлени в TheoPhysEval, показват как дефектни задачи или очаквани отговори могат да изкривят резултатите от оценяването.

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

Стъпка 3. Изпълнете агента във възпроизводима тестова среда

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

Можете да започнете, като съхранявате представителни входни данни като JSON файлове и използвате Python скрипт, за да изпълните работния процес на агента и да проверите изходите му с проверки (assertions). За агента за наличности в нашия производствен завод възпроизводимата тестова среда може да изглежда така:

Уголеми

За да настроите възпроизводима тестова среда, следвайте тези стъпки:

1. Запазете представителни входни данни. Съхранявайте реални събития или тестови случаи в същата структура, в която приложението ви ги получава в продукционна среда. В нашия сценарий бихте запазили като JSON файл заявка за поддръжка, съдържаща ID на машината, необходимата резервна част и датата на поддръжката, заедно с моментна снимка на данните за наличностите и одобрените части.
2. Изпълнете работния процес. Прекарайте всеки вход през агента, включително стъпките му за извличане на информация, извикванията на инструменти и генерирането на отговор.
3. Запишете резултата и трасето. Запазете крайния изход и съответните междинни действия (например справки за наличности), за да виждате не само дали агентът се е провалил, но и къде.
4. Повтаряйте случаите в зависимост от сериозността и честотата на грешката и от това колко трудно се отстранява проблемът. LLM приложенията са недетерминистични (могат да дават различни резултати при идентични входни данни), така че едно успешно изпълнение не гарантира, че и следващото ще бъде успешно. Отчитайте дела на успешните опити и проучвайте неуспешните.

За последното Khomutov съветва да се измерват pass@1 (колко често агентът успява от първия опит) и pass@k (вероятността да успее поне веднъж в рамките на определен брой опити). Ако отчитате pass@k, посочете броя на опитите, тъй като получаването на един верен отговор сред няколко не означава, че агентът знае кой от тях да избере.

С разрастването на приложението ви използвайте тестова рамка като pytest, за да организирате и изпълнявате тестовете, и обмислете съхраняването на големи тестови набори от данни и резултати в база данни.

Стъпка 4. Изберете подходящия оценител за всяка проверка

Оценителят (grader, често наричан също evaluator) е механизъм под формата на част от код, LLM, ръководен от рубрика за оценяване, или човек рецензент, който проверява изхода или действието на агента спрямо определен критерий. Оценителят връща преценка „успешно/неуспешно“ и обяснение, посочващо съответните доказателства.

Информация: Рубриката за оценяване е набор от критерии и инструкции, които определят какво се счита за правилен или приемлив резултат.

Правилният тип оценител зависи от това какво се опитвате да проверите. Ето как се сравняват трите подхода:

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

Как се комбинират оценители?

Задайте си въпроса: „Може ли резултатът да бъде проверен спрямо известно правило или очаквана стойност, или изисква преценка, подобна на човешката?“

• Ако можете да проверите резултата точно, започнете с оценител, базиран на код. Оценителите, базирани на код, могат също да проверяват структурирани изходи, валидни стойности на полета, аргументи на инструменти или крайното състояние на база данни.
• Ако проверката изисква тълкуване на контекста, използвайте LLM като съдия.
• Използвайте хора рецензенти за специфични за областта или спорни решения.

Важно! LLM оценителят може да изтълкува погрешно доказателствата или да приложи рубриката неправилно. Затова е нужна допълнителна стъпка на оценяване: калибриране спрямо човешките преценки.

Калибрирайте LLM оценителя спрямо човешките преценки.

По същество калибрирането изисква експерт в областта да оцени реални изпълнения на агента. След това експертът сравнява своите преценки с тези на LLM и прецизира рубриката за оценяване въз основа на разминаванията.

Ето процес за калибриране на оценителя в пет стъпки:

1. Съберете примери за входни данни, изходи и съответните трасета на агента.
2. Нека експерт в областта прецени независимо дали всеки пример отговаря на критерия за оценяване.
3. Изпълнете LLM оценителя върху тези примери.
4. Сравнете преценките на човека и на модела.
5. Проучете разминаванията и прецизирайте рубриката на оценителя, преди да го тествате върху нови примери.

Khomutov подчертава и колко е важно последователността на LLM оценителя да се тества отделно:

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

Ако един и същ изход получава различни присъди, не приемайте, че всяка промяна в оценката идва от агента. Вместо това разгледайте матрица на объркването, която показва кога оценителят правилно е разпознал грешки, кога ги е пропуснал и кога неправилно е маркирал приемливи изходи.

Човешкият преглед остава от съществено значение за установяване на референтни преценки, разрешаване на спорни случаи и откриване на нови типове грешки, за чието разпознаване съществуващите оценители не са проектирани.

Стъпка 5. Сравнете версиите и изпълнете регресионни проверки

Да предположим, че анализът на грешките показва, че вашият агент за наличности често препоръчва неодобрени резервни части. Променяте системния му промпт така, че да изисква изрична проверка за съвместимост. Първоначално неуспешният случай вече преминава. Но как да сте сигурни, че промяната не е засегнала други задачи?

Тук на помощ идва регресионното тестване.

Регресионното тестване означава повторно изпълнение на вече успешни тестови случаи след промяна на промпта, модела или работния процес на агента, за да се уверите, че промяната не е довела до нови грешки.

1. Възпроизведете първоначалната грешка, като използвате запазени входни данни от тестовия набор.
2. Направете целенасочена промяна в промпта, модела или работния процес.
3. Изпълнете отново неуспешния тест, за да проверите дали проблемът е решен.
4. Изпълнете останалите тестове, за да се уверите, че промяната не е нарушила поведението, което досега е работило успешно.
5. Прегледайте резултатите и проучете всички нови неуспехи.

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

Стъпка 6: Наблюдавайте представянето на AI агента в продукционна среда

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

Това е известно като онлайн оценяване и е част от по-широк процес на наблюдение в продукционна среда, който помага да се откриват повтарящи се и неизвестни досега неуспехи.

Процесът е итеративен и включва четири взаимно допълващи се дейности:

• Прилагайте калибрирани LLM съдии върху продукционни трасировки. Вземете извадка от реални взаимодействия с агента и приложете оценителите, които вече сте валидирали спрямо човешки преценки.
• Проследявайте процента на неуспехите във времето. Използвайте категориите неуспехи, установени при анализа на грешките, за да измерите количествено повтарящите се проблеми.
• Продължавайте да преглеждате трасировките ръчно. Автоматизираните оценители откриват само проблемите, за чието откриване са създадени. Преглеждайте ръчно извадки от реални взаимодействия с агента, за да откриете нови грешки или необичайни потребителски заявки.
• Използвайте A/B тестове, за да измервате бизнес резултатите (само когато е уместно). Сравнявайте различни промптове, модели или работни процеси с помощта на показатели като изпълнение на задачите, удовлетвореност на потребителите и време до разрешаване. Този процес помага да се определи дали дадена промяна подобрява реалното изживяване с продукта, а не само дали преминава отделни тестове.

Една важна бележка: оценките не е нужно да са изпипани до съвършенство. Те просто трябва да са достатъчно добри, за да подобрят продукта ви.

Често срещани заблуди при оценяването на AI агенти

• Оценките са просто модулни тестове. Не са; модулните тестове са малки автоматизирани проверки, които са само една част от оценяването. Оценките включват също качествен анализ на грешките, човешки преценки, наблюдение в продукционна среда и експерименти за измерване на качеството на приложението.
• Една платформа за оценяване може да свърши всичко вместо вас. Готовите инструменти могат да автоматизират някои проверки, но не могат да определят кои видове неуспехи (типове грешки или нежелано поведение на агента) са важни за вашия продукт.
• Можете да оставите LLM да оценява всичко. Това е голяма заблуда. Анализът на грешките, воден от хора, и калибрирането на оценителите остават от съществено значение, тъй като LLM моделите нямат бизнес контекста, необходим за откриването на всеки проблем.
• A/B тестовете или просто използването на агента заместват оценките. Невярно. A/B тестовете могат да покажат коя версия се представя по-добре спрямо избрани показатели, но сами по себе си не могат да обяснят основните проблеми.

Често задавани въпроси за оценяването на AI агенти

1. Каква е разликата между оценяването на AI агенти и оценяването на LLM?

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

За разлика от типичното оценяване на LLM, оценяването на агенти разглежда както крайния резултат, така и последователността от действия, предприети за постигането му, включително извикванията на инструменти, взетите решения и спазването на предварително определени правила.

2. Ключови показатели за оценяване на AI агенти

Показателите за оценяване на AI агенти попадат в две широки категории:

• Показатели за техническа ефективност: Процент на успешно изпълнени задачи, коректност на действията, качество на отговорите, надеждност (pass@1 и pass@k), латентност, използване на токени и цена на успешно изпълнена задача.
• Показатели за бизнеса и потребителското изживяване: Удовлетвореност на клиентите (CSAT), процент на разрешени проблеми, процент на ескалации, коефициент на конверсия, време за изпълнение на задачите и други резултати, специфични за ролята на агента.

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

Правилните показатели трябва да отразяват както колко надеждно работи агентът, така и дали работата му подобрява бизнес резултатите.

3. Кои са най-добрите инструменти за оценяване на AI агенти?

Сред най-често използваните варианти са:

• Рамки за тестване: Проверките (assertions) в Python и pytest са полезни за изпълнение на повторяеми тестови случаи и проверка на точни условия, например дали агентът е избрал правилния инструмент или е върнал валиден идентификатор на част.
• Рамки за оценяване на AI агенти: DeepEval и инструментариумът agent-eval на Google поддържат по-сложни оценявания, включително трасировки на изпълнението, оценители, базирани на LLM, и автоматизирано регресионно тестване.
• Платформи за оценяване и наблюдаемост: LangSmith, Arize Phoenix и MLflow помагат на екипите да анализират поведението на агентите, да управляват набори от данни за оценяване, да сравняват версии на агентите и да наблюдават представянето им в продукционна среда.

4. Как да автоматизирате оценяването на AI агенти?

Можете да автоматизирате оценяването на AI агенти, като създадете повторяеми тестове, приложите автоматизирани оценители и интегрирате тези проверки в работните процеси при разработката и в продукционна среда:

1. Създайте набор от данни за оценяване: Съберете представителни потребителски задачи, очаквани резултати, известни неуспехи и трасировки на изпълнението на агента. Включете гранични случаи, като неуспешни извиквания на инструменти, липсваща информация и неоторизирани действия.
2. Автоматизирайте изпълнението на тестовете и оценяването: Използвайте рамки като pytest или DeepEval, за да изпълнявате тестови случаи и да прилагате проверки, базирани на код, или LLM оценители. Валидирайте LLM оценителите спрямо човешки преценки, преди да разчитате на резултатите им.
3. Интегрирайте оценяването в CI/CD: Автоматично изпълнявайте отново регресионните тестове, когато разработчиците актуализират промптовете, моделите, инструментите или работния процес на агента. Сравнявайте резултатите с базова версия и задайте прагове за качество, които блокират издаването на нови версии, когато критични проверки са неуспешни.
4. Прилагайте калибрирани оценители върху извадки от продукционни трасировки, проследявайте процента на неуспехите и други показатели за ефективност и проучвайте новите грешки чрез ръчен преглед.