Оцінювання та регресійне тестування LLM-промптів у продакшені

Інтуїція — поганий спосіб покращувати LLM-систему в продакшені. Команда підтримки править промпт, кілька разів його пробує й оголошує, що нова версія відчувається кращою. Це не оцінювання. Зміна могла підняти якість класифікації. А могла допомогти лише кільком прикладам, які хтось випадково спробував, і водночас зробити відповіді багатослівнішими, сповільнити їх, погіршити роботу на незвичних випадках або ширше відчинити двері для промпт-ін'єкцій.

Коли на промптах працює реальний застосунок, оцінювання — це петля зворотного зв'язку, яка показує, чи справді зміна допомогла.

Починаємо з конкретних тест-кейсів

Тестування промптів починається з конкретних випадків. Для застосунку підтримки один кейс може поєднувати повідомлення клієнта про те, що посилання для скидання пароля прострочене, і документацію, що стосується цієї проблеми.

Input:
Customer says their password reset link expired.

Context:
Relevant support documentation.

Expected behavior:
Classify as password-reset issue.
Do not claim the account is locked.
Recommend the documented recovery path.
Return the required structured output.

Ранер проганяє кейс через застосунок і зберігає результат. У принципі просто, але в продакшені багато що може змінюватися водночас. Правка промпту може прийти разом із новою моделлю, іншим способом вибору контексту, свіжими даними для retrieval, іншими визначеннями інструментів, новою схемою виводу чи зміненими параметрами генерації. Тож тестується вся конфігурація системи, а не лише рядок промпту.

Почасти тому робота з промптами починає скидатися на програмну інженерію. Промпт перетворюється на артефакт із вхідними даними, очікуваною поведінкою, версіями, тестами й регресіями.

Що входить у добрий тестовий набір

Сильний набір для оцінювання — це не купа звичайних запитів, що проходять успішно. Для системи підтримки він має навмисно містити:

• прості випадки скидання пароля
• неоднозначні запити
• випадки з бракуючою інформацією
• документи, що суперечать одне одному
• нерелевантний контекст
• незвично довгі розмови
• ворожі повідомлення клієнтів
• ворожий видобутий контент
• запити, які система не може обслужити
• випадки, що потребують інструмента
• випадки, коли інструмент викликати не можна
• некоректні або неповні результати інструментів

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

Вимірюємо більше ніж один показник

Оцінювання, або eval, — це відтворюваний спосіб виміряти роботу системи за заданими критеріями. У найпростішому вигляді кожна відповідь отримує «правильно» чи «неправильно», одиницю чи нуль. Для класифікації цього може вистачити, але реальним LLM-застосункам зазвичай потрібно кілька вимірів. Відповідь підтримки можна оцінювати за такими критеріями:

1. Класифікація: чи розпізнала система справжню проблему клієнта?
2. Обґрунтованість: чи підкріплюють відповідь наявні дані й видобута інформація?
3. Повнота: чи охоплює вона все потрібне для розв'язання проблеми?
4. Безпека: чи уникла система несанкціонованих тверджень і дій та чи лишилася в межах своїх повноважень?
5. Формат: чи відповідає вивід потрібній структурі або схемі?
6. Корисність: чи справді вона допоможе клієнтові досягти мети?
7. Ефективність: чи обійшлася система без зайвого контексту, retrieval і викликів інструментів, зберігши добру відповідь?

Саме тому одна цифра якості може вводити в оману. Система може стати кориснішою й менш безпечною, точнішою й набагато дорожчою або красномовнішою, але частіше ламати схему. Серйозне оцінювання відстежує виміри, важливі для конкретного застосунку. Проєкт HELM зі Стенфорда відображає ту саму думку: він оцінює моделі в безлічі сценаріїв і вимірів, а не стискає поведінку в один бал здібностей, і охоплює здібності, виконання інструкцій, безпеку, довгий контекст, предметні тести та багато іншого.

Датасет важливіший за хитрий промпт для судді

Уявіть, що систему підтримки тестують лише на десяти простих кейсах, і всі вони про скидання пароля.

password reset
password reset
password reset
password reset
...

Новий промпт може набрати 100% і все одно погано працювати в продакшені. Корисний датасет відображає ту суміш випадків, з якою система має зіткнутися, тож йому потрібна різноманітність формулювань, складності, якості документів, мов чи діалектів, де це важливо, довжини контексту, неоднозначності, граничних випадків, ворожого вводу й обставин клієнтів. І в ньому має бути досить складних прикладів, щоб виявити важливі режими відмови.

Публічні бенчмарки допомагають порівнювати загальні здібності моделей. MMLU охоплює 57 предметних галузей, а HELM — безліч прикладних і орієнтованих на ризики сценаріїв. Жоден із них не замінює власного набору застосунку, бо продукт підтримки визначає успіх по-своєму. Питання не в тому, яка модель очолює загальний рейтинг. Питання в тому, яка конфігурація найкраще справляється з роботою, яку цей застосунок реально виконує.

Як оцінювати вивід

Точне порівняння

Якщо відповідь фіксована, порівняйте згенероване значення з очікуваним, наприклад категорія дорівнює password_reset або пріоритет дорівнює high. Для вільного тексту, де прийнятними можуть бути багато відповідей, це працює погано.

Перевірки за правилами

Деякі властивості можна перевірити детерміновано.

Does the JSON parse?
Does the required field exist?
Is urgency one of the permitted values?
Was a prohibited field returned?
Was an unauthorized tool called?

Таким перевіркам не потрібна друга модель для ухвалення рішення, тож вони дешеві й надійні.

Еталонні відповіді

Відповідь, написана або перевірена людиною, дає точку для порівняння. У кейсі підтримки можна зафіксувати очікуваний діагноз і дані, на які відповідь мусить послатися.

Expected diagnosis:
Password-reset issue
Required evidence:
Recent reset request + unused reset link
Forbidden claim:
Account is locked

Потім згенеровану відповідь оцінюють за цими вимогами.

Рубрики

Рубрика — це явна шкала оцінювання. Замість питання «чи добра відповідь» вона задає рівні для кожного критерію.

Grounding:
0 = contains unsupported claims
1 = mostly grounded
2 = fully grounded

Completeness:
0 = misses critical information
1 = partially complete
2 = complete

Safety:
0 = unsafe action or disclosure
1 = safe

Оцінки стають відтворюванішими, а команді доводиться чітко сформулювати, що насправді означає «добре».

LLM у ролі судді

Для вільного тексту оцінювачем іноді може виступати інша LLM.

Evaluate this support response.
Criteria:
1. Is the diagnosis supported by the supplied evidence?
2. Does the response answer the customer's question?
3. Does it avoid unsupported claims?
4. Does it follow the required tone?
Return a score from 1 to 5 and explain each score.

Це значно дешевше й швидше, ніж змушувати людину читати кожен вивід, і дає змогу оцінювати якості, яких прості правила не вловлюють, як-от ясність чи корисність. Але суддя — теж модель, і постає друга проблема: хто оцінює оцінювача? Дослідження не раз знаходили в модельному суддівстві упередженість і нестабільність, зокрема ефекти позиції, стилю й авторитету. Модель-суддю не можна автоматично вважати істиною.

Звідси розумний порядок переваг. Використовуйте детерміновані перевірки скрізь, де можна, ревʼю людьми там, де треба, і модельне оцінювання там, де воно допомагає, — з валідацією за ним. Перевіряйте валідність JSON парсером, а не ще однією LLM. Перевіряйте, чи справді було оформлено повернення коштів, за системою транзакцій, а не за розповіддю самої моделі про те, що сталося. Для чогось на кшталт емпатії у відповіді клієнтові LLM-суддя може дати один сигнал, підкріплений ревʼю людини.

Регресійні тести

Припустімо, версія 7 промпту підтримки працює добре. За місяць інженер змінює шаблон контексту. Відповіді, що спираються на документи, покращуються, але модель починає ігнорувати історію розмови. Сам диф промпту може ніяк не натякати на проблему.

Регресійний тест ловить момент, коли поведінка, що раніше була прийнятною, після зміни погіршується. Процес виглядає так.

Ідею запозичено з класичного тестування софту. Просто в LLM-застосунків значно більше компонентів, які можуть зсунутися, а отже, ширша зона, де ховаються регресії. Зміна будь-якого пункту тут може змінити поведінку.

Prompt
Model
Model version
Context selection
Retrieved documents
Memory
Tool definitions
Tool implementation
Output schema
Generation settings
Safety policies

Тому регресійний набір має проганяти систему в репрезентативних умовах, а не перевіряти лише текст промпту.

Компроміси ховаються всередині єдиного вердикту

Припустімо, старий промпт отримав такі оцінки.

Classification accuracy: 94%
Grounding:               96%
Schema validity:         99%
Unsafe tool calls:       1%
Average latency:         1.8 s

А новий — такі.

Classification accuracy: 96%
Grounding:               95%
Schema validity:         99%
Unsafe tool calls:       4%
Average latency:         2.4 s

Назвати нову версію кращою означало б приховати компроміс. Класифікація додала два пункти, але небезпечних викликів інструментів стало вчетверо більше, і затримка теж зросла. Оцінювання виставляє такі компроміси на загальний огляд.

Середні значення теж можуть приховувати серйозні провали. Якщо 99% запитів безпечні, а решта 1% пов'язані з несанкціонованими фінансовими діями, 99% за безпекою можуть бути неприйнятними. Для високоризикової поведінки команди часто розглядають відповідну категорію відмов окремо, щоб вона не розчинилася в агрегаті.

Пастки покриття в датасеті

Є тонка пастка. Датасет із 1000 кейсів, у якому 900 — майже однакові запити на скидання пароля, може дати вражаючий результат і водночас майже нічого не сказати про рідкісні, але важливі ситуації. Покриття треба планувати. Практичний набір складається з шарів.

Core cases
    Common production scenarios

Edge cases
    Ambiguous, unusual, incomplete inputs

Adversarial cases
    Injection, manipulation, malicious content

Safety cases
    Requests involving restricted actions or information

Regression cases
    Previously observed failures

Golden cases
    Carefully reviewed examples representing important behavior

Еталонний (golden) кейс — це особливо надійний приклад, очікувану поведінку якого ретельно перевірено; він слугує опорою під час порівняння версій.

Датасет теж має постійно розвиватися. Коли моніторинг виявляє новий збій у продакшені, цей збій часто варто перетворити на новий регресійний тест. Виходить цикл.

З часом набір стає журналом помилок, які систему навчили більше ніколи не повторювати.

До чого це веде

У промпт-інжинірингу тепер з'явився ще один шар зверху.

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

Вимірювання відкривають шлях і до наступного етапу. Щойно якість можна виразити числами, постають слушні питання. Чи допоможуть додаткові приклади або коротший промпт? Чи варто видобувати більше контексту чи менше? Чи є сенс спробувати іншу модель або інакше розбити задачу? Чи можна автоматизувати пошук промптів? Чи вартий приріст точності зайвих токенів? Відповіді залежать від вимірюваних компромісів, і саме тут починається оптимізація промптів.