Это прописи, а не четыре чужие тетради

В проекте часто лежат четыре семейства. Для 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": "ru",
    "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% без ревью. Красивый лосс, пустой пилот.

Обучение на эталоне оценки. Метрики радуют до первого чужого запроса.

Один автор всех 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).