RAG (Retrieval-Augmented Generation) — способ дать модели точный ответ по своим документам: система сначала находит нужные фрагменты в базе знаний компании, затем модель строит ответ на их основе и указывает источник. Материал собирает статьи сайта про RAG — архитектуру, базу знаний, ассистента для сотрудников и выбор между RAG и дообучением модели.
Поиск и генерация
RAG расшифровывается как Retrieval-Augmented Generation — поиск с дополненной генерацией: модель строит ответ на найденных фрагментах документов компании вместо общих знаний из обучения и указывает источник. На сайте — пять статей про RAG и термины в глоссарии.
Обычная модель отвечает по общим знаниям из обучения, а внутренние регламенты, договоры и базу клиентов компании видит впервые в момент вопроса: без RAG ответ строится на догадке вместо точного текста документа.
Механика простая: вопрос сотрудника ищет похожие фрагменты в заранее подготовленной базе документов — это называется retrieval, поиск, — затем модель получает эти фрагменты вместе с вопросом и формулирует ответ — generation, генерация. Итоговый ответ обычно сопровождается ссылкой на конкретный документ и раздел, откуда взята информация: это и отличает RAG-ответ от обычного диалога с моделью.
Условный пример устройства такой системы: сотрудник спрашивает бота про порядок возврата товара, RAG-система находит фрагмент действующего регламента, модель формулирует ответ своими словами и прикладывает ссылку на раздел документа. Изменится формулировка регламента завтра — ответ бота обновится при следующем обращении к базе, без переобучения модели.
RAG или дообучение
Альтернатива RAG — дообучение модели (fine-tuning) на данных компании: модель буквально переучивают под конкретный домен или стиль. У подходов разная цена запуска и разная скорость обновления данных.
| Критерий | RAG | Дообучение модели |
|---|---|---|
| Обновление данных | Мгновенно — обновили документ в базе | Требует нового цикла переобучения |
| Затраты на запуск | Ниже, без переобучения модели | Выше, нужны размеченные данные и вычисления |
| Точность цитат | Ссылка на конкретный документ | Ответ без прямой ссылки на источник |
| Когда выбирают | База знаний, регламенты, договоры | Специфический стиль или узкий домен ответов |
На практике для базы знаний компании и ответов по регламентам почти всегда выбирают RAG: дообучение обычно избыточно и обходится дороже, если задача решается точным поиском по документам. Подробное сравнение — в статье RAG или дообучение модели для компании.
Комбинация подходов тоже встречается: базовую модель дообучают под общий стиль и терминологию компании, а актуальные факты и цифры подключают через RAG поверх дообученной модели. Для большинства задач такой уровень сложности избыточен на старте — начинают с чистого RAG и добавляют дообучение только при выраженной потребности в специфическом стиле ответов.
База знаний и архитектура
База знаний для RAG устроена иначе, чем обычная папка с файлами: документы разбивают на фрагменты, каждый фрагмент превращают в вектор (embedding) и складывают в специальную базу для поиска по смыслу вместо поиска по точному совпадению слов.
Архитектура системы — отдельный вопрос: как разбивать документы на фрагменты, какой размер фрагмента выбрать, как часто обновлять базу при изменении документов компании. Практический разбор устройства такой системы — в статье про архитектуру RAG.
Формат исходных документов у компании обычно смешанный: PDF, Word, таблицы, страницы внутреннего портала. Перед загрузкой в базу их приводят к единому текстовому виду, а таблицы и сканы требуют отдельной обработки — распознавания текста и разметки структуры, иначе система теряет часть данных при разбивке на фрагменты.
Размер фрагмента — компромисс между точностью и контекстом: слишком короткий кусок текста теряет смысл вне окружения, слишком длинный тянет за собой лишнее и размывает поиск. Отправная точка для большинства регламентов и договоров — фрагмент в несколько абзацев, дальше значение подбирают тестами на реальных вопросах.
Три частых точки входа для компании, которая начинает работу с RAG:
- Ответы сотрудникам по регламентам и договорам — типичный первый пилот с понятной метрикой качества.
- Разбор устройства системы с нуля, если команда строит контур своими силами.
- Сравнение с дообучением модели, если выбор между архитектурами ещё предстоит.
Ассистент и оценка
Готовый пример применения — ассистент для сотрудников: вопрос по регламенту, договору или внутренней инструкции получает ответ с точной цитатой и ссылкой на документ вместо похода к коллеге или поиска в общей папке компании. Разбор сценария — в статье RAG-ассистент для сотрудников.
Юридический отдел компании подключает RAG-ассистента к базе договоров и регламентов — сотрудник получает точную цитату вместо звонка юристу по каждому вопросу. Первые недели уходят на разбор ошибочных ответов и донастройку разбивки документов на фрагменты.
- Собрать десять-двадцать реальных вопросов сотрудников по теме базы знаний.
- Прогнать вопросы через систему и сверить ответ с оригиналом документа человеком.
- Отметить случаи, где система прошла мимо нужного фрагмента или процитировала мимо смысла.
- Донастроить разбивку документов и объём контекста под слабые места.
Отдельный источник ошибок — вопросы, сформулированные иначе, чем написан документ: сотрудник спрашивает бытовым языком, регламент — канцелярским. Система ищет по смыслу вместо точного совпадения слов, и всё же на редких формулировках промахивается — обычная часть настройки, устраняемая донастройкой поиска и словаря синонимов.
Штатный ресурс на поддержку системы после запуска — вопрос, который компания обычно недооценивает на старте проекта.
Какой раздел базы знаний запустить первым?
Риски и условия
Главный риск RAG-системы — устаревшая или противоречивая база: если в документах компании лежат две версии одного регламента, система способна процитировать устаревшую версию с той же уверенностью, что и актуальную. Порядок в исходных документах здесь важнее любой настройки модели.
От компании для запуска RAG нужны три вещи: структурированные документы вместо разрозненных файлов на разных дисках, ответственный за актуальность базы после запуска и понятная область задачи — узкий домен для старта. Разбор подхода под конкретные документы — на странице про нейросети для документов, а что влияет на бюджет такого проекта — в статье про стоимость разработки RAG-системы для бизнеса.
Ответственный за базу знаний редко становится отдельной штатной единицей: в небольшой компании эту роль обычно берёт тот же сотрудник, который вёл документацию до внедрения RAG, добавляя актуализацию базы в свой обычный рабочий процесс.
Начните с одного раздела базы знаний — например, регламентов одного отдела — вместо всей документации компании сразу. Метрика простая: доля вопросов, на которые система ответила точной цитатой без ошибки. При высокой доле базу расширяют на соседние разделы.