Суть. Систематическая проверка качества ответов вместо ощущения «вроде лучше». Нужна с первого дня: без неё любое изменение — промпта, модели, источника данных — это ставка вслепую, а откат к прошлой версии невозможен, потому что не с чем сравнить.
Слои проверки
| Слой | Что проверяет | Чем |
|---|---|---|
| Набор примеров | Типовые запросы с эталонными ответами | Автоматическое сравнение |
| Проверка правил | Формат, обязательные поля, запрещённые темы | Код, а не модель |
| Оценка моделью | Полнота, точность, тон | Отдельная модель по описанной шкале |
| Человек | Спорные и новые случаи | Разметка выборки |
| Обратная связь пользователей | Реальные провалы | Оценка ответа в интерфейсе |
С чего начать
Тридцать-пятьдесят реальных запросов с эталонными ответами дают больше, чем сложная система. Главное — набор растёт: каждый найденный провал добавляется в него, чтобы не повториться. Это и есть основной механизм улучшения.
Когда применять
С первого дня работы над любым внедрением языковой модели. Без набора проверочных задач невозможно ответить на вопрос, стало ли лучше после изменения подсказки, модели или способа поиска, — а меняются они постоянно.
Что измерять
| Свойство | Как проверяется | Кто оценивает |
|---|---|---|
| Фактическая верность | Совпадение с эталоном и наличие источника | Эксперт предметной области |
| Полнота | Все ли части вопроса закрыты | Эксперт или модель-судья |
| Следование формату | Автоматическая проверка структуры ответа | Скрипт |
| Отказ отвечать | Доля правильных «не знаю» на вопросах без ответа | Скрипт |
| Безопасность | Поведение на провокационных и вредных запросах | Отдельный набор |
| Стоимость и задержка | Замер на том же наборе | Скрипт |
Как собрать набор
- Взять реальные вопросы пользователей, а не придуманные командой, — они устроены иначе.
- Пятьдесят задач для первого набора достаточно; важнее покрытие типов, чем количество.
- Обязательно включить: типовые вопросы, редкие случаи, вопросы без ответа в данных, неоднозначные формулировки.
- Зафиксировать эталонные ответы письменно и с указанием источника.
- Хранить набор в системе контроля версий рядом с кодом — он часть продукта.
Модель как судья
Оценивать ответы другой моделью дешевле, чем людьми, и это работает — но с оговорками. Судья систематически завышает оценку длинным и уверенным ответам и плохо ловит фактические ошибки в узкой предметной области. Рабочая схема: судья прогоняет весь набор, человек проверяет случайную выборку из его оценок и считает, насколько судье можно верить.
Где ломается
Проверяют на тех же примерах, на которых настраивали. Результат всегда отличный и ничего не значит.
Доверяют оценке модели без калибровки. Модель-судья имеет собственные склонности: любит длинные ответы и уверенный тон. Её оценки надо хотя бы раз сверить с человеческими.
Меряют только точность. В рабочем применении не менее важны отказ отвечать при недостатке данных и стабильность формата.
- Набор собран после запуска. Тогда он неизбежно подстроен под текущее поведение системы и перестаёт что-либо ловить.
- Одна общая оценка. Средний балл скрывает, что система стала лучше на типовых вопросах и хуже на редких.
- Нет замера отказов. Система, которая всегда что-то отвечает, показывает хорошие цифры и приносит вред.
- Публичные рейтинги вместо своего набора. Они измеряют другое и на ваших документах ничего не предсказывают.