RAG или дообучение: как использовать свои данные

Компания хочет, чтобы ИИ отвечал по внутренним инструкциям, учитывал ассортимент, разбирал обращения клиентов и соблюдал корпоративный формат. Задачу обычно формулируют одинаково: «Нужно обучить нейросеть на наших данных». Но за этой фразой скрываются разные технические задачи — и для каждой требуется своё решение.

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

Моя рекомендация по умолчанию: не начинать с fine-tuning. Сначала проверить обычную инструкцию для модели и детерминированный workflow. Если системе не хватает корпоративных знаний — добавить RAG. И только когда правильный контекст уже найден, а модель продолжает системно ошибаться в поведении, рассматривать дообучение.[1][2]

В статье под нейросетью я буду иметь в виду языковую модель, которая работает с текстом. Обучение собственной модели с нуля — отдельный проект, который не нужен для большинства прикладных задач малого и среднего бизнеса.

Сначала уточните, что означает «на своих данных»

Корпоративные данные могут играть в системе четыре разные роли.

Документы нужны прямо в текущем запросе

Допустим, сотруднику нужно один раз проанализировать договор, отчёт или несколько инструкций. Если материалов немного и они помещаются в контекст модели, рационально передать их непосредственно вместе с запросом.

Строить отдельную базу знаний ради нескольких файлов не обязательно. Сначала стоит проверить самое простое решение.

Модель должна регулярно отвечать по базе документов

Регламенты, инструкции, карточки товаров, техническая документация и внутренние правила меняются независимо от модели. Ответ должен учитывать действующую версию и, желательно, показывать источник.

Это задача для RAG.

Модель должна стабильно выполнять одну операцию

Например:

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

Сначала это проверяется промптом и примерами. Если результат остаётся нестабильным, а качественных размеченных примеров достаточно, можно рассматривать дообучение.

Результат уже можно получить по точному правилу

Цена находится в учётной системе. Остаток хранится в базе данных. Регион указан в поле CRM. Скидка рассчитывается по формуле.

Здесь не нужен ни RAG, ни fine-tuning. Система должна вызвать API, выполнить SQL-запрос или применить обычное правило. Языковая модель может объяснить результат человеку, но не должна угадывать точное значение по косвенным признакам.

Именно здесь часто возникает лишняя сложность. Бизнес пытается «обучить нейросеть», хотя на самом деле ему нужно связать две системы или привести в порядок справочник. Подробнее этот принцип разобран в статье о том, какие операции поручать ИИ, а какие оставлять правилам.

RAG добавляет актуальные знания перед ответом

RAG подходит, когда правильный ответ уже существует во внешнем источнике и его нужно найти в момент запроса. Документы остаются во внешнем хранилище: система извлекает подходящие фрагменты, добавляет их в контекст и просит модель сформировать ответ с опорой на найденные сведения.[1][8]

RAG меняет информацию, которую модель получает перед конкретным ответом. Он не переписывает знания модели и не исправляет её поведение автоматически.

Типичные задачи для RAG:

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

Как работает RAG

Упрощённый процесс выглядит так:

Пользователь задаёт вопрос.
Система определяет его роль и доступные источники.
Поиск находит релевантные документы или фрагменты.
Найденный контекст передаётся языковой модели.
Модель формирует ответ.
Система возвращает ответ, показывает источники или передаёт вопрос человеку.

Документы не «запоминаются» моделью навсегда. Если регламент изменился, команда обновляет источник и индекс, а не переобучает модель. Для корпоративных знаний это основное преимущество RAG.

Что RAG не исправляет

RAG не превращает плохую документацию в хорошую.

Если в базе лежат две версии инструкции без даты и статуса, поиск может вернуть обе. Если нужное правило вообще не записано, система не сможет достоверно его восстановить. Если документ неправильно разбит на фрагменты, полезная часть может не попасть в контекст.

Проблемы обычно появляются в четырёх местах:

качество и актуальность документов;
извлечение текста и структура фрагментов;
поиск, фильтры и переранжирование;
формирование ответа по найденному контексту.

Поэтому оценивать RAG одной метрикой «правильный ответ» недостаточно. Поиск и генерацию нужно проверять отдельно. Microsoft выделяет качество retrieval, groundedness, relevance и completeness: нашёл ли поиск нужную информацию, опирается ли ответ на контекст, отвечает ли он на вопрос и не пропускает ли существенные сведения.[4]

Практическая схема такой проверки есть в материале о тестировании RAG-чат-бота перед запуском.

Права доступа — часть поиска

Внутренняя база знаний редко одинакова для всех. Отдел продаж не должен видеть документы финансового подразделения, а внешний клиент — внутренний регламент сотрудника.

Фильтрация должна происходить до передачи документа модели. Корпоративные сервисы могут поддерживать ACL и ролевой доступ, но само приложение должно аутентифицировать пользователя, передать его проверенную идентичность и настроить синхронизацию прав. Такие ограничения не включаются автоматически для любого источника.[1][5]

Фраза в промпте «не показывай конфиденциальное» не заменяет архитектурного ограничения. Модель не должна получать документ, который пользователь не имеет права видеть.

Дообучение меняет поведение модели

Дообучение имеет смысл, когда информации модели достаточно, но она неправильно выполняет повторяющуюся задачу.

Например, поиск уже передал действующий регламент, а модель:

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

Здесь проблема находится не в знаниях, а в поведении. При supervised fine-tuning модель обучается на примерах «вход — ожидаемый выход». Подход применяют, в частности, для классификации, соблюдения формата, стиля, выбора инструментов и повышения эффективности на узкой задаче.[3]

Дообучение не заменяет источник истины. Если завтра изменится цена, остаток или регламент, новая информация не появится в модели автоматически.

Документы сами по себе ещё не являются выборкой

Нельзя просто собрать папку с PDF и считать её готовым датасетом для supervised fine-tuning.

Для типичного дообучения нужны качественные примеры:

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

Если задача — классификация заявки, в выборке нужны реальные заявки и правильные классы. Если требуется JSON, нужны входные тексты и ожидаемые структуры. Если модель должна выбирать действие, нужны ситуации и верные решения.

Качество и репрезентативность важнее формального размера выборки. Часть примеров нужно оставить для независимой проверки, а не использовать при настройке. Без такого набора команда не поймёт, стала ли новая версия лучше или просто запомнила знакомые случаи.[3][6]

Когда fine-tuning не стоит использовать

Не стоит начинать с дообучения, если:

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

Для часто обновляемой фактологии RAG обычно управляемее. Fine-tuning оправдан, когда задача устойчива, поведенческая ошибка повторяется, хороших примеров достаточно, а улучшение можно измерить на отдельном тестовом наборе.[1][3]

Как выбрать архитектуру и проверить её на пилоте

Выбор проще делать не по названию технологии, а по месту, где возникает ошибка.

Ситуация	С чего начать	Почему
Несколько коротких документов нужны эпизодически	Передача файлов в контекст	Отдельная инфраструктура может быть избыточна
Ответ должен учитывать меняющиеся инструкции	RAG	Знания обновляются отдельно от модели
Нужно показывать источник ответа	RAG	Найденные документы можно сохранить и отобразить
Нужна точная цена, остаток или статус	API, SQL, правило	Значение уже хранится в структурированной системе
Модель нарушает формат или категории	Промпт и примеры, затем fine-tuning	Проблема относится к поведению
Нужно сократить длинный промпт для частой узкой задачи	Оценить fine-tuning	Дообученная модель может требовать меньше инструкций
Не хватает знаний и стабильности поведения	RAG, затем возможный гибрид	Каждый контур нужно проверить отдельно
Процесс ещё не утверждён	Описать процесс без ИИ	Автоматизировать пока нечего
Результат влияет на деньги, права или договор	Правила и подтверждение человека	Цена ошибки требует контроля

Порядок усложнения ИИ-решения: от описания процесса и baseline к RAG, дообучению и гибридной архитектуре — Сначала докажите необходимость каждого следующего компонента.

Ищите источник ошибки

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

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

В документах нет однозначного ответа. Это не ошибка RAG и не недостаток модели. Компания должна определить владельца решения, утвердить правило или передавать случай человеку.

Ответ можно получить точным запросом. Нужен инструмент: API, база данных, CRM или код. Просить модель угадывать значение по документам нерационально.

Ошибки есть в поиске и поведении. Возможна гибридная архитектура: RAG поставляет актуальные факты, а дообученная модель устойчивее выполняет целевую операцию. Но сначала нужно доказать необходимость каждого компонента на одном тестовом наборе.[3][7]

Нужна ли для RAG векторная база

Не всегда.

Векторный поиск полезен, когда нужно находить фрагменты со схожим смыслом, даже если пользователь и документ сформулированы разными словами. Но RAG не требует обязательной отдельной векторной базы во всех проектах. Индекс может поддерживать поиск по ключевым словам, семантический, векторный или гибридный поиск.[1]

Для небольшого корпуса иногда достаточно полнотекстового поиска. Для структурированных данных — фильтров и запросов к основной базе. В крупных системах могут сочетаться ключевые слова, векторы, метаданные, фильтры по правам и переранжирование.

Выбирать хранилище до того, как собраны реальные вопросы, рано.

Пилот в шесть шагов

Ограничьте процесс. Не «ассистент по всем документам компании», а ответы по одной группе инструкций, классификация одного типа обращений или поиск по документации одного продукта.
Соберите эталонный набор. Для каждого реального запроса зафиксируйте ожидаемый источник, обязательные факты, допустимый формат, условия отказа, роль пользователя и недопустимый результат.[6]
Зафиксируйте baseline. Проверьте обычную модель с хорошей инструкцией и несколькими примерами. Для точных операций используйте код и workflow.
Добавьте RAG, если не хватает знаний. Сначала оценивайте найденные документы, затем — то, что модель сделала с контекстом.
Рассматривайте fine-tuning после диагностики. Новую версию сравнивайте с baseline и RAG на закрытой части тестового набора.
Проверьте эксплуатацию. Измеряйте задержку, стоимость операции, ошибки поиска и API, нарушения доступа, долю ручных исправлений, причины отказа и версии всех компонентов.

У первой версии должен быть владелец и измеримый результат. Модель может отвечать лучше, но делать процесс экономически бессмысленным. Может быть и наоборот: небольшой рост качества на дешёвой модели даст полезный результат при большом объёме операций.

Что дешевле: RAG или дообучение

Универсального ответа нет.

У RAG появляются расходы на подготовку документов, индекс, поиск, синхронизацию, контекст и поддержку базы знаний. Каждый запрос может требовать дополнительных операций и увеличивать задержку.[1]

У fine-tuning нужны разметка данных, обучение, отдельная оценка, развёртывание и повторная проверка после изменения базовой модели или задачи. При этом дообучение иногда сокращает промпт или позволяет использовать меньшую модель для узкой операции.[3]

Поэтому сравнивать нужно не стоимость одного запуска обучения и не цену одного поискового запроса. Нужна полная экономика:

подготовка данных + разработка + проверка + запросы + инфраструктура + ручные исправления + обновление + стоимость ошибки.

Для пилота рациональнее начинать с архитектуры, которую проще проверить и изменить.

Вывод: сначала определите, где находится правильный ответ

Вопрос «как обучить нейросеть на своих данных» лучше заменить другим:

Где находится правильный ответ и какую ошибку мы пытаемся исправить?

Если ответ лежит в актуальных документах, начинайте с RAG. Если информация уже передана модели, но она нестабильно выполняет устойчивую задачу, проверяйте дообучение. Если значение хранится в CRM или базе, используйте API. Если правило однозначно, оставьте его обычному workflow.

Первый практический шаг — собрать таблицу реальных запросов с ожидаемыми источниками, результатами и условиями отказа. Уже на ней будет видно, нужны ли компании поиск по базе знаний, настройка поведения модели или сначала порядок в данных и процессе.

Если границы задачи, источники данных и критерий пилота пока не определены, их можно зафиксировать на аудите бизнес-процессов. Цель такого этапа — не обосновать применение ИИ, а выбрать минимально достаточное решение и понять, по каким результатам его масштабировать, доработать или остановить.

Частые вопросы

Можно ли дообучить нейросеть на PDF-документах?

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

Можно ли просто загрузить документ в ИИ?

Для разовой работы с несколькими файлами этого может быть достаточно. Если документов много, они обновляются, имеют разные права доступа и используются регулярно, потребуется управляемая база знаний, поиск, журналирование и тестирование.

Как создать базу знаний для ИИ?

Сначала определите источники, владельцев документов, статусы версий и права доступа. Затем подготовьте текст, метаданные и индекс, настройте поиск и соберите тестовые вопросы с ожидаемыми источниками. Загрузка файлов — только один из этапов. Порядок обновления такого контура разобран в статье об актуализации базы знаний для ИИ.

Можно ли совместить RAG и дообучение?

Да. RAG может поставлять свежие факты, а дообученная модель — стабильнее соблюдать формат или выполнять узкую операцию. Комбинировать подходы имеет смысл только после того, как на тестах отдельно подтверждены проблемы поиска и поведения.

Как понять, что RAG работает хорошо?

Проверьте, находит ли система правильные и доступные пользователю документы, опирается ли ответ на найденный контекст, не пропускает ли существенные сведения и вовремя ли отказывается от ответа. Итоговую оценку дополните бизнес-метриками: ручными исправлениями, временем обработки, повторными обращениями и стоимостью операции.

Как обучить нейросеть на своих данных: когда нужен RAG, а когда дообучение