RAG или дообучение: что выбрать для базы знаний

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

Два подхода — два разных механизма

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

Fine-tuning — продолжение обучения на ваших примерах «вход → желаемый выход». В корпоративной практике это почти всегда LoRA/QLoRA поверх открытой модели (Qwen, Llama, Mistral) — полное дообучение весов экономически бессмысленно. Результат: модель начинает писать как ваши примеры — в нужном формате, тоне, с нужной структурой. Факты из примеров она запоминает ненадёжно и воспроизводит с искажениями; это подтверждено и исследованиями, и нашими замерами — на закрытых вопросах по регламентам дообученная 7B-модель без RAG даёт 40–55% точности против 85–90% у RAG на той же базе.

Почему RAG побеждает в 9 из 10 корпоративных задач

• Актуальность. Изменился прайс или регламент — обновили один файл в индексе. Дообученную модель пришлось бы переучивать.
• Прозрачность. Каждый ответ ссылается на конкретный абзац источника. Юристы и служба безопасности это любят.
• Права доступа. Менеджер видит ответы только по своим документам — фильтр на уровне поиска, а не «попросили модель молчать».
• Цена. Индексация 10 000 страниц — часы работы и копейки в токенах. Дообучение — недели, GPU и датасет, который надо ещё собрать.

Где RAG ломается — и это не про модель

Честно: RAG-системы «из туториала» работают плохо, и разочарование в них часто и толкает к дообучению. Три места, где всё ломается на практике.

Чанкинг. Резать документы по 512 токенов с перекрытием — путь к тому, что таблица тарифов разъедется на три фрагмента, а пункт договора потеряет заголовок раздела. Мы режем по структуре документа (заголовки, пункты, строки таблиц), добавляем в каждый чанк «хлебные крошки» — путь от корня документа — и для таблиц храним строку целиком с шапкой. Это даёт больше прироста точности, чем смена модели.

Retrieval. Чисто векторный поиск плохо ловит артикулы, номера приказов, аббревиатуры — всё, что в русском корпоративном языке составляет половину запросов. Гибрид с BM25 и реранкером (bge-reranker или Cohere Rerank, если данные могут уходить наружу) закрывает это. Метрику recall@k мы измеряем отдельно от качества ответа: если нужный фрагмент не попал в топ-10, модель ни при чём.

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

Когда дообучение оправдано

• Жёсткий формат вывода. Заполнение структурированных форм, генерация кода на внутреннем DSL, разметка по сложной схеме из 40 классов. Промпт с примерами даёт 80%, LoRA на 2–3 тысячах примеров — 95%+.
• Доменный язык. Медицинские эпикризы, нефтесервисные отчёты, юридические заключения в стиле конкретной практики. Базовая модель пишет «правильно, но не так, как у нас».
• Экономика инференса. Миллионы запросов в месяц, где дообученная 7–8B модель заменяет 70B или внешний API. Разница в стоимости — порядок; окупается за квартал.
• Латентность. Голосовые агенты, где RAG-цикл в 3–4 секунды неприемлем, а маленькая специализированная модель отвечает за 400 мс.

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

Как принимать решение: протокол

Мы прогоняем его на каждом пилоте, и он занимает неделю, а не квартал.

1. 1Собираем 200–300 реальных вопросов из логов и размечаем эталонные ответы с экспертом заказчика. Половину откладываем.
2. 2Замеряем recall@10 поиска отдельно. Ниже 90% — чиним чанкинг и retrieval, к модели не трогаемся.
3. 3Запускаем RAG на сильной модели (Claude/OpenAI или Qwen 72B в контуре). Точность выше целевой — дообучение не нужно, вопрос закрыт.
4. 4Классифицируем ошибки. Если доминируют «нашли, но сформулировали не так» — это кандидат на LoRA. Если «не нашли» — возвращаемся к шагу 2.
5. 5Считаем экономику: стоимость сбора датасета и обучения против разницы в стоимости инференса за 12 месяцев. Дообучение выигрывает только при большом объёме или жёстких требованиях к формату.

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