Подготовка датасетов для обучения ИИ

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

Ниже — практический гайд, как построить пайплайн подготовки данных для задач ML и LLM/RAG: от сбора и очистки до разметки, версионирования и мониторинга.

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

Какие задачи ИИ требуют разных датасетов

Разные задачи = разные структуры данных и разные “болезни” качества.

• Классификация: нужны стабильные признаки + корректные labels, важен баланс классов.
• Извлечение сущностей/атрибутов: нужны тексты/структура и разметка по сущностям, важна согласованность правил.
• Сопоставление объектов (matching): нужны пары “одно и то же / разные” и признаки сходства; критичны утечки и смещение на “простые” пары.
• Поиск/ранжирование: нужны запросы + документы + сигналы релевантности (клики/оценки), важна временная целостность.
• Рекомендации: нужны события (просмотры/покупки) и контекст; критичен холодный старт и дрейф.
• Прогнозирование (временные ряды): нужен временной индекс, корректное разбиение по времени, контроль утечек из будущего.
• LLM/RAG: нужен корпус документов + метаданные + чанкинг, важны права на контент и качество источников.
• Контроль качества контента: нужны “правильные/ошибочные” примеры, важны правила и воспроизводимость.

Схема пайплайна подготовки данных

Базовая схема, которая “вывозит” прод:

Сбор → Сырой слой (raw) → Очистка → Нормализация → Дедуп → Разметка → Feature/Dataset → Train/Eval → Версионирование → Мониторинг

Коротко по этапам:

• Сбор: получаем данные и метаданные источника.
• Raw: сохраняем “как есть” (для аудита и воспроизводимости).
• Очистка: убираем мусор/ошибки формата.
• Нормализация: единицы, справочники, канонизация сущностей.
• Дедуп: удаляем копии и “почти копии”.
• Разметка: получаем labels (ручные/правила/active learning).
• Feature/Dataset: финальная форма под модель, split train/val/test.
• Train/Eval: обучение и честная оценка.
• Версионирование: фиксируем состав данных и процессы подготовки.
• Мониторинг: дрейф, деградация, изменения источников.

Сбор данных: что важно сделать правильно в самом начале

1) Сформулировать цель и минимальный набор полей

Самая частая ошибка — “собрать всё, вдруг пригодится”. Это:

• удорожает подготовку,
• ухудшает комплаенс,
• размывает ответственность.

Сделайте список: какие решения будет принимать модель → какие поля нужны.

2) Provenance: происхождение данных

С первого дня фиксируйте:

• источник (домен/система/выгрузка),
• время получения (timestamp),
• условия использования (если критично),
• версию схемы/парсера/скрипта.

Это нужно не “для красоты”, а для расследований, репликации эксперимента и юридической чистоты.

3) Исключить ПДн и чувствительные поля, если они не нужны

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

4) Разделить raw и “готовый датасет”

Raw-слой — это архив фактов. Датасет — это продукт с правилами и качеством. Никогда не смешивайте.

 

Очистка и нормализация: где чаще всего теряется качество

Что чаще всего нужно делать:

• Пропуски и пустые значения: стандартизировать “пусто”, решать — удалять/импутировать.
• Выбросы: нереальные цены/размеры/веса, ошибки парсинга.
• Единицы измерения: “0.5 л” vs “500 мл”, “1 kg” vs “1000 г”.
• Кодировки и мусор: HTML-артефакты, спецсимволы, сломанные эмодзи.
• Нормализация сущностей: бренды, категории, города, модели.
• Справочники: заведите “источник истины” для ключевых словарей (brand/category/unit).
• Текст: определить язык, привести регистр, удалить системный мусор; токенизацию и стоп-слова делайте осознанно (без агрессивного “вычищения смысла”).

Дедуп и утечки: как не обучить модель на копиях

Типы дублей

• Полные: один и тот же объект несколько раз.
• Почти дубли: чуть изменен заголовок/описание/атрибут.
• Семантические: один объект представлен разными карточками/объявлениями.

Почему это опасно

• модель “запоминает” вместо того, чтобы обобщать;
• метрики на тесте завышаются, потому что в test попадают копии из train;
• в проде качество резко падает.

Практики защиты

• дедуп по ключам/хешам (точные дубли),
• дедуп по эмбеддингам/сходству (почти и семантические),
• split train/val/test по сущностям (например, по product_id) или по времени (для временных рядов),
• “запрет утечки”: одинаковые сущности не должны появляться и в train, и в test.

Разметка: как получать labels эффективно

1) Golden set

Сделайте небольшой “золотой” набор, размеченный тщательно. Он нужен для:

• честной оценки качества,
• калибровки правил,
• контроля разметчиков.

2) Weak supervision

Правила и эвристики (регулярки, справочники, шаблоны) дают быстрый старт. Важно:

• фиксировать правила как код,
• оценивать на golden set,
• не забывать про ошибки “уверенных” правил.

3) Distant supervision

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

4) Active learning и human-in-the-loop

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

5) Согласованность разметки

Если разметчиков несколько — измеряйте согласованность (inter-annotator agreement) и улучшайте гайдлайн.

Quality gates: метрики качества датасета

Перед обучением полезно иметь “шлагбаумы” качества:

• заполненность ключевых полей (coverage),
• доля дублей и near-duplicates,
• баланс классов и доля редких классов,
• стабильность распределений (drift) относительно прошлой версии,
• покрытие сегментов (регионы/категории/бренды),
• доля “сомнительных” примеров (аномалии),
• оценка качества разметки (ошибки на golden set).

Таблица: проблема → как проявляется → как лечить

Проблема	Как проявляется	Как лечить
Шум в данных	“странные” значения, мусор в тексте	валидация, фильтры, нормализация
Смещение (bias)	модель плоха на “длинном хвосте”	выборка по сегментам, стратификация
Дрейф источника	резкий рост пустых полей	мониторинг, быстрый фикс пайплайна
Дубли	завышенные метрики	дедуп + split по сущностям
Leakage	тест слишком “легкий”	time-based split, entity-based split
Неверные единицы	“5000 мл” вместо “500 мл”	конвертеры, справочники единиц
Ошибки разметки	нестабильная точность	golden set, ревью, активное обучение
Слишком много признаков	переобучение	минимизация полей, регуляризация, отбор
Нет provenance	нельзя воспроизвести результат	метаданные источника и версии
Персональные данные “про запас”	юридические/репутационные риски	исключение, обезличивание, доступы

Версионирование и воспроизводимость

Если датасет обновляется — он должен иметь версии так же, как код.

Что обычно фиксируют:

• dataset_version (например, v2026-03-12),
• список источников и временной диапазон,
• код подготовки (commit),
• схему данных,
• правила фильтрации и дедупа,
• split train/val/test (какие сущности/временные окна).

Практика “raw → clean → features” помогает:

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

Полезные артефакты: datasheet для датасета и краткая “карта модели” (model card) — хотя бы на уровне внутренних документов.

Таблица: артефакт → что хранить → зачем

Артефакт	Что хранить	Зачем
Raw dump	оригинальные ответы + метаданные	аудит и воспроизводимость
Схема данных	типы полей, обязательность	стабильная интеграция
Правила очистки	фильтры, нормализация	повторяемость сборки
Правила разметки	гайдлайн + примеры	качество labels
Golden set	эталонные примеры	контроль качества
Split	списки сущностей/временные окна	защита от leakage
Report качества	coverage, дубли, баланс	“шлагбаумы”
Версия пайплайна	commit/версия сборки	расследования и откат
Логи обновлений	что изменилось в версии	понимание дрейфа

Правовые и этические риски

Коротко, но обязательно:

• Персональные данные: минимизация, ограничение доступа, сроки хранения, обезличивание, если возможно.
• Авторское право: тексты/изображения/контент могут быть защищены; для публикации и коммерческого использования нужны права.
• Terms и лицензии источников: проверяйте условия использования и предпочитайте официальные API/выгрузки.
• Безопасность хранения: доступы по ролям, логирование выгрузок, удаление “лишнего”.

 

Пошаговый план: от идеи до первого production-датасета

1. Зафиксировать задачу и KPI модели.
2. Определить минимальные поля и источники + provenance.
3. Собрать raw и сделать первичную очистку.
4. Нормализовать справочники и единицы.
5. Настроить дедуп и правила split (без утечек).
6. Разметить golden set + запустить разметку (правила/active learning).
7. Ввести quality gates, версионирование и мониторинг дрейфа.

 

Чек-лист перед обучением

• цель и KPI описаны;
• provenance фиксируется (источник, timestamp, версия);
• ПДн исключены или выделен отдельный контур;
• есть raw и clean слои;
• единицы и справочники нормализованы;
• дедуп сделан, leakage проверен;
• split train/val/test корректный (по времени/сущностям);
• есть golden set и отчет по качеству разметки;
• quality gates пройдены (coverage, дубли, баланс);
• датасет имеет версию и описание изменений;
• план обновлений и мониторинга дрейфа определен.