Утечка в LLM-eval: почему перефразы одного вопроса нельзя считать независимыми тестами

Команда настроила промпт на вопросе «как вернуть товар», а затем проверила его на перефразе «как оформить возврат покупки». Формально строки разные, но проверяется почти тот же случай. Итоговая оценка может выглядеть сильнее, чем поведение на действительно новых намерениях.

Для оценки разделяйте не только тексты, но и смысловые группы: исходный документ, тип проблемы, клиента или сценарий. Граница зависит от того, на какое обобщение вы рассчитываете.

Разбор на примере

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

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

Утечка возникает и при синтетической генерации: один документ превращают в обучающие примеры и одновременно в «неизвестный» контрольный набор без разделения сценариев.

Порядок диагностики

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

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

Что этот способ не гарантирует

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

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

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

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