Це прописи, а не чотири чужі зошити

У проєкті часто лежать чотири сімейства. Для SFT важливо не сплутати, чим ви вчите, а чим міряєте — інакше калібр із опорного огляду знову змішають із партією.

SFT — це прописи: за такого входу бажаємо один вихід (або відмову). Вподобання — два твори, який кращий. Еталон для безперервної інтеграції (CI, Continuous Integration) — контрольна з ключем. Буфер — чернетки зі парти, ще без оцінки.

Корпус може бути ширшим і шумнішим за еталон: мета — вивчити патерн, не зафіксувати регресійний бар’єр. Якщо запис не описати як «за такого входу бажаємо такий вихід», це ще не вправа для SFT — нотатка чи кандидат у буфер.

Спочатку правила рядка, потім стопка аркушів

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

Без цього два експерти напишуть дві «правильні» відповіді різної довжини, і модель вивчить середнє з шуму. Якщо контракт закривається пошуком і жорстким шаблоном, спочатку перевірте коли донавчання виправдане. SFT потрібен, коли стійка поведінка (формат, відмова, тон, жаргон) не втримується підказкою й пошуком.

Одна клітинка — одні поля

Мінімальний запис для налаштування інструкцій — не «простирадло тексту», а поля, що переживають зміну чекпоінта й бібліотеки:

{
  "id": "sft-reg-0142",
  "messages": [
    {"role": "system", "content": "…одна версія системної інструкції…"},
    {"role": "user", "content": "Чи можна зберігати ЗІЗ без журналу видачі?"},
    {"role": "assistant", "content": "За регламентом v3.2, п. 4.1 — ні. …"}
  ],
  "meta": {
    "domain": "ot_pb",
    "intent": "policy_qa",
    "doc_version": "3.2",
    "language": "uk",
    "refusal": false,
    "source": "editor",
    "difficulty": "medium"
  }
}

Чотири правила економлять тижні:

1. Одна версія системної підказки на маніфест (або явне system_version). П’ять різних system в одному JSONL — учити конфлікт політик.
2. id стабільний між версіями: правка відповіді не повинна плодити «новий» кейс без сліду.
3. Метадані для зрізів: домен, намір, версія документа, мова, відмова, джерело. Без них не відповісти, на якому зрізі впали.
4. Шаблон чату як у проді. Якщо в проді немає system, не вчіть на довгому system, якого не буде під час виклику.

Для класифікації структура може бути простішою (input / label); принцип той самий: схема + метадані + версія маніфесту.

Звідки брати рядки в зошит

Чотири джерела — у кожного свій ризик.

Робоча суміш у пілотах: ядро 30–40% пише або затверджує експерт; периферія росте синтетикою за шаблонами намірів; хвіст — із буфера провалів після рев’ю. Ксерокс без квоти й рубрики швидко заповнює зошит «впевненим середнім» — модель стає ввічливою й порожньою.

«Модель згенерувала пару» ≠ «пару перевірено». У доменах із ціною помилки фінальний статус — лише після людини. Синтетика не підписує маніфест.

Не число рядків, а карта вправ

«Скільки прикладів?» без карти покриття — питання в порожнечу. Орієнтири (не догма):

«Більше» допомагає, лише якщо росте покриття намірів і умов, а не число парафраз одного рядка. Карта — наміри × умови (є джерело / немає; актуальна / застаріла версія; один документ / конфлікт). Порожня клітинка важливіша за сто схожих «успішних» відповідей.

Якщо всі репліки користувача написав один редактор «літературно», модель погано переносить розмовний прод. Змішуйте уривки, помилки (якщо вони в потоці) і формальні листи — у частках потоку, не смаку розмітника.

Для вузької класифікації на маленькій моделі іноді вистачає сотень прикладів — як у кейсі Qwen 0.6B. Для відкритого діалогу за регламентами без відмов навіть десять тисяч пар не врятують пілот.

Вправи, де правильна відповідь — «не писати»

Корпус без відмов вчить модель завжди відповідати. У корпоративному асистенті це прямий шлях до вигаданих пунктів.

Мінімальний набір «негативних» навичок у прописах:

1. Відмова без джерела — «у переданих фрагментах немає відповіді; не вигадую».
2. Відмова за ACL — немає прав; не переказувати «із загальних знань».
3. Відмова за застарілою версією — документ знято з дії.
4. Ескалація — конфлікт двох норм; передати спеціалісту за шаблоном.
5. Форматна відмова — запит поза областю, якщо продукт це забороняє.

Частка таких кейсів часто 15–30% на старті — інакше позитивний клас задавить поведінку. Важливіша не відсоток, а наявність усіх типів відмови з контракту.

«Схожі, але невірні» відповіді зазвичай не кладуть як assistant — це територія вподобань / DPO. Для SFT корисніший жорстко правильний вихід або запис, де правильний вихід — відмова. Якщо треба обирати між двома формулюваннями — окреме сімейство, інакше один зошит тягне модель у різні боки.

Не відкривайте урок, доки зошит не пройшов перевірку

Навчання не стартує з «теки на диску». Спочатку бар’єр — як перевірка прописів перед контрольною:

flowchart TB
  sources[Джерела: редактор / прод / синтетика] --> normalize[Нормалізація схеми й шаблону]
  normalize --> lint[Статичні перевірки]
  lint --> split[Train / dev / holdout]
  split --> trainJob[Задача SFT]
  split --> evalGate[Оцінка на еталоні]
  evalGate --> release{Регресійний бар’єр}
  release -->|pass| ship[Реліз адаптера]
  release -->|fail| buffer[Буфер правок корпусу]
  buffer --> sources

Що ловить біду до GPU:

• схема: обов’язкові поля, типи, допустимі role;
• один system на маніфест (або явні версії);
• дедуплікація за текстом і майже-дублікатами;
• нуль перетинів з еталоном оцінки;
• частка відмов у коридорі;
• довжина, порожні content, гігантські вставки логів;
• персональні дані й секрети за політикою;
• мітка мови збігається з текстом на вибірці аудиту.

Підсумок бар’єра — маніфест: версія, хеш, зрізи, хто затвердив, посилання на рубрику. Без нього порівнювати «модель A vs B» безглуздо: порівнюєте ще й різні зошити.

Домашня робота не повинна збігатися з контрольною

Типова пастка: взяти 10% «з кінця файлу» в тест. Якщо файл відсортовано за часом чи автором, тест не відображає прод. Гірше — правити відповіді в train, підглядаючи в ті самі формулювання, що в звіті замовнику.

Практичні правила:

1. Прихована вибірка (holdout) — десятки–сотні кейсів, які не відкривають під час ітерацій. Звіт «готові до пілоту» — за нею або за окремим еталоном.
2. Видима dev — для налагодження; її метрики не продавати бізнесу як фінальні.
3. Еталон оцінки версіонується окремо від train-маніфесту. Можна посилатися («train v0.4 на gold v0.3»), але не тримати еталон всередині train JSONL «для зручності».
4. Парафраз — теж витік. «Чи можна зберігати ЗІЗ без журналу?» і «Чи обов’язковий журнал видачі ЗІЗ?» не повинні роз’їхатися по train і holdout без політики. Шукайте майже-дублікати.

Для RAG-оцінки еталон будується інакше — золоті набори для RAG. RAG перевіряє пошук і опору на фрагменти; SFT вчить формулювання й політику відповіді. Спільні питання між контурами — кандидат на витік.

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

Внутрішній асистент відповідає за актуальними регламентами. Пошук уже віддає фрагменти; відповіді все одно «пливуть» за форматом і дописують пункти, яких немає у фрагментах.

Контракт: відповідь лише за переданими фрагментами; обов’язково doc_id і версія; за відсутності — відмова; тон формальний.

Корпус v0.2 (приклад розподілу):

Синтетика — лише парафрази успішних і «немає у фрагментах», квота 25%, обов’язкове рев’ю. Після пілоту провали «впевнена відповідь за порожньої видачі» додали як відмови в v0.3, а не як нові «успішні» фантазії.

Метрика релізу адаптера: не середнє «схоже на еталон», а частка порушень контракту на holdout нижче порога.

Промисловий приклад: операторські інструкції

Кіоск або планшет у цеху: модель допомагає знайти крок інструкції й допустимі відхилення. Помилка дорожча за офісний чат.

Відмінності прописів: короткі репліки, шум розпізнавання мовлення, змішана мова (українська/російська + коди обладнання); жорстка відмова на «як обійти блокування» й запити поза допуском; метадані — лінія, верстат, версія техкарти, рівень допуску.

Тут 800–1500 затверджених пар із повним покриттям відмов і ліній важливіші за п’ять тисяч синтетичних «ввічливих» діалогів. Та сама логіка, що в розборі OCR рукописних цифр: спочатку схожість на експлуатацію, потім масштаб.

Суміжні матеріали: що читати поруч

Вузький експеримент «класифікація → мітка» показує: маленька модель + чисті мітки б’ють великий чекпоінт із брудним набором. Не переносьте це один в один на відкритий діалог: там одиниця — політика відповіді, і ціна «майже правильного» тексту вища.

Цей текст закриває: як спроєктувати корпус, якщо рішення «донавчаємо» вже прийняте.

Де псують прописи

Тека з чату без схеми. Різні system, немає id — відтворюваність нульова.

Нуль відмов. Модель вчиться бути корисною завжди; у проді — галюцинації впевненим тоном.

Синтетика на 90% без рев’ю. Гарний loss, порожній пілот.

Навчання на еталоні оцінки. Метрики тішать до першого чужого запиту.

Один автор усіх user-реплік. Розрив із мовою співробітників чи операторів.

SFT і вподобання в одному файлі. Модель не розуміє: вчити єдину відповідь чи «що частіше подобається».

Немає маніфесту. Не можна відкотити корпус і пояснити регресію.

Ігнор ACL і персональних даних у логах. Юридичний борг і борг із безпеки в тому самому JSONL.

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

1. Запишіть контракт пари на одну сторінку: вхід, вихід, відмова, ескалація, тон.
2. Випишіть карту покриття намірів × умов і позначте порожні клітинки — це черга розмітки, не «ще LoRA».
3. Додайте не менше п’яти відмов кожного типу з контракту.
4. Проженіть статичний бар’єр до першого запуску навчання.
5. Призначте власника маніфесту — без чийого підпису файл не потрапляє в задачу навчання.

Спочатку допишіть прописи — потім знову крутіть адаптер. Інакше наступне «зростання метрики» знову виявиться списаним із того самого зошита.

Часті запитання (FAQ)

Далі в серії

• Інженерія датасетів: огляд — рамка сімейств і життєвого циклу.
• JSONL, шарди й шлях до GPU — фізичний устрій корпусу.
• Редактори еталонів — рубрика й узгодження (golden-editors-annotation-workflow-2026).
• Навчання / оцінка / прихована вибірка й витоки (dataset-splits-leakage-2026).
• Дані вподобань: DPO і пари (preference-dataset-rlhf-2026).
• Синтетика й гібридний конвеєр (synthetic-human-dataset-pipeline-2026).