Вивантаження — ще не приймання

Зібрати 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": "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 пов’язують зразок із правилами. Без них через півроку ніхто не пояснить, чому «придатна» відповідь раптом стала іншою — калібр змінили мовчки.

Хто відповідає за сенс «золота»

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

Інженери будують схему, валідацію, 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 у репозиторії проєкту.