Ключевые выводы

Набор данных — версионируемый продукт. У него есть схема, владелец, манифест (хэш + версия + правила разметки) и история изменений в git или хранилище данных.

Обучение и оценка — разные контуры. Тренировочный корпус учит поведение; эталонный набор измеряет его. Смешивать без аудита утечек — обманывать себя метриками.

Сначала контракт задачи, потом объём и модель. Что на входе, что на выходе, когда отказ — определяется до разговора о низкоранговой адаптации LoRA (Low-Rank Adaptation) и размере чекпоинта.

Эталонная запись (golden-запись) — контракт на один пример: вход, ожидаемый результат или критерии приёмки, метаданные. Набор таких записей — эталонный набор.

Редакторы эталонов — доменные эксперты, которые создают и согласуют эталон. Без них синтетика и краудсорсинг дают красивые числа и слабый прод.

Параметры зависят от задачи и домена: объём, единица разметки, «похожие, но неверные» примеры и пороги качества для классификации, дообучения с учителем (SFT, Supervised Fine-Tuning), поиска контекста и компьютерного зрения — разные.

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

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

Чем инженерия датасетов отличается от «собрали CSV»

Инженерия датасетов — это не разовая выгрузка логов и не заказ разметки на бирже. Это повторяемый процесс с явными артефактами:

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

Почему данные важнее очередной модели

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

Три сигнала, что пора заняться набором данных

1. Метрика скачет без воспроизводимости — в одном запросе на слияние (PR, pull request) меняли промпт, набор и модель. Отчёт «+12%» нельзя связать с одним изменением.
2. Хорошие цифры на тесте, плохой пилот — разрыв доменов: обучающая выборка не похожа на реальный поток. Классический пример — MNIST против фотографий бланков в разборе оптического распознавания рукописных цифр (OCR).
3. Нет владельца разметки — «правильный ответ» определяется тем, кто последним смотрел в чат.

Стоимость плохих данных

Плохой набор обходится дороже, чем кажется:

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

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

Контракт задачи: вход, выход, отказ

До разметки зафиксируйте контракт в одном документе (или в meta.yaml набора):

Контракт — основа рубрики для редакторов эталонов. Без него два эксперта разметят один кейс по-разному, и согласие между разметчиками (inter-annotator agreement) будет низким не из-за «сложной задачи», а из-за отсутствия правил.

Подход к оценке до эксплуатации в целом — в материале про оценку LLM перед запуском; здесь мы фокусируемся на данных, которые питают этот контур оценки.

Четыре семейства данных

В одном проекте сосуществуют до четырёх семейств. Путать их — источник утечек и ложных релизов.

Тренировочный корпус

Учит модель как отвечать: тон, формат, типичные паттерны домена. Для SFT это пары «инструкция → ответ»; для классификатора — «текст → метка»; для ранжировщика — «запрос, документ → релевантность**.

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

Данные предпочтений

Нужны, когда важно не только «правильный факт», но и предпочтение между двумя правдоподобными ответами: короче или полнее, формальный или разговорный, с цитатой или без. Типичные форматы — прямая оптимизация предпочтений DPO (Direct Preference Optimization) и пары для обучения с подкреплением от человека RLHF (Reinforcement Learning from Human Feedback). Объём обычно меньше, чем у SFT; качество разметчиков критичнее.

Эталонный набор

Фиксированный, версионированный, часто меньше обучающего корпуса. Каждая golden-запись — эталон для сравнения. При оценке RAG измеряем поиск контекста и генерацию; в классификации — точность по срезам; при извлечении — точное совпадение и F1 по полям.

Отдельный разбор: эталонный набор для оценки RAG.

Буфер сбора кейсов

Сырой поток: логи, жалобы, «модель ошиблась». Не отчётная метрика, пока редактор не промотировал запись в эталон или обучение. Соглашение об уровне сервиса (SLA) на ревью зависит от класса риска: инцидент безопасности — часы, косметика — недели.

Эталонная запись: минимальная схема

В экосистемах DeepEval / Confident AI golden-запись — «предшественник» тест-кейса: фиксированные поля до прогона; на оценке добавляются actual_output, контекст поиска, вызовы инструментов.

Минимальный контракт для своего репозитория (JSONL в git):

{
  "id": "reg-2026-0142",
  "input": "Какой срок действия инструкции по работе на высоте?",
  "expected_output": "Ответ со ссылкой на действующую редакцию И-ОТ-12 от 2024-03-01; если в корпусе только отменённая версия — отказ с указанием версии.",
  "acceptance": "citation_required",
  "metadata": {
    "domain": "industrial_safety",
    "risk_class": "high",
    "language": "ru",
    "source_ids": ["И-ОТ-12"],
    "tags": ["height_work", "validity"]
  },
  "annotator": "editor:petrov",
  "rubric_version": "ot-rubric-1.2",
  "dataset_version": "golden-regulations-v3"
}

Поля acceptance и rubric_version связывают запись с правилами редактора. Без них через полгода никто не объяснит, почему «правильный» ответ изменился.

Редакторы эталонов: роль, а не только интерфейс

Термин редактор эталонов (golden editor) пришёл из инструментов оценки LLM: интерфейс, где эксперт заполняет поля, комментирует, назначает ревью. В промышленном контуре важнее роль:

Инженеры строят схему, валидацию, непрерывную интеграцию (CI); редактор эталонов отвечает за смысл «золота». Без этого — «театр датасетов»: файлы есть, доверия нет.

Состояния записи (как в Confident AI: queue vs push):

Подробный процесс — в статье golden-editors-annotation-workflow-2026.

Жизненный цикл: от прода обратно в набор

flowchart TB
  subgraph sources [Источники]
    prod[Трафик и логи]
    docs[Документы и регламенты]
    synth[Синтетика по рубрике]
  end

  subgraph human [Люди]
    editors[Редакторы эталонов]
    adjud[Согласование спорных кейсов]
  end

  subgraph artifacts [Артефакты]
    buffer[Буфер сбора кейсов]
    golden[Эталонный набор vN]
    train[Тренировочный корпус]
    pref[Пары предпочтений]
  end

  subgraph gates [Контроль]
    eval[Стенд оценки]
    ci[Регрессионный барьер]
  end

  prod --> buffer
  docs --> train
  synth --> train
  buffer --> editors
  editors --> adjud
  adjud --> golden
  adjud --> train
  train --> eval
  golden --> eval
  eval --> ci
  ci -->|pass| release[Релиз модели / промпта]
  prod -->|новый провал| buffer

Правила петли

• Буфер ≠ эталон — пока нет рубрики и ревью, кейс не в отчётности.
• Версия фиксируется к каждому прогону — в логе: dataset_version, model_version, prompt_version.
• Скрытая выборка закрыта при итерациях промпта — иначе подгонка.
• Один эксперимент — одна переменная — не меняйте парсер, промпт и набор в одном релизе; иначе непонятно, что сработало.

Обучение, оценка и скрытая выборка: границы

Три пула оценки часто путают: обучение (train) — корпус для дообучения; dev — видимая оценочная выборка для итераций команды; holdout — скрытая выборка для редкой проверки перед релизом.

flowchart LR
  subgraph pools [Пулы данных]
    train[Обучение / SFT]
    dev[Dev — видимая оценка]
    hold[Holdout — скрытая]
    mine[Буфер сбора]
  end

  train -->|обучение| model[Модель / промпт]
  dev -->|итерации| model
  dev -->|метрики в CI| gate[Барьер]
  hold -->|редкая проверка| gate
  mine -->|после редакторов| dev
  mine -->|после редакторов| hold

Утечки: парафразы одного вопроса в обучающей и оценочной выборках; примеры в запросе (few-shot) из эталона; дообучение на текстах, близких к оценочной выборке. Перед доверием баллу — поиск близких дубликатов между пулами. Отдельная статья: dataset-splits-leakage-2026.

Когда нужно обучение, когда достаточно RAG и промпта

Критерии «нужен ли fine-tuning» — в главе о дообучении: без бизнес-причины корпус для SFT — дорогой способ переобучиться на шум.

Параметры по типу задачи

Универсального «10 000 примеров» нет. Ориентиры для планирования:

«Похожие, но неверные» примеры

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

Отказы и запросы вне области

Доля кейсов с ожидаемым отказом — не ошибка разметки, а требование. Для ассистента по регламентам разумно 15–25% эталона с отказом или эскалацией; для узкой классификации — по балансу классов.

Параметры по домену (краткая матрица)

Полный разбор — в dataset-parameters-by-domain-2026. Сжатый ориентир:

Команда и владение

Матрица RACI (Responsible, Accountable, Consulted, Informed — кто делает, кто утверждает, кого спрашивают, кого информируют) должна быть записана: кто утверждает попадание кейса из буфера в эталон, кто может менять рубрику без мажорной версии набора.

Версионирование и манифест

Каждый релиз оценки привязывайте к манифесту:

dataset_id: golden-regulations
version: v3.2.0
schema_version: 2
rubric_version: ot-rubric-1.2
content_hash: sha256:...
record_count: 142
holdout_count: 28
created_at: 2026-08-15
changelog: "Добавлены 12 кейсов устаревших редакций; исправлен id reg-0088"

В непрерывной интеграции (CI): валидация схемы, уникальность id, запрет пустого expected_output без acceptance: refusal, проверка что скрытая выборка (holdout) не попала в обучающий корпус. Статья dataset-versioning-governance-2026 развернёт управление и контроль.

Метрики качества набора (не только точность модели)

Организационные метрики ИИ — в оценке корпоративного ИИ; здесь — качество артефакта «набор».

Корпоративный пример: ассистент по регламентам

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

Неделя 0 — контракт. Продукт и ОТ фиксируют: ответ только с цитатой; при конфликте версий — отказ; вопросы вне ОТ — отказ с маршрутом к HR/IT.

Недели 1–2 — эталон v0 (80 записей). Редакторы эталонов (два инженера ОТ + методист) размечают по рубрике. Оценка для разработки (dev) — только для команды. Скрытая выборка (holdout): 20 записей — в отдельном файле, доступ у технического лида.

Недели 3–4 — базовая линия RAG. Индексация по контуру подготовки данных. Оценка на golden v0: срез «устаревшая версия» — 40% провалов. Вывод: не модель, а индекс без valid_to и отсутствие отказов в промпте.

Недели 5–8 — корпус SFT (600 пар). Только после фикса поиска. Пары «вопрос → ответ с пунктом», не сырые фрагменты. Обучение не пересекается с holdout (дедупликация по эмбеддингам).

Постоянно — буфер. Два финализированных эталона в неделю из пилота. Ежеквартально — пересмотр рубрики и мажорная версия набора.

Через квартал отчёт воспроизводим: golden v1.3, манифест индекса, модель — и видно, что подняло срез «устаревший регламент».

Промышленный пример: полевые бланки и OCR

В разборе OCR рукописных цифр параметры диктует среда:

• не глиф 28×28, а фото с перспективой;
• не одна цифра, а последовательность в ячейке;
• разметка из БД, а не ручная армия;
• разные постановки → разные метрики и архитектуры.

Тот же закон для LLM: канал, шум, постановка в наборе важнее размера чекпоинта.

Связь с RAG-кластером и книгой

Эта серия не заменяет RAG-кластер: она закрывает обучение, разметку, редакторов эталонов и управление данными там, где индекса одного недостаточно.

Типичные ошибки

Один файл на обучение и тест. Нужен аудит дубликатов и парафраз, не только случайное разбиение.

Эталон без версии. Метрики месяца назад несравнимы — сменилась линейка, не «дрейф модели».

Синтетика вместо экспертов на редких кейсах. LLM размножает правдоподобный шум.

Нет отказов в эталоне. Модель учится угадывать.

Метаданные пустые. Нельзя резать по арендатору, языку, риску — регрессии невидимы.

Дообучение до исправления поиска. SFT запоминает ошибки извлечения контекста.

Разметка без рубрики. Споры бесконечны, κ низкий.

Что сделать сегодня

1. Нарисуйте четыре семейства и выпишите, где данные лежат сейчас.
2. Назначьте владельца эталонного набора и зафиксируйте одну golden-запись (JSON выше).
3. Проведите поиск утечки между обучением, dev и отчётной оценкой.
4. Добавьте 5 кейсов с ожидаемым отказом до смены модели.
5. Запишите манифест v0.1.0 даже для 30 записей — привычка версий с первого дня.

Часто задаваемые вопросы (FAQ)

Дальше в серии

• Golden-записи и редакторы эталонов — рубрика, согласование, очередь ревью (golden-editors-annotation-workflow-2026).
• Обучение / оценка / holdout и утечки (dataset-splits-leakage-2026).
• SFT и данные предпочтений (sft-dataset-design-2026, preference-dataset-rlhf-2026).
• Параметры по домену (dataset-parameters-by-domain-2026).

Каталог серии: docs/ml-datasets/README.md в репозитории проекта.