«Обучите модель на наших документах» — типичная формулировка задачи, и почти всегда она означает не то, что нужно. В большинстве корпоративных сценариев обучать модель не надо: нужно научить её находить ваши документы и отвечать по ним. Разберём разницу, стоимость и то, когда дообучение всё-таки оправдано.
Что делает каждый подход
RAG: модель ищет и отвечает по найденному
Документы разбиваются на фрагменты и индексируются. При вопросе система находит подходящие фрагменты, передаёт их модели, и та формирует ответ по ним, прикладывая ссылку на источник. Знания живут в базе, а не в модели.
Дообучение: знания уходят в веса модели
Модель дополнительно обучается на ваших данных, и они становятся частью её весов. Модель начинает отвечать в вашем стиле и знать вашу предметную область, но проверить источник ответа уже невозможно.
Пять различий, которые решают выбор
- Обновление. В RAG документ меняется — переиндексируется фрагмент, это минуты. При дообучении изменение знаний означает переобучение модели, это дни и деньги.
- Проверяемость. RAG показывает фрагмент-первоисточник, и ответ можно проверить. Дообученная модель выдаёт утверждение без ссылки — проверить его нечем.
- Права доступа. В RAG поиск идёт от имени пользователя, и он видит только доступное ему. В дообученную модель знания «зашиты» без разграничения: она ответит всем одинаково.
- Удаление данных. Из индекса фрагмент удаляется за секунды. Из весов модели — только переобучением с нуля, и это серьёзная проблема при отзыве согласия.
- Стиль и формат. Здесь выигрывает дообучение: научить модель отвечать в определённой манере через инструкции сложнее, чем показать ей тысячу примеров.
Когда нужен RAG
Практически всегда, когда речь о корпоративных знаниях: регламенты, договоры, техническая документация, база поддержки. Признаки задачи, где RAG правильный ответ:
- Ответ должен опираться на конкретный документ, и ссылку на него нужно показать.
- Документы обновляются — хотя бы иногда.
- У разных пользователей разные права на разные документы.
- Есть требование удалять данные по запросу.
Наш проект поиска по корпоративной базе построен именно так: ответ приходит за 5–10 секунд, точность до 90%, и к каждому ответу приложен фрагмент документа. Без ссылки на источник такой инструмент был бы бесполезен — юрист не может опереться на утверждение, которое нельзя проверить.
Когда нужно дообучение
Реже, чем принято думать, но случаи есть.
- Нужен устойчивый стиль и формат ответа: определённая структура документа, тон, терминология. Инструкциями это добивается хуже и дороже по токенам.
- Предметная область далека от общего языка: узкая техническая терминология, внутренний жаргон, специфические сокращения, которых модель просто не понимает.
- Задача узкая и повторяющаяся, а требования к скорости жёсткие: небольшая дообученная модель работает быстрее и дешевле большой универсальной.
- Нужно уменьшить размер модели без потери качества на конкретной задаче — это частый мотив при развёртывании в закрытом контуре.
Ключевой признак: дообучение хорошо передаёт форму и плохо — факты. Если задача звучит как «модель должна знать наши данные», это почти наверняка RAG. Если «модель должна отвечать как мы» — тогда дообучение.
Сколько стоит каждый путь
RAG
Основные затраты — подготовка документов и настройка поиска, а не модель. Работы: сбор и приведение документов к пригодному виду, разбиение на фрагменты, настройка поиска и реранжирования, сборка проверочного набора вопросов, отладка. Обновление знаний после запуска почти бесплатно.
Дообучение
Основные затраты — подготовка обучающей выборки. Нужны тысячи пар «запрос — эталонный ответ», подготовленных вашими специалистами. Это человеко-недели квалифицированных людей, и обойти это нечем. Плюс вычисления на обучение и повторение всего цикла при каждом существенном изменении.
На практике RAG почти всегда дешевле в запуске и радикально дешевле в сопровождении. Дообучение окупается, когда задача стабильна и объёмна: тогда разовые затраты на выборку размазываются по большому числу запросов.
Третий путь: сначала попробуйте без обоих
Прежде чем выбирать между RAG и дообучением, стоит проверить, не решается ли задача хорошей инструкцией и парой примеров в запросе. Это бесплатно, занимает часы и закрывает больше задач, чем принято ожидать — особенно классификацию, извлечение полей и приведение текста к формату.
Порядок усложнения: инструкция → инструкция с примерами → RAG → RAG с дообучением. Переходить на следующий уровень стоит, только когда предыдущий измеримо не дотягивает. Каждый шаг добавляет стоимость и сопровождение, и делать его «на всякий случай» — верный способ построить дорогое решение вместо работающего.
Комбинация, которая работает лучше всего
В сложных проектах эти подходы не конкурируют, а дополняют друг друга: RAG отвечает за факты, дообучение — за форму. Модель дообучается на том, как надо отвечать: структура, тон, обязательные оговорки. А сами факты подставляются поиском в момент запроса. Так знания остаются обновляемыми и проверяемыми, а ответы — единообразными.
Начинать при этом всё равно стоит с чистого RAG. Дообучение формы имеет смысл добавлять, когда уже видно, что именно в ответах не устраивает, — иначе вы учите модель стилю, который сами ещё не сформулировали.
Из чего RAG состоит на самом деле
Со стороны кажется, что RAG — это «положить документы в базу и спросить». На практике это конвейер из нескольких шагов, и качество определяется всеми, а не только моделью.
Подготовка документов
Сканы распознаются, форматы приводятся к тексту, таблицы разбираются, служебный мусор вроде колонтитулов убирается. Шаг незаметный, но именно здесь чаще всего теряется качество: из плохо разобранного документа нельзя достать хороший ответ.
Разбиение на фрагменты
Документ режется на куски. Слишком мелкие теряют контекст — фрагмент без указания, к какому разделу он относится, бесполезен. Слишком крупные размывают смысл и ухудшают поиск. Правильный размер зависит от типа документа, и подбирается он измерением, а не по умолчанию.
Поиск
Векторный поиск находит смысловые совпадения, полнотекстовый — точные формулировки. По отдельности каждый ошибается: векторный не отличит «вправе» от «обязан», полнотекстовый не найдёт синоним. Комбинация обоих работает заметно лучше и стоит недорого.
Реранжирование
Отдельная модель переупорядочивает найденное, чтобы наверх попало действительно подходящее, а не просто похожее. Шаг, который часто пропускают ради экономии, — и зря: он даёт заметный прирост качества при небольших затратах.
Генерация ответа
Модель формирует ответ строго по переданным фрагментам и указывает источник. Здесь же задаётся поведение при отсутствии ответа — та самая возможность сказать «не нашёл».
Почему RAG редко работает с первого раза
Первая версия почти всегда даёт качество ниже ожидаемого, и причина обычно не в модели. Разберём типичные места отказа.
- Документы разобраны плохо. Таблица превратилась в кашу, приложения потерялись, у сканов низкая точность распознавания. Проверяется просто: посмотрите глазами, во что превратились ваши документы после подготовки.
- Фрагменты потеряли контекст. Кусок текста без указания документа, раздела и редакции не даёт модели понять, о чём речь.
- Поиск только векторный. Точные термины, номера пунктов и артикулы находятся плохо.
- Нет реранжирования. В контекст попадают похожие, но не те фрагменты, и модель отвечает по ним.
- Не различаются редакции документов. Система уверенно отвечает по недействующей версии, и это худший вид ошибки.
Диагностический приём: когда ответ неверный, сначала посмотрите, какие фрагменты были найдены. Если нужного среди них нет — проблема в поиске, и менять модель бессмысленно. Если нужный есть, а ответ всё равно неверный — тогда дело в генерации. Это разделение экономит недели работы не в ту сторону.
Что измерять
RAG удобен тем, что его качество раскладывается на измеримые части, и каждую можно улучшать отдельно.
- Доля вопросов, для которых нужный фрагмент вообще попал в найденное. Это потолок качества: то, что не найдено, не может попасть в ответ.
- Доля случаев, когда нужный фрагмент оказался в верхних позициях. Показывает работу реранжирования.
- Доля ответов, соответствующих найденным фрагментам, — то есть отсутствие выдумывания.
- Доля корректных отказов на вопросах, ответа на которые в документах нет. Метрика, которую забывают чаще всего и которая важнее остальных.
- Доля верных ответов по оценке ваших специалистов — итоговая цифра, ради которой всё делается.
Для этого нужен набор из 50–100 реальных вопросов с эталонными ответами. Его подготовка — самая ценная работа в проекте и единственная, которую нельзя переложить на подрядчика: эталон может задать только тот, кто знает предметную область.
Как подготовить документы, чтобы поиск работал
Это та часть проекта, где решается судьба качества, и она почти не связана с моделями. Несколько практических требований к корпусу документов.
- Известен статус каждого документа: действующий, проект, отменённый, заменённый. Без этого система будет уверенно отвечать по недействующей редакции — худший вид ошибки в юридических и регламентных задачах.
- Сохранена структура: раздел, пункт, страница. Ответ со ссылкой «где-то в этом документе» бесполезен, если документ на триста страниц.
- Приложения связаны с основным документом. Условия часто живут именно в приложениях, и оторванный фрагмент теряет смысл.
- Убран служебный мусор: колонтитулы, номера страниц, повторяющиеся шапки. Он засоряет фрагменты и ухудшает поиск.
- Таблицы разобраны в текст с сохранением связи ячейки со столбцом и строкой, а не превращены в поток чисел.
Проверить готовность корпуса можно просто: возьмите десяток случайных фрагментов после подготовки и прочитайте их глазами. Если вам, знающему предметную область, из фрагмента непонятно, о чём речь и к какому документу он относится, — модели тем более будет непонятно.
Опыт показывает, что подготовка документов занимает больше времени, чем настройка поиска и генерации вместе взятые. Это нормально и это стоит закладывать в план: попытка сэкономить здесь оборачивается бесконечной отладкой на следующих этапах.
Сколько занимает запуск и от чего зависит срок
Ориентиры полезно знать заранее, чтобы отличать реалистичный план от оптимистичного.
Прототип поиска по готовому корпусу документов — до двух недель. Это работающий ответ на вопросы с указанием источника, без интеграций и красивого интерфейса. Его задача — показать достижимое качество на ваших документах и ваших вопросах.
Срок сдвигается в первую очередь состоянием документов. Если корпус лежит в одном месте, в машиночитаемых форматах и со статусами редакций — две недели реальны. Если документы разбросаны по системам, часть в сканах, а какая версия действует, знает только человек, — подготовка займёт больше времени, чем всё остальное вместе.
Второй фактор — наличие проверочного набора. Без него невозможно понять, стало ли лучше после очередной настройки, и отладка превращается в блуждание. Подготовка пятидесяти вопросов с эталонными ответами занимает у ваших специалистов несколько дней и экономит недели.
Дообучение как отдельный этап добавляет к сроку время на подготовку обучающей выборки — и это обычно недели, а не дни. Поэтому мы советуем не закладывать его в первую версию: сначала запустить RAG, посмотреть на реальные ответы и только потом решать, нужна ли работа над формой.
Коротко
- RAG хранит знания в базе, дообучение — в весах модели. Это определяет всё остальное.
- RAG выигрывает по обновляемости, проверяемости, правам доступа и удалению данных.
- Дообучение выигрывает по стилю, формату и узкой терминологии.
- «Модель должна знать наши данные» — это RAG. «Модель должна отвечать как мы» — дообучение.
- Проверьте сначала обычную инструкцию с примерами: она закрывает больше задач, чем принято думать.