RAG подключает базу знаний компании к готовой модели без изменения самой модели и обходится дешевле. Дообучение меняет веса модели под стиль и формат задач компании и оправдано только при устойчиво большом потоке однотипных запросов.
Быстрый вывод
Для большинства задач малого и среднего бизнеса хватает RAG: он дешевле, быстрее в разработке и мгновенно видит обновлённые документы. Дообучение — редкое и дорогое решение под узкую устойчивую задачу.
Термины путают часто: RAG — это поиск нужного фрагмента в базе документов перед ответом модели, дообучение — это изменение весов самой модели на примерах компании. Разница ощутима именно в эксплуатации, тогда как демонстрация возможностей её слабо показывает.
Путаница чаще всего идёт от маркетинга: разработчики моделей рекламируют дообучение как способ научить модель компании, хотя большинству задач бизнеса нужны актуальные факты вместо нового навыка модели — а это ровно то, что делает RAG проще и дешевле.
Представьте интернет-магазин, который подключает RAG к каталогу товаров и отвечает клиентам точными характеристиками и остатками на складе вместо общих фраз про ассортимент — обновление цены или остатка в карточке товара сразу видно модели без нового цикла обучения.
Сравнение по критериям
| Критерий | RAG | Дообучение |
|---|---|---|
| Данные и 152-ФЗ | База документов хранится отдельно, легче обезличить и контролировать | Персональные данные могут закрепиться в весах модели — сложнее точечно удалить |
| Цена запуска | От разработки базы знаний и поиска, обычно дешевле на старте | Подготовка датасета и обучение — дороже на старте в разы |
| Обновление знаний | Достаточно обновить документы в базе — модель сразу видит новое | Требует повторного обучения при каждом заметном обновлении данных |
| Качество на узкой задаче | Хорошо на фактах и цитировании источников | Сильнее на устойчивом стиле и формате ответа компании |
| Лимиты | Ограничена объёмом контекста модели за один запрос | Ограничена объёмом и качеством обучающего датасета |
Порог, где дообучение начинает окупаться, — устойчиво большой поток однотипных запросов с чётким форматом ответа, который редко меняется месяцами; для разовых и разнородных задач RAG почти всегда обходится дешевле.
Есть и промежуточный вариант — так называемое лёгкое дообучение или адаптер поверх базовой модели: он дешевле полного дообучения и подходит, если нужно закрепить узкий стиль или формат ответа, сохранив при этом гибкость обновления фактов через отдельную базу знаний.
Ответственность за качество тоже распределяется по-разному: у RAG результат сильно зависит от качества самой базы документов и от того, как она разбита на части для поиска. У дообучения результат зависит от качества и объёма обучающих примеров, которые нужно заранее подготовить и разметить вручную.
Когда что берут
- База знаний компании часто меняется — прайсы, регламенты, новости — берите RAG: обновление документа мгновенно доступно модели.
- Нужен устойчивый фирменный стиль ответа на тысячах однотипных обращений — дообучение окупается именно на таком объёме.
- Бюджет и сроки ограничены, а задача разовая — RAG почти всегда быстрее и дешевле в разработке.
- Данные компании чувствительные и часть их придётся удалить по запросу клиента — базой RAG проще управлять, чем весами дообученной модели.
- Команда ещё сомневается в самом формате ответа модели и хочет быстро тестировать разные варианты подачи — на RAG изменить промпт и логику поиска намного быстрее, чем перезапускать цикл дообучения.
Практическое правило простое: начинать почти всегда стоит с RAG, а к дообучению возвращаться только тогда, когда накопленная статистика однотипных запросов ясно показывает устойчивый объём и стабильный формат ответа. Готовый контур поиска по базе документов компании под ключ — на странице нейросетей для документов.
Типичная ошибка
Частая картина на пилотах — компания заказывает дообучение модели на своих документах, рассчитывая, что модель запомнит все факты навсегда. Через месяц часть документов устаревает, а модель продолжает уверенно отвечать по старым данным, потому что повторное обучение остаётся дорогим и редким шагом, который откладывают месяцами.
RAG в этой ситуации решил бы задачу проще: команда обновила бы документ в базе знаний, и модель сразу подхватила бы актуальную версию без нового цикла обучения и связанных с ним расходов.
Похожая история случается и в обратную сторону: команда собирает RAG-базу из десятков разнородных документов без единой структуры, и модель путает похожие по смыслу, но разные по сути фрагменты из разных источников. Здесь помогает аккуратная разметка и разбиение документов на части перед загрузкой в базу вместо смены подхода на дообучение.
Стоимость такой ошибки редко ограничивается только повторной оплатой обучения: пока модель отвечает по устаревшим данным, клиенты получают неверную информацию, и часть из них замечает это раньше, чем сама компания успевает обновить модель.
Разобрать, что подойдёт вашей базе знаний?
Как решить для себя
- Оценить, как часто меняются данные, на которых должна отвечать модель — ежедневно или раз в квартал.
- Посчитать объём однотипных запросов в месяц — дообучение окупается только на устойчиво большом потоке.
- Проверить, придётся ли точечно удалять чьи-то данные из базы знаний по запросу — это проще на RAG.
- Начать с RAG как более дешёвого и быстрого варианта, а дообучение добавить позже, если сохранится такая потребность. Полезно также заранее прописать критерий возврата к RAG на случай, если расходы на дообученную модель окажутся выше ожидаемой экономии в первые несколько месяцев.
- Спросить у подрядчика, какой формат документов на входе даёт лучший результат в RAG-базе — таблицы, инструкции и договоры часто требуют разного способа разбиения перед загрузкой.
Оба подхода стоит сначала проверить на небольшом пилоте — десяток реальных вопросов клиентов и сравнение качества ответа с ручной проверкой сотрудника — прежде чем вкладываться в полноценную разработку любого из двух вариантов. Стоимость этой проверки обычно ниже, чем кажется: достаточно прогнать десяток типовых запросов через оба варианта на скромном бюджете, чтобы увидеть разницу в качестве и в деньгах. Итоговое решение редко бывает окончательным — база знаний и объём запросов компании меняются, и его стоит пересматривать раз в год. Договор с подрядчиком стоит фиксировать явно: какой из двух подходов выбран для старта и при каком объёме запросов пересматривается переход на другой формат.
Из чего складывается цена RAG-системы под конкретную задачу — в статье про стоимость разработки RAG-системы. Смета на дообучение модели под компанию — в материале про стоимость дообучения российской нейросети. Разбор конкретной ситуации — на консультации в рамках ИИ-консалтинга.