Генерация синтетических данных для дообучения LLM под ключ

Синтетические данные для дообучения LLM: где ломается качество

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

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

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

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

Что даёт управляемая генерация обучающих выборок

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

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

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

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

Подходы к формированию выборок: генерация, дополнение, перенос

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

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

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

Этапы работы над выборкой: от аудита до передачи

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

Что фиксируем на каждом шаге

1. Аудит данных. Считаем объём, дубли, качество разметки, распределение по темам, длине и сложности. На выходе — карта пробелов: какие сценарии не покрыты и что придётся синтезировать.

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

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

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

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

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

Что остаётся у вас: выборка, генератор, документация

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

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

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

Практика: как выборка закрыла дефицит примеров в поддержке

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

Что сделали

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

Что изменилось

На отложенной выборке реальных обращений доля корректных ответов выросла с 61% до 89%, доля отказов упала с 18% до 4%. Покрытие редких сценариев в обучающем наборе выросло с единиц до сотен примеров на тему, а объём ручной разметки сократился примерно втрое — специалисты проверяют спорные случаи вместо написания примеров с нуля. Метрики качества считаем на том же наборе, что и до дообучения, поэтому сравнение до и после остаётся корректным.

Чем синтетические данные отличаются от разметки реальных логов?

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

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

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

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

Частые вопросы о данных, приватности и приёмке работ

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

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

Нужна ли ваша разметка?

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

Как проходит приёмка работ?

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

Что входит в поддержку после передачи?

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

Обсудим задачу и вернёмся с оценкой и планом

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

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

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

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

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