Fine-tuning против RAG: что выбрать под вашу задачу

Короткий ответ: RAG выигрывает, когда база знаний часто меняется и нужна прослеживаемость источников; fine-tuning — когда нужен стиль, формат и узкая доменная логика модели. Часто правильный ответ — комбинация. Разбираем критерии выбора.

Ложная дилемма

Вопрос «что лучше, fine-tuning или RAG» звучит часто и почти всегда некорректно. Это инструменты для разных проблем. Fine-tuning учит модель вести себя иначе: стиль ответов, формат вывода, специфика отрасли. RAG даёт модели доступ к знаниям: документы, регламенты, актуальные цены.

Когда нужен RAG

Ответ должен опираться на ваши документы, которые меняются чаще, чем раз в квартал. Регламенты, прайсы, инструкции, договоры. Знание нужно добавлять без переобучения, за минуты. Требуется ссылка на источник каждого факта — для юротдела и комплаенса это обязательное условие. Стоимость старта в разы ниже, чем у fine-tuning.

Когда оправдан fine-tuning

Модель должна говорить языком вашей предметки так, как этого не добиться промптом: узкая терминология, устойчивые форматы ответов, специфические задачи классификации. Объём статики велик, а изменения редки. Есть обучающая выборка от тысячи примеров и бюджет на её разметку.

Комбинация, которая работает чаще всего

Enterprise-сценарий обычно выглядит так: лёгкий fine-tune небольшой открытой модели под стиль и формат плюс RAG поверх базы знаний. Модель отвечает в нужном формате, факты подтягиваются из документов со ссылками. Так мы делаем в проектах, где требования к точности и консистентности максимальны.

RAG отвечает на вопрос «что говорит наша база знаний». Fine-tuning отвечает на вопрос «как должна звучать модель». Большинству бизнеса нужен первый ответ, а второй он хочет просто потому, что услышал слово на конференции.

Цена ошибки

Fine-tuning ради знаний — самая дорогая ошибка: модель устаревает вместе с датой обучения, а каждое обновление прайса превращается в новый цикл обучения. Если ваш подрядчик предлагает дообучение там, где хватит базы знаний, задайте один вопрос: как будет обновляться информация завтра?

Деньги и сроки: трезвое сравнение

• RAG: старт. Готовые компоненты, MVP за 4–6 недель. Основные затраты — интеграция с вашими источниками данных и пайплайн индексации. Обновление знаний — загрузка нового документа: минуты и рубли, без разработчиков.
• Fine-tuning: старт. Сбор и разметка выборки от тысячи примеров — недели работы ваших экспертов, которые в смете проекта обычно не фигурируют. Затем обучение, оценка, итерации. Каждое изменение требований — снова полный цикл.
• OPEX. RAG платит за поиск и инференс на каждом запросе. Дообученная модель дешевле на инференсе и может быть компактнее — это аргумент при миллионах запросов в сутки, а не для внутреннего ассистента.
• Риск устаревания. База знаний живёт столько, сколько живут ваши документы. Дообученная модель начинает устаревать в момент завершения обучения.

Итог по цифрам: для типовой корпоративной задачи — база знаний плюс ассистент поддержки — RAG дешевле на порядок в первый год и единственный вариант, который вообще поддерживает актуальность данных ежедневно. До 80% типовых тикетов закрываются RAG-системой без человека; дообучение эту цифру не улучшает — оно меняет стиль ответов, а не факты.

Чеклист решения: четыре вопроса

1. Что меняется чаще — знания или стиль? Прайсы, регламенты, цены обновляются еженедельно? Тогда RAG без вариантов: дообучать модель под каждый прайс экономически бессмысленно.
2. Нужна ли ссылка на источник? Юротдел, комплаенс, аудит клиентов — только RAG. У дообученной модели нет источников, есть веса, и проверить факт внутри них невозможно.
3. Есть ли размеченная выборка? Тысяча примеров с эталонными ответами — минимум для осмысленного fine-tune. Нет выборки и бюджета на её разметку — разговор закрыт до её появления.
4. Готовы ли платить за каждое изменение поведения? Правка тона или формата = новый цикл обучения и повторная валидация. Если правки ожидаются чаще раза в квартал — промпты и RAG.

Три рабочие конфигурации из практики

1. Поддержка L1: чистый RAG. База знаний из регламентов и FAQ поверх корпоративных документов. Бот закрывает до 80% типовых тикетов без эскалации, окупаемость — около двух месяцев за счёт экономии 70% рутинных операций. Дообучение не используется вовсе.
2. Ассистент юриста и комплаенса: RAG со строгими источниками. Каждый факт сопровождается ссылкой на пункт договора или регламента. Fine-tuning исключён политикой: модель обязана цитировать документы, а не «вспоминать» веса. Проверяемость источника здесь ценнее беглости формулировок.
3. Классификатор обращений: лёгкий fine-tune. Тысяча размеченных обращений, компактная модель, стабильный набор категорий. Знания не нужны — нужна точность классификации при высокой частоте запросов. Это единственный сценарий из трёх, где дообучение оправдано полностью.

Общий паттерн: чем больше в задаче фактов и источников, тем ближе решение к RAG. Чем больше устойчивых форматов и классификаций — тем оправданнее fine-tune. Смешанные задачи решаются комбинацией, но начинать всё равно стоит с базы знаний: она даст метрики, относительно которых решение о дообучении принимается по данным, а не по впечатлению от демо подрядчика.

TCO на горизонте трёх лет: где ломается экономика fine-tuning

Сравнение подходов честно только на длинном горизонте:

• Старт. RAG ниже: нет затрат на сбор датасета и разметку — самой недооценённой статьи бюджета.
• Каждое обновление знаний. RAG: загрузка документа, минуты силами контент-менеджера. Fine-tune: новый цикл разметки, обучения и валидации, недели и ML-бюджет.
• Инференс. Дообученная компактная модель дешевле на запрос — единственная строка, где fine-tuning стабильно выигрывает, и то при миллионах запросов в сутки.
• Команда. RAG обслуживают разработчики приложения; fine-tuning требует ML-инженера. Разница в ставке — постоянная статья расходов, а не разовый платёж.

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

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

Финальная рекомендация: принимайте решение по чеклисту письменно, до старта проекта. Если три из четырёх ответов указывают на RAG, а подрядчик всё равно предлагает дообучение — запросите расчёт TCO на три года по списку выше. Обычно этого достаточно, чтобы предложение вернулось в инженерное русло.

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

Сколько стоит дообучение по сравнению с RAG?

Разметка тысячи примеров силами экспертов — это недели их времени, которые редко вычитываются из бюджета проекта. Добавьте инфраструктуру обучения, оценку качества и повторение цикла на каждую итерацию. RAG-проект в нашей практике окупается примерно за два месяца за счёт экономии 70% рутинных операций — и это без затрат на датасеты и разметку.

Как быстро запускается RAG-система?

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

Когда комбинация избыточна?

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