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

Два самых частых вопроса от клиентов, которые хотят корпоративного AI-ассистента: «А можно ли обучить модель на наших данных?» и «А что такое RAG?». За этими вопросами скрывается ключевой архитектурный выбор, от которого зависит бюджет, скорость запуска и итоговое качество.

Коротко о разнице

RAG (Retrieval-Augmented Generation) — это архитектура, при которой LLM получает в промпт релевантные куски ваших документов, найденные поиском по векторной базе. Модель не «знает» ваши данные — она каждый раз их подсматривает.

Fine-tuning — это дообучение модели на вашем датасете. Данные «впитываются» в веса модели и становятся частью её «знаний». Самый популярный метод — LoRA, не меняющий исходные веса, а добавляющий небольшие адаптеры.

Когда хватит RAG

RAG закрывает 80% задач корпоративных ассистентов. Выбирайте его, если:

• Документы регулярно обновляются: регламенты, прайсы, техподдержка. RAG переиндексирует базу за минуты, fine-tuning пришлось бы запускать заново.
• Нужна трассируемость ответов: ассистент показывает, откуда взял информацию. Для комплаенса и доверия это критично.
• Объём данных: гигабайты—терабайты. Fine-tuning на таких объёмах неподъёмен, RAG масштабируется индексом.
• Нужен короткий time-to-market: 3–4 недели до MVP против 8–12 недель с fine-tuning.

Практические примеры:

• Внутренняя база знаний (регламенты HR, IT-гайды, FAQ продукта).
• Ассистент поддержки на основе истории тикетов и продуктовой документации.
• Юридический поиск по корпоративным договорам.

Когда без fine-tuning не обойтись

Fine-tuning оправдан, когда RAG упирается в потолок. Три типовых сценария:

1. Специфический стиль общения. Нужно, чтобы ассистент отвечал в тоне вашего бренда — не просто «по регламенту», а как сотрудник с опытом. RAG подсказывает факты, но не учит стилистике.

2. Узкоспециализированный жаргон или формат вывода. Например: генерация структурированных рецептов в медицине, описаний товаров по строгому шаблону, автоматические ответы с обязательным формальным стилем.

3. Улучшение reasoning на конкретном домене. Если базовая модель часто путает логику вашего процесса (например, сложные правила расчёта тарифов или страховых случаев), LoRA на 1000–5000 парах «вопрос-эталонный ответ» серьёзно повышает качество.

Экономика

Сравним порядок стоимости на типовой задаче корпоративного ассистента.

RAG

• Разработка MVP: 380–720 тыс. ₽ (зависит от числа каналов и интеграций).
• Инфраструктура: от 15 тыс. ₽/мес (векторная БД + небольшой LLM-хостинг).
• Обновление данных: автоматическое, без повторных затрат.

Fine-tuning (LoRA)

• Разработка MVP: 700–1500 тыс. ₽ (подготовка датасета — главная статья расходов).
• Тренировка: 150–400 тыс. ₽ разово (3–7 дней GPU-времени на H100).
• Обновление: повторная тренировка при смене корпуса — 100–200 тыс. ₽.
• Инфраструктура: сопоставимо с RAG.

Сухой вывод: fine-tuning добавляет к проекту +40–70% бюджета и 4–6 недель срока. Оправданно это примерно в 20% сценариев.

Главный миф

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

1. Датасет для fine-tuning — это не просто документы. Это пары «вопрос — идеальный ответ», сотни или тысячи. Собрать такой датасет — отдельный проект длительностью недели.
2. Знания устаревают. Любое обновление политики или прайса превращается в повод для повторной тренировки. RAG решает это индексацией файла.
3. Fine-tuning не уменьшает галлюцинации. Наоборот: модель может уверенно выдавать «выученные» устаревшие данные. RAG с грамотными гардрейлами честно скажет «в документах нет».

Гибридный подход

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

Пример из практики: финтех-клиент просил ассистента, который отвечает в формальном стиле банка, но работает с ежедневно обновляющимся справочником тарифов. Сделали LoRA на 2000 типовых диалогов + RAG по тарифам. Точность ответов выросла с 71% (чистый RAG) до 89%.

Как выбрать — короткий алгоритм

1. Начните с RAG. Поднимите MVP за 3–4 недели, замерьте качество.
2. Если качество устраивает (обычно точность 80%+) — остановитесь. Не надо платить за fine-tuning ради ещё +5%.
3. Если упираетесь в стиль/формат/reasoning — добавьте LoRA поверх. Базу знаний оставляете в RAG.
4. Если качество плохое из-за проблем с данными — не спасёт ни RAG, ни fine-tuning. Сначала чиним корпус документов.

Итог

• RAG — ваш дефолт. 80% проектов закрываются им.
• Fine-tuning — инструмент точечной доводки, не замена RAG. Считайте экономику и честно отвечайте: «нам реально это нужно или мы повторяем моду?».
• Гибрид — топовая практика для сложных ассистентов, но это уже зрелый проект, а не первый шаг.

Если думаете, какой подход подойдёт под вашу задачу — на 30-минутном звонке разберём конкретный кейс и дадим честную рекомендацию. Часто ответ звучит как «сначала сделайте X, а fine-tuning — через полгода, если упрётесь».