Как проверять качество ответов модели: набор примеров вместо ощущений

Правка промпта, смена модели, новый способ поиска фрагментов — после каждого изменения возникает вопрос: стало лучше или хуже? Без набора примеров ответ на него сводится к впечатлению того, кто последним смотрел на экран.

Что такое тестовый набор

Это список реальных запросов с эталонными ответами или хотя бы с критериями, по которым ответ считается приемлемым. Тридцати-пятидесяти примеров достаточно, чтобы заметить ухудшение.

Собирать их надо из настоящих обращений, а не придумывать за столом. Придуманные примеры всегда удобнее реальных и создают ложное ощущение, что всё работает.

Из чего он состоит

Типовые случаи показывают базовое качество. Пограничные — устойчивость к необычным формулировкам. Заведомо плохие проверяют, умеет ли система отказывать: на запрос вне своей области она должна честно сказать, что не знает, а не сочинить ответ.

Как оценивать

Три способа, от простого к сложному.

**Точное совпадение.** Работает там, где ответ формальный: извлечённое поле, категория, да или нет. Проверяется кодом, стоит ноль.

**Проверка человеком.** Полсотни ответов просматриваются вручную по чек-листу. Медленно, но надёжно и годится для любых задач.

**Оценка моделью.** Другая модель сравнивает ответ с эталоном по заданным критериям. Быстро и дёшево, но требует калибровки: сверьте её вердикты с человеческими хотя бы один раз.

Как этим пользоваться

Заведите правило: любое изменение промпта, модели или поиска сопровождается прогоном набора. Результат записывается рядом с версией.

Через несколько итераций появляется история, из которой видно не только текущее качество, но и направление движения. Без неё команды регулярно откатывают полезные правки и внедряют вредные.

Полезнее всего не абсолютная цифра, а сравнение двух версий на одном и том же наборе. «86 % приемлемых» само по себе не значит ничего, а «было 74, стало 86» — значит.

Чего измерять не стоит

Средний балл по всем задачам сразу. Если чат-бот и разбор документов живут в одном показателе, ухудшение в одном скроется за улучшением в другом.

Разделите набор по сценариям и смотрите на них отдельно. Это дороже ровно на одну таблицу.

Что делать с расхождениями

Не бросайтесь править промпт после первого же неудачного ответа. Сначала разберите, в чём именно поломка: не нашлись данные, нашлись, но неверно пересказаны, или задача сформулирована неоднозначно и эталон спорный.

Третий случай встречается чаще, чем кажется. Иногда правильный вывод из прогона — уточнить эталон, а не менять систему.

Кто этим занимается

Самая частая причина, по которой набор примеров не появляется, — непонятно, чья это работа. Разработчик считает, что оценивать качество текста должен продукт, продукт — что это техническая задача.

Разделение, которое обычно работает: набор примеров и эталоны собирает тот, кто отвечает за содержание — руководитель поддержки, редактор, методолог. Прогон и таблицу результатов делает разработчик. Решение о выкате принимают вместе.

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

Полезная привычка — держать набор в репозитории рядом с кодом, в обычном текстовом формате. Тогда он попадает в код-ревью, историю изменений и не теряется при смене людей.

Не пытайтесь сразу автоматизировать всё. Первый прогон можно сделать вручную в таблице: пятьдесят строк, три колонки — вопрос, ответ, вердикт. Этого достаточно, чтобы принять решение по конкретной правке, а инструменты появятся, когда прогоны станут частыми.

С чего начать

Выгрузите пятьдесят последних реальных запросов. Разметьте ожидаемые ответы — это займёт несколько часов. Прогоните текущую версию и запишите результат.

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

Отдельно фиксируйте, какая версия модели использовалась при прогоне. Поставщики обновляют модели молча, и ответ на тот же промпт через месяц может измениться. Запись версии превращает необъяснимое «внезапно стало хуже» в понятную и проверяемую причину.