У світі корпоративних LLM?агентів одна з найскладніших задач — не стільки навчити модель відповідати клієнтам, скільки надійно оцінювати, чи дотримується вона бізнес?політик. У воркшопі на каналі AI Engineer співзасновник і CEO Agenta AI Махмуд Мабрук показує, як побудувати й оптимізувати LLM?«суддю» для авіалінійного сапорт?агента, використовуючи алгоритм GEPA та бібліотеку GPA. На відміну від загальних «якість відповіді: 1–5» оцінювачів, тут фокус — вузький: бінарне судження, чи порушив агент політику авіакомпанії в конкретному діалозі.
Цей матеріал розбирає саме етап оптимізації такого LLM?джаджа: від слабкого початкового промпта до більш надійного, каліброваного оцінювача, який краще знаходить реальні порушення, а не просто «погоджується» з усім, що робить агент.
Вузький суддя замість універсального критика
У більшості команд, що запускають LLM?агентів у продакшн, типовий сценарій виглядає однаково. З’являється потреба «моніторити якість», хтось підключає готовий «LLM?as?a?judge» з бібліотеки — часто з розмитою метрикою на кшталт «галюцинація / не галюцинація» — і інтегрує його в observability?дашборд. Графіки виглядають пристойно, але користувачі скаржаться, що агент працює погано. При розборі з’ясовується, що оцінювач майже нічого корисного не бачить.
Ключова причина — невідповідність між тим, що реально важливо бізнесу, і тим, що вимірює LLM?суддя. Для авіалінійного сапорт?агента критично не те, наскільки «красиво» він відповідає, а чи дотримується складної політики: коли можна змінювати бронювання, за яких умов дозволена безкоштовна відміна, що саме потрібно перевірити перед підтвердженням операції.
Саме тому в цьому кейсі будується окремий LLM?джадж виключно для перевірки policy adherence — дотримання політик — у домені авіакомпанії. Він не оцінює стиль, не міряє «загальну якість», не виставляє бали за ввічливість. Його завдання — дати чітку відповідь «так / ні»: чи порушив агент політику в конкретній розмові, і пояснити, чому.
Такий вузький фокус має дві важливі переваги. По?перше, спрощується сама задача для моделі: замість абстрактного «чи хороша ця відповідь?» вона розв’язує конкретну перевірку правил. По?друге, це краще відповідає тому, як працюють людські рев’юери в сапорт?командах: вони дивляться саме на відповідність політикам, а не на естетику тексту.
Початковий «людяний» промпт: припускати відповідність, доки не доведено протилежне
Відправною точкою для оптимізації стає так званий seed judge — початковий промпт, який описує роль LLM?судді й формат відповіді. У цьому воркшопі він спеціально спроєктований так, щоб імітувати типову поведінку людини?рев’юера в сапорт?команді.
Логіка проста: за замовчуванням вважати, що агент діяв коректно, і позначати кейс як non?compliant лише тоді, коли можна чітко сформулювати конкретну причину порушення. Іншими словами, модель має «виправдовувати» агента, доки не знайде явне порушення політики, яке здатна описати природною мовою.
Такий дизайн промпта здається інтуїтивно привабливим. У реальних службах підтримки люди часто працюють саме так: вони не шукають помилки там, де все виглядає нормально, і лише при очевидному відхиленні від правил фіксують порушення з поясненням. Крім того, вимога надати текстове обґрунтування має допомогти моделі не «стріляти навмання»: якщо вона не може сформулювати, що саме зроблено не так, краще вважати кейс compliant.
Однак уже перша валідація показує, що така «людяність» у промпті має високу ціну.
Коли промпт?інженіринг не рятує: 61% точності і майже повна сліпота до порушень
Після побудови seed?джаджа його перевіряють на валідаційній вибірці з реальних діалогів авіалінійного агента, де кожен трейс уже має людську розмітку: бінарний лейбл «дотримано / порушено політику» та пояснення. Це дозволяє об’єктивно виміряти, наскільки LLM?суддя узгоджується з людськими оцінками.
Результат виявляється показовим: приблизно 61% точності на валідаційному наборі. На перший погляд, це може здатися «не так уже й погано», особливо якщо згадати, що політика авіакомпанії складна, а самі діалоги багатокрокові. Але детальніший розбір метрик оголює серйозну проблему.
Seed?джадж позначає близько 98% кейсів як compliant. Тобто майже завжди вважає, що агент діяв за правилами. Враховуючи, що в обробленому датасеті приблизно 62% трейсів справді compliant, а 38% — non?compliant, така поведінка означає катастрофічно низький recall по порушеннях. Модель майже не бачить non?compliant випадків, систематично даючи хибно негативні оцінки.
Це класичний приклад того, як наївний промпт?інженіринг без подальшої оптимізації може створити ілюзію адекватного оцінювача. Формально точність вища за випадкову, але з точки зору бізнес?ризиків такий суддя практично марний: він не сигналізує про значну частину реальних порушень політики, які якраз і є найбільш критичними.
Причина криється в самій структурі промпта. Жорстке припущення «комплаєнс за замовчуванням» у поєднанні з вимогою чітко сформулювати причину порушення створює сильний зсув у бік «виправдання» агента. Модель, яка не має внутрішньої формальної моделі політики, часто не може впевнено сформулювати, що саме було зроблено не так, і тому обирає безпечний для себе варіант — compliant.
Цей експеримент добре демонструє межі ручного промпт?інженірингу. Навіть ретельно продуманий seed?промпт, який наслідує людську логіку, може виявитися системно упередженим. Щоб отримати надійного LLM?джаджа, потрібен автоматизований процес пошуку кращих формулювань і конфігурацій.
GEPA та GPA: як працює оптимізація LLM?судді
Для виходу за межі слабкого seed?джаджа використовується GEPA — алгоритм оптимізації промптів, реалізований у бібліотеці GPA. Запуск відбувається через API Optimize Anything, який бере на себе всю рутину: від генерації кандидатних промптів до їх оцінки на датасеті.
Концептуально GEPA працює як ітеративний пошук кращих «версій» судді, стартуючи з початкового промпта. На кожному кроці він виконує кілька ключових дій.
Спочатку генерується набір кандидатних промптів на основі поточного пулу найкращих. Для цього використовуються дві стратегії. Перша — prompt mutation: варіації існуючих промптів через локальні зміни формулювань, інструкцій, прикладів або форматів відповіді. Це дозволяє досліджувати «околицю» поточного рішення, поступово підлаштовуючи його поведінку. Друга — prompt merging: поєднання елементів кількох успішних промптів у нові конфігурації, що дає змогу комбінувати сильні сторони різних підходів. Такий підхід нагадує еволюційні алгоритми, де кращі особини «схрещуються», породжуючи потенційно сильніших нащадків.
Далі кожен кандидатний промпт використовується як LLM?джадж для оцінки трейсів із датасету. На цьому етапі GPA виступає як евалюатор: для кожної конфігурації збираються вихідні лейбли, фіксуються помилки, логуються міркування моделі, якщо вони передбачені форматом відповіді. Це не просто підрахунок точності — система зберігає детальну інформацію, яка згодом може бути використана для аналізу та налагодження.
Після цього GEPA відбирає найкращі кандидатні промпти не за єдиним усередненим показником, а за допомогою Парето?фронту по задачах. Це означає, що замість того, щоб максимізувати, наприклад, лише загальну точність, алгоритм шукає конфігурації, які є «неспростовно кращими» за інші одночасно по кількох вимірах. У контексті policy?adherence це особливо важливо: суддя має бути не тільки точним у середньому, а й стабільно працювати в різних сценаріях порушень політики, не провалюючись на певних типах кейсів.
Після відбору найкращі промпти стають новим «пулом батьків» для наступної ітерації. Цикл «згенерувати — оцінити — відфільтрувати — уточнити» повторюється доти, доки не буде досягнуто заданих критеріїв зупинки: наприклад, обмеження за кількістю ітерацій, викликів моделі чи відсутність помітного покращення метрик.
Таким чином, GEPA перетворює оптимізацію LLM?джаджа з ручного ремесла на систематичний пошук у просторі промптів і конфігурацій, спираючись на реальну людську розмітку як джерело істини.
Чому Парето?відбір важливіший за «середню оцінку»
Вибір кандидатних суддів за Парето?фронтом, а не за єдиною агрегованою метрикою, — не просто технічна деталь, а принциповий дизайн?рішення. У задачі policy?adherence для авіалінійного агента різні типи порушень можуть мати різну природу й частоту, а також різну критичність для бізнесу.
Якщо оптимізувати лише середню точність, алгоритм може «навчитися» добре працювати на домінуючих кейсах, але системно провалювати рідкісні, проте дуже важливі сценарії. Наприклад, він може чудово розпізнавати прості порушення, пов’язані з відсутністю перевірки правил відміни, але ігнорувати складніші випадки, де агент неправильно комбінує кілька політик.
Парето?підхід дозволяє уникнути такої пастки. Конфігурація вважається кращою, лише якщо вона не гірша за інші по всіх розглянутих вимірах і краща хоча б по одному. Це стимулює пошук суддів, які поводяться збалансовано, не жертвуючи якістю на одних сценаріях заради покращення на інших.
У практичному вимірі це означає, що фінальний LLM?джадж буде більш надійним у продакшні. Він не просто дає «гарну цифру» на загальному датасеті, а демонструє стійку поведінку на різних типах політичних порушень, які зустрічаються в реальних діалогах із клієнтами.
Від слабкого seed?джаджа до надійного інструменту контролю
Порівняння початкового seed?джаджа з тим, що виходить після оптимізації GEPA, добре ілюструє, чому одного лише промпт?інженірингу недостатньо для побудови надійних LLM?оцінювачів.
Seed?суддя, спроєктований за принципом «комплаєнс за замовчуванням», показує близько 61% точності й майже повністю ігнорує 38% non?compliant трейсів, позначаючи 98% кейсів як compliant. Це типовий приклад систематичного зсуву: модель «боїться» назвати порушення, якщо не може чітко його сформулювати, і в результаті перетворюється на джаджа, який майже ніколи не піднімає тривогу.
Оптимізація через GEPA та GPA’s Optimize Anything API змінює ситуацію принципово. Замість того, щоб покладатися на одну людську інтуїцію при написанні промпта, система автоматично досліджує широкий простір можливих інструкцій і конфігурацій, відбираючи ті, що краще узгоджуються з людською розміткою на реальних даних. При цьому Парето?відбір гарантує, що фінальний суддя буде не просто «середньо точним», а стійким до різних сценаріїв порушень політики.
Важливу роль відіграє й те, що GPA логуватиме виходи, помилки та міркування кожного кандидатного судді. Це створює прозорий слід для аналізу: інженери можуть не лише бачити метрики, а й розбиратися, чому конкретна конфігурація поводиться так чи інакше, і за потреби втручатися в процес із додатковими обмеженнями чи доменними знаннями.
У підсумку LLM?джадж перестає бути «чорною скринькою з гарним промптом» і стає інструментом, чия поведінка систематично наближена до людських оцінок, зафіксованих у датасеті. Для команд, які будують складних агентів на кшталт авіалінійного сапорту, це означає можливість швидше й безпечніше ітерувати над промптами й архітектурою агента, не покладаючись щоразу на повний цикл ручної розмітки.
Висновок: калібрований LLM?суддя — це не про «кращий промпт», а про системну оптимізацію
Історія з авіалінійним сапорт?агентом добре показує, чому наївний підхід «напишемо розумний промпт і отримаємо хорошого суддю» не працює в реальних продакшн?сценаріях. Навіть промпт, що імітує людську логіку й вимагає пояснень, може виявитися глибоко упередженим, як це сталося з seed?джаджем, який майже завжди вважав агента compliant.
Щоб отримати LLM?оцінювача, якому можна довіряти, потрібен повноцінний цикл оптимізації, заснований на людській розмітці. GEPA в поєднанні з GPA’s Optimize Anything API пропонує саме такий підхід: старт із початкового промпта, ітеративне генерування кандидатів через мутації та мерджинг, систематична оцінка на датасеті й відбір за Парето?фронтом, який забезпечує стійкість до різних сценаріїв.
У результаті LLM?джадж із абстрактної «моделі, що щось оцінює» перетворюється на конкретний інструмент контролю дотримання політик у вузькому домені — у цьому випадку, в авіалінійному клієнтському сервісі. І саме така вузька, але добре калібрована оптика виявляється значно ціннішою для бізнесу, ніж будь?які універсальні «оцінки якості» без прив’язки до реальних правил і ризиків.