RAG
RAG (англ. retrieval-augmented generation, генерация с дополнением из поиска) — архитектура систем искусственного интеллекта, в которой перед созданием ответа выполняется поиск во внешней базе знаний. Найденные фрагменты документов передаются большой языковой модели вместе с запросом пользователя. Модель формирует ответ на основе этого контекста и при необходимости указывает использованные источники.[1]
RAG объединяет два разных механизма: информационный поиск находит подходящие сведения, а генеративная модель преобразует их в связный ответ. Знания при этом не требуется заранее помещать в параметры модели. Документы можно обновлять независимо от модели, разграничивать по правам доступа и показывать пользователю как подтверждение ответа. Национальный институт стандартов и технологий США определяет RAG как тип генеративной системы, в которой модель работает совместно с отдельной поисковой системой или базой знаний.[2]
Архитектура применяется в поиске по внутренним документам, справочных службах, технической поддержке, анализе научной литературы и других задачах, где ответ должен учитывать большой или часто меняющийся набор источников. Сам по себе RAG не гарантирует достоверность: система может найти неподходящий текст, пропустить важный документ или неверно пересказать полученный фрагмент. Поэтому качество поиска и проверка соответствия ответа источникам являются отдельными частями разработки.
Архитектура RAG
Большинство систем RAG состоит из двух конвейеров. Первый заранее подготавливает документы и поисковый индекс. Второй запускается для каждого пользовательского запроса, извлекает подходящие фрагменты и передаёт их модели.
Подготовка базы знаний
Источниками служат текстовые документы, веб-страницы, базы данных, электронная почта, инструкции, программный код и расшифровки аудиозаписей. Для каждого источника система должна сохранить происхождение, время обновления, владельца и правила доступа. Без этих метаданных трудно показать точную ссылку, удалить устаревшую версию или запретить пользователю чтение закрытого документа.
Документ разбирается с учётом структуры: заголовков, абзацев, таблиц, списков и подписей. Затем текст делится на фрагменты, или чанки. Слишком короткий фрагмент может потерять смысл, а слишком длинный — содержать много посторонней информации и занимать значительную часть контекстного окна модели. Поэтому размер и границы фрагментов выбирают по типу материалов: договор удобно делить по разделам, справочник — по статьям, программный код — по функциям и классам.
Для поиска могут создаваться два представления текста:
- полнотекстовый индекс хранит слова и их позиции и хорошо находит точные термины, имена, номера и редкие обозначения;
- векторный индекс хранит эмбеддинги — числовые представления смысла фрагментов — и находит близкие по содержанию формулировки, даже если в запросе использованы другие слова.
Новые и изменённые документы должны повторно проходить обработку. При удалении источника связанные фрагменты также удаляются из индекса; иначе система продолжит возвращать сведения, которых уже нет в основной базе.
Поиск по запросу
Пользовательский вопрос преобразуется в поисковый запрос. Простая система сравнивает его эмбеддинг с векторами документов и выбирает несколько ближайших фрагментов. Более надёжный конвейер сочетает семантический и полнотекстовый поиск, применяет фильтры по метаданным и затем объединяет результаты. Такой гибридный поиск сохраняет способность находить точные обозначения и одновременно учитывает смысл запроса.[3]
Первичный поиск ориентирован на полноту и может вернуть десятки или сотни кандидатов. Отдельная модель-реранжировщик повторно оценивает каждый фрагмент относительно вопроса и переставляет результаты по релевантности. В контекст языковой модели попадает только небольшая верхняя часть списка. Это позволяет применить более точный, но вычислительно дорогой метод лишь к уже отобранным кандидатам.[4]
Формирование контекста и ответа
Приложение объединяет вопрос, инструкции и найденные фрагменты в один запрос к модели. Каждому фрагменту присваивается идентификатор или ссылка на исходный документ. Инструкция обычно требует отвечать только по предоставленным материалам, отмечать недостаток данных и прикреплять к утверждениям ссылки.
Языковая модель не обращается к индексу напрямую: она видит только текст, который выбрало приложение. Если нужный фрагмент не был найден, модель не сможет использовать его при ответе. Если в контекст попали противоречащие друг другу версии документа, система должна учитывать дату, статус и приоритет источников либо сообщать о расхождении.
После генерации приложение может проверить, подтверждаются ли отдельные утверждения найденными материалами, соответствует ли формат ответа требованиям и существуют ли указанные ссылки. Для задач с высокими последствиями окончательное решение передаётся человеку.
Основные способы поиска
| Способ | Что сравнивается | Сильные стороны | Ограничения |
|---|---|---|---|
| Полнотекстовый | Слова, формы слов и их частота | Точные имена, коды, цитаты, редкие термины | Может не распознать близкие по смыслу формулировки |
| Векторный | Эмбеддинги вопроса и фрагментов | Семантическое сходство, перефразированные запросы | Иногда поднимает тематически похожий, но фактически неподходящий текст |
| Гибридный | Результаты полнотекстового и векторного поиска | Совмещает точность терминов и смысловую близость | Требует объединения и настройки разных шкал ранжирования |
| Поиск с реранжированием | Пары «вопрос — фрагмент» после первичного отбора | Повышает точность верхних результатов | Увеличивает время ответа и стоимость обработки |
В производственной системе методы дополняются фильтрами. Например, поиск ограничивается документами текущей организации, языком пользователя, действующей редакцией инструкции или материалами, доступными конкретной учётной записи. Фильтрация после получения текста недостаточна: закрытый документ не должен попадать в контекст модели даже на промежуточном этапе.
Варианты архитектуры
Базовый RAG
Базовый вариант выполняет один поиск по исходному вопросу, добавляет несколько верхних фрагментов в запрос и создаёт ответ. Такая схема проста и подходит для небольшого однородного корпуса, где пользовательские вопросы хорошо совпадают с формулировками документов.
Расширенный RAG
Расширенный конвейер преобразует вопрос перед поиском, создаёт несколько запросов, сочетает разные индексы, применяет метаданные и реранжирование. После генерации он может проверить ссылки или повторить поиск, если данных недостаточно. Эти операции устраняют разные ошибки, поэтому их добавляют по результатам измерений, а не как обязательный набор компонентов.
Агентный RAG
В агентной системе модель сама решает, когда и где искать сведения. ИИ-агент может последовательно обратиться к нескольким базам, уточнить запрос, открыть исходный документ и повторить поиск после обнаружения пробела. Такой подход полезен для сложных исследовательских задач, но увеличивает число вызовов, время выполнения и риск выбора неподходящего источника.
RAG также может работать через Model Context Protocol: сервер предоставляет поисковый инструмент или ресурсы, а клиент передаёт найденные данные модели. Протокол унифицирует соединение с источником, но не задаёт способ разбиения документов, индексирования и ранжирования.
RAG, длинный контекст и дообучение
RAG не является единственным способом предоставить модели предметные знания. Выбор зависит от объёма материалов, частоты обновлений и того, нужно ли изменять знания или поведение модели.
| Подход | Где находятся сведения во время ответа | Обновление | Подходящие задачи | Основное ограничение |
|---|---|---|---|---|
| RAG | В найденных фрагментах внешней базы | Переиндексация изменённых документов | Большие, меняющиеся и разграниченные коллекции; ответы со ссылками | Нужный материал может не попасть в результаты поиска |
| Длинный контекст | В документах, целиком переданных модели | Замена вложенных документов | Анализ ограниченного набора заранее выбранных материалов | Стоимость и предел контекста; важные сведения могут теряться среди большого объёма текста |
| Дообучение | В параметрах модели и выученных закономерностях | Новый цикл обучения | Изменение стиля, формата и устойчивого поведения | Неудобно для частого обновления фактов и точного указания источников |
| Обычный поиск | В списке найденных документов | Обновление поискового индекса | Навигация к источникам без генерации сводного ответа | Пользователь самостоятельно читает и сопоставляет документы |
Длинное контекстное окно и RAG могут использоваться вместе. Поиск сокращает многомиллионную коллекцию до нескольких документов, после чего модель получает их расширенные разделы или полный текст. Google указывает, что длинный контекст удобен для заранее выбранных материалов, а RAG помогает масштабировать работу за пределы контекстного окна и сокращать число передаваемых токенов.[3]
Дообучение также не исключает RAG. Модель можно обучить следовать отраслевому формату, а актуальные факты получать из базы знаний. Попытка заменить поиском недостаточно качественную модель обычно не решает проблемы рассуждения, а попытка хранить постоянно меняющиеся инструкции только в параметрах затрудняет их обновление и аудит.
Оценка качества
RAG оценивается не одной общей метрикой, а по этапам. Иначе удачный ответ может скрыть слабый поиск, а правильный документ — ошибочную генерацию.
Качество поиска показывает, присутствуют ли необходимые фрагменты среди верхних результатов и насколько мало в них постороннего текста. Для этого создаётся набор реальных вопросов с известными подтверждающими документами и измеряются полнота и точность на заданной глубине выдачи.
Соответствие ответа контексту отражает, подтверждаются ли утверждения найденными фрагментами. Полезность ответа оценивает, решает ли он вопрос пользователя, а качество ссылок — ведут ли ссылки к тем местам источника, которые действительно поддерживают соответствующий текст. RAGAS предложил раздельно измерять релевантность контекста, верность ответа контексту и качество самого ответа без обязательного эталонного текста для каждого примера.[5]
Автоматические оценки дополняются проверкой людьми. Модель-судья способна систематически ошибаться, предпочитать определённый стиль и считать правдоподобное утверждение подтверждённым. Перед выпуском изменения сравнивают с базовой версией на фиксированном наборе запросов, а после выпуска отслеживают неуспешные поиски, отказы, жалобы и переходы по источникам.
Типичные ошибки
Неправильная обработка документов
Текст из таблиц, колонок и сканированных страниц может извлекаться в неверном порядке. Заголовок отделяется от раздела, единица измерения — от числа, а подпись — от изображения. В результате индекс содержит фрагменты, которых не существовало в исходном документе. Качество разбора проверяют до настройки эмбеддингов и генерации.
Неудачное разбиение
Фиксированное деление через одинаковое число символов способно разорвать определение, условие или таблицу. Слишком большое перекрытие между чанками создаёт множество почти одинаковых результатов. Структурное разбиение и сохранение соседних фрагментов обычно дают модели более целостный контекст.
Низкая полнота поиска
Вопрос пользователя может содержать сокращение, опечатку или термин из другой редакции документа. Помогают нормализация, словари синонимов, преобразование запроса, гибридный поиск и несколько вариантов запроса. При этом расширение поиска повышает вероятность получить нерелевантные документы, поэтому его сочетают с реранжированием.
Устаревшие и противоречивые источники
Если индекс не синхронизирован с основной системой, RAG отвечает по отменённой инструкции. Документам присваивают версии и сроки действия, а результаты фильтруют по статусу. При наличии нескольких действующих источников ответ должен показывать расхождение, а не незаметно объединять несовместимые положения.
Ответ без достаточного основания
Даже при хорошем поиске модель может дополнить контекст сведениями из собственных параметров или сделать вывод, который источники не поддерживают. Инструкция об отказе при недостатке данных, указание фрагментов и последующая проверка уменьшают риск, но не устраняют его полностью.
Безопасность
RAG обрабатывает документы как часть запроса к модели, поэтому текст источника нельзя считать доверенной инструкцией. Злоумышленник способен поместить в веб-страницу или загружаемый файл фразу, которая требует раскрыть данные, игнорировать правила или вызвать инструмент. Такая косвенная инъекция промпта срабатывает после того, как вредоносный фрагмент попадёт в результаты поиска.[6]
Основные меры защиты включают:
- проверку происхождения документов и ограничение круга источников, которые могут изменять индекс;
- применение прав доступа во время поиска, а не после генерации ответа;
- отделение найденного текста от системных инструкций и запрет выполнять команды из документов;
- фильтрацию секретов и персональных данных до передачи контекста внешней модели;
- минимальные полномочия у инструментов, которые может вызвать агентный RAG;
- журналирование найденных фрагментов, версии индекса и ответа модели;
- подтверждение человеком действий с финансовыми, юридическими или административными последствиями.
Отдельной угрозой является отравление базы знаний: добавление специально подготовленных документов, которые вытесняют правильные результаты или систематически изменяют ответы. Защита требует контроля публикации, обнаружения дубликатов и аномалий, версионирования и возможности быстро исключить источник из индекса.
Когда применять RAG
RAG оправдан, если ответы должны опираться на большую коллекцию документов, знания часто меняются, пользователям доступны разные наборы материалов либо требуется показывать происхождение утверждений. Архитектура особенно полезна, когда обычный поиск уже существует и его результаты можно оценить отдельно от генерации.
RAG может быть излишним для небольшой инструкции, которая целиком помещается в запрос, для задачи без внешних знаний или для строго детерминированного расчёта. Если ошибка недопустима и правило можно выразить кодом, проверкой базы данных или формальной схемой, генеративный ответ не должен заменять такой механизм.
Внедрение начинают не с выбора векторной базы, а с набора пользовательских вопросов и критериев правильного ответа. Затем создают минимальный конвейер, измеряют ошибки и определяют, на каком этапе они возникают: в источниках, разборе, поиске, ранжировании или генерации. Только после этого добавляют преобразование запросов, реранжирование и агентные циклы.
Распространённые вопросы
RAG устраняет галлюцинации модели?
Нет. Найденный контекст уменьшает потребность полагаться на внутренние знания модели, но не запрещает ей создавать неподтверждённые утверждения. Требуются измерение верности источникам, ссылки, правила отказа и контроль в задачах с высокими последствиями.
Для RAG обязательно нужна векторная база данных?
Нет. Поиск может быть полнотекстовым, векторным, основанным на графе или сочетать несколько методов. Для небольшого корпуса точный полнотекстовый поиск иногда даёт лучший результат, особенно если запросы содержат коды и специальные термины.
Сколько фрагментов нужно передавать модели?
Единого числа нет. Малое количество повышает риск пропустить доказательство, большое — добавляет шум и расходует контекст. Значение выбирают экспериментально по полноте поиска, верности ответа, времени и стоимости на реальных запросах.
Может ли RAG искать в интернете?
Да. Внешним источником может быть веб-поиск, однако найденные страницы различаются по качеству и способны содержать вредоносные инструкции. Система должна сохранять адрес, дату получения, проверять допустимость домена и отделять содержимое страницы от управляющих инструкций.
Нужно ли обновлять языковую модель при изменении документов?
Обычно нет. Достаточно повторно обработать изменённые документы и обновить поисковый индекс. Модель обновляют отдельно, если требуется улучшить её способности, изменить поддерживаемый контекст или формат работы.
См. также
Примечания
- ↑ Patrick Lewis; Ethan Perez; Aleksandra Piktus; Fabio Petroni; Vladimir Karpukhin; Naman Goyal; Heinrich Küttler; Mike Lewis; Wen-tau Yih; Tim Rocktäschel; Sebastian Riedel; Douwe Kiela. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (англ.). arXiv; Advances in Neural Information Processing Systems (2020). Дата обращения: 14 ноября 2026.
- ↑ Retrieval-augmented generation (англ.). National Institute of Standards and Technology. Дата обращения: 14 ноября 2026.
- ↑ 3,0 3,1 What is Retrieval-Augmented Generation (RAG)? (англ.). Google Cloud. Дата обращения: 14 ноября 2026.
- ↑ Improve search and RAG quality with ranking API (англ.). Google Cloud Documentation. Дата обращения: 14 ноября 2026.
- ↑ Shahul Es; Jithin James; Luis Espinosa-Anke; Steven Schockaert. RAGAS: Automated Evaluation of Retrieval Augmented Generation (англ.). arXiv; European Chapter of the Association for Computational Linguistics (2024). Дата обращения: 14 ноября 2026.
- ↑ Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (англ.). National Institute of Standards and Technology (2026). Дата обращения: 14 ноября 2026.