Ловушки синтетических данных при настройке малых моделей

Что идёт не так с синтетическими данными

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

Синтетические образцы часто выглядят нормальными при беглом просмотре. Грамматика аккуратна, намерение очевидно, и каждый ответ стройно соответствует запросу. Команда просматривает двадцать строк, успокаивается и пропускает настоящую проблему: данные более «гладкие», чем реальная жизнь.

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

Обычная неудача сначала кажется безобидной. В каждом обучающем промпте просят помощи в одном вежливом тоне, полными предложениями и с ясным контекстом. Затем модель выходит в продакшн, и реальные пользователи пишут «возврат??», вставляют половину лога ошибки или задают два вопроса сразу. Модель колеблется, догадывается или даёт неверный ответ с излишней уверенностью.

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

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

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

Предупреждающие сигналы в вашем датасете

Маленькая настроенная модель быстро перенимает привычки. Если в наборе есть слабые места, модель скопирует их прежде, чем научится чему-то полезному.

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

Обратите внимание на несколько простых закономерностей:

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

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

Повторяющаяся формулировка — ещё один сигнал. Синтетический набор часто содержит строки вроде «Пожалуйста, помогите мне с X» или «Мне нужна помощь с Y» снова и снова. Маленькая модель усваивает рамку, а не задачу. Измените формулировку в реальном использовании — и производительность быстро падает.

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

Тон целевых ответов тоже важен. Многие синтетические наборы звучат отредактированно, спокойно и полно. Реальный служебный текст часто резкий: «cant login. code expired. fix pls». Если в обучении все строки звучат как отредактированная проза, модель будет ожидать мир, которого нет.

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

Простой процесс проверки перед настройкой

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

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

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

Простая рабочая схема работает хорошо:

1. Возьмите сбалансированную выборку для каждой метки или задачи.
2. Прочитайте каждый пример и отметьте очевидные ошибки.
3. Поместите очень похожие промпты рядом друг с другом.
4. Посчитайте, как часто появляется каждая задача.
5. Сравните выборку с небольшим набором реальных входов.

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

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

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

Датасет поддержки это хорошо показывает. Синтетика может повторять строки вроде «Я не могу получить доступ к своему аккаунту и мне нужен сброс пароля». Реальные пользователи пишут «cant log in» или «reset link dead». Если вы заметили этот разрыв до настройки, исправить его ещё дешево.

Как заметить шум в метках

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

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

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

Практическая проверка обычно выявляет четыре паттерна:

• почти-дубликаты с разными метками
• метки, основанные на «чтении мыслей», а не на тексте
• пограничные случаи, прыгающие между двумя классами
• правила аннотации, требующие постоянных пояснений

Второй пункт наносит много вреда. Если в тексте недостаточно доказательств для однозначной метки, аннотаторы начинают догадываться. Вы видите это в примерах вроде «Мне нужна помощь с моим аккаунтом», когда набор меток заставляет выбирать между billing, login, security или profile changes. Такая строка не должна оставаться без изменений. Добавьте контекст, поместите её в более широкий класс или удалите.

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

Хорошие проверки меток обычно сводятся к инструкции по аннотации. Перепишите расплывчатые определения простым языком. Добавьте по одному–двум реальным примерам для каждого класса. Укажите, что перевешивает, когда кажется возможным две метки. Затем перезапишите спорные строки после изменения правил, а не до.

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

Как повторяющиеся формулировки вводят в заблуждение малую модель

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

Это часто случается с сгенерированными наборами. Шаблон промпта даёт сотни примеров, которые на первый взгляд выглядят разными, но каркас едва меняется. Имя клиента меняется, продукт меняется, возможно, жалоба меняется, но каждый ответ начинается с «Спасибо, что обратились» и заканчивается «Пожалуйста, дайте знать, если нужна дополнительная помощь». Маленькая модель воспринимает эти повторяющиеся края как безопасные ставки.

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

Несколько коротких проверок помогают:

• сгруппируйте примеры по первым 4–6 словам и посмотрите, какие открытия повторяются;
• сканируйте концовки на одинаковые подписи или фразы извинения;
• ищите места-шаблоны, где меняются только имена, даты или ID продуктов;
• сравните ответы, которые должны звучать по-разному, но имеют одинаковый ритм.

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

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

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

Пробелы в покрытии, которые ломают реальную работу

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

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

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

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

Уровень навыков тоже важен. Новый пользователь может написать: «can't log in after payment». Опытный админ объединит роли, журналы аудита и SSO в одном предложении. Если обе группы используют продукт, обе должны быть представлены в наборе.

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

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

Реалистичный пример из ассистента поддержки

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

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

В синтетическом наборе для одобренных возвратов почти всегда встречаются одни и те же фразы: «I understand your frustration», «I have reviewed your request», «your refund has been processed». Для отказов используется другой тесный набор фраз. Модель начинает воспринимать формулировку как сигнал, даже когда причину нужно извлекать из политики, даты покупки, статуса использования или истории аккаунта.

Метки выглядят чистыми, но язык выдаёт ответ.

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

Реальный клиент редко пишет как шаблон. Они пишут: «charged twice need help», «kid clicked buy by mistake» или «app no work want money back». Некоторые вообще не говорят «refund». Они описывают проблему с оплатой, задают смутный вопрос или смешивают две проблемы в одном сообщении.

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

Небольшой набор реальных тикетов быстро выявит разрыв. Даже 30–50 реальных разговоров покажут, где синтетика ошиблась:

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

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

Ошибки команд под давлением времени

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

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

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

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

Под давлением многие команды совершают четыре одинаковые ошибки:

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

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

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

Быстрые проверки и дальнейшие шаги

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

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

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

Короткий чеклист

Используйте ту же короткую проверку перед каждой новой версией набора данных:

• Прочитайте 30–50 случайных примеров без фильтрации.
• Проверьте, сохраняют ли смысл метки, если скрыть поле с ответом.
• Найдите повторяющиеся формулировки и почти-дубликаты.
• Посчитайте, сколько примеров покрывают краевые случаи, а не только обычные.
• Запустите маленькую настройку и сравните результаты на невидимых промптах.

Эта рутина ловит большинство проблем с датасетом до того, как они станут проблемами модели. Она также удерживает команды от соблазна считать «больше данных» панацеей, когда сроки поджимают.

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

Если ваша команда хочет второй взгляд, Oleg Sotnikov at oleg.is просматривает наборы данных, планы настройки и рабочие процессы оценки как Fractional CTO и консультант для стартапов. Внешний обзор помогает, когда команда слишком близка к своим данным, чтобы заметить слабые метки, повторяющиеся паттерны и тонкое покрытие до следующего прогонa.