РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-30
Утечка тестовых данных: почему оценка LLM может быть завышена
Порядок работы с контрольными примерами, когда промпт и правила регулярно меняют по результатам теста.
Если один набор примеров используют для настройки промпта и для заявления итогового качества, оценка перестаёт быть независимой. Даже без обучения весов команда может подстроить инструкции, маршрутизацию и правила проверки под знакомые случаи. Отделите рабочий набор разработки от закрытого контрольного и фиксируйте происхождение примеров. Хороший результат на известном тесте полезен для регрессии, но не доказывает качество на новых запросах. Не называйте отсутствие найденных дублей доказательством отсутствия любой утечки.
1. Разделите назначение наборов
Создайте набор для разработки и отдельный набор для финальной проверки. В первый можно возвращаться после каждого изменения, разбирать ошибки и добавлять пояснения в промпт. Второй открывайте по установленной процедуре, когда кандидат уже выбран. Если результаты финальной проверки стали основой новой настройки, считайте эти примеры освоенными и подготовьте новую независимую проверку. Сохраняйте историю использования набора, чтобы не называть его закрытым только из-за имени файла.
2. Ищите не только одинаковые строки
Разные вопросы могут относиться к одному документу, клиенту или шаблону обращения. Случайное разделение строк оставляет почти одинаковые случаи по обе стороны границы. Группируйте связанные примеры до разделения и проверьте близкие дубли. Для временных задач учитывайте дату доступности информации. Документация scikit-learn объясняет общий принцип: сведения тестового набора не должны участвовать в настройке. Для LLM-приложения это относится и к ручному редактированию инструкции после просмотра ответов.
3. Проверьте контекст и оценщика
Убедитесь, что эталонный ответ не попадает в промпт, retrieval-контекст или демонстрационный пример случайно. Если тест предполагает поиск по документу, сам документ может быть допустимым входом, а готовое решение — уже утечкой. Опишите эту границу заранее. Для оценщика на базе LLM отделите критерии от информации о том, какая система считается фаворитом. Проверяйте случаи, где формально похожая формулировка скрывает неправильное значение или неподтверждённый вывод.
4. Публикуйте воспроизводимый результат
Сохраните версии модели, промпта, инструментов, индекса и набора. Запишите правила пропуска примеров и обработки технических ошибок. Показывайте число принятых случаев и причины отклонения вместо одного процента без контекста. Не смешивайте независимую оценку и регрессионный прогон в одну цифру. Если историю обучения внешней модели проверить нельзя, обозначьте это ограничение отдельно: собственное корректное разделение не доказывает, что публичный бенчмарк никогда не встречался поставщику.
Частые вопросы
Нужен ли закрытый набор, если веса не обучаются?
Да. Промпт, параметры и выбор маршрута тоже меняются по ошибкам. Это может подстроить приложение под известные примеры.
Все ли похожие вопросы нужно удалять?
Нет. Сначала определите реальную единицу независимости. Связанные варианты можно оставить в одной группе и разделять наборы по группам.
Можно ли использовать прежний тест для регрессии?
Да, но называйте его регрессионным. Для вывода о новых данных нужна отдельная проверка, не использованная при настройке.
Доказывает ли хороший результат качество в production?
Нет. Нужны представительные данные, явные критерии и наблюдение за реальными ошибками. Известный тест покрывает только свой сценарий.