Методы аугментации датасетов при обучении LLM

Почему аугментация данных ломается на реальных наборах

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

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

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

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

Что меняется после внедрения: эффект в измеримых метриках

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

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

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

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

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

Сравнение подходов: правила, модели и синтетика

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

Что учесть при выборе

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

Как строится аугментация данных: этапы инженерной работы

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

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

Артефакты передачи: схемы конвейера, правила качества, регламенты

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

• Схемы конвейера — граф этапов аугментации в виде конфигурации (YAML/JSON): зависимости шагов, точки ветвления, форматы входа и выхода на каждом этапе.
• Документация по данным — паспорт датасета: источники и лицензии, схема полей, распределение классов и дублей, доля синтетических примеров относительно исходных.
• Правила разметки — инструкция с граничными случаями, разобранными примерами и порядком эскалации спорных фрагментов; новый аннотатор входит в задачу без устных пояснений.
• Регламент контроля качества — метрики согласия между разметчиками, доля примеров на повторной проверке и порог, ниже которого партия уходит на переработку.
• Конфигурации фильтрации — правила дедупликации, пороги по близости векторных представлений, чёрные списки; параметры вынесены наружу, правка не требует изменения кода.
• Скрипты воспроизводимости — зафиксированные окружения и зерна генератора: повторный прогон даёт тот же набор, а расхождение объясняется, а не ищется.
• Отчёт о замерах — сравнение модели до и после аугментации на отложенной выборке, с разбивкой по подгруппам и честным указанием, где эффект не подтвердился.
• Журнал решений — какие подходы пробовали, какие отклонили и почему.

Кейс: устойчивость модели на редких формулировках и шуме

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

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

Метрики до и после: доля верных ответов на редких формулировках 61-72% → 88-91%, разброс между запусками обучения 11 → 3 пункта, ручные правки 32% → 8%. На общей оценке, включая RussianSuperGLUE, просадки не было — устойчивость не куплена ценой остального качества.

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

Чем отличается дообучение на слабой разметке от полного цикла

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

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

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

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

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

Технические сомнения: шум, утечки, контроль качества

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

Шум и повторы — чем отсеиваются?

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

Что входит в контроль качества набора?

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

Не исказит ли аугментация распределение классов?

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

Обсудим задачу: с чего начать работу на вашем корпусе

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

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

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

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