Выгрузка — ещё не приёмка

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

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

Новая машина не чинит кривой калибр

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

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

Три сигнала, что пора чинить калибр, а не крутить чекпоинт:

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

Плохой набор стоит дороже, чем кажется: переобучение на оценочной выборке, часы на GPU на шум вместо исправления поиска, невозможность откатить «набор v3», потеря доверия экспертов. Инженерия данных делает улучшения объяснимыми: версия, срез, барьер — артефакты, понятные и инженеру, и владельцу продукта.

Сначала договоритесь, что считать годным

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

Без этого два эксперта размечат один кейс по-разному, и низкое согласие разметчиков окажется отсутствием правил, а не «сложной задачей». Подход к оценке до эксплуатации — в материале про оценку LLM перед запуском; здесь фокус на данных, которые кормят этот контур.

Четыре ящика, которые нельзя смешивать

На одном складе могут стоять четыре ящика. Свалить их в один — получить «красивую» метрику и ложный релиз.

Тренировочный корпус учит как отвечать: тон, формат, типичные паттерны. Для SFT это пары «инструкция → ответ»; для классификатора — «текст → метка». Он может быть большим и шумным на краях, но проходит статическую проверку: дедупликация, ACL, запрет явных дубликатов с оценочной выборкой.

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

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

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

Один образец — один контракт

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

{
  "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 связывают образец с правилами. Без них через полгода никто не объяснит, почему «годный» ответ внезапно стал другим — калибр сменили молча.

Кто отвечает за смысл «золота»

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

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

Подробный процесс — в статье 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

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

Учить, мерить и прятать линейку

Три пула оценки путают чаще всего. Обучение — корпус для дообучения. Видимая оценка для разработки (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

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

Когда хватает поиска, а когда нет

Не каждый кривой ответ лечится дообучением. Иногда достаточно найти нужный документ и не врать.

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

Объём зависит от задачи, не от моды

Универсальных «десяти тысяч примеров» нет — у разных задач разная единица приёмки.

Особенно важны случаи «похоже, но неверно»: без них модель учится на лёгких примерах и падает на соседних разделах регламента. Доля кейсов с ожидаемым отказом — не ошибка разметки, а требование. Для ассистента по регламентам разумно 15–25% эталона с отказом или эскалацией.

Домен меняет дефицит

Полный разбор — в dataset-parameters-by-domain-2026. Сжатый ориентир: в каждом домене не хватает своего ресурса — цитаты, допуска, свежести API или качества канала.

Кто утверждает калибр

Запишите, кто утверждает перевод кейса из буфера в эталон и кто может менять рубрику без мажорной версии набора. Без владельцев калибр «плывёт» незаметно — и все спорят о модели.

Без номера версии метрика — другая линейка

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

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, запрет пустого ожидаемого выхода без отказа, проверка что скрытая выборка не попала в обучающий корпус. Статья dataset-versioning-governance-2026 развернёт управление.

Считайте качество самого набора

Точность модели — не единственная шкала. Смотрите на сам артефакт «набор»:

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

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

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

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

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

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

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

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

Через квартал отчёт воспроизводим: версия эталона, манифест индекса, модель — и видно, что подняло срез «устаревший регламент». Калибр остался тем же инструментом; меняли то, что им измеряли.

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

В разборе OCR рукописных цифр параметры диктует среда: не глиф 28×28, а фото с перспективой; не одна цифра, а последовательность в ячейке; разметка из базы, а не армия разметчиков. Тот же закон для языковых моделей: канал, шум и постановка в наборе важнее размера чекпоинта. Калибр должен отражать цех, а не учебный стенд.

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

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

Где ломают линейку

Один файл на обучение и тест — без аудита дубликатов и парафраз. Эталон без версии — метрики месяца назад несравнимы. Синтетика вместо экспертов на редких кейсах размножает правдоподобный шум. Нет отказов в эталоне — модель учится угадывать. Пустые метаданные — регрессии по арендатору и риску невидимы. Дообучение до исправления поиска — SFT запоминает ошибки извлечения. Разметка без рубрики — бесконечные споры и низкое согласие.

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

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

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

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

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

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

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