✅ Решения

← К оглавлению урока

⚡ Кратко

Хорошая сдача показывает не только код обучения, но и инженерное мышление: почему fine-tuning выбран, как подготовлены данные, чем измеряется улучшение и какие риски закрыты.

Часть 1. Ответы

  1. Fine-tuning — продолжение обучения готовой модели на небольшом специализированном датасете.
  2. Pretraining создаёт базовую модель на огромных данных; fine-tuning адаптирует уже обученную модель к задаче.
  3. Полезные сценарии: стиль бренда, классификация доменных текстов, фиксированный формат ответа, корректировка instruction-following.
  4. RAG лучше для документов и свежих знаний, потому что данные можно обновлять без переобучения и показывать источники.
  5. Garbage in, garbage out означает: шумные, предвзятые и противоречивые данные дают плохую модель.
  6. Test split нужен для честной проверки на примерах, которых модель не видела во время обучения.
  7. После запуска отслеживают качество, ошибки, latency, стоимость, drift, safety-инциденты и обновления модели.

Часть 2. Пример плана задачи

# task_plan.md
Задача:
Классифицировать отзывы о мобильных телефонах: positive / neutral / negative.

Почему prompt недостаточен:
На коротких саркастичных отзывах baseline часто ошибается.

Почему RAG не главный:
Задача не про внешние знания, а про устойчивую классификацию.

Baseline:
Обычная LLM с few-shot prompt на том же test set.

Данные:
300 размеченных отзывов, очищены от дублей и PII.

Метрики:
accuracy, macro F1, confusion matrix, ручная проверка 30 ошибок.

Риски:
Сарказм, токсичность, личные данные, перекос классов.

Часть 3. Мини-датасет

instructioninputoutput
Classify review sentiment.Battery lasts two days, camera is great.positive
Classify review sentiment.The phone freezes after every update.negative
Classify review sentiment.Average screen, acceptable price.neutral

Часть 4. Эталонные критерии качества

  • Train/test разделены до обучения и test не редактируется под результат.
  • Есть baseline без fine-tuning.
  • Есть понятная метрика: accuracy/F1 для классификации, exact format match для JSON, human rubric для текстов.
  • Показаны ошибки, а не только удачные примеры.
  • Есть вывод: fine-tuning окупается или нет.

Часть 5. Production checklist

ВопросПример ответа
Персональные данные?Удаляем email, телефоны, адреса; храним только обезличенный текст.
Human-in-the-loop?Нужен, если результат влияет на деньги, здоровье, юридические решения или доступ к услуге.
Логи?Логируем request id, latency, модель, версию промпта, оценку; не логируем секреты и лишнюю PII.
Устаревание?Отслеживаем падение метрик, новые типы входов, жалобы пользователей, drift распределения.

Часть 6. Что сдавать по LMS

  1. Ссылка или описание датасета.
  2. До/после очистки: что удалили и почему.
  3. Размер train/test и способ разделения.
  4. Код или план fine-tuning пайплайна.
  5. Таблица тестовых результатов и короткий вывод.