Ключові висновки

Датасет — версіонований продукт — схема, власник, маніфест (хеш + версія + правила розмітки), історія змін у git або data store.

Навчання й оцінка — різні контури. Тренувальний корпус вчить поведінку; еталонний набір її вимірює. Змішувати без аудиту витоків — обманювати себе метриками.

Спочатку контракт задачі, потім обсяг і модель. Вхід, вихід, відмова — до розмови про LoRA й розмір чекпоінта.

Golden-запис — контракт на один приклад: вхід, очікуваний результат або критерії приймання, метадані. Набір таких записів — еталонний набір (golden dataset).

Редактори еталонів (golden editors) — доменні експерти, які створюють і погоджують еталон. Без них синтетика й краудсорс дають гарні числа й слабкий прод.

Параметри залежать від задачі й домену: обсяг, одиниця розмітки, hard negatives і пороги якості для класифікації, SFT, retrieval і computer vision — різні.

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

Середнє без зрізів бреше. Гарне середнє може ховати провал на рідкому, але дорогому сегменті — застарілий регламент, чужий тенант, поганий скан.

Чим інженерія датасетів відрізняється від «зібрали CSV»

Інженерія датасетів — не разова вигрузка логів і не замовлення розмітки на біржі. Це повторюваний процес із явними артефактами:

Якщо немає схеми, власника еталона й версії — ви ще експериментуєте з промптом, а не займаєтесь інженерією даних. Це нормально на нульовій стадії, але небезпечно, коли пілот уже обіцяний бізнесу.

Чому дані важливіші за чергову модель

Ціна помилки асиметрична. Хибний клас на демо — неприємно. Хибна інтерпретація пункту регламенту з охорони праці — інцидент. Тому «яку модель поставити» — після «який контракт можемо перевірити на production-подібних даних».

Три сигнали, що пора зайнятися датасетом

1. Метрика стрибає без відтворюваності — у одному PR змінювали промпт, набір і модель.
2. Гарні цифри на тесті, поганий пілот — domain gap (див. MNIST проти фото бланків у OCR рукописних цифр).
3. Немає власника розмітки — «правильно» визначає той, хто останнім дивився в чат.

Вартість поганих даних

• Переобучення на eval — метрики радують до першого чужого запиту.
• Дороге дообучення — GPU-години на шум замість retrieval або rubric.
• Регресії без імені — не відкотити «набір v3», бо версії не було.
• Втрата довіри домену — експерти перестають рев’юити.

Інженерія датасетів робить покращення пояснюваними: версія набору, зріз, гейт — зрозумілі інженеру й власнику продукту.

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

До розмітки зафіксуйте контракт:

Контракт — основа rubric для редакторів еталонів. Без нього низький inter-annotator agreement — провал процесу, а не «складна задача».

Загальний підхід до eval: оцінка LLM перед production. Тут фокус на даних для цього eval.

Чотири сімейства даних

Тренувальний корпус

Вчить як відповідати: тон, формат, патерни домену. Може бути більшим і шумнішим на краях — але з lint: дедуп, ACL, без перетину з eval.

Preference data

Коли важливе уподобання між двома правдоподібними відповідями. Менший обсяг, ніж SFT; якість розмітників критичніша.

Еталонний набір

Фіксований, версіонований. Окремий розбір eval RAG: еталонний набір для оцінки RAG.

Буфер майнінгу

Сирий потік: логи, скарги. Не звітна метрика, поки редактор не промотував запис. SLA за класом ризику.

Golden-запис: мінімальна схема

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

Поля acceptance і rubric_version пов’язують запис із правилами редактора.

Редактори еталонів: роль, а не лише UI

Інженери будують схему, CI; редактор еталонів відповідає за зміст «золота».

Детальний workflow: golden-editors-annotation-workflow-2026.

Життєвий цикл

flowchart TB
  subgraph sources [Джерела]
    prod[Трафік і логи]
    docs[Документи й регламенти]
    synth[Синтетика за rubric]
  end

  subgraph human [Люди]
    editors[Редактори еталонів]
    adjud[Узгодження спорних кейсів]
  end

  subgraph artifacts [Артефакти]
    buffer[Буфер майнінгу]
    golden[Еталонний набір vN]
    train[Тренувальний корпус]
    pref[Preference пари]
  end

  subgraph gates [Контроль]
    eval[Eval harness]
    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

Правила: буфер ≠ еталон; версія піниться до кожного прогону; holdout закритий при ітераціях промпта; один експеримент — одна змінна.

Train, eval і holdout

flowchart LR
  subgraph pools [Пули даних]
    train[Train / SFT]
    dev[Dev eval — видимий]
    hold[Holdout — прихований]
    mine[Буфер майнінгу]
  end

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

Витоки: парафрази в train і eval; few-shot з golden; fine-tune на текстах близько до eval. Стаття: dataset-splits-leakage-2026.

Коли потрібен train, коли достатньо RAG і промпта

Критерії дообучення: коли потрібен fine-tuning.

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

Для асистента з регламентів розумно 15–25% golden з відмовою або ескалацією; для вузької класифікації — за балансом класів.

Hard negatives

Особливо важливі для retrieval і класифікації: «схоже, але хибно». Без них модель вчиться на легких прикладах і падає на сусідніх розділах регламенту або схожих артикулах.

Параметри за доменом (коротка матриця)

Повний розбір: dataset-parameters-by-domain-2026.

Команда та володіння

Запишіть RACI: хто затверджує buffer → golden.

Версіонування та маніфест

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 кейсів застарілих редакцій"

У CI: валідація схеми, унікальність id, holdout не в train.

Метрики якості набору

Організаційні метрики ШІ: оцінювання корпоративного ШІ.

Корпоративний приклад: асистент з регламентів

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

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

Тижні 1–2 — golden v0 (80 записів). Редактори еталонів (два інженери ОТ + методист) розмічують за rubric. Dev eval — лише для команди. Holdout 20 записів — окремий файл, доступ у tech lead.

Тижні 3–4 — baseline RAG. Індексація за контуром підготовки даних. Eval на golden v0: зріз «застаріла версія» — 40% провалів. Висновок: не модель, а індекс без valid_to і відсутність відмов у промпті.

Тижні 5–8 — корпус SFT (600 пар). Лише після фікса retrieval. Пари «питання → відповідь із пунктом», не сирі чанки. Train не перетинається з holdout (перевірка embedding-dedup).

Постійно — буфер. Два finalized golden на тиждень із пілота. Щокварталу — перегляд rubric і мажорна версія набору.

За квартал звіт відтворюваний: golden v1.3, маніфест індексу, модель — видно, що підняло зріз «застарілий регламент».

Промисловий приклад: польові бланки

У розборі OCR рукописних цифр параметри диктує середовище: не гліф 28×28, а фото з перспективою; не одна цифра, а послідовність у комірці; розмітка з БД замість армії розмітників; різні постановки → різні метрики й архітектури.

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

Зв’язок з RAG-кластером

Ця серія не замінює RAG-кластер: вона закриває навчання, розмітку, golden editors і governance даних там, де одного індексу недостатньо.

Типові помилки

Один файл на train і test. Потрібен аудит дублікатів і парафраз, не лише random_split.

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

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

Немає відмов у golden. Модель вчиться вгадувати.

Порожні метадані. Неможливо різати за тенантом, мовою, ризиком — регресії невидимі.

Fine-tune до виправлення retrieval. SFT запам’ятовує помилки пошуку.

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

Що зробити сьогодні

1. Намалюйте чотири сімейства і де лежать дані.
2. Призначте власника еталонного набору і одну golden-запис (JSON вище).
3. Перевірте витік між train/dev і звітним eval.
4. Додайте 5 кейсів з очікуваною відмовою.
5. Запишіть маніфест v0.1.0 навіть для 30 записів.

FAQ

Далі в серії

• Golden-записи й редактори еталонів — golden-editors-annotation-workflow-2026
• Train / eval / holdout і витоки — dataset-splits-leakage-2026
• SFT і preference data — sft-dataset-design-2026, preference-dataset-rlhf-2026
• Параметри за доменом — dataset-parameters-by-domain-2026

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