Проверять качество ответов LLM по нескольким удачным примерам ненадёжно: модель может хорошо справляться с демонстрационным запросом и ошибаться на обычных задачах. Практичнее собрать небольшой повторяемый тестовый набор — запросы, ожидаемые свойства ответа и правила оценки. Тогда после смены модели, системной инструкции или параметров можно увидеть не только отдельный эффектный результат, но и характер изменений.
Такой набор не доказывает, что модель «понимает» задачу или будет безошибочна в работе. Его цель скромнее: обнаружить регрессии и выяснить, на каких случаях система стала лучше или хуже.
Как проверять ответы LLM на собственных задачах
Начните с одного конкретного сценария: например, классификации обращений, извлечения полей из документов или ответов по внутренней базе знаний. Не объединяйте в одной проверке совершенно разные задачи: для них нужны разные примеры и критерии.
Запишите, что получает модель и что должно считаться приемлемым ответом. Для извлечения данных это могут быть обязательные поля и допустимые значения. Для ответа на вопрос — корректность фактов, опора на предоставленный контекст и соблюдение формата. Для краткого резюме — сохранение ключевых пунктов без добавления сведений, которых не было во входном тексте.
Сформулируйте проверку так, чтобы коллега мог применить её без догадок. «Ответ хороший» — не критерий. «Все названные даты присутствуют в источнике, а отсутствующие даты обозначены как неизвестные» — уже проверяемое требование.
Соберите примеры, которые показывают границы задачи
Для первого прохода достаточно компактной подборки реальных или обезличенных запросов. Включите обычные случаи, трудные примеры и ситуации, в которых правильный ответ — отказ от догадки или просьба уточнить входные данные. Размер сам по себе не гарантирует качества: важнее покрыть разные типы ошибок, которые действительно встречаются в вашем сценарии.
Для каждого примера сохраните входные данные, версию инструкции, настройки вызова, ответ модели и ожидаемое поведение. Если задача предполагает ответ по источникам, приложите соответствующий фрагмент документа или идентификатор документа. Так можно будет понять, ошиблась ли модель, изменились ли данные или тест выполняется в других условиях.
Разделите примеры хотя бы на две группы:
- разработческую — для настройки инструкции и критериев;
- контрольную — для итогового сравнения, которую не используют при каждой правке.
Если одни и те же примеры постоянно подгонять под инструкцию, результат на них перестанет быть честной проверкой. Небольшая отдельная контрольная группа помогает заметить такую подстройку, хотя не заменяет проверку на новых данных.
Запишите ожидаемый ответ как критерии, а не только как образец
Для задач со строго заданным результатом храните ожидаемые значения. Например, для классификатора это метка, а для извлечения — набор полей. Сравнение может быть точным, если важны буквальное совпадение и формат, или нормализованным, если эквивалентные записи допустимы.
Для открытых ответов один «эталонный текст» часто слишком жёсток: корректных формулировок может быть несколько. Вместо буквального сравнения задайте отдельные критерии:
есть ли ответ на вопрос;
подтверждаются ли ключевые утверждения входным контекстом;
3. соблюдён ли требуемый формат;
4. добавлены ли неподтверждённые сведения;
5. обозначена ли нехватка данных, когда это необходимо.
OpenAI в руководстве по evals рекомендует строить проверки вокруг конкретного поведения, которое нужно измерить. Anthropic также советует заранее определить критерии успеха и проверять их на репрезентативных примерах. Общий практический вывод: сначала задайте, что значит «достаточно хорошо» для вашего применения, и лишь затем выбирайте метрику.
Сравнивайте версии в одинаковых условиях
При сравнении моделей зафиксируйте всё, что может повлиять на ответ: входной запрос, системную инструкцию, доступный контекст, инструменты и параметры генерации. Меняйте по одному фактору. Если одновременно обновить модель, промпт и документы, разницу будет трудно объяснить.
Для каждого примера полезно записывать:
- идентификатор теста;
- версию модели и инструкции;
- параметры генерации;
- сырой ответ;
- результат каждой проверки;
- причину ошибки, если её удалось определить.
Повторите запуск, если система недетерминирована или использует случайность. Один прогон показывает конкретный результат, но не обязательно типичное поведение. Не сводите оценку к среднему баллу: одинаковый общий результат может скрывать разные проблемы — например, больше ошибок в критичных случаях и меньше в простых.
Где подходят точные проверки, а где нужен человек
Точные проверки хорошо работают для форматов и ограниченных выходов: корректный ли JSON, присутствуют ли обязательные ключи, совпала ли метка, укладывается ли ответ в заданные ограничения. Они быстры и воспроизводимы, но ничего не говорят о смысле ответа, если проверяют только синтаксис.
Для свободного текста можно применять проверку по критериям, в том числе с помощью другой языковой модели. Но оценщик тоже может ошибаться или предпочитать определённый стиль. Поэтому не считайте его вердикт объективной истиной. Сначала вручную разберите часть результатов, сравните автоматические оценки с решениями людей и уточните формулировки критериев там, где оценки расходятся.
Исследование Zheng и соавторов о судьях на базе LLM описывает ограничения такого подхода, включая смещение в пользу определённых ответов и чувствительность к формулировке. Это не означает, что автоматические оценщики бесполезны; это означает, что их стоит использовать как инструмент сортировки и предварительной проверки, а не как единственный источник истины.
Проверьте, что тест измеряет нужный риск
До запуска решите, какие ошибки имеют разную цену. В демонстрационной классификации ошибочная метка может быть неудобством; в маршрутизации запросов в службу поддержки она может отправить обращение не туда. Один агрегированный балл не отражает это различие.
Разберите результаты по типам ошибок и важности сценариев. Отдельно отмечайте случаи, когда модель:
- уверенно сообщает то, чего нет во входных данных;
- пропускает обязательное поле;
- нарушает формат, который использует следующая система;
- выдаёт корректный ответ, но не выполняет инструкцию;
- отказывается в допустимом случае или отвечает там, где данных недостаточно.
Для ответа по документам полезно проверять не только итоговый текст, но и подтверждение ключевых утверждений источником. Если модель должна цитировать контекст, проверьте, действительно ли приведённый фрагмент поддерживает вывод, а не просто содержит похожие слова.
Минимальный пример проверки извлечения полей
Предположим, модель получает короткое описание обращения и должна вернуть категорию и срок. Для каждого примера задайте ожидаемые значения, затем проверьте структуру и содержимое отдельно:
python
import json
required = {«category», «deadline»}
def check_response(text, expected):
try:
result = json.loads(text)
except json.JSONDecodeError:
return {«valid_json»: False, «fields_match»: False}
valid_json = (
isinstance(result, dict)
and required.issubset(result.keys())
)
fields_match = valid_json and all(
result.get(key) == value
for key, value in expected.items()
)
return {
«valid_json»: valid_json,
«fields_match»: fields_match,
}
Эта проверка отвечает на два узких вопроса: удалось ли разобрать JSON и совпали ли поля с ожидаемыми значениями. Она не оценивает, были ли сами ожидания размечены правильно, корректно ли сформулирован запрос и подходит ли категория для реального процесса. Для этого нужны проверенные эталонные примеры и периодическая ручная ревизия.
Если допустимы разные варианты записи срока, сравнивайте нормализованные значения, а не строки. Если в данных иногда нет срока, задайте явное правило для такого случая — например, `null` или отдельную метку. Не исправляйте ошибки парсинга так, чтобы плохой ответ незаметно превращался в успешный.
Как не сделать вывод по слишком маленькой выборке
Маленький тестовый набор удобен для быстрой проверки, но его результаты применимы прежде всего к включённым в него случаям. Если в реальности встречаются короткие и длинные документы, разные языки или пустые поля, а в тесте есть только аккуратные примеры, оценка не описывает рабочую нагрузку.
Добавляйте новые примеры после реальных сбоев, сохраняя прежние контрольные случаи. Удалять неудобный тест только потому, что он снижает оценку, — плохая практика: сначала выясните, представляет ли он допустимый сценарий и правильно ли задано ожидаемое поведение.
Перед тем как принять новую версию, проверьте, что:
- условия сравнения зафиксированы и воспроизводимы;
- контрольные примеры не использовались для постоянной подгонки;
- ошибки просмотрены по типам, а не только по общей оценке;
- автоматические оценки сверены с ручной проверкой на части случаев;
- критичные ограничения и неизвестные сценарии записаны отдельно.
Такой набор не предскажет поведение на каждом будущем запросе. Зато он даст команде проверяемый способ сравнивать изменения и покажет, какие именно случаи стоит исследовать дальше.
