Модуль 13. Капстоун: доменный ассистент за один уик-энд

Цель модуля: пройти весь цикл курса одним проектом — домен и граница, датасет, golden set, тюнинг, сравнение base vs tuned, решение take/rollback и сервис-обёртка с fallback — и защитить результат по критериям приёмки.

Перед началом: модули 1–12; опорные — 5, 8, 10 (или 11) и 12. Инструменты: python3, песочница сайта; аккаунт Yandex Cloud со стартовым грантом (путь А) или DataSphere-проект с GPU-квотой (путь Б). Трудоёмкость: уик-энд: ~10–12 ч чистого времени плюс ожидание обучения.

🔥 «Расскажите про ваш проект с LLM»

Собеседование, внутренняя инициатива, стартап-идея — формулировка одна: «Вы дообучали модели? Покажите». Не сертификат и не пересказ «LoRA — это низкоранговые дельты», а проект: какая задача, откуда данные, что показал baseline, что изменил тюнинг — цифрами, как катали, что деградировало.

Без такого проекта знания двенадцати модулей за месяц ссыхаются до «что-то там про адаптеры». С проектом остаётся артефакт, который можно показать, продолжить и развить: датасет, golden set, таблица метрик, работающая обёртка и честный отчёт.

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

📖 13.1. Выбор домена: три проекта на выбор

Домен определяет, откуда брать пары и как оценивать. Три проверенных варианта:

ДоменАссистент…Данные из…Камень
Поддержка платформыотвечает по регламентуFAQ, тикетыфакты — это RAG
Двойник авторадержит стиль и ритмпосты, черновикитолько свой текст
Классификатор тикетовтема и приоритеттикеты с меткамидисбаланс классов

Расшифровка «камней». В поддержке нельзя требовать «выучить базу знаний»: свежие факты живут в контексте (RAG), дообучение — про тон и формат. У двойника — копирайт: обучайте только на своём тексте. У классификатора — дисбаланс классов из модуля 5.

Критерии выбора простые: у вас есть доступ к 100–300 реальным примерам «запрос → эталонный ответ» (для классификатора — «текст → метка»); вы сами оцениваете «хорошо/плохо» за 10 секунд; результат можно показать другому человеку. Если ни один домен не даёт данных — берите первый: FAQ открыт, пары собираются вручную за вечер.

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

📖 13.2. Архитектура: роутер, fallback и петля качества

Что должно получиться к концу уик-энда — на одной схеме:

Архитектура капстоуна: роутер A/B, fallback и петля качества

Разбор. Пользователь приходит в виджет и попадает в ваш сервис-обёртку — единственное, что он видит. Внутри три механизма из модуля 12:

  • роутер A/B — hash(user_id) % 100 делит трафик: группа A получает tuned-ассистента, группа B — базовую модель; пока идёт сравнение, группы стабильны, после решения take процент становится 100;
  • fallback-цепочка tuned → base → шаблонный ответ — падение эндпоинта не роняет виджет;
  • лог каждой пары: промпт, ответ, версия модели, thumb up/down — с PII-осторожностью из модуля 12.

Правый контур схемы — петля качества: куратор размечает «плохие» ответы, пишет эталонные, и пары идут в следующую итерацию датасета, а golden set CI прогоняет каждый новый тюнинг против baseline до выката. Обратите внимание, где стоит eval: между петлёй и версией A — новая версия добирается до пользователей только через него. Это компактный образ всего курса: тюнинг без eval не катится, фидбек без разметки не превращается в данные.

Реализовать обёртку можно на чём угодно: Go-сниппет модуля 12, FastAPI на python, Serverless Container. Для приёмки важна не технология, а поведение — версии, роутер, fallback, лог.

📖 13.3. Решения: take, rollback и правило стопа

Главное решение капстоуна — take/rollback по итогам сравнения на golden set. Сравнение честное, когда выполнены три условия. Первое: базовая и tuned версии получают одни и те же кейсы из golden set. Второе: метрики успеха зафиксированы заранее, до просмотра результатов — что вы считаете успехом: точность формата, попадание в регламент, длина, тон. Третье: прогоняется весь regression suite из модуля 8 — «стало лучше в домене» не должно оплачиваться «разучилась извиняться».

Take — tuned значимо лучше на целевых метриках и регрессий нет. Rollback — любое из: главная метрика не выросла; появилась регрессия на suite; tuned подозрительно идеальна на golden set при слабых ответах на живых примерах — значит, датасет и golden set пересекаются или модель переобучилась. Rollback — не провал, а результат: причины уходят в бэклог датасета (мало пар, грязные пары, не та граница) — это штатный оборот цикла из модуля 12.

Правило стопа. Уик-энд ограничен, поэтому порог фиксируется заранее: тюнинг не удался с третьей попытки — остаётесь на base, документируете попытки и заканчиваете отчётом. Отчёт с честным rollback — полноценный результат капстоуна; бесконечный «ещё один тюнинг» — нет.

📖 13.4. Компромиссы

  • Путь А (YandexGPT Lite) vs путь Б (QLoRA в DataSphere). А — часы активной работы и managed-инференс, но меньше контроля; Б — полный контроль и свои веса, но дороже по времени и рискам (OOM, деплой на ВМ).
  • Больше пар vs чище пары. 300 сырых против 150 вычищенных — берите чистые (модуль 5): качество пар бьёт количество.
  • Широкий домен vs узкая граница. Узкая — меньше пар и точнее ответы; широкий — полезнее, но расплывчат в оценке и хуже отказывает.
  • Ручная разметка фидбека vs только автоматические метрики. Ручная — медленно, но это единственный источник эталонных ответов; автоматика быстра, но слепа к тону и пользе.
  • Отшлифовать обёртку vs пройти весь цикл. Цикл важнее: красивый сервис без датасета и eval — ноль результата капстоуна.

💻 Практика

План уик-энда. Каждый этап заканчивается артефактом — файлом или записью; без артефакта этап не завершён. Время чистое, ожидание тюнинга не считается. Раскладка на два дня: суббота — этапы 0–3 (тюнинг запускайте до обеда), воскресенье — этапы 4–6.

  1. Домен и граница (30 мин). Выберите вариант из 13.1, сформулируйте строку «ассистент делает X, всё остальное — оператору» и решите, откуда возьмёте данные. Артефакт: README.md с границей домена и источником данных.

  2. Датасет: 100–300 пар (3–4 ч). Соберите пары instruction/request/ response из вашего источника (для классификатора — text + метка) и прогоните гигиену по модулю 5: нормализация, дедупликация точная и близкая, баланс тем/классов, стратифицированный train/val без утечки. Скрипт гигиены можно собрать из песочницы модуля 5. Артефакт: dataset/train.jsonl, dataset/val.jsonl, скрипт гигиены.

  3. Golden set и baseline (1.5–2 ч). Отберите 20–50 кейсов реальных задач, не входящих в train; заранее выпишите метрики успеха из 13.3. Прогоните base-модель на golden set и зафиксируйте результаты цифрами — это точка отсчёта для любого сравнения. Артефакт: golden.jsonl, таблица baseline.md.

  4. Тюнинг (1–2 ч активных + ожидание). Путь А — YandexGPT Lite через AI Studio SDK по модулю 10: датасет, tune_deferred, TensorBoard-метрики, uri с суффиксом версии. Путь Б — QLoRA в DataSphere по модулю 11: модель 3–4B, конфигурация gt4.1, чекпойнты в Object Storage. Запускайте как можно раньше — обучение идёт часами. Артефакт: tuned.uri (или чекпойнт) и versions.md с гиперпараметрами.

  5. Сравнение и решение (1–1.5 ч). Прогоните tuned на golden set и на regression suite — 20+ «общих» вопросов вне домена, чтобы поймать потерю общих способностей. Соберите таблицу base vs tuned по выбранным метрикам и примите take/rollback по правилам 13.3. Артефакт: compare.md — таблица, решение, обоснование.

  6. Обёртка (1.5–2 ч). CLI или мини-сервис: версия модели с суффиксом, роутер hash(user_id) с долей из конфига, fallback-цепочка, лог пар с версией модели. Отправная точка — Go-сниппет модуля 12 или FastAPI- заготовка; боевой вызов облака за флагом --live, по умолчанию мок — демонстрация не должна зависеть от сети и квот. Артефакт: репозиторий assistant/ с README и конфигом.

  7. Отчёт (1 ч). Заполните шаблон ниже; отдельно и честно — что улучшилось, что деградировало и какой следующий шаг. Артефакт: REPORT.md.

text
Проект: <домен и граница одной строкой>
Датасет: <N пар, источник, что вычищено; размеры train/val>
Golden set: <M кейсов, метрики успеха, baseline base-модели>
Тюнинг: путь А|Б, версия, гиперпараметры, время и стоимость обучения
Сравнение: <таблица base vs tuned; что улучшилось, что деградировало>
Решение: take | rollback — обоснование одной строкой
Эксплуатация: версия в бою, доля A/B, fallback-цепочка, что пишем в лог
Следующий шаг: <одно конкретное улучшение датасета или golden set>

🧩 Quiz "Проверь себя"

1. Откуда берутся кейсы golden set?
2. Что обязательно пишется в лог каждого ответа обёртки?
3. Tuned лучше на главной метрике, но в suite — регрессия. Что делать?
4. Когда оправдан путь Б (QLoRA в DataSphere) вместо пути А?
5. Сколько пар достаточно для первой итерации ассистента поддержки?

✅ Итоги модуля

Проект считается принятым, когда выполнены все пункты:

  • Граница домена сформулирована одной строкой и видна в датасете: пары «вне домена» учат отказу и передаче оператору.
  • Датасет 100–300 пар прошёл гигиену модуля 5: дедупликация, баланс, train/val без утечки валидации в train.
  • Golden set 20–50 кейсов не пересекается с train; метрики успеха зафиксированы до прогона.
  • Baseline base-модели на golden set измерен и записан цифрами.
  • Тюнинг завершён по пути А или Б; версия имеет суффикс, гиперпараметры зафиксированы в versions.md.
  • Regression suite модуля 8 прогнан; сравнение base vs tuned — таблицей.
  • Решение take/rollback принято по правилам 13.3 и записано с обоснованием.
  • Обёртка: версии, A/B-роутер по hash(user_id), fallback-цепочка, лог пар с версией модели.
  • A/B-группы стабильны: один пользователь всегда в одной группе.
  • Отчёт отвечает на три вопроса: что улучшилось, что деградировало, какой следующий шаг.

🧭 Куда дальше

Курс закончился, маршрут — нет. Что изучать и строить следующим:

  • RAG-системы. Если модели не хватает свежих фактов, а не стиля — следующий курс трека (в планах) про retrieval: векторные базы, поиск по эмбеддингам (косинусную близость вы уже считали в модуле 1), реранкинг и гибрид «FT для тона + RAG для фактов» из модуля 4. Ваш капстоун легко расширяется: ассистент остаётся, рядом появляется поиск по базе знаний.
  • LLM-агенты. Модели, которые не только отвечают, но и вызывают инструменты: планирование шагов, память, контроль галлюцинаций. Курс по агентам — второй кандидат в трек; капстоун — готовый «одношаговый агент» и задел к нему.
  • Eval и данные всерьёз. Превратите петлю качества из капстоуна в постоянный процесс: регулярная разметка фидбека, пополнение golden set, regression suite на каждое изменение датасета. Это самый дешёвый способ расти после курса — без единого нового метода обучения.

RLHF/DPO — одним абзацем. За пределами курса остался класс методов обучения не на готовых парах, а на предпочтениях: «этот ответ лучше того». RLHF (reinforcement learning from human feedback) обучает модель политике наград, DPO (direct preference optimization) подбирает веса прямо из пар предпочтений, без отдельной reward-модели. Это следующий уровень после SFT-тюнинга, которым вы занимались: нужны тысячи размеченных сравнений, зрелый eval и распределённое обучение — не уик-энд-проект. Когда ваш датасет и golden set вырастут, DPO поверх вашего же QLoRA-стека — логичный следующий эксперимент.

Инструменты, которые стоит держать под рукой:

И привычка, которую стоит забрать из курса: любое изменение модели — это новая версия, eval до выката и откатываемый маршрут; любой фидбек — сырьё для следующего датасета. Цикл с диаграммы модуля 12 не заканчивается — он просто теперь ваш.