Контаминация бенчмарков больших языковых моделей

Материал из MachineLearning.

Версия от 12:34, 6 июля 2026; Miraslava Ladutska (Обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

Статья написана с использованием LLM ChatGPT (GPT-5.5) и проверена участником Miraslava Ladutska 6 июля 2026 (MSD).

Контаминация бенчмарков больших языковых моделей — попадание примеров из оценочных бенчмарков, их правильных ответов, решений, метаданных или близких переформулировок в данные, использованные при предобучении, дообучении, инструкционном обучении или настройке большой языковой модели. В результате качество модели на тесте может отражать не только обобщающую способность, но и узнавание ранее встречавшегося текста, шаблона решения или пары «вопрос — ответ».

[[Файл:Benchmark contamination LLM.svg|мини|справа|Схема контаминации бенчмарка: фрагменты тестовой выборки попадают в обучающий корпус, после чего оценка модели на бенчмарке может быть завышена.]]

Проблема стала особенно заметной с распространением трансформерных языковых моделей, обучаемых на больших веб-корпусах. В классическом машинном обучении исследователь обычно явно разделяет обучающую, валидационную и тестовую выборки. В обучении современных LLM используются миллиарды документов из веба, репозиториев кода, научных архивов, форумов, учебных сайтов и синтетических корпусов; поэтому публичный тестовый набор со временем может стать частью тех же данных, на которых обучаются новые модели.

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

Содержание

1 Краткая экспертная оценка
2 Терминология и базовые понятия
3 Исторический контекст
4 Математическая постановка
5 Таксономия контаминации
6 Источники контаминации
7 Методы обнаружения контаминации
8 Оценка влияния контаминации на качество
9 Методы снижения риска
10 Ограничения методов обнаружения
11 Практический протокол для исследователя
12 Эмпирические исследования и современные бенчмарки
13 Теоретические связи
14 Типичные ошибки при оценке LLM
15 Значение для исследований и практики
16 См. также
17 Примечания
18 Литература
19 Ссылки

Краткая экспертная оценка

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

Хороший отчёт о качестве LLM поэтому должен отвечать на два разных вопроса. Первый — насколько модель справляется с задачами данного типа. Второй — насколько сам протокол позволяет верить, что эти задачи были новыми для модели и для процедуры её настройки. В инженерной практике полезнее не спорить о «полной чистоте», которую почти невозможно доказать, а явно указывать проверенные источники данных, даты среза, методы поиска совпадений и чувствительность результата к удалению подозрительных примеров.

Терминология и базовые понятия

Бенчмарк, тестовая выборка и лидерборд

Бенчмарк в машинном обучении — стандартизованный набор данных, задач, метрик и протоколов, предназначенный для сравнения моделей. В задачах NLP бенчмарк обычно включает входные примеры, правильные ответы или критерии проверки, инструкцию по запуску модели и одну или несколько метрик качества.

В простейшей постановке бенчмарк задаёт тестовую выборку $\mathcal{D}_{\mathrm{test}}$ , на которой вычисляется агрегированная оценка качества. В задачах множественного выбора используется accuracy, в задачах извлечения ответа — exact match или F1, в задачах генерации кода — pass@ $k$ , в вероятностной оценке — log-likelihood или perplexity.

Статический бенчмарк фиксируется один раз и затем многократно используется разными исследовательскими группами. К таким наборам относятся MMLU, GSM8K, HellaSwag, BIG-bench и C-Eval.^[1]^[1]^[1]^[1]^[1] Динамический бенчмарк регулярно обновляет задания или строит их из свежих источников, что снижает риск попадания тестовых примеров в обучающие данные будущих моделей. Пример такого подхода — LiveBench.^[1]

Большая языковая модель

Большая языковая модель — параметрическая модель распределения текстовых последовательностей, обычно основанная на архитектуре трансформера. В авторегрессионной постановке модель оценивает вероятность следующего токена по предыдущему контексту:

$p_{\theta}(x_t \mid x_{<t}),$

где $\theta$ — параметры модели, $x_t$ — текущий токен, а $x_{<t}$ — последовательность предшествующих токенов. При предобучении минимизируется функция потерь, близкая к отрицательной логарифмической вероятности обучающих текстов:

$\mathcal{L}(\theta) = -\sum_{x \in \mathcal{D}_{\mathrm{train}}} \sum_{t=1}^{|x|} \log p_{\theta}(x_t \mid x_{<t}).$

После предобучения модель может проходить дообучение на инструкциях, обучение с подкреплением по человеческой обратной связи (RLHF), настройку на предпочтениях, фильтрацию ответов и другие формы постобучения. Контаминация возможна на любом из этих этапов: тестовые примеры могут попасть не только в исходный веб-корпус, но и в датасет инструкций, набор диалогов, таблицу предпочтений, синтетический корпус или данные для оценки безопасности.

Контаминация, утечка и мемоизация

Контаминацию бенчмарков следует отличать от нескольких близких понятий.

Утечка данных — нарушение независимости между обучением и проверкой модели. В классических задачах она возникает, если информация из тестовой выборки используется при выборе признаков, нормализации, подборе гиперпараметров или обучении. Контаминация бенчмарка является частным случаем утечки, но имеет более широкий масштаб: она может возникнуть не в одном эксперименте, а на уровне всей инфраструктуры публикации датасетов, лидербордов, учебных материалов и обучающих корпусов.

Мемоизация — способность модели воспроизводить фрагменты обучающих данных. Карлини и соавторы показали, что языковые модели могут запоминать редкие последовательности, а степень воспроизведения зависит от размера модели, числа повторов примера и длины подсказки.^[1] Контаминация не всегда требует дословной мемоизации: модель может получить преимущество, если видела формат задачи, фрагмент решения или частую переформулировку того же вопроса.

Утечка метки возникает, когда в обучающих данных присутствует правильный ответ $y_i$ к тестовому примеру $x_i$ . Для задач множественного выбора это может быть буква варианта; для математических задач — полный ход решения; для программирования — эталонная реализация или скрытые тесты.

Оценочная утечка возникает уже после обучения модели, если исследователь подбирает промпт, формат вывода, few-shot-примеры или стратегию декодирования по финальной тестовой выборке. В таком случае параметры модели не меняются, но сам протокол оценки адаптируется к тесту.

Исторический контекст

Утечка данных до появления LLM

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

Для LLM меняется масштаб. Исследователь часто не знает полного состава корпуса, а сами данные многократно копируются между сайтами, репозиториями и архивами. Проверка независимости превращается из простой операции над таблицами в задачу поиска совпадений в распределённой веб-экосистеме.

Веб-корпуса и рост риска контаминации

Корпуса предобучения строятся из Common Crawl, книг, научных статей, форумов, репозиториев кода, документации и образовательных материалов. Публичный бенчмарк, однажды опубликованный в статье или на GitHub, может появиться в ноутбуках, блогах, обучающих курсах, обсуждениях ошибок модели и зеркалах датасетов. Один тестовый пример способен существовать в десятках вариантов: исходный вопрос, перевод, сокращение, разбор решения, таблица с ответом, комментарий к ошибке, синтетическая переформулировка.

Поэтому контаминация редко сводится к совпадению одного файла с другим. Модель может не видеть оригинальный JSON датасета, но видеть страницу, где тот же вопрос обсуждается вместе с правильным ответом.

GPT-3 и ранняя практика деконтаминации

В работе о GPT-3 авторы явно анализировали риск попадания тестовых данных в предобучающий корпус и выполняли поиск пересечений с рядом оценочных наборов.^[1] Значение этой работы состоит не только в конкретной методике, но и в установлении новой нормы: для моделей, обученных на веб-масштабе, публичный тест не следует считать автоматически независимым.

Математическая постановка

Обозначения

Пусть $\mathcal{D}_{\mathrm{train}}$ — совокупность данных, использованных при обучении, дообучении или постобучении модели, а $\mathcal{D}_{\mathrm{test}}$ — тестовая выборка бенчмарка. Модель обозначается через $M_{\theta}$ , где $\theta$ — параметры. Отдельный тестовый пример имеет вид $(x_i,y_i)$ , где $x_i$ — вход, а $y_i$ — правильный ответ, метка, эталонное решение или критерий проверки.

Показатель качества на одном примере обозначим как

$s(M_{\theta},x_i,y_i),$

а агрегированную оценку на тестовой выборке — как

$S(M_{\theta},\mathcal{D}_{\mathrm{test}}) = \frac{1}{|\mathcal{D}_{\mathrm{test}}|} \sum_{(x_i,y_i)\in \mathcal{D}_{\mathrm{test}}} s(M_{\theta},x_i,y_i).$

Формальное определение контаминации

Пусть $z_j \in \mathcal{D}_{\mathrm{train}}$ — документ, окно токенов или иной фрагмент обучающего корпуса. Введём функцию близости

$r(x_i,z_j) \in \{0,1\},$

где $r(x_i,z_j)=1$ означает, что тестовый вход $x_i$ и обучающий фрагмент $z_j$ совпадают или считаются достаточно близкими по выбранному критерию. Критерий может быть точным, например совпадение хеша, или приближённым: высокая доля общих $n$ -грамм, близость эмбеддингов, совпадение после нормализации или семантическая эквивалентность.

Доля контаминированных тестовых примеров задаётся как

$\rho = \frac{1}{|\mathcal{D}_{\mathrm{test}}|} \sum_{(x_i,y_i)\in \mathcal{D}_{\mathrm{test}}} \mathbf{1} \left[ \exists z_j\in \mathcal{D}_{\mathrm{train}}: r(x_i,z_j)=1 \right].$

Если проверяется наличие полной пары «вопрос — ответ», удобно определить

$\rho_{\mathrm{label}} = \frac{1}{|\mathcal{D}_{\mathrm{test}}|} \sum_{(x_i,y_i)\in \mathcal{D}_{\mathrm{test}}} \mathbf{1} \left[ \exists z_j\in \mathcal{D}_{\mathrm{train}}: r((x_i,y_i),z_j)=1 \right].$

Величины $\rho$ и $\rho_{\mathrm{label}}$ зависят от выбранного отношения $r$ , версии обучающего корпуса, токенизации, способа разбиения документов и решения о том, считать ли перевод или переформулировку контаминацией.

Инфляция метрики

Практический вопрос состоит не только в том, пересекались ли данные, но и в том, изменило ли это оценку модели. Пусть $\mathcal{D}_{\mathrm{test}}^{\mathrm{obs}}$ — фактически использованный тест, а $\mathcal{D}_{\mathrm{test}}^{\mathrm{clean}}$ — чистый тест той же предметной области и сложности. Тогда завышение метрики можно записать как

$\Delta = S(M_{\theta},\mathcal{D}_{\mathrm{test}}^{\mathrm{obs}}) - S(M_{\theta},\mathcal{D}_{\mathrm{test}}^{\mathrm{clean}}).$

Факт $\rho>0$ не гарантирует $\Delta>0$ . Модель могла видеть пример без ответа, не запомнить его, запомнить ошибочную метку или решить задачу независимо. Возможна и обратная ситуация: точного совпадения не обнаружено, но модель обучалась на множестве почти идентичных задач и поэтому получает преимущество на конкретном формате бенчмарка.

Разбиение на чистые и подозрительные примеры

Если тестовую выборку можно разделить на чистую и потенциально контаминированную части,

$\mathcal{D}_{\mathrm{test}} = \mathcal{D}_{\mathrm{clean}} \cup \mathcal{D}_{\mathrm{cont}}, \qquad \mathcal{D}_{\mathrm{clean}} \cap \mathcal{D}_{\mathrm{cont}} = \varnothing,$

то сравнивают

$S_{\mathrm{clean}} = S(M_{\theta},\mathcal{D}_{\mathrm{clean}})$

$S_{\mathrm{cont}} = S(M_{\theta},\mathcal{D}_{\mathrm{cont}}).$

Разность

$\delta = S_{\mathrm{cont}}-S_{\mathrm{clean}}$

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

Статистическая проверка гипотез

Один из формальных подходов — проверка гипотез

$H_0: S_{\mathrm{cont}}-S_{\mathrm{clean}}=0,$

$H_1: S_{\mathrm{cont}}-S_{\mathrm{clean}}>0.$

Для проверки применяются бутстрэп, перестановочные тесты, доверительные интервалы для разности долей, байесовские модели и сравнение с контрольными наборами. Более надёжная схема сопоставляет каждому подозрительному примеру новый пример той же сложности: переформулировку, задачу с изменёнными сущностями или независимый аналог из той же категории.

Таксономия контаминации

Дословная контаминация

Дословная контаминация возникает, когда тестовый пример или его значимая часть присутствует в обучающем корпусе без изменений. В задачах множественного выбора это может быть полный блок: условие, варианты ответа, правильный вариант и объяснение. Такая форма проще всего обнаруживается хешированием, поиском подстрок или сравнением $n$ -грамм.

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

Частичная контаминация

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

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

Семантическая контаминация

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

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

Контаминация меток

Контаминация меток возникает, когда в данных присутствует соответствие между входом и правильным выходом:

$(x_i,y_i)\in \mathcal{D}_{\mathrm{train}}.$

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

Контаминация задачи

Контаминация задачи означает, что модель обучалась не на конкретных тестовых примерах, а на большом числе задач того же узкого формата. Граница между такой контаминацией и честным обобщением не всегда очевидна. Обучение на школьной арифметике не является нарушением для арифметического бенчмарка; обучение на инструкциях вида «реши задачу из GSM8K пошагово» уже может адаптировать модель к конкретному оценочному протоколу.

Непрямая контаминация закрытых моделей

Для закрытых LLM обучающие корпуса и процедуры постобучения обычно неизвестны внешним исследователям. Контаминация может возникнуть косвенно: пользователи отправляют тестовые примеры в API, публикуют промпты и ответы, другие системы собирают эти данные, а будущие модели обучаются на производных корпусах. Balloccu и соавторы рассматривают такие практики как отдельный риск оценки закрытых моделей.^[1]

Источники контаминации

Публичные датасеты и зеркала

Основной источник контаминации — открытая публикация тестовых наборов. Открытость необходима для воспроизводимости, но делает тесты видимыми для поисковых систем и веб-краулеров. Один датасет может существовать в официальном репозитории, зеркалах на GitHub, карточках Hugging Face, Kaggle-ноутбуках, блогах и архивах.

Удаление исходного файла не гарантирует исчезновения данных: копии могут сохраняться в форках, кэшах, учебных материалах и производных датасетах.

Научные статьи и разборы ошибок

Статьи о моделях часто приводят примеры успехов и ошибок на известных бенчмарках. Такой анализ повышает прозрачность, но одновременно раскрывает тестовые вопросы, ответы и типичные объяснения. Особенно рискованны таблицы, где рядом указаны вопрос, правильный ответ, ответ модели и комментарий автора.

Образовательные материалы и форумы

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

Синтетические данные

Синтетические корпуса могут наследовать контаминацию от моделей-генераторов. Если модель-учитель видела тестовые примеры или получила их в запросах, она может создавать переформулировки, решения и инструкции, которые затем попадут в обучение модели-ученика. В результате исходный бенчмарк распространяется не как точная копия, а как множество близких текстов.

Подбор промптов по тестовой выборке

Если исследователь многократно проверяет разные промпты на финальном тесте и оставляет лучший, тестовая выборка фактически становится валидационной. В LLM-оценке это особенно существенно: результат может заметно зависеть от формата инструкции, порядка few-shot-примеров, ограничения длины ответа, температуры и правил самопроверки.

Методы обнаружения контаминации

White-box методы

White-box методы применяются, когда доступен обучающий корпус или его существенная часть. В таком случае используют точное сравнение строк, хеширование полных примеров и окон токенов, сравнение множеств $n$ -грамм, MinHash, locality-sensitive hashing, поиск почти дубликатов, сравнение URL, доменов и метаданных, а также поиск по эмбеддингам.

Точное хеширование выявляет копии, но не перефразировки. $n$ -граммные методы устойчивее к небольшим изменениям, но зависят от токенизации, длины $n$ и порога совпадения. MinHash и LSH позволяют масштабировать поиск на большие корпуса, однако найденные совпадения требуют ручной или полуавтоматической валидации.

Дедупликация обучающих корпусов связана с деконтаминацией, но не равна ей. Lee и соавторы показали, что удаление дубликатов снижает мемоизацию и уменьшает train-test overlap в стандартных наборах данных.^[1] Однако дедупликация внутри корпуса не гарантирует отсутствия пересечений с внешним бенчмарком.

Black-box методы

Black-box методы используются, когда обучающие данные неизвестны, а модель доступна только через ответы или вероятности токенов. Они не доказывают наличие конкретного документа в обучении, но позволяют обнаружить статистические признаки знакомости: различие между исходными и переформулированными примерами, аномально высокую уверенность, чувствительность к перестановке вариантов ответа, необычные логарифмические вероятности правильных ответов, а также расхождения между моделями с разными датами обучения.

Если модель правильно отвечает на исходный вопрос, но заметно хуже решает смысловую переформулировку той же сложности, это может указывать на узнавание поверхности текста. Такой вывод требует осторожности: переформулировка может случайно изменить сложность, неоднозначность или распределение ответов.

Методы на основе распределения ответов

Dong и соавторы предложили CDD — Contamination Detection via output Distribution. Метод использует идею, что модель, видевшая пример при обучении, может давать более концентрированное распределение ответов, чем на незнакомом примере.^[1] Такой подход полезен для закрытых моделей, если доступны многократные сэмплы или логвероятности, но чувствителен к температуре, режиму декодирования и калибровке модели.

Performance-based методы

Performance-based методы определяют контаминацию через негенерализующееся завышение качества. Метод ConStat сравнивает производительность модели на основном и референсном бенчмарках относительно набора референсных моделей и статистически оценивает аномалии.^[1] Преимущество подхода — ориентация на фактический эффект для оценки. Ограничение — необходимость подобрать сопоставимые контрольные задачи.

Data Contamination Quiz

Data Contamination Quiz формулирует обнаружение контаминации как серию вопросов множественного выбора, проверяющих знакомство модели с конкретным датасетом. Метод создаёт возмущённые варианты примеров и оценивает, может ли модель выбрать исходный или связанный с ним вариант с вероятностью, превышающей случайную.^[1] Метод применим к закрытым моделям, но требует дизайна вопросов, не решаемых по общим знаниям или артефактам формулировки.

Оценка влияния контаминации на качество

Метрики влияния

Влияние контаминации зависит от задачи. Для классификации измеряют прирост accuracy; для QA — exact match и F1; для программирования — pass@ $k$ ; для вероятностной оценки — log-likelihood, perplexity и калибровку.

Если $A_{\mathrm{cont}}$ — accuracy на подозрительных примерах, а $A_{\mathrm{clean}}$ — accuracy на чистых примерах, то простая оценка различия имеет вид

$\Delta_A = A_{\mathrm{cont}}-A_{\mathrm{clean}}.$

Иногда используют нормировку

$R_A = \frac{A_{\mathrm{cont}}-A_{\mathrm{clean}}} {1-A_{\mathrm{clean}}},$

которая показывает, какая доля оставшихся ошибок исчезает на подозрительном подмножестве. Такая величина осмысленна только при сопоставимой сложности примеров.

Факторы, усиливающие эффект

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

Связь между масштабом модели, повторяемостью данных и мемоизацией была подробно исследована в работах по извлечению и количественной оценке запоминания.^[1]^[1]

Контаминация без роста метрики

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

наличие пересечения данных;
долю и тип контаминации;
измеримый эффект на метрику.

Экосистемный эффект

Контаминация часто возникает не в одном месте, а в цепочке: публикация бенчмарка, цитирование примеров, разбор ошибок, использование API, генерация синтетических данных, сбор новых корпусов. В этом смысле она связана с законом Гудхарта: когда показатель становится целью оптимизации, он постепенно теряет диагностическую силу.

Методы снижения риска

Дедупликация обучающих корпусов

Дедупликация удаляет точные и близкие копии документов, снижая повторяемость и риск мемоизации.^[1] Для борьбы с benchmark contamination она должна быть направленной: корпус проверяется не только сам против себя, но и против конкретных тестовых наборов.

Практически применяются:

списки запрещённых URL и доменов;
хеши тестовых примеров;
фильтрация benchmark-репозиториев;
удаление документов с высокой долей совпадающих $n$ -грамм;
аудит данных инструкционного обучения;
хранение версий датасетов и дат среза корпуса.

Слишком агрессивная фильтрация может удалить полезные данные: общеизвестные факты, стандартные задачи, цитаты законов, документацию или типовые фрагменты кода. Поэтому нужны отчёты о порогах, источниках и объёме удалённых данных.

Деконтаминация перед обучением

Деконтаминация — процедура удаления из $\mathcal{D}_{\mathrm{train}}$ фрагментов, пересекающихся с $\mathcal{D}_{\mathrm{test}}$ . Для каждого бенчмарка строятся представления тестовых примеров: исходный текст, нормализованный текст, токены, $n$ -граммы, хеши окон и эмбеддинги. Затем обучающий корпус сканируется на совпадения.

Отчёт о деконтаминации должен указывать:

какие бенчмарки проверялись;
какие версии датасетов использовались;
какие части примера сравнивались;
какие методы поиска применялись;
какие пороги считались совпадением;
сколько документов или токенов удалено;
проверялись ли данные постобучения.

Без этих деталей утверждение о деконтаминации трудно воспроизвести.

Закрытые и отложенные тестовые выборки

Закрытая тестовая выборка снижает риск прямого попадания примеров в обучение. Модель отправляет ответы на сервер оценки, а публичным становится только результат. Недостатки такого подхода — меньшая прозрачность, зависимость от поддерживающей организации и риск утечки через многочисленные запросы.

Отложенные тесты строятся из источников, появившихся после даты среза обучающих данных. Это естественно для новостей, новых научных статей, свежих соревнований по программированию и недавно опубликованных экзаменационных задач. Метод требует достоверной информации о датах обучения модели, которая часто недоступна для закрытых систем.

Динамические бенчмарки

Динамические бенчмарки регулярно обновляют задания. LiveBench использует свежие источники и объективно проверяемые ответы, чтобы снизить риск контаминации и субъективности оценки.^[1] Обзоры 2025 года рассматривают переход от статической к динамической оценке как один из основных ответов на проблему benchmark contamination.^[1]

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

Перефразирование и inference-time decontamination

Если бенчмарк уже утёк, его можно частично переиспользовать через controlled rewriting. Zhu и соавторы предложили Inference-Time Decontamination: метод обнаруживает подозрительные примеры и переписывает их без намеренного изменения сложности.^[1] В экспериментах авторы показывают снижение искусственно завышенной accuracy на GSM8K и MMLU.^[1]

Главная трудность — сохранить эквивалентность. Переформулировка может изменить сложность, убрать подсказку, добавить неоднозначность или нарушить баланс вариантов ответа. Поэтому такой подход требует автоматической и человеческой проверки.

Новые формы оценивания

Современная оценка LLM всё чаще сочетает несколько протоколов: свежие задачи с временным срезом, закрытые holdout-наборы, генерацию задач с формальной проверкой, adversarial evaluation, приватные прикладные тесты, интерактивные сценарии, проверку устойчивости к переформулировкам, а также анализ калибровки и отказов от ответа.

Цель состоит не в замене всех бенчмарков одним новым тестом, а в переходе от единственного числа к профилю качества: точность, устойчивость, калибровка, чувствительность к промпту, способность решать новые задачи и риск мемоизации.

Ограничения методов обнаружения

Невозможность доказать полное отсутствие контаминации

Даже тщательная проверка не доказывает абсолютную чистоту модели. Если обучающий корпус закрыт, можно проверять только косвенные признаки. Если корпус известен, приближённый поиск может пропустить перевод, перефразировку или фрагмент с изменённым порядком. Корректная формулировка результата должна быть ограниченной: «контаминация не обнаружена по заданной процедуре и при заданных порогах».

Семантические копии и сложность задачи

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

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

Закрытые модели

Для закрытых моделей обычно неизвестны состав обучающих данных, даты среза, источники инструкционного обучения, правила использования пользовательских запросов и изменения между версиями. Это делает выводы о контаминации вероятностными. Непрозрачность обучения снижает воспроизводимость и затрудняет честное сравнение с открытыми моделями.^[1]

Ложные сигналы уверенности

Высокая уверенность модели не доказывает контаминацию: вопрос может быть простым, факт — общеизвестным, а варианты ответа — неравновероятными. Низкая уверенность также не доказывает чистоту. Методы на логвероятностях должны учитывать длину ответа, токенизацию, формат вариантов и режим декодирования.

Практический протокол для исследователя

До обучения модели

На этапе подготовки данных рекомендуется:

зафиксировать дату среза корпуса;

описать основные источники;

исключить известные benchmark-репозитории и зеркала;

выполнить дедупликацию документов и окон токенов;

проверить корпус против планируемых бенчмарков;

отдельно проверить данные инструкционного обучения и RLHF;

сохранить хеши удалённых фрагментов;

документировать пороги и версии инструментов.

Во время оценки

При запуске бенчмарка рекомендуется:

не подбирать промпт на финальной тестовой выборке;

использовать отдельный dev-набор;

фиксировать шаблоны промптов до финальной оценки;

публиковать режим декодирования и число попыток;

проверять устойчивость к перестановке вариантов ответа;

считать доверительные интервалы;

отдельно оценивать чистые и подозрительные примеры;

сравнивать исходные вопросы с контролируемыми переформулировками.

После обнаружения контаминации

Если обнаружены пересечения, важнее всего не скрывать их и не сводить вывод к фразе «результат недействителен». В зависимости от доли и типа совпадений возможны несколько действий:

удалить подозрительные примеры и пересчитать метрику;
опубликовать отдельные оценки на $\mathcal{D}_{\mathrm{clean}}$ и $\mathcal{D}_{\mathrm{cont}}$ ;
заменить примеры новыми;
переписать задачи с контролем сложности;
отказаться от бенчмарка для данной модели;
явно указать ограничение в статье или отчёте.

Минимальный отчёт о чистоте оценки

Минимальные сведения для отчёта о benchmark contamination
Элемент	Что указать	Зачем нужно
Дата среза данных	Временную границу корпуса	Оценить риск временной контаминации
Источники	Домены, репозитории, книги, датасеты	Проверить воспроизводимость и область действия выводов
Метод поиска	Хеши, $n$ -граммы, MinHash, эмбеддинги	Понять, какие типы совпадений процедура вообще способна обнаружить
Порог совпадения	Правило для $r(x,z)$	Интерпретировать величину $\rho$ и сравнивать отчёты между собой
Проверяемые части примера	Вопрос, варианты, ответ, решение	Различать поверхностную и меточную контаминацию
Раздельные метрики	Результаты на чистых и подозрительных примерах	Оценить влияние контаминации на итоговый балл
Код и версии	Скрипты, токенизацию, версии датасетов	Обеспечить повторяемость проверки

Эмпирические исследования и современные бенчмарки

GPT-3

В работе о GPT-3 контаминация рассматривалась как естественный риск обучения на больших веб-корпусах. Авторы проверяли пересечения с тестовыми наборами и оценивали влияние найденных совпадений на результаты.^[1] Эта работа стала одним из ранних примеров систематической деконтаминации в публикациях о LLM.

MMLU, GSM8K, HellaSwag и C-Eval

MMLU стал одним из основных тестов на академические и профессиональные знания.^[1] Его популярность делает результаты удобными для сравнения, но повышает риск распространения вопросов в обучающих материалах.

GSM8K проверяет многошаговое арифметическое рассуждение.^[1] Для него особенно важна контаминация решений: если модель видела не только ответ, но и цепочку рассуждений, метрика может переоценивать способность к самостоятельному выводу.

HellaSwag был построен с adversarial filtering, чтобы сделать задачу трудной для моделей и лёгкой для человека.^[1] Этот пример показывает, что сложность бенчмарка меняется с развитием моделей и данных.

C-Eval расширяет оценку foundation models на китайский язык и многоуровневые экзаменационные задачи.^[1] Для многоязычных бенчмарков важны переводы, локальные учебные сайты и двуязычные материалы, которые усложняют поиск контаминации.

Открытые отчёты о контаминации

Li, Guerin и Lin предложили открытый pipeline для анализа контаминации и исследовали более $15$ LLM на нескольких QA-бенчмарках.^[1] Значение таких работ — в переносе анализа из внутренних отчётов разработчиков в воспроизводимую академическую практику.

Deng и соавторы исследовали контаминацию в современных бенчмарках и методы её выявления для открытых и закрытых моделей.^[1]

Обзоры 2024–2025 годов

Xu и соавторы систематизируют определения benchmark data contamination, источники, методы обнаружения и альтернативные формы оценки.^[1] Deng и соавторы описывают спектр контаминации от обнаружения до remediation-подходов.^[1] Обзор Chen и соавторов 2025 года отдельно рассматривает переход от статических тестов к динамической оценке.^[1]

Извлечение обучающих данных

Контаминация бенчмарков связана с более общей проблемой извлечения обучающих данных. Работы по training data extraction показывают, что LLM могут воспроизводить фрагменты обучающего корпуса при специальных запросах, включая редкие строки и чувствительные данные.^[1]^[1] Для benchmark contamination это означает, что вопрос о знакомстве модели с тестом имеет не только методологический, но и эмпирически проверяемый аспект.

Теоретические связи

Обобщение и запоминание

Цель обучения с учителем — получить модель, работающую на новых данных из того же распределения. Контаминация нарушает новизну теста. Однако граница между обобщением и запоминанием не бинарна: модель может дословно помнить ответ, помнить шаблон решения, знать общий алгоритм или независимо вывести результат.

В задачах знаний это различие особенно тонкое. Если модель видела факт в тексте, это не обязательно утечка: языковая модель должна усваивать знания. Но если она видела конкретную тестовую пару $(x_i,y_i)$ , предназначенную для независимой проверки, протокол оценки нарушается.

Контаминация и калибровка

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

Контаминация и безопасность

Контаминация связана с безопасностью ИИ. Если модель способна запоминать тестовые задачи, она потенциально может запоминать и чувствительные фрагменты обучающих данных. Если разработчики оптимизируют модель под публичные safety-бенчмарки, поведение на них может перестать отражать устойчивость в реальных сценариях. Если злоумышленник внедряет данные в будущий обучающий корпус, возникает связь с отравлением данных.

Типичные ошибки при оценке LLM

Распространённые ошибки при оценке больших языковых моделей
Ошибка	Причина	Последствие	Снижение риска
Подбор промпта на тестовой выборке	Промпт воспринимается как интерфейс, а не часть протокола	Тест становится валидационным набором	Использовать отдельный dev-набор
Проверка только точных совпадений	Точное сравнение проще масштабировать	Семантические копии остаются незамеченными	Добавлять $n$ -граммы, MinHash и эмбеддинги
Публикация только общей accuracy	Лидерборды требуют одно число	Скрывается различие между чистыми и подозрительными примерами	Давать стратифицированные метрики
Игнорирование постобучения	Основное внимание уделяется предобучению	Контаминация через инструкции и RLHF не учитывается	Проверять все этапы обучения
Утверждение о чистоте без методики	Нет единого стандарта отчётности	Результат трудно воспроизвести	Публиковать пороги, код и версии данных
Сравнение моделей с разными датами среза	Даты обучения закрытых моделей неизвестны	Новая модель может иметь преимущество за счёт экспозиции тестам	Использовать временные и динамические бенчмарки

Значение для исследований и практики

Контаминация бенчмарков изменила представление о корректной оценке LLM. Для небольших моделей на фиксированных датасетах часто достаточно аккуратного train/dev/test-разбиения. Для больших языковых моделей требуется учитывать жизненный цикл данных: публикацию, копирование, обсуждение, использование в API, генерацию синтетических вариантов и повторное включение в новые корпуса.

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

Публичные бенчмарки остаются важным инструментом сравнения и воспроизводимости. Их результаты, однако, должны рассматриваться как часть более широкой системы доказательств: статические тесты, динамические бенчмарки, приватные holdout-наборы, анализ контаминации, проверка устойчивости и качественный разбор ошибок.

См. также

Примечания

Литература

Brown T. B., Mann B., Ryder N. et al. Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems, 2020.
Lee K., Ippolito D., Nystrom A., Zhang C., Eck D., Callison-Burch C., Carlini N. Deduplicating Training Data Makes Language Models Better. Proceedings of ACL, 2022.
Carlini N., Ippolito D., Jagielski M., Lee K., Tramer F., Zhang C. Quantifying Memorization Across Neural Language Models. ICLR, 2023.
Carlini N., Tramer F., Wallace E. et al. Extracting Training Data from Large Language Models. USENIX Security Symposium, 2021.
Nasr M. et al. Scalable Extraction of Training Data from (Production) Language Models. arXiv, 2023.
Balloccu S., Schmidtová P., Lango M., Dušek O. Leak, Cheat, Repeat: Data Contamination and Evaluation Malpractices in Closed-Source LLMs. EACL, 2024.
Deng C. et al. Investigating Data Contamination in Modern Benchmarks for Large Language Models. NAACL, 2024.
Dong Y. et al. Data Contamination and Trustworthy Evaluation for Large Language Models. Findings of ACL, 2024.
Li Y., Guerin F., Lin C. An Open-Source Data Contamination Report for Large Language Models. Findings of EMNLP, 2024.
Xu C., Guan S., Greene D., Kechadi M.-T. Benchmark Data Contamination of Large Language Models: A Survey. arXiv, 2024.
Deng C. et al. Unveiling the Spectrum of Data Contamination in Language Models: A Survey from Detection to Remediation. Findings of ACL, 2024.
Dekoninck J., Müller M. N., Vechev M. ConStat: Performance-Based Contamination Detection in Large Language Models. NeurIPS, 2024.
Zhu Q., Cheng Q., Peng R. et al. Inference-Time Decontamination: Reusing Leaked Benchmarks for Large Language Model Evaluation. Findings of EMNLP, 2024.
Golchin S., Surdeanu M. Data Contamination Quiz: A Tool to Detect and Estimate Contamination in Large Language Models. Transactions of the Association for Computational Linguistics, 2025.
Chen S., Chen Y., Li Z. et al. Benchmarking Large Language Models Under Data Contamination: A Survey from Static to Dynamic Evaluation. EMNLP, 2025.
White C. et al. LiveBench: A Challenging, Contamination-Free LLM Benchmark. arXiv, 2024.
Hendrycks D., Burns C., Basart S., Zou A., Mazeika M., Song D., Steinhardt J. Measuring Massive Multitask Language Understanding. ICLR, 2021.
Cobbe K., Kosaraju V., Bavarian M. et al. Training Verifiers to Solve Math Word Problems. arXiv, 2021.
Zellers R., Holtzman A., Bisk Y., Farhadi A., Choi Y. HellaSwag: Can a Machine Really Finish Your Sentence? ACL, 2019.
Srivastava A. et al. Beyond the Imitation Game: Quantifying and extrapolating the capabilities of language models. Transactions on Machine Learning Research, 2023.
Liang P. et al. Holistic Evaluation of Language Models. arXiv, 2022.
Huang Y. et al. C-Eval: A Multi-Level Multi-Discipline Chinese Evaluation Suite for Foundation Models. NeurIPS, 2023.

Ссылки

ACL Anthology — библиотека публикаций по обработке естественного языка и оценке языковых моделей.
arXiv: Computation and Language — препринты по языковым моделям и NLP.
HELM — платформа Stanford CRFM для комплексной оценки языковых моделей.
LiveBench — динамический бенчмарк для оценки больших языковых моделей.
Deduplicating text datasets — код для дедупликации текстовых корпусов из работы Lee и соавторов.
Data Contamination Quiz — репозиторий метода DCQ.
Leak, Cheat, Repeat — сопроводительный ресурс к исследованию косвенной утечки данных в закрытые LLM.

Источник — «http://machinelearning.ru/wiki/index.php?title=%D0%9A%D0%BE%D0%BD%D1%82%D0%B0%D0%BC%D0%B8%D0%BD%D0%B0%D1%86%D0%B8%D1%8F_%D0%B1%D0%B5%D0%BD%D1%87%D0%BC%D0%B0%D1%80%D0%BA%D0%BE%D0%B2_%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85_%D1%8F%D0%B7%D1%8B%D0%BA%D0%BE%D0%B2%D1%8B%D1%85_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B5%D0%B9»