11.5 · Файнтюнинг: базовый пример LoRA

Неделя 11 · Продакшен · ⏱ ~4 ч · Теория, Практика

Зачем это AI-инженеру

AI-инженер дообучает модели редко, но вопрос «а почему не дообучить?» звучит на каждом втором собеседовании и в каждом втором разговоре с заказчиком. Сильный ответ — не «файнтюнинг крутой», а «вот когда он оправдан, вот почему здесь RAG, а здесь хватит промпта, и вот как его запустить и оценить». Эта глава даёт и аргументы, и реальный прогон LoRA своими руками: сначала готовый учебный ноутбук, чтобы пройти весь цикл, затем (по желанию) своя задача из магазина «Полка» — определить, к какому разделу базы знаний относится вопрос клиента.

Теория

Где файнтюнинг в жизненном цикле модели

pretraining           →  SFT (instruction tuning)  →  preference tuning     →  наш файнтюнинг
триллионы токенов         примеры «вопрос → ответ»      DPO / RLHF:               сотни–тысячи примеров
текста, модель учится     модель учится следовать        «этот ответ лучше того»   нашей задачи
продолжать текст          инструкциям, формату чата                                (обычно SFT + LoRA)
делают лаборатории        делают лаборатории             делают лаборатории         можем сделать мы

Видео Карпатого из гл. 1.5 описывало первые этапы. Supervised fine-tuning (SFT) — то же обучение «предскажи следующий токен», только на наших примерах «вход → желаемый выход». Модель сдвигает веса так, чтобы на похожих входах выдавать похожие выходы.

Что важно понять: файнтюнинг меняет поведение (стиль, формат, решение узкой задачи), а не надёжно добавляет знания. Модель, дообученная на 500 примерах «вопрос клиента → ответ поддержки», не «запомнит базу знаний» kb/ — она научится отвечать в стиле этих примеров и будет уверенно выдумывать сроки возврата и гарантии в этом стиле.

Промпт vs RAG vs файнтюнинг: когда что

Задача	Чем решать	Почему
Модель должна знать правила магазина из базы знаний kb/	RAG	Правила меняются; нужны ссылки на источник (гл. 5.3); обновление = переиндексация, а не переобучение
Нужен определённый формат/тон, который промптом держится нестабильно	Файнтюнинг (если промпт + few-shot + structured output не помогли)	Поведение «вшивается» в веса, промпт короче
Узкая классификация на большом трафике (раздел базы знаний для вопроса, тональность отзыва, тип обращения)	Файнтюнинг маленькой модели	Маленькая дообученная модель часто догоняет большую на узкой задаче — в разы дешевле и быстрее
Дорогая большая модель хорошо решает задачу, нужно дешевле	Дистилляция: ответы большой модели → обучающий набор → файнтюнинг маленькой	Удешевление при сохранении качества на узкой задаче
Новая задача, мало примеров, требования меняются каждую неделю	Промпт	Итерация за минуты, а не часы; нечего «переобучать»
Модель должна знать заказы и остатки магазина	Tool calling / SQL (Проект 1)	Данные меняются каждую минуту и должны быть точными

Лестница решений, которую стоит произносить на собеседовании:

1. Промпт (+ few-shot, + structured output)   — часы, почти бесплатно
2. RAG / инструменты                           — если не хватает знаний или данных
3. Более сильная модель                        — если не хватает «ума»
4. Файнтюнинг                                  — если нужен стабильный формат/стиль,
                                                 узкая задача в масштабе, или удешевление
   ...и только при наличии evals, чтобы доказать, что стало лучше

Цена файнтюнинга — не только GPU. Это сбор и чистка данных (самое дорогое), evals, хранение и сервинг своих весов, и переобучение при каждой смене базовой модели. Облачные модели обновляются; наш адаптер к старой базе — нет.

Часть провайдеров предлагает управляемый файнтюнинг через API (загружаем JSONL, получаем id дообученной модели). Какие модели и на каких условиях это поддерживают — меняется, поэтому смотрим актуальную документацию провайдера.

Full fine-tuning vs PEFT

Если лестница всё же привела к файнтюнингу, следующий вопрос — какие веса менять: все или небольшую добавку к ним. Полный файнтюнинг обновляет все веса. Для модели 8B это означает хранить в памяти веса, градиенты и состояние оптимизатора (у Adam — ещё два числа на параметр) — десятки гигабайт GPU-памяти и отдельная копия модели на каждую задачу.

PEFT (parameter-efficient fine-tuning) — семейство методов, которые замораживают исходные веса и обучают небольшое число новых. Самый популярный — LoRA.

LoRA: идея в одной формуле

Возьмём одну матрицу весов W размером d × k (например, 4096 × 4096 в слое внимания). Полный файнтюнинг ищет поправку ΔW того же размера. Гипотеза LoRA: нужная для адаптации поправка имеет низкий ранг, то есть её можно представить как произведение двух узких матриц:

W' = W + ΔW = W + (alpha / r) · B · A

W:  d × k   (заморожена)
B:  d × r   (обучается, инициализирована нулями → в начале W' = W)
A:  r × k   (обучается)
r:  ранг, обычно 8–64

параметров в ΔW полного файнтюнинга: 4096 × 4096 = 16 777 216
параметров в LoRA при r = 16:        4096 × 16 + 16 × 4096 = 131 072  (≈0.8%)

Аналогия из обычной разработки: вместо того чтобы хранить новую копию всего репозитория, храним маленький патч (diff), который применяется поверх. Патч (адаптер) весит мегабайты, базовая модель одна, адаптеров под разные задачи — сколько угодно.

Параметры, которые встречаются в LoraConfig:

Параметр	Что значит	Типичное начало
r	ранг: «ёмкость» адаптера	8–16; больше — больше параметров, риск переобучения
lora_alpha	масштаб поправки (делится на r)	часто равен r или 2r
target_modules	к каким матрицам добавлять адаптер	проекции внимания (q_proj, k_proj, v_proj, o_proj), часто и MLP (gate_proj, up_proj, down_proj); имена зависят от архитектуры
lora_dropout	регуляризация	0–0.1

Иллюстративный пример на Hugging Face PEFT (сверяем с актуальной версией docs):

from transformers import AutoModelForCausalLM
from peft import LoraConfig, get_peft_model

base = AutoModelForCausalLM.from_pretrained("<org>/<small-instruct-model>")
config = LoraConfig(
    r=16,
    lora_alpha=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)
model = get_peft_model(base, config)
model.print_trainable_parameters()  # expect well under 1% trainable

После обучения адаптер либо подгружается поверх базы (PeftModel.from_pretrained), либо вливается в веса (merge_and_unload() — возвращает новую модель, это не in-place операция) — тогда это обычная модель без дополнительной латентности, которую можно сконвертировать, например, в GGUF и запустить в Ollama (гл. 11.4).

QLoRA: LoRA на бесплатном GPU

QLoRA = базовая модель загружается квантизованной в 4 бита (заморожена), а LoRA-адаптер обучается в 16 битах поверх неё. Память под базу падает в ~4 раза, и модель на несколько миллиардов параметров обучается на одной небольшой GPU — например, на бесплатной облачной T4. Связь с гл. 11.4: это та же квантизация, только применённая во время обучения.

Где обучать: Google Colab — Jupyter-ноутбуки в браузере (как в главе 1.4 · Jupyter-ноутбуки в VS Code, гл. 1.4, только на чужой машине) с бесплатной видеокартой NVIDIA T4 на ограниченное время; или своя машина с NVIDIA GPU (8 ГБ видеопамяти хватает на QLoRA модели 3–4B). На Apple Silicon и CPU обучение заметно медленнее, поддержку проверяем в документации инструмента. Запускать результат проще: модель на 4B в q4_k_m работает в Ollama на машине с 8 ГБ RAM, как и qwen3:4b.

Чем обучать: Unsloth — открытая библиотека поверх Hugging Face PEFT и TRL (библиотека Hugging Face для SFT-обучения), которая ускоряет LoRA/QLoRA и экономит память; у неё есть готовые бесплатные ноутбуки для Colab под популярные маленькие модели, с ними и работаем в Практике. Unsloth рекомендует начинать именно с QLoRA и обучать/сервить в одной и той же точности. Стартовые гиперпараметры из их гайда: learning rate 2e-4, для быстрой проверки max_steps=60, для полного прогона 1–3 эпохи (больше — риск переобучения).

Данные: формат и качество

Метод и инструмент выбраны; дальше — данные, от которых результат зависит больше всего. Для чат-модели пример — это диалог в формате сообщений. Наша задача — вопрос клиента → раздел базы знаний, те же значения category, что во front matter страниц kb/, плюс other для вопросов не про магазин:

{"messages": [
  {"role": "system", "content": "Определи раздел базы знаний магазина для вопроса клиента. Ответь одним словом: delivery, payment, returns, warranty, promo, orders, products или other."},
  {"role": "user", "content": "можно ли вернуть вскрытый чай?"},
  {"role": "assistant", "content": "returns"}
]}

Каждый такой диалог перед обучением превращается в строку через chat template модели — специальные токены, обозначающие роли. Шаблон при обучении и при инференсе должен совпадать: если модель обучена с одним, а запускается с другим (например, другой шаблон в Ollama), она ведёт себя странно. Обычно лосс считают только на ответе ассистента, а не на промпте.

Качество данных важнее количества: 300 чистых, разнообразных, единообразно размеченных примеров лучше 3000 противоречивых. Как в главе 2.5, правила разметки записываем до разметки: вопрос получает раздел той страницы, которая на него отвечает; «действует ли TEA15 вместе со скидкой?» — это promo, а не payment; вопрос, которому нужны два раздела, получает главный. Для узкого классификатора — сотни примеров на класс; для стиля — сотни–тысячи диалогов. Данные можно сгенерировать сильной моделью (синтетика из гл. 6.2 — та же техника), но тогда обязательно ручная проверка выборки.

Как понять, что стало лучше

Обучение закончилось, loss упал — но это ещё не значит, что модель стала лучше решать задачу. Как и всё в этой книге, проверяем только через evals:

• Отложенная выборка (test split, например 20%), которую модель не видела. Вопросы из eval/golden.jsonl с заполненным category попадают только в test: это готовый эталон, и в train ему не место.
• Три строки сравнения: базовая модель с хорошим промптом и few-shot; дообученная модель; сильная облачная модель. Если базовая + few-shot ≈ дообученная — файнтюнинг не нужен.
• Шум: на 60 тестовых вопросах (20% от 300 примеров) 0,90 против 0,85 — это три вопроса; «доказано» или «тенденция», решает eval/stats.py из главы 8.1.
• Признаки переобучения: train loss падает, а качество на test не растёт или падает; модель дословно повторяет обучающие ответы.
• Catastrophic forgetting: модель стала хорошо классифицировать, но разучилась нормально отвечать на всё остальное. Для узкой задачи это допустимо, для общего ассистента — нет.

Безопасность и данные

• Colab — облако Google. Никаких данных клиентов в обучающем наборе для Colab: только публичные или выдуманные тексты — страницы kb/, синтетика из них, демо-база. Реальные сообщения клиентов (у нас они выдуманы, но обращаемся с ними как с настоящими) в Colab не загружаем даже обезличенными; набор с ними обучаем только локально, на своей машине с GPU.
• Ноутбук Colab — исполняемый код. Берём ноутбуки из официальных источников (репозиторий/документация Unsloth, Hugging Face), просматриваем ячейки перед запуском, особенно pip install и всё, что скачивает что-то по URL.
• Токен Hugging Face (если нужен для gated-модели или загрузки результата) — через Colab Secrets, не строкой в ячейке; токен с правами только на чтение, если модель никуда не загружается.

DeepSeek и Ollama: как это сделать у нас

Сам файнтюнинг идёт в Colab (Unsloth/PEFT) и от провайдера API не зависит. Провайдеры важны на трёх участках: где взять данные, где запустить результат и с чем сравнить. Проверено по документации DeepSeek и Ollama в ноябре 2026.

Что	Claude	OpenAI	DeepSeek	Ollama
Управляемый файнтюнинг через API	проверяем актуальные docs Anthropic	есть (загрузка JSONL, задача обучения) — условия и модели в docs	нет: в API Reference на ноябрь 2026 только chat/responses/messages, FIM, модели, баланс, файлы и инструменты	не обучает
Открытые веса для своего LoRA	нет	см. docs (часть open-weight моделей)	есть в организации deepseek-ai на Hugging Face, но флагманские модели слишком велики для Colab T4 и обычного ноутбука — смотрим размеры в карточках	—
Запустить свой результат	нет	дообученная модель живёт у OpenAI	нет	да: GGUF → Modelfile → ollama create
Роль в этой главе	для сравнения	для сравнения	«учитель» для синтетики по публичным данным; сильная строка сравнения	запуск адаптированной модели, базовая линия

Данные. Синтетику для классификатора (опциональное задание) дешевле всего генерировать на DeepSeek (deepseek-flash; deepseek-v4-pro — если качество примеров хуже) — но только из публичных страниц kb/ (база знаний магазина публичная и выдуманная, поэтому облаку её показывать можно), без архивных страниц, как в главе 6.2. Перед тем как обучать модель на ответах другой модели, читаем условия использования провайдера про использование выходов для обучения моделей — это меняется и различается у провайдеров. Сообщения клиентов и снимки базы data/shop.db не идут ни в DeepSeek, ни в Colab.

Практический смысл задачи: настоящие вопросы клиентов обрабатывает только локальная модель. Если маленькая дообученная модель определяет раздел так же хорошо, как DeepSeek, она может выбирать categories в plan_query (5.1) — локально и дёшево.

Запуск результата в Ollama. Надёжный путь, который описан в Importing a Model: влить адаптер (merge_and_unload()), экспортировать в GGUF (у Unsloth есть функция экспорта в ноутбуке) и создать модель:

# Modelfile
FROM ./classifier-q4_k_m.gguf
PARAMETER temperature 0

ollama create category-clf -f Modelfile. Ollama не квантизует GGUF при импорте — квантизуем заранее (llama.cpp llama-quantize или экспорт Unsloth). Шаблон чата должен совпадать с тем, на котором модель обучалась (см. «На что обратить внимание»): проверяем его в ollama show --modelfile category-clf. Инструкция ADAPTER (подключить LoRA поверх базы без слияния) на текущей странице Modelfile не нашлась — если она есть в установленной версии, это вариант, но путь через слияние проверен.

Ответ классификатора — строго из списка. У Ollama format с JSON-схемой (Structured Outputs) ограничивает ответ схемой, в том числе enum:

# illustrative: classifier output constrained to the label set
from typing import Literal
from pydantic import BaseModel
import ollama

class QuestionCategory(BaseModel):
    category: Literal["delivery", "payment", "returns", "warranty",
                      "promo", "orders", "products", "other"]

r = ollama.chat(model="category-clf", messages=[{"role": "user", "content": question}],
                format=QuestionCategory.model_json_schema(), options={"temperature": 0})
label = QuestionCategory.model_validate_json(r.message.content).category

Три строки сравнения из теории на наших провайдерах: базовая маленькая модель в Ollama (та же, что дообучали, например qwen3:4b) с хорошим промптом и few-shot; та же модель после LoRA в Ollama; сильная облачная — deepseek-v4-pro на тех же публичных вопросах (Claude/OpenAI — для сравнения, если есть ключ). Нулевая строка — правила detect_category_rules из 5.1: модель должна их обогнать. Если дообученная локальная модель догоняет DeepSeek на классификации — это и есть аргумент «дешевле и приватно» для собеседования.

Маршрут изучения

1. Открываем Hugging Face LLM Course → глава 11 (fine-tuning): Chat Templates, Supervised Fine-Tuning, LoRA, Evaluation (≈75 мин). Обращаем внимание на chat templates и на то, как SFT-тренер (TRL) принимает датасет.
2. Открываем Hugging Face PEFT → Quicktour, затем гайд по LoRA (developer guides) (≈30 мин). Находим: LoraConfig, get_peft_model, print_trainable_parameters, merge_and_unload, и что такое QLoRA-вариант загрузки.
3. Открываем Unsloth → README: список поддерживаемых моделей и таблицу бесплатных ноутбуков (≈15 мин). Затем Fine-tuning LLMs Guide в их документации → разделы про выбор модели, LoRA vs QLoRA, датасет, гиперпараметры (≈30 мин). Там же есть страница с гайдом по гиперпараметрам LoRA — читаем про r и lora_alpha.
4. (Желательно) Оригинальная статья «LoRA: Low-Rank Adaptation of Large Language Models» (Hu et al., 2021, arXiv) — только аннотация, введение и рисунок 1 (≈20 мин). Этого хватит, чтобы объяснить идею своими словами.
5. Открываем Ollama: Importing a Model и Modelfile Reference → импорт GGUF, FROM, PARAMETER, шаблон (≈15 мин).
6. Открываем DeepSeek: Models & Pricing и смотрим API Reference — убеждаемся сами, что эндпоинта файнтюнинга нет, и прикидываем стоимость генерации 300 синтетических вопросов (≈10 мин).
7. Запускаем ноутбук (см. Практику) (≈60–90 мин вместе с ожиданием обучения).

На что обратить внимание

• Файнтюнинг ради знаний — самая частая ошибка. Новые факты и часто меняющиеся данные (правила возврата, тарифы доставки, остатки) — это RAG или инструменты.
• Нет базовой линии. Без сравнения с «базовая модель + хороший промпт» любое улучшение не доказано.
• Утечка test в train: дубликаты и почти-дубликаты в обеих выборках дают красивые и ложные цифры. Дедуплицируем до разбиения; вопросы из eval/golden.jsonl — только в test.
• Несовпадение chat template между обучением и запуском.
• Слишком много эпох / большой learning rate — модель заучивает примеры.
• Неконсистентная разметка: если в данных одна и та же ситуация размечена по-разному (вопрос про промокод то promo, то payment), модель выучит шум.
• Colab-сессия обрывается — адаптер (он маленький) сохраняем на Google Drive или скачиваем сразу после обучения.
• Сторонний код в ноутбуке — читаем ячейки до запуска.
• «Дообучим DeepSeek» — через его API нельзя; открытые веса флагманов в Colab не влезут. Дообучаем маленькую open-weight модель.
• GGUF без квантизации в Ollama: импорт не квантизует, модель займёт память как FP16.
• Синтетика из реальных данных через облачную модель — утечка; генерируем только из публичных страниц kb/.

Практика

• Открываем бесплатный Colab-ноутбук Unsloth для маленькой instruct-модели (из таблицы в README Unsloth или со страницы ноутбуков в их документации). Основной трек — ноутбук как есть, на его собственном учебном датасете: цель — пройти весь цикл от загрузки модели до адаптера; классификатор «Полки» — опциональное задание ниже. Выбираем runtime с GPU (T4).
• До запуска читаем все ячейки. Находим и выписываем: какая базовая модель, загружается ли она в 4 бита (QLoRA), значения r, lora_alpha, target_modules, learning rate, max_steps/эпохи, какой датасет и как к нему применяется chat template.
• Перед обучением задаём модели 3 вопроса в духе датасета ноутбука и сохраняем ответы (базовая линия).
• Запускаем обучение как есть. Записываем: число обучаемых параметров и их долю (print_trainable_parameters или вывод ноутбука), время обучения, как менялся loss.
• После обучения — те же 3 вопроса. Что изменилось в стиле/формате?
• Сохраняем адаптер, смотрим его размер в МБ и сравниваем с размером базовой модели.
• (Опционально, +2 ч) Свой мини-набор в projects/02-support-kb-rag/finetune/: классификатор вопросов клиентов по разделам базы знаний (delivery, payment, returns, warranty, promo, orders, products, other). 300 вопросов синтетикой DeepSeek (сильная модель-«учитель») по технике главы 6.2 · Синтетические данные для evals из публичных страниц kb/, без архивных; метка — category страницы-источника, вопросы other пишем руками. Записываем стоимость генерации и правила разметки, проверяем выборку вручную; JSONL в формате messages (clf_train.jsonl, clf_test.jsonl), дедупликация, затем 80/20 split; вопросы из eval/golden.jsonl с заполненным category — только в test. Сравниваем на test строки: detect_category_rules, базовая модель + few-shot в Ollama, дообученная в Ollama (с format и enum), deepseek-v4-pro + few-shot. Таблица в finetune/RESULTS.md: accuracy с интервалом Уилсона, ошибки по классам (какие разделы путаются), латентность, стоимость 1000 классификаций.
• (Опционально) Экспорт в GGUF (квантизованный, например q4_k_m) через функцию ноутбука и запуск в Ollama (глава 11.4, гл. 11.4) через Modelfile с FROM ./<file>.gguf; сверяем шаблон в ollama show --modelfile.
• Конспект notes/prompt-vs-rag-vs-finetune.md: таблица «задача → решение → почему», лестница решений, 3 примера из своих проектов курса (что стоит дообучить, а что нет и почему), цена файнтюнинга кроме GPU.
• Репетируем вслух ответ на «Когда вы бы стали файнтюнить модель?» — 60–90 секунд, с примером.

Готово, когда

• Ноутбук запущен до конца, мы знаем, какие гиперпараметры в нём стоят и что они значат, и видели разницу ответов до/после.
• Есть конспект «промпт vs RAG vs файнтюнинг» с примерами из своих проектов.
• Можем за полторы минуты объяснить на собеседовании, когда файнтюнинг оправдан, как работает LoRA и как доказать, что стало лучше.

Тест для самопроверки

Вопрос 1

Ассистент поддержки должен отвечать по базе знаний магазина, правила в которой меняются каждый месяц. Файнтюнинг или RAG? Почему?

RAG. Правила меняются, их нужно обновлять переиндексацией и подтверждать ссылками на kb/; файнтюнинг ненадёжно добавляет факты и устаревает.

Вопрос 2

Какое утверждение о LoRA верно?

• a) обновляет все веса модели, но быстрее
• b) замораживает веса и обучает две маленькие матрицы низкого ранга, произведение которых добавляется к весам
• c) уменьшает модель, удаляя слои
• d) это способ квантизации

b. Исходные веса заморожены, обучается поправка B·A низкого ранга.

Вопрос 3

Сколько параметров обучается в LoRA для матрицы 4096 × 4096 при r = 8?

4096 × 8 + 8 × 4096 = 65 536 параметров (против 16.7 млн у полной матрицы).

Вопрос 4

Чем QLoRA отличается от LoRA?

В QLoRA базовая модель загружена квантизованной в 4 бита (заморожена), а адаптер обучается поверх в 16 битах. Это резко снижает память и позволяет обучать на одной небольшой GPU.

Вопрос 5

Что не так в этом плане? «Хочу, чтобы бот знал все заказы магазина. Выгружу 2000 заказов из shop.db в JSONL как примеры “вопрос → ответ”, загружу в Colab и дообучу модель — тогда не нужны ни SQL, ни tool calling.»

Файнтюнинг не даёт надёжного точного знания данных, а заказы меняются постоянно — модель будет выдумывать правдоподобные суммы и статусы. Плюс персональные данные клиентов уезжают в облако Google. Правильно: инструменты/SQL по снимку базы только на чтение (Проект 1).

Вопрос 6

Что такое chat template и почему он должен совпадать при обучении и инференсе?

Шаблон, превращающий список сообщений с ролями в строку со служебными токенами. Модель обучается на конкретной разметке; при другой разметке на инференсе она видит непривычный формат и ведёт себя непредсказуемо.

Вопрос 7

Какие два признака говорят о переобучении при файнтюнинге?

Train loss падает, а качество на test стоит или падает; модель дословно повторяет обучающие ответы; хуже справляется с перефразированными входами.

Вопрос 8

Какая базовая линия обязательна, чтобы доказать пользу файнтюнинга?

• a) никакая
• b) базовая модель с хорошим промптом и few-shot на той же test-выборке
• c) train loss
• d) мнение пользователей

b. Если базовая модель с хорошим промптом даёт сопоставимое качество, файнтюнинг не нужен.

Вопрос 9

В каком случае дообучение маленькой модели экономически оправдано?

При узкой, стабильной задаче с большим трафиком, где дообученная маленькая модель достигает качества большой (например, определение раздела базы знаний для вопроса клиента), — тогда экономия на каждом запросе и латентности окупает сбор данных и сопровождение; локальная модель к тому же может обрабатывать данные, которые нельзя отправлять в облако.

Вопрос 10

Что делает merge_and_unload() и зачем?

Вливает веса адаптера в базовую модель и возвращает обычную модель без отдельного адаптера: нет дополнительной латентности, можно конвертировать (например, в GGUF). Операция не in-place — результат надо присвоить.

Вопрос 11

Какие расходы файнтюнинга не связаны с GPU?

Сбор, разметка и проверка данных; построение evals; хранение и сервинг своих весов; мониторинг; переобучение при смене базовой модели.

Вопрос 12

Почему важно дедуплицировать данные до разбиения на train/test?

Иначе почти одинаковые примеры попадут и в train, и в test, и модель будет «угадывать» заученное — метрики на test окажутся завышенными.

Вопрос 13

Можно ли дообучить DeepSeek через его API, как это делают через управляемый файнтюнинг OpenAI? Что делать вместо этого?

Нет: в API DeepSeek (на ноябрь 2026) нет эндпоинта файнтюнинга, а открытые веса его флагманов слишком велики для Colab. Дообучают маленькую open-weight модель (LoRA/QLoRA), а DeepSeek используют как «учителя» для синтетики и как сильную строку сравнения.

Вопрос 14

В Ollama импортирован GGUF в FP16 размером 6 ГБ, хотя ожидалось 2 ГБ. Почему так вышло?

Ollama не квантизует GGUF при импорте: какой файл дали, такой и запустился. Квантизуем заранее (llama-quantize или экспорт Unsloth в q4_k_m).

Вопрос 15

Обучающие примеры генерируются на DeepSeek. Какие данные можно отдать модели-«учителю», а какие нет?

Только публичные и выдуманные данные: страницы kb/, синтетика из них, демо-база. Сообщения клиентов, снимок data/shop.db, журнал событий и ключи — нет: правило общее для облачных провайдеров, а серверы DeepSeek ещё и в Китае; плюс проверяем условия использования выходов модели для обучения.

Что дальше

Это последняя глава курса. Цифры стоимости, латентности и сравнения моделей из этой недели стоит сохранить: они ложатся в README проектов, а аргументы «промпт vs RAG vs файнтюнинг» пригодятся, когда понадобится объяснить архитектуру LLM-приложения.