RAG или fine-tuning: что выбрать для корпоративных знаний
Выберите актуальные evidence, повторяемое поведение или их ограниченное сочетание
Freshness, citations, access boundaries, dataset operations и evaluation
Авторская RFT-5 matrix с тремя сценариями выбора для корпоративных знаний
RAG vs fine tuning, RAG или fine-tuning, RAG система, AI база знаний, fine-tuning модели, corporate knowledge AI и RFT-5
$ decide knowledge --contract RFT-5
> inspect: freshness / evidence / access
> compare: retrieval / behaviour / correction-loop
> test: baseline / representative-cases / no-answer
> route: RAG / fine-tune-test / hybrid / baselineRAG или fine-tuning: начните с того, как меняются знания
RAG и fine-tuning решают разные задачи, поэтому вопрос «что лучше?» поставлен слишком широко. RAG находит выбранные актуальные материалы во время ответа. Fine-tuning адаптирует поведение модели по подготовленным примерам. В корпоративной системе со временем могут понадобиться оба подхода, но первое решение должно отделять изменяемые evidence от повторяемого поведения.
Широкий разговор об услуге находится на странице RAG-систем. Здесь разобран более узкий вопрос: для какой конкретной задачи корпоративных знаний подходит retrieval, fine-tuning, их сочетание или более простой инструмент.
Что именно меняет каждый подход
RAG меняет контекст ответа. Приложение находит разрешённые фрагменты, версии и metadata источников, затем передаёт их модели вместе с вопросом. Это обычно уместно, когда policies, каталоги, runbooks или факты дела меняются, а пользователю важно увидеть, на чём основан ответ.
Fine-tuning меняет изученное поведение модели. Подготовленный dataset обучает повторяемому формату, тону, границе классификации или преобразованию. Он не делает новую policy автоматически актуальной, не открывает приватный документ и не создаёт проверяемую citation для конкретного ответа.
| Критерий | RAG | Fine-tuning |
|---|---|---|
| Актуальные знания | Использует выбранные текущие источники во время запроса | Для новых знаний нужен новый цикл обучения |
| След источника | Может показать passage, ссылку и версию | Примеры обучения не являются citation к ответу |
| Хороший первый сценарий | Вопросы по документам, policies, контролируемый research | Стабильный формат, повторяемая классификация, ограниченная трансформация |
| Операционная работа | Ownership источников, доступы, indexing и evaluation | Curated dataset, labels, versioning и regression evaluation |
| Типичный сбой | Неверный, устаревший или неразрешённый retrieval | Слабые labels, устаревшее поведение или слишком широкое обобщение |
Ни один вариант не обещает точность. Для обоих нужны тесты конкретной задачи, owner и явный маршрут неопределённости.
Авторская RFT-5 matrix для выбора
До выбора архитектуры используйте авторскую RFT-5 matrix. Оценивайте каждый пункт для конкретного workflow, а не для общего желания «добавить AI».
| Сигнал | Сигнал в пользу retrieval | Сигнал в пользу fine-tuning | Вывод для архитектуры |
|---|---|---|---|
| Freshness знаний | Факты часто меняются или имеют версии | Задача опирается на устойчивые договорённости | Изменяемые знания склоняют к RAG |
| Требование evidence | Нужны ссылки, passages или audit context | Ответу не нужна citation к источнику | Видимые evidence склоняют к RAG |
| Повторяемость поведения | Ответы зависят от документов и вопроса | Повторяется одна размеченная трансформация | Повторяемость может оправдать fine-tuning |
| Граница доступа | Документы отличаются по role или tenant | Примеры можно безопасно подготовить | Доступ применяйте до RAG; не тренируйте чувствительные данные по умолчанию |
| Loop исправлений | Source можно быстро исправить или исключить | Labels и примеры можно системно проверять | Выберите loop, который команда реально сможет вести |
Итог не является магической суммой баллов. Это повод для review. Если доминируют freshness и evidence, начинайте с RAG. Если доминируют устойчивое поведение и качественный размеченный dataset, тестируйте fine-tuning. Если высоки оба сигнала, разделите обязанности: retrieval даёт текущие факты, а fine-tuning может формировать ограниченный ответ.
Три типовых корпоративных сценария
1. Policy assistant со ссылками на действующие правила
Сотрудник спрашивает, какое согласование требуется для изменения договора. Ответ зависит от актуальной версии policy, role mapping и, возможно, контролируемого исключения. Это задача формы RAG: найти только разрешённые текущие документы, показать source trail и направить существенное решение назначенному owner. Fine-tuning на policy прошлого квартала не сохранит ответ актуальным.
2. Support-классификатор с устойчивой внутренней таксономией
Operations-команда получает много сообщений, которые нужно отнести к небольшому стабильному набору категорий. Deterministic rules или аккуратно проверенный fine-tuning могут подойти, если таксономия, примеры и loop исправлений устойчивы. RAG может помочь reviewer увидеть документацию продукта, но не обязан быть частью каждой классификации.
3. Product knowledge assistant с единым форматом ответа
Assistant должен отвечать по текущим release notes и документации, но всегда возвращать ответ в одном approved формате. Сначала сделайте текущие документы доступными для retrieval и проверки. Fine-tuning рассматривайте только после появления устойчивого набора примеров, показывающего, что prompt и schema controls не дают требуемый формат надёжно. Гибридный дизайн не должен скрывать границу источников.
Стоимость и риск — это прежде всего операционная работа
У RAG есть data и retrieval operating model: owners источников, access filters, ingestion rules, evaluation questions, исключение устаревших материалов и route для исправлений. У fine-tuning есть dataset operating model: релевантные и разрешённые примеры, качество labels, evaluation splits, версии training data и regression checks. Оба пути становятся дорогими, если у feedback loop нет owner.
Не используйте training data как обход permissions. То, что документ доступен проектной команде, не делает его уместным для общего датасета. Минимизируйте чувствительные поля, определите retention, фиксируйте разрешения и тестируйте, кто может получить каждый ответ. В юридически, финансово, медицински, кадрово или access-критичных решениях AI может готовить evidence или draft, но authority остаётся у назначенного человека.
Маленькая evaluation до большого обязательства
Выберите одну группу пользователей, один ограниченный task и репрезентативный test set. Добавьте обычные кейсы, изменённые sources, отсутствие evidence и случаи, которые нужно отклонить или эскалировать. Сравните с простым baseline — search, approved template или deterministic logic — до усложнения модели.
require(task.owner && task.boundary && testSet.representative);
require(sources.current || examples.versioned);
require(access.enforced && correction.owner && escalation.path);
choice = evidenceRequired ? "RAG" : repeatableBehaviour ? "fine-tune test" : "baseline first";Фиксируйте denominator для каждого полезного сигнала: coverage retrieval, долю ответов с evidence, валидность формата, corrections reviewer, no-answer handling и время обновления изменённого правила. Красивое демо не является сравнением, если из него исключены обычные failure cases.
Практическое решение
Выбирайте RAG, когда ценность состоит в актуальной, permission-aware и проверяемой связи с документами. Выбирайте fine-tuning только когда устойчивый проверенный dataset должен формировать повторяемое поведение, а команда готова поддерживать его жизненный цикл. Сочетайте подходы, только если их обязанности остаются видимыми.
Для предметного архитектурного обсуждения принесите RFT-5 matrix, небольшой разрешённый corpus или набор примеров, репрезентативные вопросы и owner исправлений. Так решение о RAG-системе станет проверяемым, а не превратит любую из техник в универсальный ответ. Контекст дополняют RAG простыми словами и кейсы.
require(task.owner && task.boundary && testSet.representative);
require(sources.current || examples.versioned);
choice = evidenceRequired ? "RAG" : repeatableBehaviour ? "fine-tune test" : "baseline first";