У розробці агентів на базі великих мовних моделей (LLM) з’явився новий «стандарт»: оцінювати якість відповідей за допомогою іншої моделі — LLM-as-a-judge. На цьому будується ціла екосистема observability?платформ і бібліотек для «автоматичних» метрик на кшталт hallucination score. Але коли такі оцінки погано відкалібровані, вони не просто марні — вони небезпечні.
У своєму виступі на каналі AI Engineer Махмуд Мабрук, співзасновник і CEO Agenta AI, open?source LLMOps?платформи для побудови та оцінювання LLM?застосунків, демонструє це на практичному кейсі: побудові LLM?судді для клієнтського підтримувального агента авіакомпанії на базі бенчмарку Towbench. На цьому прикладі добре видно, чому універсальні «галюцинаційні» метрики вводять команди в оману, як правильно формулювати цілі оцінювання і чому прості бінарні метрики, підкріплені експертною розміткою, працюють краще за «розумні» шкали від 1 до 5.
Коли дашборд каже «все добре», а користувачі — ні
Типовий сценарій для команди, що запускає LLM?агента в продакшн, виглядає знайомо. Агент уже обробляє реальні запити, з’являється потреба «моніторити надійність», і хтось підключає готовий модуль «hallucination judge» з популярної бібліотеки або observability?платформи. На графіках — заспокійливі зелені лінії, відсоток галюцинацій низький, усе начебто під контролем.
Проблема в тому, що користувачі паралельно скаржаться: агент працює погано. Команда відкриває конкретні трейси — і бачить очевидні помилки, які жодна метрика не підсвітила. Починається розслідування, і виявляється, що «суддя» — це LLM із примітивним промптом на кшталт: «Оціни, чи є ця відповідь галюцинацією. Не помиляйся». Модель не має доступу до джерел правди, не розуміє бізнес?контексту, але впевнено видає оцінки, які потім агрегуються в красиві дашборди.
У такій конфігурації LLM?оцінювач не просто не допомагає. Він створює небезпечну ілюзію контролю. Команда бачить «хороші» метрики, вважає, що система стабільна, і відкладає реальне дебагінг?розслідування. Користувачі тим часом продовжують отримувати неправильні відповіді, а проблеми накопичуються.
Саме тому хибно відкалібровані оцінки гірші, ніж їхня повна відсутність. Коли метрик немає, команда принаймні не має фальшивої впевненості й змушена дивитися на реальні розмови, слухати користувачів і проводити ручний аналіз. Коли ж є «розумні» числа, що не корелюють із людською оцінкою якості, вони відтягують увагу від справжніх сигналів.
Чому LLM?оцінювання має починатися з бізнес?цілей, а не з «галюцинацій»
Ключова помилка багатьох команд — спроба застосувати універсальні, абстрактні метрики до конкретних бізнес?агентів. «Hallucination rate», «overall quality», «helpfulness score» звучать науково, але в реальному продукті вони часто нічого не говорять про те, що насправді важливо бізнесу.
У випадку з клієнтською підтримкою авіакомпанії контекст радикально інший, ніж у загальних чат?ботів. Агент має доступ до інструментів для керування бронюваннями, перегляду інформації про рейси та даних користувача. Він працює за складною політикою: коли можна змінювати квитки, за яких умов дозволена відміна, як поводитися з різними тарифами. Помилка тут — це не абстрактна «галюцинація», а конкретне порушення політики, неправильне використання інструментів або невдала комунікація з клієнтом.
Ефективне оцінювання LLM?агента в такому середовищі має бути жорстко прив’язане до бізнес?цілей. Питання звучить не «наскільки відповідь хороша за шкалою від 1 до 5», а «чи дотримався агент політики», «чи правильно повідомив клієнта про зміну», «чи коректно викликав потрібний тул». Інакше кажучи, метрики мають відображати конкретні типи помилок, які реально болять бізнесу, а не розмиту «якість».
Це особливо важливо як в офлайн?циклі розробки, так і в онлайн?моніторингу.
В офлайні швидкість розвитку агента визначається тим, наскільки швидко команда може пройти цикл: змінити промпт або архітектуру, прогнати A/B?оцінювання, зрозуміти, що стало краще чи гірше, і повторити. Людська розмітка дає високу якість, але кожна ітерація дорога й повільна. LLM?суддя може прискорити цикл, але лише за умови, що його оцінки добре корелюють із людськими. Якщо ж ні — команда швидко рухається в нікуди.
В онлайні ситуація ще чутливіша. Продакшн?метрики мають показувати, чи покращили останні зміни поведінку агента, чи змінилася дистрибуція запитів, чи з’явилися нові класи помилок. Якщо LLM?оцінювач не прив’язаний до бізнес?цілей, він не помітить критичних збоїв, і команда не зможе вчасно відреагувати.
Тому перший принцип здорового підходу до LLM?оцінювання: метрики мають народжуватися з конкретного use case, а не з бібліотеки «готових» показників.
Чотири типи помилок авіаційного агента, які не можна звести в один бал
Кейс із Towbench особливо показовий тим, що він змушує дивитися на помилки агента не як на щось монолітне, а як на набір різних вимірів. У бенчмарку використовується агент авіакомпанії з доступом до інструментів і складною політикою, а також 599 розмовних трейсів із анотаціями. Після пост?обробки кожен трейс має бінарну мітку «комплаєнтний / некомплаєнтний» і текстове пояснення, чому саме відповідь вважається такою. Приблизно 62% трейсів — комплаєнтні, 38% — ні.
Щоб зрозуміти, як насправді ламається агент, потрібна не модель, а людина — предметний експерт. Саме він має пройтися по трейсах, залишити вільні коментарі, що пішло не так, а потім поступово згрупувати ці коментарі в класи помилок. Такий підхід до error analysis добре описаний у спільноті AI?інженерів і виявляється набагато продуктивнішим, ніж одразу вигадувати абстрактні метрики.
У випадку з авіаційним агентом цей аналіз вивів щонайменше чотири різні типи помилок.
По?перше, це дотримання політики. Агент може, наприклад, схвалити відміну бронювання, не перевіривши, чи дозволяють це правила тарифу. У конкретному трейс?прикладі саме так і сталося: агент погодив скасування без валідації відповідності правилам авіакомпанії. Формально відповідь виглядає «корисною» для клієнта, але з точки зору бізнесу це грубе порушення.
По?друге, стиль відповіді. Навіть якщо політика дотримана, агент може відповідати надто сухо, нечемно або заплутано. Для служби підтримки це критично: тон і ясність комунікації безпосередньо впливають на задоволеність клієнта.
По?третє, доставка інформації. Агент може виконати дію в бекенді, але не повідомити про це клієнта або зробити це так, що користувач не розуміє, що саме змінилося. З погляду системи все гаразд, але з погляду користувача — ні.
По?четверте, використання інструментів. Агент може неправильно викликати тул, не викликати його тоді, коли це потрібно, або інтерпретувати результати некоректно. Це вже не про політику чи стиль, а про інтеграцію з системами.
Усі ці помилки важливі, але вони різні за природою, наслідками й способами виправлення. Спроба звести їх у один «загальний» показник успіху агента неминуче призводить до втрати інформації. Команда бачить, що «загальна якість» впала на кілька відсотків, але не розуміє, чи це через нові порушення політики, чи через погіршення стилю, чи через збої в інструментах.
Саме тому в кейсі Towbench було прийнято принципове рішення: будувати окремих LLM?суддів для кожного типу помилок, а не один універсальний. Окремий суддя для політики, окремий — для стилю, окремий — для доставки інформації, окремий — для використання інструментів. Це дозволяє діагностувати конкретні режими відмови, а не спостерігати за усередненим числом, яке нічого не пояснює.
Чому бінарні метрики кращі за шкали 1–5 — і для людей, і для моделей
Ще одна спокуса, яка часто з’являється при проєктуванні LLM?оцінювання, — використати «багату» шкалу. Здається логічним: якщо замість «так/ні» ми дамо судді можливість виставляти бали від 1 до 5 або відсоткові оцінки, отримаємо більш тонку картину. На практиці це рідко працює.
Навіть для людських анотацій узгодити шкалу 1–5 виявляється складно. Двоє експертів можуть погодитися, що відповідь «неправильна», але один поставить 2, інший — 3. Різниця в інтерпретації шкали, контекст, настрій — усе це вносить шум. Коли ж до цього додається LLM?суддя, який має навчитися відтворювати таку нечітку шкалу, завдання стає ще важчим.
У випадку з політикою авіакомпанії питання насправді бінарне: дотримано її чи ні. Агент або перевірив правила перед скасуванням бронювання, або ні. Або повідомив клієнта про зміну, або ні. У таких сценаріях введення проміжних градацій не додає корисної інформації, але ускладнює калібрування.
Тому в описуваному підході свідомо обираються бінарні метрики для LLM?суддів. Для кожного типу помилки суддя має відповісти «комплаєнтний / некомплаєнтний» або «правильно / неправильно», доповнюючи це текстовим поясненням. Це не означає, що система втрачає нюанси: саме пояснення дає контекст, чому відповідь вважається помилковою. Але сам сигнал, який потім агрегується в метрики, залишається простим і чітким.
Ця простота критично важлива для калібрування. Навіть з бінарною класифікацією побудувати LLM?суддю, який добре узгоджується з людськими анотаціями, виявляється нетривіальним завданням. Додавання додаткових рівнів складності у вигляді шкал 1–5 лише погіршує ситуацію.
Люди проти «магічних» моделей: хто визначає, що таке «якість»
Ще один фундаментальний принцип, який випливає з цього підходу: визначати, що таке «хороша» відповідь, мають не моделі, а люди — предметні експерти. LLM?суддя не повинен «вигадувати» критерії якості з нуля. Його завдання — відтворювати вже сформульовані людські стандарти.
У практичному робочому процесі це означає кілька кроків. Спочатку експерти отримують набір трейсів — повних діалогів між агентом і користувачем. Вони вільно коментують, що спрацювало, а що ні, не обмежуючись наперед заданими категоріями. Потім ці коментарі поступово групуються в кластери помилок: політика, стиль, доставка інформації, інструменти тощо.
Далі для кожного типу помилки формується чітке визначення того, що вважається «добре» і «погано». Наприклад, для політики — чи перевірив агент відповідні правила перед дією, чи не пообіцяв те, що суперечить умовам тарифу. Ці визначення лягають в основу інструкцій для анотації.
На етапі розмітки експерти не лише ставлять бінарну мітку, а й пишуть вільний текстовий коментар, чому саме відповідь комплаєнтна чи ні. У прикладі з Towbench це виглядає так: «Агент не є комплаєнтним, оскільки схвалив скасування без перевірки, чи відповідає бронювання правилам відміни». Такий коментар не просто фіксує факт помилки, а й пояснює її природу.
Ці пояснення критично важливі для подальшого навчання LLM?судді. Без них модель змушена самостійно «відкривати» причини, чому та чи інша відповідь вважається неправильною, лише з прикладів «так/ні». У складних сценаріях, як?от політика авіакомпанії, це практично нереально. З поясненнями ж суддя може навчитися не тільки класифікувати, а й аргументувати свої рішення в термінах, близьких до людських.
У результаті саме люди задають рамку якості, а LLM?суддя стає інструментом масштабування цієї рамки на великі обсяги даних — як в офлайн?тестах, так і в продакшн?моніторингу.
Від ручної розмітки до автоматичного «data flywheel»
Хоча основний фокус цього підходу — на правильному визначенні метрик і ролі експертів, у ньому закладена й довгострокова інженерна мета: побудувати справжній «data flywheel» для LLM?застосунків.
У класичному циклі розробки команда оптимізує промпти або архітектуру агента, спостерігає за трейсами, додає нові оцінки для edge cases і повторює. Якщо цей цикл повністю ручний, він неминуче повільний. Але якщо є надійні, відкалібровані LLM?судді, які добре відтворюють людські оцінки за ключовими бізнес?метриками, значну частину цього циклу можна автоматизувати.
У такій конфігурації оптимізаційні алгоритми, на кшталт GEPA, можуть застосовуватися не лише до промптів агента, а й до самих суддів. Нові трейси з продакшну автоматично проходять через LLM?оцінювачів, виявляються нові класи помилок, для них додаються метрики, а судді поступово донавчаються. З часом застосунок покращується не завдяки разовим «великим релізам», а завдяки безперервному циклу спостереження, оцінювання й оптимізації.
Але фундаментом для такого flywheel залишаються ті самі речі: правильно визначені, бізнес?орієнтовані метрики, бінарні й інтерпретовані, окремі судді для різних типів помилок і людські експерти, які задають стандарт якості й забезпечують початкову розмітку.
Висновок: менше магії, більше дисципліни
Індустрія LLM?застосунків швидко рухається до все більшої автоматизації: автоматичні судді, автоматичні оптимізатори промптів, автоматичні пайплайни. На цьому тлі легко піддатися спокусі «підключити готовий hallucination judge» і вважати, що питання якості закрите.
Кейс із авіаційним агентом Towbench показує протилежне. Погано відкалібровані LLM?оцінювачі не просто не допомагають — вони створюють небезпечну фальшиву впевненість, яка відтягує увагу від реальних проблем користувачів. Щоб уникнути цього, командам доводиться повертатися до базових принципів: починати з бізнес?цілей, розкладати помилки на окремі типи, будувати для кожного з них окремі бінарні метрики й залучати предметних експертів до визначення того, що таке «якість».
У такій рамці LLM?судді перестають бути магічними чорними ящиками й стають інструментами, які можна калібрувати, перевіряти й покращувати. А це, своєю чергою, відкриває шлях до справжньої автоматизації — не на рівні красивих дашбордів, а на рівні реального, вимірюваного покращення поведінки агентів у продакшні.