Версия eval-датасета: почему одной папки с вопросами недостаточно
Промпт получил оценку восемьдесят процентов, но за неделю из набора удалили неудобные вопросы и поправили эталоны. Сравнивать новое число со старым уже нельзя: изменился измерительный инструмент. Версионировать нужно не только модель и промпт, но и сами примеры, правила оценки и состав срезов.
Датасет удобно рассматривать как проверяемый артефакт с манифестом. Это позволяет восстановить, что именно считалось успехом в конкретном прогоне.
Сценарий и ожидаемое поведение
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Изменение | Новая версия нужна | Почему |
|---|---|---|
| Исправлен неверный эталон | Да | Меняется критерий ответа |
| Добавлены сложные случаи | Да | Меняется состав проверки |
| Исправлена подпись отчёта | Обычно нет для данных | Не меняются сами примеры |
Номер версии без журнала изменений мало помогает. Для каждого исправления сохраняйте причину и связь с примером. Удаление спорного случая должно быть видно, иначе качество можно незаметно улучшить очисткой теста вместо улучшения системы.
Идентификатор примера должен оставаться стабильным при исправлении формулировки, если это тот же сценарий. При смене смысла полезнее новый идентификатор со ссылкой на заменённый случай.
Проверочный протокол
В манифест включите список примеров, источник, дату разметки, схему ожидаемого результата и версию оценщика. Для каждого прогона сохраняйте идентификатор этого манифеста. Проверьте, что отчёт нельзя случайно пересчитать на уже изменённых данных.
Сделайте учебный эксперимент: измените один эталон и один срез, затем сравните отчёты. Система должна показать, что сравнение требует одинаковой версии либо отдельного пересчёта обеих моделей. Сохраняйте прежние версии с контролем доступа, а не перезаписывайте единственный файл поверх.
Когда нужна другая схема
Не каждое изменение требует полного ручного аудита. Но правила выпуска датасета должны быть явными. Персональные данные и закрытые документы нельзя бесконтрольно копировать во все архивы ради удобства воспроизводимости.
В оценке LLM отдельно задаются данные, эксперимент и оценщики; их версии нужно связывать в отчёте. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Утечка в LLM-eval: почему перефразы одного вопроса нельзя считать независимыми тестами, Откат LLM-релиза: почему старый код может не работать с новым индексом.
