Валидация качества датасета для дообучения LLM: аудит и очистка

Почему валидация датасета LLM ломается на объёме

На выборке в тысячу примеров расхождения в разметке почти не видны: их вычищают вручную и считают случайным шумом. На объёме в сотни тысяч картина меняется — десятки разметчиков трактуют инструкцию по-разному, и один и тот же вопрос получает то развёрнутый ответ, то односложный, то отказ. Разница в 5-8% разметки между исполнителями не всплывает в отчёте, но именно она задаёт потолок, выше которого дообученная модель не поднимается.

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

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

Разбираем, как это закрывается: какие проверки ставятся на вход, как размечаются спорные случаи и что показывает расхождение до и после очистки.

Что чинится перед обучением: дубли, шум, разметка, утечки

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

• Дубли и почти-дубли. Точные повторы и перефразированные пары ищем по пересечению n-грамм с настраиваемым порогом близости. Обучающая часть после чистки короче на 15–40% без потери смысла — модель перестаёт переоценивать частые формулировки.
• Шум и мусор. Обрывки распознавания, служебные вставки, битые символы и примеры не по теме отсекаем правилами и статистикой по длине. Доля мусора уходит ниже 1%: ёмкость модели не тратится на заучивание артефактов.
• Согласованность разметки. Один и тот же пример у разных исполнителей получает разные метки. Считаем долю расхождений на контрольной подвыборке, спорные случаи разбираем и фиксируем правило в инструкции, а подозрительные метки ранжирует Cleanlab. Расхождения ниже 5% означают, что граница классов размечена одинаково.
• Утечка между выборками. Похожие примеры попадают и в обучение, и в проверку, из-за чего метрики на отложенной части завышены. Группируем связанные примеры по источнику и документу и делим по группам — доля пересечений ноль, оценка честная.
• Дисбаланс классов. Редкий класс тонет в частом: пересчитываем веса в функции потерь, отбираем примеры по слоям вместо синтетики. Кривая качества на редком классе выходит из шума.

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

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

Поэтому сравниваем подходы по трём осям: что именно ловит, на каком объёме окупается, что требует от команды. По таблице ниже выбираем одиночный режим или собираем каскад.

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

Этапы аудита и очистки датасета: от инвентаризации до передачи

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

1. Инвентаризация источников. Собираем все корпуса и выгрузки, фиксируем происхождение, права на использование, дату сбора и пересечения между источниками — часть записей обычно дублируется в двух-трёх наборах.
2. Профилирование выборки. Считаем распределения: длина записей, язык, доля пустых и обрезанных примеров, разброс меток. Перекос вскрывается здесь — до того, как он попадёт в обучение.
3. Схема разметки. Формализуем целевые классы, правила аннотации и порядок разрешения расхождений между разметчиками, иначе одинаковые примеры получат разные метки.
4. План очистки. Описываем дедупликацию точную и почти-дублей, отсев мусора, нормализацию, балансировку классов и разбиение на обучающую, валидационную и отложенную выборки без утечки данных.
5. Фильтрация и переразметка. Прогоняем правила, спорные случаи разбираем вручную, замеряем согласованность разметки до и после.
6. Контрольный прогон. Обучаем на очищенном и на исходном срезах, сравниваем метрики на отложенной выборке — так видно, что именно дала очистка, а не ощущение.
7. Передача. Отдаём версионированный датасет, карточку данных с описанием ограничений и скрипты, воспроизводящие сборку срезов.

Артефакты: схемы разметки, правила фильтрации, отчёты

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

• Схема разметки: поля записи, типы значений, обязательность, допустимые метки и правило разрешения конфликтов между разметчиками.
• Инструкция для исполнителей: как трактовать пограничные примеры, что считать браком, как помечать неуверенную разметку — расхождения между людьми падают кратно.
• Правила фильтрации данных: дедупликация по нормализованному тексту, пороги по длине и языку, отсев шаблонных и машинно-сгенерированных фрагментов, обработка персональных данных.
• Отчёт о качестве данных: распределение по классам и сегментам, доля расхождений между разметчиками, покрытие набора проверками, перечень проблемных срезов.
• Журнал исключённых примеров: каждый отброшенный фрагмент с причиной и ссылкой на правило — решение можно оспорить и пересмотреть, а не принимать на веру.
• Конфигурации и скрипты очистки: повторный прогон на новом срезе даёт тот же результат и те же отчёты.
• Регламент повторной валидации: по каким метрикам и как часто перепроверять набор после дообучения.

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

Кейс: дообучение на зашумлённых данных до и после

До: что показал аудит

Проект — ассистент первой линии поддержки, который отвечает по внутренней базе знаний. Заказчик принёс архив обращений и хотел дообучить модель на нём. Перед обучением прогнали аудит: из 240 тысяч пар почти 19% оказались близкими дублями с разной разметкой, 8% содержали противоречивые ответы, ещё 6% потеряли контекст при выгрузке — ответ был, а вопроса, к которому он относится, в паре не осталось. Обучение на таком наборе давало нестабильность: два запуска на одной конфигурации расходились по доле корректных ответов на контрольной выборке на несколько процентов.

После: что изменили и что получили

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

Доля дублей упала с 19% до 2%, противоречивых примеров стало меньше 1%, объём выборки сократился примерно на четверть. Доля корректных ответов на контрольной выборке выросла с 61% до 79%, а разброс между повторными запусками — меньше одного процента, то есть результат перестал зависеть от того, какой была последовательность данных.

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

Что делать, если обучающая выборка уже собрана и размечена?

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

Частичный аудит выборки строим стратифицированно — по источникам, типам задач и длине ответа. Смотрим долю расхождений между разметчиками на пересечённых примерах, долю обрезанных и пустых ответов, дубликаты, пересечение тестовой части с обучающей. Брак обычно сосредоточен в двух-трёх срезах, и переразмечать остальное — расход без прироста метрик.

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

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

Ограничения и частые сомнения по качеству данных

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

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

Как понять, что очистка дала эффект, если метрика шумит?

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

Обсудим задачу: с чего начинается работа

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

• Объём и состав: языки, тематики, как собирались данные и какая доля получена генерацией, а какая — из реальных обращений.
• Инструкции разметки и гайд для аннотаторов, включая места, где практика разошлась с текстом.
• 30–50 фрагментов, где разметчики не сошлись между собой или ответ выглядит сомнительным: по ним видно, где ломается согласованность.
• Требования продукта: какие ошибки недопустимы, что модель не должна отвечать, какие сценарии считаются целевыми.
• Как выборка делится на обучение и контроль — чтобы исключить пересечения и утечки между частями.
• Доступы: обезличенная выгрузка или работа на вашей стороне, кто подтверждает спорные случаи.
• Критерии приёмки и сроки, которые для вас критичны.

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