Датасет для дообучения без мусора: отбор и разметка

Почему датасет быстро портится

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

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

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

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

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

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

Что выкинуть сразу

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

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

• Точные и почти точные дубли. Если один и тот же диалог попал в выборку десять раз, модель начнет переоценивать этот сценарий. Почти дубли мешают не меньше: отличается одно слово, а смысл тот же.
• Пары вопрос-ответ с пустым, обрезанным или явно недописанным ответом. Модель быстро перенимает привычку отвечать двумя словами или обрывать мысль на середине.
• Записи с именами, телефонами, почтой и другими персональными данными без маскировки. Для российских команд это еще и риск по 152-ФЗ, а не только плохая гигиена данных.
• Примеры, где инструкция спорит с ответом. Если в задаче написано "ответь вежливо и кратко", а в ответе грубый длинный текст, такую пару проще удалить.
• Тексты с битой кодировкой, HTML-шумом, JSON-хвостами, служебными полями и артефактами копипаста. Если человек не может быстро прочитать запись, модель тоже не извлечет из нее нормальный шаблон.

Особенно вредны конфликтные примеры. Допустим, в датасете службы поддержки есть запрос "Как сменить тариф?", а ответ внутри другой темы: про возврат денег или сброс пароля. Формально текст есть, но связи между запросом и ответом нет. Такой пример хуже пустого.

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

Спорные случаи лучше складывать в отдельный "карантин". Не тратьте время на ручной ремонт всего подряд. Сначала уберите явный шум, потом проверьте консистентность разметки и качество оставшейся выборки.

Как собрать первую чистую выборку

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

Потом разделите будущие примеры на 2-4 понятных типа. Больше на старте обычно только мешает. Для той же поддержки расклад может быть таким:

• 50% простые вопросы по доставке
• 25% возвраты и обмен
• 15% оплата и чеки
• 10% случаи, где нужен перевод на человека

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

Не собирайте сразу тысячи строк. Возьмите маленький срез, который можно прочитать целиком вручную за один-два дня. Часто хватает 200-300 примеров. На этом этапе лучше потратить время на ручную чистку, чем потом чинить поведение модели после дообучения.

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

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

Расширяйте набор только после такой проверки. Берите следующую порцию данных и чистите ее тем же способом, без новых исключений на ходу. Если правила меняются посередине, разметка расползется очень быстро. Лучше медленно собрать первые 500 чистых примеров, чем быстро получить 5 000 спорных.

Как задать правила разметки

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

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

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

Пограничные случаи лучше описать отдельно. Для каждого класса добавьте 2-3 примера, где решение неочевидно. Например, ответ верный по смыслу, но слишком длинный. Или ответ вежливый и структурированный, но пропускает одно обязательное ограничение. Именно на таких примерах правила чаще всего ломаются.

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

Оформляйте правила как короткий рабочий документ, а не как памятку на десять экранов. В хорошем документе есть определения классов, 5-10 типовых примеров и список спорных сценариев с решением. Чем проще текст, тем стабильнее разметка.

И еще одна практическая вещь: храните только одну актуальную версию правил. У каждой правки должна быть дата. Если три человека размечали по версии от 12 мая, а еще двое по версии от 18 мая, вы получите скрытую смесь критериев. Потом такие расхождения трудно найти даже при повторной проверке.

Как проверить консистентность разметки

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

Возьмите небольшой срез, обычно хватает 100-300 примеров, и дайте его двум разметчикам независимо. Не обсуждайте спорные случаи заранее. Иначе вы проверите не качество правил, а то, насколько люди умеют быстро договориться в чате.

Сначала посчитайте простое совпадение. Смотрите не только на главную метку, но и на спорные поля: приоритет, тон ответа, наличие эскалации, запрет на ответ, если такие поля есть. Если из 200 примеров по главной метке совпали 176, это 88% совпадения. Для старта уже достаточно, чтобы увидеть слабые места.

Потом не разбирайте расхождения по одному примеру подряд. Команда быстро увязнет в частностях. Гораздо полезнее собрать споры по типам:

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

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

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

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

Пример на датасете службы поддержки

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

Сначала смотрите не на красоту текста, а на смысл. Сообщение "где маой закз 4581" стоит оставить: опечаток много, но человек явно спрашивает про статус заказа. А вот пустой чат, автоответ вроде "Ваше обращение принято" или кусок, где в один текст случайно склеились два разных диалога, лучше удалить сразу. Такие примеры учат модель шуму, а не задаче.

Если брать реальные фразы, разметка может выглядеть так:

• "Хочу вернуть куртку, не подошел размер" -> Возврат
• "Заказ третий день висит без движения" -> Доставка
• "Подскажите, где заказ 4581" -> Статус заказа
• "Когда привезут посылку, обещали вчера" -> Доставка
• "Как оформить возврат после получения" -> Возврат

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

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

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

Такой мини-набор быстро показывает, где класс "Доставка" разросся слишком широко, а где "Статус заказа" используют как запасную метку для всего подряд.

Где команды чаще ошибаются

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

Первая частая ошибка - смешивать обучение и проверку. Один и тот же смысл попадает в train и test в слегка другой формулировке, и модель просто узнает знакомый шаблон. На бумаге все выглядит хорошо, но после релиза качество проседает.

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

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

Типичные ошибки выглядят так:

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

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

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

Быстрая проверка перед дообучением

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

Короткий стоп-чек

Проверьте выборку по пяти пунктам.

• Удалите дубли, почти дубли и пустые пары. Если один и тот же пример встречается десять раз, он получает лишний вес. Если в паре пустой ответ или обрезанный промпт, такой образец лучше выкинуть сразу.
• Убедитесь, что личные данные замаскированы одинаково во всем датасете. Телефоны, почты, номера договоров и ФИО не должны оставаться в одних примерах и скрываться в других. Иначе модель запомнит лишнее и начнет воспроизводить это в ответах.
• Сравните фактическое распределение классов и форматов с тем, что вы хотели получить. Если вы собирали набор для коротких деловых ответов, а треть выборки состоит из длинных объяснений, модель уйдет не туда.
• Возьмите контрольный срез, например 100 примеров, и дайте его двум разметчикам. Если они постоянно спорят, проблема не в людях, а в правилах. Дообучать модель на таком наборе рано.
• Сформулируйте одну понятную цель проверки. Например: после обучения модель должна реже путать статус заказа с номером заказа или перестать отвечать слишком многословно.

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

Красные флаги

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

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

Что делать дальше

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

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

Сначала короткий прогон

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

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

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

Если вы гоняете несколько моделей и провайдеров, не стоит плодить отдельные интеграции под каждый вариант. Единый OpenAI-совместимый эндпоинт сильно упрощает сравнение: один и тот же код, один тестовый набор, меньше путаницы в логах. Для такой схемы можно использовать RU LLM на rullm.com: достаточно сменить base_url и прогонять те же проверки через разных провайдеров и модели без переписывания клиента.

Для команд с требованиями по 152-ФЗ организационные детали лучше учесть сразу, а не после пилота. Проверьте, где лежат логи запросов, где хранятся бэкапы, кто видит сырые данные и как вы маскируете персональные данные в процессе проверки. Если этот контур не собран заранее, даже хороший датасет для дообучения может застрять на согласовании.

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