Подготовка датасета для дообучения: качество и приватность

Зачем заранее думать о качестве и приватности

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

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

Качество и приватность стоит проверять вместе, а не по очереди. Самые «подозрительные» фрагменты (номера, адреса, ФИО, внутренние идентификаторы) нередко встречаются в самых ценных примерах - реальных переписках и заявках. Если сначала разметить, а потом «вычищать», легко сломать смысл, контекст и метки. Если сначала чистить без понятных правил, можно удалить важные сигналы и получить перекос.

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

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

Уточняем цель и требования к датасету

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

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

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

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

В организациях с регламентами и госзакупками (в том числе у системных интеграторов) этот документ с требованиями часто важнее первого набора данных: он защищает проект от переделок и рискованных утечек.

Сбор данных и проверка прав на использование

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

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

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

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

Процесс разметки: правила, примеры, единый подход

Разметка чаще ломается не из-за «плохих разметчиков», а из-за туманных правил. Перед стартом зафиксируйте, что именно вы размечаете: классы (например, тип обращения), поля (тема, продукт), сущности (организация, модель устройства), тональность или причины. Это базовый шаг в подготовке датасета для дообучения, потому что модель учится ровно тому, что вы назвали и показали.

Простая инструкция, которую реально читают

Инструкция должна быть короткой и практичной: 1-2 страницы, минимум теории, больше примеров.

Опишите каждую метку простыми словами и добавьте границы: что подходит и что не подходит. Дайте по 3-5 примеров на метку, включая «похожие, но неправильные». Добавьте правило для сомнений (куда относить пограничные случаи), уточните формат заполнения полей и что делать с пустыми значениями. Отдельно перечислите запреты: что нельзя размечать или копировать, включая личные данные.

Пример для техподдержки: заранее договоритесь, что именно считается «проблемой с сервером», «проблемой с ПК», «доступами/учетками» и что уходит в «прочее». И дайте контрпример: «компьютер медленно работает» - это не «сеть», даже если упомянут Wi‑Fi.

Неоднозначные случаи и единая позиция

Спорные категории неизбежны. Удобное правило: разметчик ставит метку и помечает запись как «сомнительно», а тимлид раз в день просматривает такие записи и фиксирует решение.

Храните версии инструкции (v1, v2, v3) и отдельный журнал решений: дата, вопрос, принятое правило, пара примеров. Так не придется переучивать людей заново, а логику разметки можно будет объяснить юристам, безопасности или аудиторам.

Контроль качества разметки без сложной статистики

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

Практичный прием - двойная разметка части выборки. Возьмите 5-10% записей и дайте их двум разметчикам независимо. Затем сравните расхождения и не сводите разговор к «кто прав». Полезнее понять, какие правила двусмысленны, а где примеров слишком мало или они слишком однотипные.

Где обычно возникают споры

Чаще всего разметчики расходятся на пограничных кейсах: смешанные намерения, неполные сообщения, сарказм, сокращения, разные языки в одном тексте. В обращениях в поддержку (в том числе у команд с 24/7 сервисом) одно сообщение может одновременно быть «не работает» и «нужно настроить». Если правило выбора класса не прописано, модель потом будет ошибаться именно на реальных сложных запросах.

Порог приемки и регулярные аудиты

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

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

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

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

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

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

На практике лучше сочетать несколько простых проверок: искать полные совпадения (нормализация текста и сравнение хэшей), почти одинаковые записи (порог похожести по n-граммам или метрике вашего инструмента), шаблонные сообщения (удалить переменные части вроде ID и дат и сравнить заново), а также группировать похожие записи в кластеры и просматривать пачками.

Пример: «Не включается ПК, срочно» и «ПК не включается, срочно» для модели почти одно и то же. Десятки таких повторов перекосят обучение.

Что делать с найденными повторами

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

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

Удаление чувствительных данных и защита приватности

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

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

Подход выбирают по задаче. Иногда лучше удалить фрагмент целиком. Иногда достаточно маскирования (заменить ИИН на "[ИИН]") или токенизации ("[PHONE_1]"), чтобы сохранить структуру. Для аналитики полезно обобщение: город вместо точного адреса, возрастная группа вместо даты рождения.

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

Перед передачей в обучение сделайте быструю проверку: прогон по шаблонам (ИИН, телефоны, email, ключевые слова вроде "password"), ручная выборка 50-100 записей из разных источников, проверка вложений (сканы, изображения, экспорт из CRM), поиск «редких строк» (уникальные длинные номера и токены) и повторная проверка после очистки.

Правильное разбиение: как не допустить утечки

Даже хорошо собранный датасет даст «слишком хорошие» метрики, если данные неправильно разделены. Главная ошибка - когда почти одинаковые записи оказываются и в обучении, и в проверке. Тогда модель не учится, а вспоминает, и после релиза качество падает.

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

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

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

Проверка перекоса и репрезентативности

Перекос возникает, когда датасет слишком сильно отражает один тип случаев и почти не содержит других. Частый пример - «слишком много одного класса» (80% примеров про «сброс пароля» и 5% про «сбой оплаты»). Второй вариант - перекос по источнику: данные только из одного канала или одного периода (например, сезонный всплеск жалоб).

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

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

Не «улучшайте метрики» ценой качества в жизни. Если искусственно уравнять классы, модель может слишком часто предлагать редкий ответ там, где он почти не встречается. Безопаснее держать отдельный тест, который сохраняет реальное распределение, и проверять на нем, не стало ли хуже после правок.

Пример сценария: дообучение на обращениях пользователей

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

На практике быстро всплывают три типовые проблемы: «копипасты» (шаблоны ответов и повторяющиеся тикеты про один и тот же сбой), «пустые» реплики вроде «ок», «принято», «спасибо», которые раздувают датасет, и персональные данные (ФИО, телефоны, адреса, ИИН, номера договоров, серийные номера, иногда реквизиты и логины).

Чтобы сохранить смысл и убрать шум, полезно сделать фильтрацию до разметки: удалять сообщения короче 2-3 слов, если в них нет сигнала; склеивать короткие подтверждения с предыдущей содержательной репликой, если это важно для диалога; сохранять контекст (хотя бы 1-2 предыдущих сообщения); маскировать чувствительные поля едиными токенами вроде [PHONE], [IIN], [CONTRACT]; убирать дубликаты и почти дубликаты, оставляя один лучший пример.

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

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

Пошаговый план подготовки датасета перед дообучением

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

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

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

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

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

5. Проверьте повторы и разбиение. Уберите дубликаты и почти одинаковые записи. Разделите данные на train, validation и test так, чтобы похожие кейсы не попадали в разные части (например, обращения одного клиента или одной организации).

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

Короткий чеклист, частые ошибки и следующие шаги

Перед стартом дообучения полезно сделать финальную проверку. Она занимает час-два, но часто экономит недели.

Проверьте три вещи: дубликаты (и почти дубликаты) найдены и обработаны; чувствительные данные удалены или замаскированы единым способом по всему датасету; разбиение на train/val/test сохраняет независимость (нет пересечений по пользователям, кейсам и документам). Затем посмотрите на перекос: какие темы, языки, регионы, типы запросов или классы представлены слишком сильно или слишком слабо. И обязательно зафиксируйте версии: исходники, скрипты очистки, правила разметки, даты выгрузок и итоговые размеры наборов.

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

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

Дальше оцените, где и как будет храниться датасет (шифрование, резервные копии, журнал доступа), кто имеет права на чтение и выгрузку, как вы запускаете обучение и сохраняете артефакты (модели, логи, конфиги). Если вам нужен закрытый контур и помощь с инфраструктурой под обучение и хранение данных, это можно обсудить с GSE.kz - например, на базе серверов S200, рабочих станций и услуг системной интеграции с контролем доступа и поддержкой.