Fine-tune, RAG, or prompting: the decision tree

У инженера три рычага адаптации LLM под задачу, и они меняют разные вещи. Промптинг меняет только содержимое контекстного окна: инструкции, примеры few-shot, декомпозицию задачи. Это самый дешёвый рычаг с самым быстрым циклом итерации — минуты от гипотезы до проверки, откат мгновенный, деплой не нужен. RAG добавляет в контекст знания, найденные во внешнем хранилище в момент запроса: модель отвечает по свежим документам, источники можно цитировать, а обновление знаний — это обновление индекса, а не модели. Fine-tuning меняет сами веса: модель усваивает форму, стиль, жаргон и навык, которые дальше не занимают ни одного токена контекста. Цикл итерации самый медленный — часы и дни на сбор данных, обучение и оценку.

Из этого следует порядок эскалации: сначала выжимаем максимум из промпта, затем закрываем пробелы знаний через RAG и только потом, если поведение всё ещё не то, берёмся за веса. Порядок важен не из осторожности, а из экономики: каждый следующий рычаг на порядок дороже в итерации. Команда, которая начинает с fine-tuning, потому что «это серьёзный ML», обычно тратит месяц на то, что решалось абзацем системного промпта.

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

Самая частая ошибка — пытаться «зашить знания» в веса: скормить модели базу статей о продукте и ждать, что она станет справочником. Так это не работает. Факты при SFT размазываются по весам тонким слоем: модель перенимает уверенный тон эксперта по домену, но продолжает путать цифры и выдумывать детали — теперь ещё убедительнее. Каждое обновление каталога или политики требует пересборки датасета и переобучения. Разграничить доступ невозможно: знание, попавшее в веса, доступно любому пользователю модели. Для фактологии ответ почти всегда RAG.

Что fine-tuning решает отлично: жёсткий формат выхода (валидный JSON по схеме, DSL, разметка), стиль и тон бренда, доменный жаргон и способ рассуждения, дисциплину вызова инструментов по сложному протоколу, устойчивость к вариациям входа. Отдельный класс — дистилляция промпта: длинный системный промпт с двадцатью правилами и десятью примерами «вшивается» в веса, и модель ведёт себя так же без этих трёх тысяч токенов на каждый запрос. И наконец, специализация малой модели: 7–8B, натюненная на узкую задачу, регулярно догоняет фронтирную API-модель на этой задаче при цене в разы ниже.

Лакмус: если провал звучит как «модель не знает X» — это знания, RAG. Если «модель знает, но отвечает не так» — это поведение, кандидат на fine-tuning.

Дерево решений проходится сверху вниз, и у каждого шага есть выход с измерением:

1. Выжмите промпт. Чёткие инструкции, 3–5 few-shot примеров, декомпозиция на шаги. Соберите eval-набор из 20–50 реальных кейсов и измерьте провалы. Без eval-набора двигаться дальше нельзя: вы не отличите улучшение от шума.
2. Классифицируйте провалы. Прочитайте неудачные ответы и разделите: «не хватает знаний» (модель не знает фактов, устаревшие данные, приватные документы) против «не то поведение» (ломает формат, не тот тон, игнорирует правила).
3. Пробелы знаний → RAG. Стройте ретривер и измеряйте на том же eval-наборе. Большинство случаев «модель тупит» лечится здесь.
4. Пробелы поведения при лучшем промпте → fine-tuning. Если формат ломается на 15% запросов, несмотря на идеальные инструкции и примеры, — это кандидат на SFT.
5. Экономика и латентность. Даже если промпт работает: длинный контекст на большом трафике, требования к скорости или приватности — самостоятельные причины дистиллировать поведение в малую модель.

Комбинации легальны и типичны: RAG для фактов плюс лёгкий тюнинг для формата цитирования. Главный красный флаг — желание начать с шага 4, минуя первые три: fine-tuning без eval-набора и анализа провалов — это дорогая лотерея.

Посчитаем промпт-налог. Системный промпт на 3000 токенов при миллионе запросов в месяц — это 3 миллиарда входных токенов, которые вы оплачиваете каждый месяц только за то, что модель «помнит правила». При цене условных 2,5 доллара за миллион входных токенов это 7500 долларов в месяц — навсегда. Кэширование промпта снижает счёт, но не обнуляет его. Тюненая модель, усвоившая те же правила весами, обходится коротким промптом на 200 токенов: налог падает в пятнадцать раз.

Теперь стоимость тюнинга. Сам прогон QLoRA для 7–8B — несколько GPU-часов: 5–30 долларов аренды. Но прогон — вершина айсберга. Реальная цена: дни работы на курирование датасета, построение eval-инфраструктуры, циклы «обучил — оценил — поправил данные», а затем поддержка: ретрейны при смене базовой модели и дрейфе задачи. Честная оценка первого проекта — одна-две недели инженерного времени.

Отсюда правило безубыточности: fine-tuning окупается на стабильной задаче с большим трафиком, где промпт-налог или цена фронтирной модели заметны в месячном счёте, и не окупается на задаче, которая меняется каждую неделю, или трафике в сто запросов в день. Отдельно учитывайте нестоимостные факторы: латентность (короткий промпт и малая модель быстрее), приватность (свои веса на своём железе) и независимость от изменений чужого API.