Оценка и регрессионное тестирование 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) кейс — это особенно надёжный пример, ожидаемое поведение которого тщательно проверено; он служит опорой при сравнении версий.

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

Со временем набор превращается в журнал ошибок, которые систему научили больше никогда не повторять.

К чему это ведёт

У промпт-инжиниринга теперь появился ещё один слой сверху.

Этот слой важнее любого отдельного приёма составления промптов. Самые сильные продакшен-системы получаются не потому, что кто-то нашёл один волшебный промпт. Они получаются из итеративного процесса, в котором каждое изменение измеряется на репрезентативных кейсах.

Измерения открывают дорогу и к следующему этапу. Как только качество можно выразить в числах, возникают здравые вопросы. Помогут ли дополнительные примеры или более короткий промпт? Стоит ли извлекать больше контекста или меньше? Имеет ли смысл попробовать другую модель или иначе разбить задачу? Можно ли автоматизировать поиск промптов? Стоит ли рост точности лишних токенов? Ответы зависят от измеримых компромиссов, и именно здесь начинается оптимизация промптов.