Эталонный набор LLM устарел: как отличить регрессию от нового правила

Помощник начал отвечать по новой инструкции, а старый golden-набор помечает ответы ошибочными. Автоматический запрет релиза защищает устаревшее поведение. Обратная крайность — без проверки исправить все эталоны под новый ответ и скрыть настоящую регрессию.

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

Сценарий и ожидаемое поведение

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

Новая инструкция не делает старый эталон бесполезным для исторического вопроса. Нужно обновить привязку времени, а не просто заменить число во всех примерах. Если правило изменилось только для части клиентов, важна и область применения.

Результат «не совпал с эталоном» должен открывать расследование, а не сразу определять виновника. Проверьте корпус, версию поиска, интерпретацию вопроса и генерацию.

Проверочный протокол

При обновлении документов найдите связанные примеры по идентификаторам источников. Отметьте их на пересмотр и сохраните прежнюю версию набора. Для каждого изменения запишите причину и подтверждённую дату действия.

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

Когда нужна другая схема

Автоматическая связь тестов с документами может быть неполной. Нужен регулярный просмотр критичных сценариев и контроль качества метаданных. Даже свежий набор не гарантирует покрытия новых пользовательских намерений.

Данные и критерии оценки следует поддерживать как отдельные артефакты; актуальность эталона определяется источником и задачей. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.

Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Качество LLM упало без релиза: как отличить дрейф запросов от поломки модели, Тайм-ауты в LLM-eval: как не улучшить метрику удалением неудачных ответов.