Очистка данных для fine-tuning LLM: пайплайн и метрики

Почему очистка данных LLM ломается на масштабе

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

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

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

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

Что даёт контролируемое качество корпуса для дообучения

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

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

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

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

Поток или разовая выгрузка: чем отличаются подходы

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

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

Как строится очистка корпуса: этапы инженерных работ

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

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

Конфигурации, схемы и регламенты подготовки корпуса

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

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

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

Кейс: как сократили долю брака в обучающем корпусе

Что пришло на вход

Заказчик — продуктовая команда, которая дообучает ассистента поддержки: корпус на 4,2 млн документов собирали из обращений, переписок и внутренней базы знаний. Замеры перед работой показали 34% почти одинаковых записей, 11% обрывков — фрагментов, обрезанных по лимиту поля, — и разнобой в служебной разметке. Дообучение из-за этого перезапускали по 5–6 раз: модель с одинаковой уверенностью воспроизводила и рабочие ответы операторов, и мусорные заготовки.

Что изменили

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

Метрики до и после

Конвейер остался у команды как регулярный прогон: новые выгрузки проходят те же проверки, отчёт по качеству корпуса собирается автоматически, доля дублей держится на уровне 6% и не растёт вместе с объёмом. Повторные прогоны дообучения сократились с 5–6 до 1–2 — правки в данных теперь видно до запуска обучения, а не после.

Что делать, если корпус уже собран и частично размечен?

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

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

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

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

Технические сомнения по качеству корпуса

Пригодность корпуса мы проверяем не на глаз, а по набору измеряемых признаков: доля точных дублей и почти-дублей, разброс длины документов, доля фрагментов на другом языке, плотность служебной разметки и битого текста, покрытие целевых тематических кластеров. Пороги фиксируем до старта работ — тогда приёмка превращается в сверку с числами, а не в спор о вкусах. Если после фильтрации остаётся 60–70% исходного объёма и он покрывает все нужные темы, корпус пригоден; если меньше — пересобираем источники, а не ужесточаем правила.

Как измерять качество, если эталонной разметки нет?

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