RAG: как научить ИИ отвечать по вашим данным, а не по памяти

RAG подключает языковую модель к внешним источникам: документам, базе знаний, сайту или корпоративной wiki. Разберём, как устроен этот подход, где он действительно полезен и почему одной векторной базы недостаточно, чтобы получить надёжного AI-ассистента.

Большая языковая модель умеет писать письма, объяснять код и поддерживать разговор, но ничего не знает о вчерашнем изменении вашего прайс-листа, новой инструкции для сотрудников или договоре, который лежит на корпоративном диске. Можно вставить нужный документ прямо в запрос, однако на сотне файлов этот метод превращается в своеобразный офисный спорт: найди правильный PDF, скопируй нужные страницы и постарайся не превысить контекстное окно модели.

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

Название расшифровывается как Retrieval Augmented Generation — «генерация, дополненная поиском». Термин закрепился после работы исследователей Meta AI, опубликованной в 2020 году. Авторы совместили генеративную модель с внешней непараметрической памятью — плотным векторным индексом Wikipedia — и показали преимущества подхода на задачах, требующих фактических знаний. Важно, что современным словом RAG называют уже целое семейство архитектур, а не только конкретную схему из той статьи. Оригинальную работу можно прочитать на arXiv.

Что такое RAG простыми словами

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

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

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

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

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

Размер и границы чанков имеют значение. Если разрезать текст слишком мелко, определение окажется в одном фрагменте, а важное исключение — в другом. Если сохранять огромные куски, поиск начнёт возвращать много лишнего, а модель потратит контекст и деньги на чтение цифрового аналога канцелярского шкафа. Универсального размера нет: юридические документы разумно делить с учётом разделов и пунктов, инструкции — по операциям, а карточки товаров зачастую лучше хранить как отдельные логические записи.

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

Когда приходит вопрос, система обычно выполняет такую цепочку:

1. Преобразует запрос пользователя в форму, подходящую для поиска, и при необходимости извлекает фильтры: версию продукта, дату, подразделение или уровень доступа.
2. Находит несколько наиболее релевантных фрагментов с помощью векторного, полнотекстового либо гибридного поиска.
3. При необходимости повторно ранжирует кандидатов более точной моделью и отбрасывает слабые совпадения.
4. Собирает промпт из вопроса, инструкций для модели и найденного контекста.
5. Генерирует ответ, прикладывает ссылки на использованные документы или честно сообщает, что подтверждённых данных недостаточно.

На практике векторный поиск полезно сочетать с обычным полнотекстовым. Семантика хорошо понимает перефразированные вопросы, а поиск по словам лучше ловит артикулы, коды ошибок, фамилии и точные названия. Гибридная выдача затем объединяется и может проходить повторное ранжирование. Такая архитектура описана, например, в актуальном руководстве Microsoft по информационному поиску для RAG.

Где RAG действительно полезен

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

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

Для интернет-магазина подход пригодится в консультанте по сложным товарам. Например, пользователь спрашивает, совместима ли материнская плата с процессором и какой разъём питания нужен видеокарте. Система извлекает характеристики из каталога и документации, после чего объясняет вывод человеческим языком. Но актуальную цену и остаток лучше получать напрямую из учётной системы через API или SQL-запрос. RAG предназначен прежде всего для поиска по неструктурированным знаниям; заставлять его угадывать точное число по текстовым фрагментам — архитектурная шалость с предсказуемым финалом.

Ещё один сильный сценарий — помощник разработчика по внутренней документации и кодовой базе. Он может находить описание сервисов, примеры использования API и связанные участки кода. Похожий практический пример семантического поиска по исходникам есть в документации Qdrant.

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

RAG или fine-tuning: что выбрать

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

Дообучение не стоит воспринимать как удобный способ «загрузить в модель все PDF». Факты после обучения сложно точечно обновлять и надёжно цитировать. RAG, напротив, позволяет заменить документ в индексе, однако добавляет зависимость от качества поиска и увеличивает задержку ответа. Подходы можно комбинировать: настроенная под задачу модель получает актуальные знания через retrieval. Сравнение вариантов есть в AWS Prescriptive Guidance.

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

Почему RAG ошибается

Главная проблема часто находится не в генеративной модели, а на шаг раньше. Сканированный PDF мог плохо распознаться, таблица — потерять структуру, а важный заголовок — отделиться от абзаца. Система найдёт именно то, что было проиндексировано, включая мусор, дубликаты и инструкции трёхлетней давности. Поэтому подготовка источников, версии документов и метаданные нередко влияют на результат сильнее, чем замена одной мощной модели на другую.

Вторая проблема — retrieval failure: правильный фрагмент есть в базе, но не попал в верхние результаты. Причиной бывает неудачное разбиение, слабая модель embeddings, неоднозначный запрос или отсутствие точного поиска. Лечится это не просьбой «отвечай внимательнее», а тестированием поиска, гибридной выдачей, фильтрами и reranking. Для простого прототипа векторы можно хранить даже в PostgreSQL через расширение pgvector; отдельная векторная платформа нужна не каждому проекту с первого дня.

Третья проблема — безопасность. Документ из внешнего источника может содержать скрытую инструкцию для модели: игнорировать правила, раскрыть данные или выполнить нежелательное действие. Это называется косвенной prompt injection. Фильтрация источников, разграничение прав, изоляция инструментов и подтверждение опасных операций обязательны, особенно если RAG входит в состав агента. OWASP относит prompt injection к ключевым рискам приложений на базе языковых моделей.

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

Как собрать первый RAG-проект без лишней магии

Начинать лучше не с выбора модной векторной базы, а с узкого вопроса: кому и по каким документам должен отвечать ассистент. Для первого проекта достаточно одного хорошо ограниченного набора — например, справочного раздела сайта или внутренних инструкций поддержки. Затем стоит собрать 30–50 реальных вопросов, включая неоднозначные, устаревшие и те, на которые в базе нет ответа.

После загрузки документов проверьте извлечённый текст вручную, сохраните заголовки, URL, даты, версии и права доступа. Сделайте простой поиск, посмотрите, попадает ли правильный фрагмент хотя бы в первые несколько результатов, и лишь затем подключайте генерацию. Такой порядок быстро показывает, где сломалась цепочка. Иначе команда будет неделю переписывать промпт, хотя нужный абзац ни разу не доходил до модели.

Оценивать следует отдельно поиск и итоговый ответ. Для retrieval полезно измерять, оказался ли эталонный фрагмент среди top-k результатов; для генерации — релевантность, полноту, корректность и groundedness, то есть подтверждается ли ответ переданным контекстом. Эти измерения описаны в руководстве Microsoft по оценке RAG. К ним нужно добавить прикладные показатели: задержку, стоимость запроса, долю отказов и оценку реальных пользователей.

Фреймворки вроде LangChain или LlamaIndex ускоряют прототипирование, но не заменяют понимание конвейера. Полезнее сначала увидеть собственными глазами запрос, найденные чанки и итоговый промпт. Тогда фраза «RAG плохо отвечает» распадается на диагностируемые причины: парсер потерял таблицу, поиск выбрал старую версию, reranker поднял не тот раздел или генератор вышел за пределы источников.

Стоит ли изучать RAG

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

Переоценён RAG там, где его продают как кнопку «убрать галлюцинации». Он не исправляет противоречивые документы, не определяет автоматически, какой регламент юридически главнее, и не превращает вероятностную модель в базу данных. Более сложные варианты — query rewriting, маршрутизация между источниками, графовый и agentic RAG — действительно расширяют возможности, но заодно увеличивают стоимость, задержку и число точек отказа. Переходить к ним разумно после того, как простой конвейер измерен и показал конкретные ограничения.

Вывод

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

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