Найчастіше запитання від команд з AI-функцією в продакшені: «Ми змінили промпт — стало краще чи гірше?» Без оцінювання цього не знає ніхто. Хтось перевіряє п'ять запитань, відповіді виглядають нормально, зміна йде в реліз, а за тиждень тікети підтримки показують регресію у випадку, який ніхто не тестував. У гайді — як побудувати evals для LLM, що ловлять такі регресії раніше за користувачів: що міряти, звідки брати тестові дані, коли довіряти LLM у ролі судді і як запускати все це на кожну зміну.

Чому LLM-застосункам потрібне окреме тестування

Класичні тести перевіряють точний результат: add(2, 2) == 4. Відповіді LLM недетерміновані, відкриті й часто мають кілька правильних варіантів. Це не робить тестування неможливим — це змінює його форму.

Eval — повторюваний експеримент: фіксований набір вхідних даних, система, що тестується, і метод оцінювання, який перетворює відповіді на бали. Запустіть той самий eval до і після зміни — і порівнюйте версії цифрами, а не враженнями. Документація Anthropic формулює це просто: спершу визначте критерії успіху, потім будуйте тести, що їх вимірюють (Anthropic: критерії успіху; розробка тестів).

Evals потрібні для трьох рішень, які ви ухвалюватимете регулярно:

  • Зміни промпту та пайплайна — чи допомогли новий chunking, retriever чи промпт?
  • Зміни моделі — чи можна перейти на новішу або дешевшу модель без втрати якості? Див. Оптимізація витрат на LLM.
  • Критерії релізу — чи достатньо добра ця версія, щоб її випускати?

Крок 1: Визначте, що означає «добре»

Розмиті цілі дають марні evals. «Асистент має бути корисним» не виміряєш, а ось це — можна:

Вимір якості Приклад критерію Як оцінювати
Правильність Відповідь збігається з еталоном для фактичних запитань Точний або нечіткий збіг, LLM-суддя
Обґрунтованість Кожне твердження підкріплене знайденими джерелами LLM-суддя з джерелами
Відмова Каже «не знаю», коли відповіді немає в документах Перевірка кодом на розміченій підмножині
Формат Повертає валідний JSON за схемою Валідація схеми
Безпека Ніколи не розкриває дані іншого клієнта Перевірка кодом, red-team набір
Тон і довжина До 120 слів, без маркетингової мови Перевірка кодом, LLM-суддя
Успіх задачі (агенти) Тікет створено з правильними полями Перевірка стану системи після дії

Оберіть три-п'ять вимірів, найважливіших для вашого продукту. Кожен потребує чіткого визначення «пройшов/не пройшов», яке дві людини застосували б однаково.

Крок 2: Зберіть еталонний набір з реальності

Еталонний набір (golden dataset) — серце кожного eval. Його якість важить більше за розмір.

  • Починайте з реального трафіку. Візьміть 100–200 запитань із тікетів підтримки, чатів, пошукових запитів і листів відділу продажів. Синтетичні запитання, написані командою, чистіші за реальність і пропускають помилки, двозначність і змішані мови, якими насправді пишуть користувачі.
  • Покрийте типовий розподіл, потім крайні випадки. Більшість прикладів має виглядати як щоденний трафік; додайте навмисні крайні випадки: запитання без відповіді в документах, двозначні запити, атакувальні вхідні дані та багатокрокові задачі.
  • Зберігайте еталони, а не лише запитання. Для кожного прикладу запишіть очікувану відповідь або ключові факти, які вона має містити, документ-джерело і теги на кшталт billing, refusal чи multi-turn.
  • Версіонуйте набір. Тримайте його в Git поруч із кодом. Коли в продакшені з'являється збій — додавайте його в набір, щоб він ніколи тихо не повернувся.
{"id": "billing-017",
 "input": "Чи можна отримати повернення, якщо скасувати річний план через 3 місяці?",
 "must_include": ["пропорційне повернення", "протягом 30 днів"],
 "source": "policies/refunds.md#annual-plans",
 "tags": ["billing", "policy"]}

Крок 3: Обирайте методи оцінювання — від найдешевших

Використовуйте найпростіший спосіб оцінювання, що надійно вимірює критерій.

Перевірки кодом швидкі, безкоштовні й детерміновані: точний збіг, регулярні вирази, валідація JSON-схеми, «містить потрібний факт», ліміти довжини або перевірка, що API-виклик агента створив правильний запис. Використовуйте їх скрізь, де можливо.

LLM-as-a-judge покриває те, чого не може код: обґрунтованість, повноту, тон. Сильні моделі в більшості випадків погоджуються з людськими оцінками на багатьох задачах (Zheng et al., 2023), але в суддів є відомі упередження: вони схильні обирати першу з двох відповідей і довші відповіді, тож перемішуйте порядок і контролюйте довжину (Wang et al., 2023).

Правила для судді, якому можна довіряти:

  1. Оцінюйте один критерій за виклик з чіткою рубрикою та бінарною шкалою або шкалою 1–3. «Оціни якість від 1 до 10» дає шум.
  2. Просіть коротке обґрунтування перед вердиктом і логуйте обидва.
  3. Калібруйте на людях. Нехай людина розмітить 50–100 відповідей, і порахуйте узгодженість. Дослідження узгодження оцінювачів показують, що критерії «дрейфують», коли люди бачать більше відповідей, тож доопрацьовуйте рубрику на реальних прикладах (Shankar et al., 2024).
  4. Використовуйте сильну модель для суддівства і не змінюйте її між запусками, інакше ви порівнюєте дві рухомі цілі.
JUDGE_PROMPT = """Ти оцінюєш відповіді асистента клієнтської підтримки.
Критерій: ОБҐРУНТОВАНІСТЬ. Кожне фактичне твердження у відповіді має
бути підкріплене джерелами. Стиль ігноруй.

<sources>{sources}</sources>
<answer>{answer}</answer>

Спершу напиши одне речення обґрунтування, потім в останньому рядку
виведи рівно PASS або FAIL."""

Людська перевірка залишається еталоном. Закладіть кілька годин на тиждень для людини, яка знає предметну область, щоб читати вибірку продакшен-розмов і приклади з низькими балами. Це найшвидший спосіб виявити види збоїв, яких ваші метрики ще не ловлять.

Для RAG-систем міряйте пошук і генерацію окремо — чи знайдено потрібний документ і чи відповідь йому вірна, — як описано в статті RAG-системи для бізнесу. Фреймворки на кшталт RAGAS автоматизують частину цієї роботи (Es et al., 2023).

Крок 4: Запускайте evals на кожну зміну

Eval, який хтось запускає «коли згадає», — не страхувальна сітка. Вбудуйте його в цикл розробки:

  • Pull request'и: швидка підмножина (30–50 прикладів, перевірки кодом плюс кілька викликів судді) запускається в CI і публікує бали в PR.
  • Щоночі або перед релізом: повний набір з усіма суддями, порівняння з останнім релізом.
  • Пороги, а не ідеал: білд падає, якщо ключова метрика знижується більше, ніж на погоджену величину, наприклад обґрунтованість — більш ніж на 3 пункти.
  • Запускайте кожен приклад кілька разів, якщо відповіді сильно варіюються; усереднення за два-три запуски відділяє реальні зміни від шуму.

Open-source інструменти на кшталт promptfoo дозволяють описати тест-кейси й перевірки в конфіг-файлах і запускати їх із CI; часто вистачає й невеликого власного скрипта. Інструмент важить менше за звичку. Наше налаштування CI для невеликих команд — у статті CI/CD без болю.

Крок 5: Замкніть цикл із продакшеном

Офлайн-evals прогнозують якість, продакшен-дані її підтверджують. Відстежуйте:

  • Явний фідбек — «палець вгору/вниз», але очікуйте низьку частку відповідей.
  • Неявні сигнали — перефразовані запитання, ескалації на людину, покинуті сесії, копіювання відповідей.
  • Бізнес-результати — частка вирішених звернень, час вирішення, конверсія.

Щотижня беріть вибірку збоїв із продакшену, розмічайте їх і додавайте показові в еталонний набір. За кілька місяців набір стає найціннішим активом проєкту: він фіксує, що означає «добре» для ваших користувачів. У клієнтській підтримці це ті самі метрики, за якими ми вирішуємо, де AI-агенти працюють, а де ні.

Типові помилки

  • Тестування лише «щасливих сценаріїв». Більшість інцидентів у продакшені — це відмови, двозначність і атакувальні запити.
  • Один зведений бал. «Якість: 82%» приховує, що запитання про оплату впали з 90% до 60%. Звітуйте за тегами.
  • Суддя — та сама модель, що тестується. Використовуйте фіксовану сильну модель-суддю і калібруйте її.
  • Набір ніколи не оновлюється. Продукт, документи й користувачі змінюються — eval має змінюватися разом із ними.
  • Не відстежуються вартість і затримка. Промпт на 2% кращий, але втричі повільніший, для користувачів може бути регресією.

FAQ

Скільки тест-кейсів потрібно? Почніть із 50–100 реальних і доведіть до кількох сотень. Покриття реальних сценаріїв важливіше за розмір.

Чи можна покладатися лише на LLM-as-a-judge? Не без калібрування. Спершу виміряйте узгодженість із людською розміткою і залиште перевірки кодом для всього, що вони можуть перевірити.

Як оцінювати агентів? Оцінюйте фінальний стан — чи створено правильний запис, чи підготовлено правильний лист — і траєкторію: кількість кроків, помилки інструментів і зайві дії.

Скільки коштує запуск evals? Зазвичай невелика частка продакшен-витрат. Пакетна обробка і кешування ще більше знижують вартість суддівства.

Джерела

  1. Anthropic. Define your success criteria і Create strong empirical evaluations.
  2. Zheng et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
  3. Wang et al. (2023). Large Language Models are not Fair Evaluators.
  4. Shankar et al. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences.
  5. Es et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation.
  6. Hamel Husain. Your AI product needs evals.
  7. Документація promptfoo.