Как работает RAG-система: поиск, контекст и ответ

RAG-система работает как управляемый контур поиска и ответа. Сначала документы загружают из выбранных источников, очищают, разбивают на фрагменты, превращают в embeddings и сохраняют в поисковый индекс или vector store. Когда пользователь задает вопрос, система ищет подходящие фрагменты, проверяет права доступа, при необходимости переранжирует найденный контекст и передает его языковой модели. Модель формирует ответ не сама по себе, а с опорой на найденные источники.

Качество RAG зависит не только от модели. Часто сильнее влияют источники, chunking, метаданные, гибридный поиск, reranking, правила отказа от ответа и проверка результата на реальных вопросах.

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

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

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

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

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

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

Reranking улучшает качество, но добавляет задержку и стоимость. Поэтому его обычно применяют не ко всему корпусу, а к top-N кандидатам после первого поиска.

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

• Retrieval quality. Нашлись ли нужные фрагменты до передачи в LLM.
• Grounded answer. Ответ опирается на найденные источники.
• Citations. Пользователь видит документ, раздел или ссылку.
• Access control. Пользователь не получает недоступный контекст.
• Отказ от ответа. Система умеет сказать, что надежного ответа нет.

Технологический pipeline RAG удобно держать как цепочку с двумя контрольными точками: качество индекса и качество ответа. На стороне индекса система получает документы, извлекает текст, очищает служебные элементы, разбивает материал на фрагменты, считает embeddings и сохраняет фрагменты вместе с metadata. На стороне запроса система ищет кандидатов, применяет фильтры, переранжирует фрагменты, собирает контекст и передает его модели.

В рабочем виде цепочка выглядит так: ingestion → parsing → chunking → metadata → embeddings → index/vector store → retrieval → reranking → context assembly → answer with sources → feedback. Если выпадает хотя бы одно звено, качество ответа становится трудно объяснить. Например, модель может отвечать красиво, но retrieval не нашел нужный раздел. Или поиск нашел правильный документ, но контекст был обрезан и модель не увидела важное условие.

Поэтому RAG лучше проектировать не как один “чат с документами”, а как наблюдаемый процесс. Для каждого этапа должны быть вход, выход, лог, метрика и владелец ошибки. Тогда можно понять, что именно нужно исправлять: коннектор, парсер, chunking, embedding-модель, индекс, фильтры, reranker, prompt или правила ответа.

В корпоративной RAG-системе доступ к контексту должен проверяться до генерации ответа. Недостаточно сказать модели “не показывай закрытые данные”: закрытые фрагменты не должны попадать в prompt. Для этого metadata должна хранить владельца, группу доступа, тип документа, дату, статус, версию и источник.

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

Хорошая практика — хранить ссылку на исходный документ и раздел, не только текст chunk. Тогда пользователь может открыть источник, проверить дату и понять, почему система дала именно такой ответ. Это снижает риск галлюцинаций и превращает RAG из “магического ответа” в проверяемый рабочий инструмент.

Когда ответ неверный, важно не обвинять сразу языковую модель. Сначала нужно посмотреть, какие фрагменты нашел retrieval. Если правильного фрагмента нет среди кандидатов, проблема в индексе, chunking, metadata, фильтрах или поисковой стратегии. Если правильный фрагмент был найден, но не попал в итоговый контекст, проверьте reranking и сборку prompt. Если контекст был правильным, но ответ искажен, тогда уже нужно менять prompt, формат ответа, правила цитирования или модель.

Для этого полезно сохранять трассу запроса: исходный вопрос, нормализованный запрос, примененные фильтры, top-K кандидатов, результат reranking, финальный контекст, ответ и ссылки. Такая трасса нужна не для контроля пользователя, а для инженерного разбора качества. Без нее RAG невозможно системно улучшать: команда видит только итоговый ответ, но не знает, где именно возникла ошибка.

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

Для production RAG нужен не только рабочий prompt. Минимальный контур включает стабильные коннекторы, журнал загрузки, контроль ошибок парсинга, версионирование индекса, проверку прав, трассу retrieval, ограничение контекста, ссылки на источники и способ собирать обратную связь. Без этих элементов система может работать в demo, но ее трудно сопровождать в реальном процессе.

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

На практике это означает, что у RAG-проекта должен быть не только владелец разработки, но и владелец знаний. Он подтверждает, какие источники входят в контур, какие документы исключаются, как быстро обновляется индекс после изменения регламента и какие ответы требуют ручной проверки. Без этой роли технически правильная система может постепенно начать отвечать по устаревшим или неполным материалам.

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

• Начали с выбора модели. Источники и качество поиска остались непроверенными.
• Сделали один индекс для всех данных. Права, версии и владельцы документов потерялись.
• Не настроили обновление. Ответы опираются на старые документы.
• Не отделили поиск от генерации. Непонятно, ошибся retrieval или LLM.
• Не собрали eval-набор. Качество оценивается впечатлением от demo.

После общей схемы RAG стоит отдельно выбрать retrieval-подход и хранилище векторов. Для корпоративных документов чаще всего нужно сравнить обычный, векторный и гибридный поиск, а затем решить, хватает ли существующей базы с pgvector или нужна отдельная vector DB.

См. также: Семантический, векторный и гибридный поиск, Векторная база данных для RAG, Локальные LLM и RAG для корпоративных данных.