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

Раздел

RAG и базы знаний

Сложность

средняя

Обновлено

2026-05-20

Короткий ответ

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

OpenAI в руководстве по model optimization описывает fine-tuning как часть цикла evals, prompt engineering и обучения на примерах: OpenAI model optimization. В supervised fine-tuning отдельно подчеркивается необходимость хороших evals перед вложениями в обучение: OpenAI supervised fine-tuning. Это важнее спора “RAG против fine-tuning”: без тестового набора оба подхода превращаются в веру.

Быстрая матрица

RAG и fine-tuning часто работают вместе. RAG приносит свежие источники, fine-tuning улучшает поведение модели на повторяемой задаче. Но если вы еще не очистили документы и не собрали вопросы, fine-tuning рано.

Как думать про RAG

RAG достает релевантный контекст во время запроса и просит модель ответить по найденным фрагментам. LangChain описывает retrieval как способ дать LLM внешний контекст, потому что контекстное окно конечно, а training data статична: LangChain retrieval. LlamaIndex описывает RAG как процесс загрузки данных, индексации, хранения, querying и evaluation: LlamaIndex RAG.

Для бизнеса это означает: если источник должен быть видим, датирован и проверяем, RAG ближе к задаче.

question
  -> access filter
  -> retrieve current sources
  -> answer with citations
  -> refuse if no source
  -> log quality signal

RAG особенно полезен для поиска по документам, RAG системы и поддержки, где база знаний меняется каждую неделю.

Как думать про fine-tuning

Fine-tuning меняет поведение модели на основе примеров. Он не является надежным способом “загрузить знания компании” так, чтобы потом получать актуальные ответы без источников. Он лучше подходит для задач, где есть много одинаковых входов и понятный ожидаемый выход.

Примеры:

• классифицировать обращение по внутренней таксономии;
• приводить ответ к строгому JSON;
• выбирать тип эскалации;
• исправлять устойчивую ошибку формата;
• писать в допустимом тоне поддержки;
• извлекать поля по размеченным примерам.

Минимальный учебный пример для классификации:

{"messages":[{"role":"user","content":"Клиент просит вернуть деньги за двойное списание"},{"role":"assistant","content":"{\"type\":\"billing_refund\",\"risk\":\"high\",\"handoff\":true}"}]}
{"messages":[{"role":"user","content":"Не могу найти инструкцию по API-ключу"},{"role":"assistant","content":"{\"type\":\"knowledge_base\",\"risk\":\"low\",\"handoff\":false}"}]}

В продакшене такой подход требует holdout-набора, сравнения с baseline и проверки ошибок. Если fine-tuned модель стала красивее отвечать, но чаще пропускать опасные случаи, это ухудшение.

FAQ и база знаний

Для FAQ почти всегда начинайте с RAG. Пользователь спрашивает про текущие правила, тарифы, лимиты, инструкции или статусы. Эти факты меняются, поэтому ответ должен ссылаться на статью и дату.

Fine-tuning может пригодиться позже: например, чтобы модель отвечала в коротком формате, всегда начинала с прямого ответа и не спорила с клиентом. Но факты все равно должны приходить из базы знаний.

Рабочая граница: RAG отвечает на вопрос “что сейчас написано в источниках”, fine-tuning отвечает на вопрос “как модель должна стабильно вести себя на этом классе задач”.

Договоры и процедуры

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

Лучший старт:

1. Ограничить корпус.
2. Добавить metadata: тип, дата, владелец, статус.
3. Настроить retrieval по разрешенным документам.
4. Требовать цитату или отказ.
5. Отправлять спорные случаи юристу или владельцу процесса.

Fine-tuning можно использовать для классификации риска или формата резюме, но не для хранения содержания договоров.

Поддержка

В поддержке RAG отвечает по базе знаний, а fine-tuning может помочь с routing и тоном. Не смешивайте метрики. Если бот отвечает по плохой статье, fine-tuning не исправит факт. Если база знаний хорошая, но модель пишет длинно и неструктурно, fine-tuning или few-shot может помочь.

Контрольная таблица:

Чеклист

• Есть eval-набор до выбора подхода.
• Понятно, меняются ли факты в ответе.
• Для свежих знаний выбран RAG.
• Для повторяемого поведения рассматривается fine-tuning.
• Источники показываются пользователю или оператору.
• Права применяются до retrieval.
• Fine-tuning не используется как склад актуальных правил.
• Есть holdout-набор для проверки переобучения.
• Измеряются refusal quality, source hit rate и формат ответа.
• Решение можно откатить к baseline.

FAQ

Можно ли заменить RAG fine-tuning?

Для актуальных документов - нет. Fine-tuning не дает надежной ссылки на текущий источник и не решает права доступа.

Когда fine-tuning окупается?

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

Что дешевле?

Зависит от объема, latency и качества. RAG добавляет retrieval и хранение индекса, fine-tuning добавляет подготовку данных, обучение и поддержку версии модели.

Что читать дальше?

Начните с RAG системы, затем посмотрите оценку качества RAG и стоимость LLM API.