Fine-tuning против RAG: что решает вашу задачу дешевле

MAATRIX

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

Сколько реально стоит внедрить RAG

Если у вас первый сценарий — считаем RAG. Минимальный стек: эмбеддинг-модель, векторная база (Qdrant, Chroma, pgvector) и сама LLM для генерации ответа. Мы подробно разбирали сборку такого пайплайна в статье «RAG-пайплайн с нуля: практический пример» — здесь сфокусируемся именно на статьях расходов.

Основные затраты на старте:

• Инфраструктура. Векторная база и эмбеддинги в большинстве случаев спокойно работают на CPU-сервере с достаточным объёмом RAM — GPU для самого RAG обязателен только если вы гоняете локальную LLM с низкой задержкой, а не облачный API.
• Подготовка данных. Документы нужно почистить, разбить на чанки разумного размера и прогнать через эмбеддинг-модель один раз при индексации. Это разовая работа по объёму базы, не по числу запросов.
• Инженерное время на интеграцию. Настройка поиска, подбор top-k, тестирование релевантности выдачи — обычно дни, а не недели, особенно если использовать готовые связки вроде AnythingLLM или Flowise вместо ручной сборки.
• Постоянные расходы в проде. Каждый запрос пользователя — это один вызов эмбеддинга (для превращения вопроса в вектор), один поиск по векторной базе и один более длинный промпт для LLM (с добавленным контекстом). Длинный промпт стоит дороже короткого — это надо учитывать в расчёте на масштаб.

Псевдокод логики запроса, чтобы было понятно, откуда берутся расходы за каждый вызов:

query_vector = embed(user_question)          # + стоимость эмбеддинга
chunks = vector_db.search(query_vector, k=5)  # + время поиска
context = "\n\n".join(c.text for c in chunks)

prompt = f"Контекст:\n{context}\n\nВопрос: {user_question}"
answer = llm.generate(prompt)                 # длинный промпт = дороже токены

Практический ориентир (именно ориентир, не измеренное значение — точные цифры зависят от объёма базы, модели эмбеддингов и провайдера LLM): для базы в несколько тысяч документов минимальный RAG-стек на арендованном VPS обычно окупает себя быстрее, чем цикл fine-tuning, просто потому что нет этапа обучения на GPU — самой дорогой статьи расходов у альтернативы.

Сколько реально стоит fine-tuning

Если у вас второй сценарий — считаем fine-tuning. Технически чаще всего используется не полное дообучение всех весов модели (это дорого по GPU-памяти и времени), а LoRA (Low-Rank Adaptation) — обучение небольших адаптеров поверх замороженной базовой модели. Мы разбирали процесс подробно в статье «LoRA fine-tuning своей модели на VPS».

Статьи расходов здесь принципиально другие:

• Датасет. Нужны примеры желаемого поведения — сотни, иногда тысячи размеченных пар «вход → правильный выход» в нужном формате или стиле. Разметка (или сбор реальных примеров из истории переписки/документов) — это человеческое время, и часто самая дорогая часть всего процесса, а не сам запуск обучения.
• GPU на этапе обучения. Аренда GPU-инстанса на часы или дни цикла обучения — обычно не гигантские деньги на один прогон LoRA, но это отдельная статья расходов, которой у RAG просто нет.
• Итерации. Первый прогон почти никогда не даёт нужный результат с первого раза — нужно менять гиперпараметры (rank, alpha, целевые слои), добавлять примеры, перезапускать обучение. Считайте не один цикл, а три-пять на пути к рабочей версии.
• Регрессионное тестирование. После дообучения модель нужно заново проверить на прежних задачах — fine-tuning иногда ухудшает то, что модель умела раньше (catastrophic forgetting), и это тестирование — тоже время, которое стоит денег.

Типичный запуск через популярный фреймворк:

python -m axolotl.cli.train config.yml

где config.yml описывает базовую модель, датасет и параметры LoRA. Если своего GPU под обучение нет, разумно смотреть на почасовую аренду — мы разбирали такой сервер отдельно: GPU-сервер в Великобритании для обучения моделей. Плюс такой схемы: платите только за часы реального обучения, а не держите GPU постоянно — обученные LoRA-адаптеры весят десятки-сотни мегабайт и подключаются к базовой модели уже на обычном инференсе без GPU-мощностей уровня обучения.

Где прячется настоящая разница в цене: обновление

Стоимость первого внедрения — это только половина расчёта. Вторая половина, которую часто забывают посчитать заранее — стоимость поддержки решения в актуальном состоянии, а она у RAG и fine-tuning отличается на порядок.

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

Обновление факта, «зашитого» в модель через fine-tuning, физически невозможно точечно — вы не можете «поправить одну строчку» в весах. Единственный путь — собрать обновлённый датасет и повторить цикл обучения целиком: снова GPU-часы, снова прогон, снова регрессионное тестирование. Если ваши данные меняются раз в квартал — это терпимо. Если раз в неделю (цены, статусы заказов, новости компании) — вы попадаете в бесконечный и дорогой цикл переобучения, который проигрывает RAG по стоимости почти при любом объёме данных.

Отсюда практическое правило: чем чаще меняются данные, тем сильнее экономика склоняется к RAG, и разница не линейная, а экспоненциальная — при еженедельных обновлениях fine-tuning-цикл на дистанции года обходится в разы дороже, чем разовое внедрение RAG плюс минутные обновления индекса.

Когда дешевле RAG, а когда — fine-tuning

Свести это в таблицу, ориентируясь на реальную природу задачи, а не на моду:

Отдельно стоит сказать про объём инференса: если у вас счёт на миллионы запросов в месяц, разница в длине промпта (короткий у fine-tuned модели против длинного с подмешанным RAG-контекстом) начинает давать заметную экономию на токенах именно в проде — это единственный сценарий, где fine-tuning может оказаться дешевле RAG даже при задаче, которая формально про «знания», а не про поведение. Но на малом и среднем объёме запросов эта экономия не отбивает стоимость цикла обучения и переобучения.

Гибридный подход: не «или», а «и»

Важно: это не взаимоисключающий выбор. Часто самое дешёвое на дистанции решение — комбинация обоих подходов, а не поиск единственного правильного:

1. Fine-tuning один раз закрепляет нужный формат, стиль и узкий навык модели — она стабильно отвечает в вашей терминологии, в нужной структуре, с нужным уровнем детализации. Это разовые инвестиции в поведение.
2. RAG поверх этой уже дообученной модели подтягивает актуальные факты из базы знаний в момент ответа — обновляется независимо, без переобучения.

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

Для такой схемы удобно физически разделить компоненты на сервере: инференс дообученной модели отдельно (vLLM или Ollama), векторная база для RAG-части отдельно, и — если моделей несколько — единый шлюз к ним через LiteLLM. Так каждый слой обновляется независимо, и вы не пересобираете всю систему ради одного изменённого документа или одной новой LoRA-версии.

Частые вопросы