RAG (Retrieval-Augmented Generation) — это способ строить ответы LLM с опорой на внешний корпус документов: модель сначала получает релевантные фрагменты через поиск, а затем генерирует ответ по ним. На практике это нужно, когда собственных знаний модели недостаточно, данные часто меняются, а дообучать модель ради каждого обновления нецелесообразно. Метод плохо подходит там, где нет надежного корпуса для поиска, нужен строго детерминированный результат без вероятностной генерации, или истина хранится не в документах, а в транзакционных и структурированных данных.
Простыми словами
Если упростить, RAG работает как специалист, которому перед ответом дают папку с релевантными материалами. Он не обязан помнить все заранее: сначала читает нужные фрагменты, потом отвечает. В этом и есть смысл подхода: не заставлять модель хранить все знания внутри себя, а подставлять нужный контекст в момент запроса.
Важно понимать разницу между знанием модели и знанием системы. В обычной LLM ответ строится из того, что модель усвоила на этапе обучения. В RAG знание живет снаружи: в документах, базе знаний, инструкциях, статьях, внутренних регламентах. Модель видит только то, что удалось найти для конкретного вопроса. Поэтому качество ответа зависит не только от самой LLM, но и от поиска, чистоты корпуса, разбиения документов на фрагменты и правил, по которым формируется подсказка для модели.
Из этого следует практический вывод: RAG — это не магическая кнопка против ошибок, а архитектурный прием. Он помогает приземлить ответ на конкретные источники, но не заменяет управление данными.
Как это работает
- Собирают корпус. Это могут быть политики компании, техническая документация, договоры, инструкции, база знаний поддержки, статьи и ответы экспертов.
- Готовят текст. Документы очищают, извлекают текст из PDF, убирают дубликаты, приводят структуру к предсказуемому виду. Если исходники плохие, качество RAG падает уже на этом этапе.
- Разбивают документы на фрагменты. Поиск редко работает по целому файлу. Обычно документ делят на небольшие смысловые куски, чтобы система находила не весь регламент, а именно нужный абзац.
- Строят индекс. Для поиска используют полнотекстовый индекс, векторные представления текста или гибрид обоих подходов. Полнотекстовый поиск хорош для точных терминов, кодов и номеров, а векторный — для семантически близких формулировок.
- Ищут релевантные фрагменты по запросу. На запрос пользователя система выбирает несколько наиболее подходящих кусков текста. Часто здесь же работают фильтры по версии документа, языку, подразделению, дате действия и правам доступа.
- При необходимости делают реранжирование. Из найденного набора выбирают самые полезные фрагменты, чтобы уменьшить шум перед генерацией.
- Формируют подсказку для модели. В промпт кладут вопрос пользователя, найденные фрагменты и правила ответа: не выдумывать, ссылаться на источник, явно говорить, если данных недостаточно.
- Генерируют и проверяют ответ. На выходе можно добавить ссылки на источники, логирование, оценку качества и дополнительные проверки на соответствие политике.
В инженерной практике RAG — это цепочка, а не один компонент. Проблема чаще возникает не в генерации, а в том, что поиск принес нерелевантный текст, в индекс попала устаревшая версия документа или фрагмент был разрезан так, что потерял смысл.
Зачем нужно
- Держать ответы в актуальном состоянии. Если документы обновляются, часто достаточно обновить индекс, а не переучивать модель.
- Привязывать ответ к источнику. Это полезно для поддержки, внутренней документации и всех задач, где важна проверяемость.
- Работать с частными знаниями. Внутренние регламенты компании, условия договоров, каталоги продуктов и служебные инструкции обычно отсутствуют в базовых знаниях модели.
- Сужать область ответа. Вместо надежды на общую эрудицию LLM можно заставить систему отвечать по конкретному корпусу.
- Разделить обновление данных и поведение модели. Знания меняются в индексе, а стиль и формат ответа — в промпте или настройках модели.
| Тип задачи | Что обычно подходит лучше |
|---|---|
| Ответы по часто обновляемым документам | RAG |
| Смена стиля, структуры или тона ответа | Промптинг или дообучение |
| Точные вычисления и операции над таблицами | SQL, API и бизнес-логика |
| Доступ к текущему состоянию системы | Интеграция с источником данных, а не только RAG |
Иными словами, RAG полезен там, где ответ нужно собирать из текстовых источников, а не угадывать из памяти модели.
Пример
Практический сценарий: компания делает внутреннего ассистента для сотрудников по кадровым правилам. Цель — отвечать на вопросы об отпусках, командировках и компенсациях только по действующим регламентам.
- В индекс загружают утвержденные политики и инструкции, а черновики и устаревшие файлы исключают.
- Каждый фрагмент получает метаданные: версия, дата действия, подразделение, язык, тип документа.
- Сотрудник задает вопрос: «Можно ли перенести отпуск, если график уже утвержден?»
- Система ищет фрагменты только в актуальном положении об отпусках и отсекает архивные версии.
- LLM получает найденные абзацы и отвечает по ним, а не по общим знаниям о трудовой практике.
Хороший ответ в такой системе: «Перенос возможен только в случаях, перечисленных в действующем положении об отпусках. Нужны согласование руководителя и заявление сотрудника. Если основание не входит в указанный перечень, я не могу подтвердить перенос без проверки документа».
Если в базе лежат две конфликтующие версии регламента или поиск не нашел нужный абзац, система не станет надежнее только потому, что у нее сильная LLM. В таком проекте качество держится на управлении версиями, дедупликации, фильтрах доступа и тестах на реальных вопросах сотрудников.
Заблуждения и ограничения
- «RAG устраняет галлюцинации». Нет. Он может снизить их вероятность, если поиск хороший, а промпт жестко ограничивает ответ найденным контекстом. Но модель все равно может сделать лишний вывод или неверно склеить несколько фрагментов.
- «Достаточно подключить векторную базу». Нет. Плохой OCR, мусорные PDF, дубликаты, неудачное разбиение текста и отсутствие метаданных ломают результат даже при хорошем индексе.
- «Чем больше контекста, тем лучше». Не всегда. Лишние фрагменты повышают шум, стоимость и риск того, что модель уцепится не за тот источник.
- «RAG заменяет бизнес-логику». Нет. Для транзакций, расчетов, изменений в системах учета и проверок по правилам нужны отдельные инструменты и валидация.
- «Любой документ одинаково хорошо ищется». Нет. Таблицы, много колонок, сноски, изображения и сканы без структуры требуют отдельной обработки. Иногда сначала нужно решить задачу извлечения текста, а уже потом строить RAG.
Есть и ситуации, где RAG не лучший выбор. Во-первых, если весь нужный корпус мал и стабилен, его проще напрямую класть в контекст без отдельного retrieval-слоя. Во-вторых, если ответ должен быть полностью воспроизводим и формально проверяем, вероятностная генерация создает лишний риск. В-третьих, если вопрос зависит от текущего состояния БД, остатков, платежей, прав доступа или статуса заявки, текстовый поиск по документам не заменит обращение к первичному источнику данных.
Частые вопросы
RAG и дообучение — это одно и то же?
Нет. RAG подает знания во время ответа из внешнего корпуса. Дообучение меняет саму модель: ее поведение, стиль или специализированные навыки. Если документы часто обновляются, обычно разумно начинать с RAG.
Нужна ли обязательно векторная база?
Нет. Для части задач хватает обычного полнотекстового поиска. На практике часто выигрывает гибридный подход: точные совпадения ищутся по словам, а смысловые перефразировки — по векторам.
Снижает ли RAG риск галлюцинаций?
Да, но не автоматически. Нужны качественный retrieval, явное правило отвечать только по источнику, сценарий отказа в духе «недостаточно данных» и регулярная оценка на вопросах без ответа в корпусе.
Что важнее: сильная модель или хороший поиск?
В документных системах провал чаще происходит на стороне поиска и подготовки данных. Сильная модель не исправит плохой корпус, устаревшие версии документов и нерелевантные фрагменты.
Когда лучше не делать RAG?
Когда задача сводится к точным операциям над данными, когда нужен жестко детерминированный результат, или когда весь контекст невелик и может быть подан модели напрямую без дополнительного индекса.
Связанные понятия
- Embeddings. Векторные представления текста, на которых строится семантический поиск.
- Vector database. Индекс и хранилище для поиска близких векторов.
- Hybrid search. Сочетание полнотекстового и векторного поиска.
- Reranking. Повторная сортировка найденных фрагментов более точной моделью или алгоритмом.
- Chunking. Разбиение документа на фрагменты для индексации и поиска.
- Fine-tuning. Дообучение модели для изменения поведения, а не для подстановки свежих документов во время ответа.
- Tool calling. Вызов внешних инструментов и API; нужен, когда ответа по документам недостаточно.
Практическое правило простое: если ответ должен опираться на изменяемые документы, начинайте с RAG и отдельно измеряйте качество поиска и качество генерации. Если истина живет не в текстах, а в правилах или транзакционных данных, выбирайте другой архитектурный слой.