Оценивать ответы LLM по одному удачному примеру — всё равно что выбирать библиотеку по скриншоту демо. На реальных запросах меняются формулировки, контекст и требования к точности. Чтобы сравнение моделей помогало принять решение, нужны зафиксированные критерии, одинаковый набор входных данных и повторяемая процедура.
Ниже — компактный способ собрать такую проверку для классификатора, помощника поддержки или внутреннего RAG-сервиса. Он не требует большой инфраструктуры, но позволяет отделить качество модели от впечатления проверяющего.
Оценка ответов LLM начинается с решения, которое вы хотите принять
Сначала определите, для чего нужен тест. Вопрос «какая модель лучше?» слишком широк: одна модель может точнее извлекать данные, другая — следовать формату, третья — реже отказываться от допустимых запросов.
Сформулируйте конкретное решение: например, можно ли заменить текущую модель в задаче извлечения суммы и валюты из счетов без роста ошибок. Тогда измеряемые свойства становятся яснее:
- корректность извлечённых полей;
- соблюдение заданной JSON-схемы;
- доля пропусков и выдуманных значений;
- стоимость и задержка, если они влияют на выбор.
Не объединяйте всё в один балл, пока не поняли, как этот балл будет использоваться. Среднее значение может скрыть критичный провал: модель, которая чаще ошибается на редких, но дорогих случаях, иногда хуже модели с чуть меньшей общей точностью.
Соберите тестовые примеры до выбора победителя
Небольшой набор для первой проверки можно составить из реальных запросов и ожидаемых результатов. Удалите персональные и конфиденциальные данные, а затем включите не только типичные случаи, но и варианты, на которых система может сломаться: неполный ввод, неоднозначность, неверный формат, отсутствующее значение.
Для каждого примера сохраните вход, эталонный ответ и краткое объяснение требований. Например:
- Вход: «Счёт на 1 250,00 EUR, дата 4 февраля 2025».
- Ожидаемый результат: `{«amount»:1250.00,»currency»:»EUR»,»date»:»2025-02-04″}`.
- Критерии: сумма числовая, валюта сохранена, дата нормализована, дополнительные поля не добавлены.
Разделите примеры на разработочную и проверочную части. Первую используйте, чтобы уточнять инструкцию или настройки. Вторую не трогайте до сравнения кандидатов: если многократно подбирать решение по одним и тем же примерам, тест постепенно перестаёт быть независимой проверкой.
Размер набора зависит от риска и разнообразия запросов. Десять примеров годятся для отладки формата, но не дают надёжной оценки редких ошибок. Сотни примеров тоже не спасут, если все они почти одинаковые. Важнее покрыть реальные классы случаев и заранее записать, откуда взяты данные.
Запишите рубрику так, чтобы два человека применили её одинаково
Критерий «ответ хороший» не воспроизводим. Рубрика должна описывать наблюдаемое поведение и различать уровни результата. Для извлечения данных можно использовать такую шкалу:
- 2 — верно: все требуемые поля соответствуют источнику;
- 1 — частично: есть полезные значения, но допущена некритичная ошибка или пропуск;
- 0 — неверно: ключевое значение ошибочно, выдумано или результат непригоден для обработки.
Для соблюдения формата удобнее отдельная проверка «да/нет»: разбирается ли ответ как JSON и соответствует ли схеме. Не смешивайте форму и смысл в одном критерии — иначе непонятно, что именно улучшилось после изменения промпта.
Отдельно определите критические ошибки. Например, неверная сумма может быть критичнее пропущенного необязательного поля. Если у критериев разные последствия, задайте веса до запуска теста и объясните их. Иначе итоговая оценка будет отражать случайный выбор весов, а не потребности продукта.
Сравнивайте модели на одинаковых входах и настройках
Каждый кандидат должен получить один и тот же набор входов, инструкцию и доступный контекст. Зафиксируйте идентификатор модели, дату теста, параметры генерации и версию промпта. При изменении любого из этих компонентов сравнение уже не является чистым: разницу нельзя уверенно приписать только модели.
Для генерации с вариативными ответами запустите часть теста несколько раз. Один прогон показывает конкретное поведение, но не обязательно его устойчивость. Сохраните все результаты, а не только лучший ответ.
Полезно сравнивать не только общий процент успешных случаев, но и разбивку по типам ошибок: формат, пропуск, неверная интерпретация, неподтверждённое утверждение. Такая картина подсказывает, что делать дальше: менять модель, инструкции, постобработку или сам процесс сбора контекста.
Используйте автоматического оценщика только после калибровки
LLM-as-a-judge может ускорить проверку свободных текстовых ответов, но не становится объективным просто потому, что выставляет числовой балл. Исследование Zheng и соавторов обнаружило у оценщиков на базе LLM систематические предпочтения, в том числе чувствительность к позиции ответа. Поэтому при попарном сравнении меняйте порядок кандидатов и проверяйте, сохраняется ли победитель.
В инструкции оценщику задайте узкие критерии, приложите вход и эталон, попросите указать конкретные фрагменты, подтверждающие оценку. Если задача допускает программную проверку — например, валидность JSON или совпадение нормализованной даты — используйте код, а не суждение модели.
Сверьте автоматические оценки на подмножестве с оценками человека. Измерьте не только совпадение итоговых баллов, но и расхождения по каждому критерию. Если оценщик систематически принимает правдоподобный, но не подтверждённый ответ, его нельзя использовать для автоматического допуска модели без дополнительной проверки.
Проведите ручную проверку расхождений
Особенно полезны случаи, где кандидаты расходятся или автоматический оценщик не согласен с человеком. Просмотрите их отдельно и классифицируйте причину: неоднозначная рубрика, ошибка эталона, особенность входных данных или реальный дефект модели.
Это помогает не «чинить» тест под желаемый результат. Если эталон неполон, исправьте его и повторно прогоните всех кандидатов. Если критерий допускает несколько корректных формулировок, уточните правило и проверьте, не меняет ли это прежнее сравнение.
Для субъективных задач, например качества объяснения, полезна независимая оценка несколькими людьми на выборке. Сначала пусть каждый оценит ответы самостоятельно, затем разберите расхождения. Единогласие не гарантировано, но сами разногласия показывают, какие части рубрики расплывчаты.
Отчёт должен показывать ошибки, а не только рейтинг
Короткий отчёт о тестировании должен позволять повторить эксперимент. Запишите:
задачу и критерии успеха;
происхождение и состав набора;
3. версии моделей, промпта и параметры запуска;
4. результаты по каждому критерию и типу случая;
5. примеры ошибок и ограничения проверки.
Не называйте разницу значимой, если она основана на нескольких примерах или нестабильных прогонах. Для важных решений увеличьте набор, повторите запуск и проверьте, сохраняется ли преимущество на отложенных данных. Если цена ошибки различается, отдельно покажите критические сбои, а не прячьте их в среднем балле.
Что проверить перед использованием результата
Перед тем как менять модель или выпускать новую версию, убедитесь, что тестовый набор не содержит утечек и чувствительных данных, критерии соответствуют реальному процессу, а оценщик проверен на человеческой выборке. Сохраните версию набора и повторяйте оценку после изменений модели, промпта, инструментов или источников контекста.
Минимальный следующий шаг — выбрать одну конкретную задачу, собрать примеры типичных и сложных входов, записать рубрику до запуска и прогнать два варианта в одинаковых условиях. Такой тест не докажет универсальное превосходство одной модели, но даст проверяемый ответ на вопрос, который действительно важен для вашего приложения.
