Fine-tuning LLM: подготовка датасета — форматы, дедупликация и чеклист

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

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

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

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

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

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

Что даёт выверенная выборка: эффект в измеримых метриках

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

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

Число повторных прогонов дообучения падает с шести-восьми до двух-трёх. Дедупликация убирает примеры, которые модель относит то к одному классу, то к другому, и обучение перестаёт метаться между эпохами в поиске компромисса.

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

Курирование ведём в Argilla: версии набора, разметка несколькими аннотаторами и история правок в одном месте — после каждой итерации видно, какое именно изменение дало прирост.

Метрики считаем на замороженном контрольном наборе, который не попадает в обучение, поэтому результат воспроизводим при следующем прогоне.

Форматы датасета для LLM и режимы дообучения: сравнение

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

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

Этапы подготовки данных: от аудита источников до приёмки

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

1. Аудит источников. Инвентаризация: логи обращений, база знаний, переписка поддержки, внутренние регламенты. По каждому источнику — владелец, право на использование, объём, доменное покрытие и доля битых записей.
2. Схема записи. Договариваемся о полях, едином формате хранения и правилах описания ответа эталонного ассистента, чтобы разметчики не расходились в трактовке.
3. Очистка и дедупликация. Убираем разметку разметки (HTML, служебные заголовки), нормализуем текст, ловим точные и почти-дубли, вырезаем персональные данные. Близкие повторы перекашивают обучение сильнее, чем шум.
4. Разметка и сверка. Каждую запись проверяет второй специалист; спорные случаи разбираем отдельно и дописываем в правила.
5. Разбиение на обучающую и проверочную части. Делим по источникам и смысловым кластерам, а не случайно — иначе похожие формулировки попадут в обе части и качество на проверке окажется завышенным.
6. Контрольный замер. Прогоняем дообученную модель на проверочной части и сравниваем с исходной по сценариям, которые важны заказчику.
7. Приёмка набора. Чеклист по составу, статистика, версия выборки и описание ограничений — что модель на этих данных освоить не сможет.

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

Схемы полей, правила разметки и регламент пересборки

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

Что входит в передаваемый набор:

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

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

Кейс: как пересборка выборки убрала поток мусорных ответов

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

Что нашли в выборке

Треть пар оказалась дублями с точностью до пунктуации — модель заучивала частотные формулировки вместо правила. В 12% случаев один вопрос имел два разных ответа от разных операторов: конфликтующая разметка, и модель усредняла противоречия. Ещё в 7% ответ был склеен из соседней строки выгрузки — сбой экспорта, а не ошибка человека. Разметку вели в Label Studio, но без единой инструкции: каждый оператор понимал «отвечай кратко» по-своему.

Что изменили

Собрали инструкцию из четырёх критериев: ссылка на конкретный пункт, ответ только по действующей редакции, фиксированная длина, отказ вместо догадки. Дедупликация шла по нормализованному тексту, а конфликтующие пары уходили на арбитраж юристу, а не решались голосованием. Выборка сократилась с 48 до 29 тысяч примеров, зато перестала учить противоречиям. На живых запросах доля ответов со ссылкой на несуществующий пункт упала с 22% до 3%, а доля честных отказов «в регламенте не нахожу» выросла с 4% до 15% — модель перестала угадывать. Эскалаций к живому юристу стало заметно меньше: ассистент перестал быть источником ложных ссылок.

Что делать, если данные уже размечены в другом формате?

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

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

Часть записей в преобразование не укладывается: несколько меток на одном фрагменте, вложенные реплики, метки, которых в новой схеме просто нет. Такие случаи не «дорисовывают» автоматически, а складывают в очередь на частичную переразметку — обычно это 5–15 % объёма, и именно они дают основной прирост качества. Переразмечать вручную остальное — заново делать уже сделанную работу.

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

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

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

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

Что проверяете в лицензиях на обучающие данные?

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

Как персональные данные попадают в выборку и как их оттуда убрать?

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

Как убедиться, что модель не «выучила» данные наизусть?

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

Обсудим задачу: какой срез данных нужен для оценки

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

• Перечень исходных материалов: откуда берутся данные — обращения в поддержку, переписка, внутренняя база знаний, документы — и в каком виде они хранятся сейчас.
• Срез данных для оценки: примеры «вопрос — ожидаемый ответ» ровно в том виде, в каком они возникают в работе, включая неудачные и неполные.
• Эталонная разметка: 20–30 примеров, размеченных вручную вашим специалистом, — по ним калибруем проверки качества и правила чистки.
• Глоссарий: принятые у вас названия продуктов, термины, сокращения и варианты написания, чтобы модель не искажала предметную область.
• Ограничения: темы и формулировки, которых в ответах быть не должно, и правила поведения в спорных или неполных запросах.
• Требования к ответу и критерии приёмки: что вы считаете корректным результатом, а что — ошибкой, требующей переработки выборки.

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