Картирование RAG: этапы пайплайна, ключевые компоненты и ландшафт вариантов
Понять, как работает генерация с усилением за счёт поиска от начала до конца, какие компоненты необходимы системе RAG и как множество различных вариантов RAG объединяются в единую структуру.
Источники: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
Модель языка способна к впечатляющему мышлению, но при этом может ничего не знать о ваших внутренних документациях, изменениях политики прошлой недели или заявке, поданной час назад. Технология генерации с усилением через поиск информации (RAG) устраняет этот недостаток, позволяя модели искать необходимые данные во внешнем источнике знаний перед тем, как давать ответ. В этом руководстве рассматриваются проблемы, которые решает RAG, и те, что он не решает, три этапа работы системы RAG, компоненты, необходимые для её создания, а также способы разбора длинного списка вариантов RAG.
RAG в одном предложении
RAG объединяет два процесса:
- Поиск: нахождение релевантной информации во внешнем источнике знаний.
- Генерация: создание ответа моделью языка на основе найденных данных.
Проще говоря, RAG предоставляет модели справочную библиотеку для ознакомления перед тем, как она отвечает. Исследования, представившие этот подход, описывали его как сочетание параметрической памяти модели — знаний, хранящихся в её весах во время обучения, — с непараметрической памятью, то есть внешним индексом, который можно искать и обновлять независимо.
Полезным сравнением может служить экзамен с открытыми учебниками:
- LLM — это студент.
- База знаний — это учебник.
- Система поиска — это студент, перелистывающий нужные страницы.
- Окончательный ответ — это ответ студента, написанный с открытыми этими страницами.
Модель обеспечивает логическое мышление и плавную речь; система поиска предоставляет факты, релевантные конкретному вопросу.
Проблемы, которые должен решать RAG
Опора исключительно на встроенные знания модели сталкивается с рядом практических ограничений. Для каждого из них RAG предлагает частичное решение.
Знания, действительные только во время обучения
Модель не может знать о чем-либо, что было добавлено или изменено после сбора её обучающих данных. С помощью RAG актуальная информация хранится во внешнем хранилище, которое можно обновлять в любое время без вмешательства в саму модель.
Неподдерживаемые или вымышленные ответы
Иногда модели генерируют утверждения, которые неверны или не имеют оснований. Полученные доказательства дают модели конкретную основу для работы, что снижает количество неподтвержденных ответов. Однако это не устраняет эту проблему полностью: процесс поиска может вернуть неверные фрагменты, сами источники могут быть неточными, а модель всё равно может делать утверждения, которые не подкрепляются доказательствами.
Конфиденциальные данные, которые модель никогда не видела
У универсальной модели нет доступа к внутренним документам вашей организации, эксклюзивному коду или конфиденциальным знаниям. Технология RAG позволяет приложению использовать авторизованные конфиденциальные источники в момент запроса без необходимости переобучения на этих данных. Контроль доступа здесь по-прежнему важен: механизм поиска должен возвращать только ту информацию, которую текущему пользователю разрешено читать.
Информация, которая часто меняется
Политики, техническая документация к продуктам и внутренние записи постоянно обновляются. Добавление или изменение записей в индексе поиска стоит гораздо дешевле и быстрее, чем переобучение языковой модели каждый раз при изменениях.
Документы, слишком большие для полной передачи
Вставка целых документов в каждый запрос тратит ресурсы и деньги без необходимости. Технология RAG передает только соответствующие части базы знаний, что позволяет сохранять фокус запросов и уменьшать объем передаваемых данных.
Шум от нерелевантного контекста
Чрезмерное количество слабо связанного материала затрудняет модели поиск важных доказательств. Фильтрация, переранжирование и сжатие контекста предназначены для повышения качества того, что в итоге попадает к модели.
RAG улучшает привязку к реальности и снижает частоту галлюцинаций, но не гарантирует точных или свободных от галлюцинаций ответов. Рассматривайте его как инструмент надежности, а не доказательство корректности.
Три этапа системы RAG
На самом простом уровне каждая система RAG выполняет три действия: подготавливает знания, извлекает из них информацию и генерирует на ее основе.
Этап 1: индексация
Индексация происходит до того, как пользователь задаст вопрос. Исходные материалы, такие как PDF-файлы, веб-страницы, документация или строки базы данных, подвергаются:
- загрузке в систему,
- разделению на более мелкие фрагменты,
В итоге получается поисковая репрезентация ваших знаний. Концептуально вы создаете индекс поиска для собственных данных.
Этап 2: поиск
Когда поступает вопрос:
- запрос преобразуется в эмбеддинг с использованием той же модели, что и при индексации,
- в базе знаний ищутся близкие по значению векторы,
- выбираются наиболее релевантные фрагменты,
- по желанию применяется фильтрация или переранжирование для улучшения выбора.
Поток от вопроса к потенциальным фрагментам выглядит следующим образом:
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
Важным свойством является то, что запросы и документы находятся в одном и том же векторном пространстве. Именно поэтому модель эмбеддингов, используемая при обработке запроса, должна совпадать с той, что использовалась для построения индекса; использование разных моделей приводит к векторам, которые невозможно значимо сравнивать.
Этап 3: генерация
Выбранные фрагменты объединяются с вопросом пользователя в промпт, и модель генерирует ответ:
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
Результативный ответ основан как на общих способностях модели, так и на конкретных данных, взятых из источника знаний. То, как промпт представляет эти данные — например, с помощью меток источников, на которые может ссылаться модель, — сильно влияет на то, насколько точно ответ будет соответствовать им.
Внутри процесса индексации
Именно на этапе индексации определяется большая часть качества системы RAG. Ее основная структура:
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
Чистые данные
Знания могут поступать практически откуда угодно:
- PDF-файлы
- Веб-сайты
- Документация
- Текстовые документы
- Базы данных
- API
- Внутренние корпоративные файлы
Загрузчики документов
Загрузчик документов считывает исходный материал и преобразует его в унифицированную структуру, которую может обработать остальная часть системы. Например, в LangChain загрузчики имеют общий интерфейс, создающий объекты Document, и могут предоставлять методы load() и lazy_load(). Вариант с отложенной загрузкой выдает документы по одному, вместо того чтобы загружать всё в память, что важно для больших коллекций. LangChain и LlamaIndex — это две экосистемы, с которых обычно начинают новички.
Разбиение на чанки
Большие документы разделяются на более мелкие части, называемые чанками, поскольку извлечение соответствующего раздела документа обычно более полезно, чем передача всего документа модели. Хорошая аналогия — превращение книги в стопку карточек с указателем, каждая из которых охватывает одну идею.
Размер чанков и степень их перекрытия не имеют универсально правильных значений. Они зависят от структуры ваших документов, типа задаваемых вопросов, используемой модели эмбеддингов и количества контекста, которое вы можете предоставить далее в обработке. Чанки, слишком маленькие, теряют окружающий смысл; чанки, слишком большие, ослабляют сигнал важного предложения. Чтобы узнать больше об этом компромиссе, ознакомьтесь с методом разбиения на чанки, сохраняющим доказательства.
Модели эмбеддингов
Каждый фрагмент преобразуется в эмбеддинг — список чисел, представляющий его смысл:
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
Эмбеддинги позволяют системе оценивать степень связанности двух фрагментов контента, что лежит в основе семантического поиска и извлечения информации: тексты с похожим значением оказываются рядом друг относительно друга в векторном пространстве, даже если они содержат мало общих слов.
В семействе моделей text-embedding-3 от OpenAI небольшая модель по умолчанию генерирует 1536-мерные векторы, а крупная — 3072-мерные.
Обе модели принимают параметр dimensions для получения более коротких векторов, при этом небольшая потеря точности компенсируется меньшим объемом хранения и более быстрым поиском. Список моделей может меняться, поэтому уточняйте текущие варианты в документации поставщика.
Векторные базы данных
Эмбеддинги хранятся в векторной базе данных или векторном индексе, предназначенных для быстрого поиска по сходству. К распространенным вариантам относятся:
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
Хранимая запись обычно содержит не только вектор, но и оригинальный текст фрагмента, а также метаданные, такие как источник, номер страницы, идентификатор документа или временная метка. Именно эти метаданные позволяют позже фильтровать по дате или типу документа, а также указывать источник ответа.
Основные компоненты приложения RAG
В совокупности типичное приложение RAG состоит из шести видов компонентов:
- Источник знаний: предоставляет информацию, например PDF-файлы, веб-сайты, SQL-базы данных или API.
- Разделитель текста: разбивает документы на управляемые фрагменты с использованием инструментов разделения текста от LangChain или собственной логики.
Карта семейства RAG
Когда основная структура процесса становится ясной, экосистема различных вариантов может показаться слишком обширной. Не существует единого канонического списка типов RAG; статьи и технические блоги используют перекрывающиеся названия для архитектур, стратегий поиска, техник контекста, источников знаний и специализированных систем. Группировка их по тем аспектам, которые они изменяют, позволяет лучше осмыслить эту структуру.
Основные архитектуры
- Naive RAG: простая последовательность операций — встраивание данных, поиск и генерация ответа.
- Advanced RAG: включает дополнительные шаги до и после поиска, такие как переписывание запроса и его повторная классификация по рангу.
- Modular RAG: рассматривает каждый этап как заменяемый модуль, который можно перекомбинировать.
Стратегии поиска
- Single-pass RAG: один поиск на каждый вопрос.
- Multi-Query RAG: генерируется несколько вариантов формулировки вопроса, и для каждого из них проводится поиск.
- Iterative RAG: сначала производится поиск, затем анализ результатов, после чего проводится ещё один поиск.
- Multi-Hop RAG: используется серия поисков, когда для получения ответа необходимо связать несколько фактов.
- Hybrid RAG: сочетает семантический векторный поиск с поиском по ключевым словам.
- RAG Fusion: объединяет результаты нескольких запросов в один рейтинг.
- Self-Query RAG: позволяет модели преобразовать вопрос в поиск с фильтрами метаданных.
Подходы к контексту и разбиению на фрагменты
- Parent-Child RAG: сопоставляет небольшие фрагменты, но возвращает их более крупные родительские разделы.
- Sentence Window RAG: извлекает предложение вместе с его соседними элементами.
- Hierarchical RAG: производит поиск на разных уровнях, от документов до отдельных абзацев.
- Contextual RAG: обогащает фрагменты контекстом на уровне документа перед их включением в модель.
- RAPTOR: создает дерево рекурсивных кратких изложений и осуществляет поиск на всех его уровнях.
Самокорректирующиеся и адаптивные подходы
- Self-RAG: модель оценивает, требуется ли извлечение информации и подкреплено ли её выводом соответствующими данными.
- Corrective RAG (CRAG): анализирует полученные результаты и запускает процедуру дополнительного извлечения информации, если они недостаточно качественны.
- Adaptive RAG: направляет каждый вопрос на стратегию, соответствующую его сложности.
- Feedback-based RAG: использует обратную связь от пользователей или оценщиков для постепенного улучшения качества извлечения информации.
Агентные подходы
- Agentic RAG
- Multi-Hop Agentic RAG
- Multi-Agent RAG
В этих подходах агент сам решает, когда и где осуществлять извлечение информации, возможно, с использованием нескольких инструментов или сотрудничающих агентов, вместо того чтобы следовать фиксированной процедуре.
Варианты, определяемые источником знаний
Некоторые названия просто описывают источник доказательств. Vector RAG выполняет поиск в индексе эмбеддингов, тогда как SQL RAG и Table RAG обрабатывают реляционные или табличные данные, часто путем формирования запросов моделью. GraphRAG извлекает информацию из графа сущностей и связей, Web или Search RAG получает актуальные результаты из поисковой системы, а Knowledge-Base RAG использует специально подобранный корпус, такой как центр помощи или вики.
Мультимодальные варианты
Другие обозначения относятся к типу содержимого, которое извлекается. Text RAG является стандартным вариантом; Image, Video и Audio RAG извлекают данные из соответствующих медиаформатов, обычно с помощью эмбеддингов или транскрипций, а Multimodal RAG — это общее название для систем, объединяющих несколько из этих подходов.
Специализированные варианты
Последняя группа — системы названий, настроенные под конкретные требования: одно поле, такое как право или медицина (специфичные для определенной области), вопросы, зависящие от времени, где важна свежесть информации (временные), ответы, адаптированные под конкретного пользователя (персонализированные), запросы и источники на нескольких языках (мультиязычные), чувствительные данные, которые должны оставаться защищенными (сохраняющие конфиденциальность), а также индексы, распределенные по нескольким сайтам или организациям (распределенные или федеративные).
Эти группы свободно пересекаются. Реальная производственная система может быть одновременно гибридной, агентной и специфичной для определенной области; эти метки описывают выборы в дизайне, а не взаимоисключающие продукты.
Самый простой пайплайн представляет собой прямую линию:
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
Именно это обычно имеют в виду, говоря о наивном или базовом подходе RAG: встраиваются вопросы, берутся k наиболее близких фрагментов, и они передаются в модель. Это разумная первая версия, которая часто достаточна для небольших, структурированных корпусов данных.
Более совершенные системы включают дополнительные этапы перед процессом поиска:
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
Каждый этап направлен на устранение определенной слабости. Переписывание запросов позволяет исправлять нечеткие или разговорные вопросы, маршрутизация направляет запрос в соответствующий индекс или инструмент, гибридный поиск находит точные термины, упускаемые чистым векторным поиском, фильтрация метаданных удаляет документы, не относящиеся к теме, переранжирование перестраивает список кандидатов с использованием более точной модели, а компрессия уменьшает объем оставшихся данных для соблюдения лимитов. Добавляйте эти элементы только тогда, когда можно измерить проблему, которую они решают; сложность сама по себе не является целью.
Почему RAG — это не просто векторная база данных плюс LLM
Распространенным заблуждением среди начинающих является мнение, что RAG означает «хранить эмбеддинги, запрашивать их, вызывать модель». На практике процесс выглядит скорее так:
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
Каждый шаг в этой цепочке может ухудшить качество итогового ответа: некорректный парсинг, небрежное разделение на части, отсутствие метаданных, несоответствующая модель эмбеддингов, слабая фильтрация или плохо сформулированный запрос. Именно поэтому подключение векторного хранилища к модели — это лишь начало. Как бы ни была мощна модель, она не сможет полностью компенсировать ошибочную информацию, полученную от нее.
Как оценить систему RAG
Главная цель — не просто сгенерировать ответ. Хорошая система RAG должна извлекать действительно полезную информацию и формировать ответ, который подкрепляется полученными доказательствами. Важные показатели для оценки:
- Качество извлечения: возвращаются ли действительно релевантные документы или их фрагменты?
Отдельная оценка каждого этапа позволяет диагностировать сбои; подход оценки RAG по этапам сбоев показывает, как это организовать.
Что делать дальше
Следующим уровнем сложности является сам путь индексации: как PDF преобразуется в текст, различия между загрузкой, парсингом и очисткой данных, компромиссы между разбиением на фрагменты по символам, токенам, рекурсивно, с учетом семантики и структуры, что на самом деле означает перекрытие фрагментов, как следует проектировать метаданные, как текст превращается в вектор, в чем разница между косинусным сходством, скалярным произведением и евклидовой расстоянием, а также как база данных векторов выполняет поиск сходства в масштабах.
Основные выводы
- RAG соединяет обученные знания модели с внешним хранилищем, доступным для поиска, что позволяет получать ответы, отражающие конфиденциальную и актуальную информацию, без необходимости переобучения.
- Этот подход сокращает количество некорректных ответов, но не гарантирует их точности; процессы поиска, получения источников и генерации ответов могут по-прежнему давать сбои.