RAG или fine-tuning: что выбрать для ИИ-агента

Что такое RAG и fine-tuning: кратко

Оба подхода отвечают на вопрос «как заставить модель знать то, чего нет в открытых данных», но делают это на разных уровнях.

RAG (Retrieval-Augmented Generation) — архитектурный приём: перед генерацией ответа агент ищет релевантные фрагменты в вашей базе знаний (документы, база данных, CRM) и подставляет их в промпт. Модель не меняется — меняется контекст, который она получает. Отсюда ключевое свойство: чтобы обновить знания, достаточно обновить базу, модель переобучать не нужно.

Fine-tuning (дообучение) — дополнительное обучение уже готовой модели на ваших размеченных примерах, чтобы скорректировать её поведение: стиль ответов, структуру, следование регламенту, владение узкой терминологией. Меняется вес модели, а значит — сама модель.

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

Таблица сравнения

Сгруппируем по критериям, которые обычно важны при выборе для ИИ-агента.

Когда достаточно RAG: большинство бизнес-случаев

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

Такое решение подходит, когда у вас:

• собственная база знаний, которая уже существует или быстро собирается из рабочих документов;
• данные, которые регулярно меняются — цены, склад, регламенты, прайсы, новости.

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

Важный плюс RAG — отслеживаемость. Ссылаясь на источник, агент позволяет проверить каждый ответ, а при проблеме — исправить один документ, а не переобучать модель. Для B2B, где репутация и аудит важнее скорости, это решающий аргумент.

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

Когда нужен fine-tuning

Дообучение становится оправданным, когда проблема не в незнании фактов, а в поведении модели:

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

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

Обратная сторона — цена вопроса. Нужен размеченный датасет (сколько примеров? часто от сотен до тысяч), обучение модели или аренда API тоннинга, и главное — повторное обучение при каждом желании что-то поменять. Для большинства компаний, которые хотят агента «под ключ», это не первый шаг, а осознанное дополнение.

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

Можно ли комбинировать

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

Хорошая практика — строить в такой последовательности. Сначала собираете базу знаний и настраиваете RAG (это делает агента полезным). Затем, если поведение не устраивает, — добавляете дообучение на реальных примерах. Так вы не тратите бюджет на тоннинг, не убедившись, что проблема вообще лежит в поведении, а не в данных.

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

Это классическая область разработки RAG-систем: проектирование индекса, выбор ретривера, оценка качества выдачи и — при необходимости — слоя дообучения. Готовое решение строится из обоих кирпичей с учётом ваших данных и KPI.

Типичные ошибки

1. Дообучать «на всякий случай». Начинают с fine-tuning, не проверив, решит ли задачу RAG. Результат — потраченные деньги и застывшие данные, которые всё равно приходится доставлять через RAG.
2. Вшивать факты в веса. Кладут в обучающую выборку цены, остатки, регламенты. Это дорого и устаревает уже к запуску — такие данные должны жить в базе знаний, а не в модели.
3. Игнорировать качество базы для RAG. Плохая сегментация документов и слабый ретривер дают нерелевантные фрагменты — агент «знает», но отвечает мимо. Проблема решается качеством индекса, а не дообучением.
4. Ретрейнить модель ради однострочной правки. Если править надо один абзац инструкции — это задача базы знаний, а не обучения.
5. Оценивать только «как звучит». Без метрик оценки выдачи и ответов нельзя понять, что именно чинит дообучение, а что нет.

Практические рекомендации

Сводим подход к простому алгоритму выбора для ИИ-агента.

1. Зафиксируйте, что именно ломается: не хватает фактов — или модель их не так подаёт. От этого зависит и RAG, и тоннинг.
2. Если есть своя база знаний или данные часто меняются — начинайте с RAG. Большинство бизнес-агентов (поддержка, онбординг, справки, работа с каталогом) закрываются им одним.
3. Если после этого тон или формат нестабильны — добавьте fine-tuning на примерах реальных ответов ваших экспертов.
4. Постройте оценку: доля ответов с помощью источника, точность по эталонной выборке, процент полного отказа в ответе. Сравнивайте «до/после» по одной метрике, а не по ощущению.

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

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

Ещё один ориентир

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

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