Одна диаграмма объясняет всю картину построения системы RAG.

На этой диаграмме четко изображен архитектурный план современной сложной системы ответа на вопросы (QA) или системы генерации ответов с дополнениями (RAG). Она начинается с того, что пользователь задает вопрос, и продолжается до окончательной генерации ответа, подробно показывая ключевые этапы и выбор технологий между ними. Весь процесс можно разделить на следующие основные этапы:

1、Построение запросов (Построение запросов)

Это первый шаг во взаимодействии пользователя с системой и отправная точка для понимания системой намерений пользователя. На рисунке показано, как строятся запросы для разных типов баз данных:
a. Реляционные базы данных: для реляционных баз данных распространенным способом построения запросов является преобразование текста в SQL, что означает, что система должна перевести вопросы пользователя на естественном языке в структурированные запросы SQL. Для этого обычно используются методы понимания естественного языка (NLU) и способность отображать семантику естественного языка на синтаксис SQL и схему базы данных. На рисунке также упоминается SQL w/ PGVector, который можно использовать вместе с векторными базами данных (PGVector - векторное расширение для PostgreSQL) для улучшения SQL-запросов, например, для выполнения поиска по семантическому сходству, и, таким образом, для более гибкой работы с нечеткими или семантизированными запросами пользователей.
b. Графовые базы данных: Для графовых баз данных соответствующим методом построения запросов является Text-to-Cypher, язык запросов для графовой базы данных Neo4j, похожий на SQL, но лучше подходящий для графовых запросов. Text-to-Cypher требует перевода вопросов на естественном языке в формулировки запросов на языке Cypher, что требует понимания структуры графовой базы данных и свойств языка графовых запросов. Требуется понимание структуры графовых баз данных и свойств языков графовых запросов.
c. векторная база данных (Векторные базы данных): для векторных баз данных показан Self-query retriever, что означает, что система может автоматически генерировать фильтры метаданных на основе вопроса пользователя и напрямую запрашивать векторную базу данных. Векторные базы данных обычно хранят векторные представления текста или данных, которые извлекаются путем поиска по сходству. Ключом к Self-query retriever является способность извлекать структурированную информацию для фильтрации из вопросов на естественном языке и объединять ее с поиском по сходству векторов для достижения более точного поиска.

Подведение итогов этапа построения запросов: основная задача этого этапа - преобразовать вопросы, заданные пользователем на естественном языке, в запросы, которые могут быть поняты и выполнены системой, с использованием различных языков запросов и техник для различных типов хранилищ данных (реляционных, графов, векторов). Демонстрируется поддержка системой мультимодальных данных и модальностей запросов.

2、Перевод запросов (Перевод запросов)

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

a. Декомпозиция запроса: сложные вопросы можно разложить на более мелкие, более управляемые подвопросы (подвопросы/повторные вопросы). Это можно сделать с помощью таких техник, как многозапросный, пошаговый, RAG-Fusion. - Мультизапрос может означать создание нескольких различных запросов для изучения вопроса с разных сторон. - Step-back может означать, что сначала нужно ответить на более простые, предварительные вопросы, а затем постепенно решить последний сложный вопрос. - RAG-Fusion может означать комбинацию генерации с расширенным поиском и методов слияния запросов для более полного понимания намерений пользователя путем многократного поиска и слияния. - Основная идея заключается в декомпозиции или перефразировании входного вопроса, т. е. в декомпозиции или перефразировании входного вопроса для снижения сложности обработки сложных вопросов.
b. Псевдодокументы: HyDE (Hypothetical Document Embeddings) - типичный метод генерации псевдодокументов. Идея заключается в том, чтобы позволить модели сгенерировать "гипотетический документ" (псевдодокумент) на основе вопроса. Этот псевдодокумент не обязательно должен быть реальным, но он должен содержать первоначальное понимание и предсказание модели относительно ответа на вопрос. Затем псевдодокумент представляется в виде вектора вместе с реальным документом, и выполняется поиск по сходству. HyDE стремится помочь специалисту по поиску векторов лучше найти релевантный реальный документ, внедряя априорные знания модели.

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

3. Маршрутизация

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

a. Логическая маршрутизация: позвольте LLM выбрать БД на основе вопроса, что означает использование Большой языковой модели (LLM) для определения того, к какой базе данных следует обратиться с запросом, исходя из содержания и характеристик вопроса. Например, если вопрос включает сущности и отношения, связанные с графами знаний, он будет направлен в базу данных графов; если вопрос включает запросы структурированных данных, он будет направлен в реляционную базу данных; если вопрос в большей степени ориентирован на семантический поиск, он будет направлен в векторную базу данных.
b. Семантическая маршрутизация: встраивание вопроса и выбор подсказки на основе сходства. Этот подход сначала встраивает вопрос, а затем выбирает другую подсказку на основе сходства векторов вопросов (Prompt #1 , Prompt #2). , Prompt #2). Это означает, что для различных типов вопросов или намерений система устанавливает различные стратегии подсказок и автоматически выбирает наиболее подходящую подсказку по семантическому сходству, чтобы направлять последующий процесс поиска или генерации.

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

4、Индексирование (индексирование)

Для эффективного поиска данные должны быть предварительно проиндексированы. Синяя область изображения демонстрирует различные стратегии оптимизации индексирования:

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

b. Индексирование по нескольким представлениям: Summary -> {} -> Relational DB / Vectorstore Это означает, что можно создать несколько представлений документа для индексирования, например, в дополнение к оригинальному текстовому блоку документа, можно также сгенерировать его краткое содержание ( Это означает, что для индексирования можно создать несколько представлений документа, например, в дополнение к исходному текстовому блоку документа можно сгенерировать и проиндексировать его краткое содержание. Это позволяет использовать различные представления для удовлетворения различных требований запросов. На рисунке подразумевается, что резюме может храниться в реляционной или векторной базе данных.
- Родительский документ, плотный X: может относиться к индексированию документа вместе с информацией о его родительском документе, а также к представлению документа с помощью плотного представления (Dense X), которое может относиться к плотному векторному представлению.
- Преобразование документов в компактные поиск единицы (например, резюме): особое внимание уделяется преобразованию документов в более компактные поисковые единицы, такие как резюме, для повышения эффективности поиска.

c. Специализированные эмбеддинги: тонкая настройка, CoLBERT, [0, 1, ...] -> Vectorstore. ] -> Vectorstore Это означает, что специально обученные или тонко настроенные модели вкраплений, такие как CoLBERT, могут использоваться для создания векторных представлений документов и хранения этих векторов в векторной базе данных.
- Модели встраивания, специфичные для конкретного домена и/или более совершенные: подчеркивает возможность использования моделей встраивания, специфичных для конкретного домена или более совершенных, для получения более точных семантических представлений и улучшения поиска.

d. Резюме с иерархическим индексированием: Splits -> cluser -> cluser -> ... -> RAPTOR -> Graph DB. -> RAPTOR -> Graph DB. RAPTOR (который может относиться к методу иерархического обобщения и индексирования документов) строит иерархическую структуру обобщений документов с помощью многоуровневой кластеризации (cluser).
- Дерево резюме документов на различных уровнях абстракции: акцент на том, что RAPTOR строит дерево резюме документов на нескольких уровнях абстракции.
- Хранящаяся в базе данных графов (Graph DB), база данных графов используется для хранения и управления этой иерархической структурой индексов, облегчая многоуровневый поиск и навигацию.

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

5. извлечение

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

a. Ранжирование: Вопрос -> {} -> Актуальность -> Фильтр. Полученные документы необходимо ранжировать по степени их релевантности запросу.
- Re-Rank, RankGPT, RAG-Fusion: упоминаются некоторые продвинутые техники ранжирования, такие как Re-Rank (повторное ранжирование, которое выполняет более тонкое ранжирование поверх первоначальных результатов поиска), RankGPT (ранжирование с помощью большой модели, такой как GPT) и RAG-Fusion (объединяет ранжирование с генерацией улучшений поиска).
- Ранжирование или фильтрация / сжатие документов на основе релевантности: целью ранжирования может быть либо непосредственное ранжирование и возврат наиболее релевантных документов, либо фильтрация или сжатие документов на основе релевантности для последующей обработки. - CRAG (Context-Relevant Answer Generation) также появляется в сеансе сортировки, процесс сортировки также должен учитывать контекстную информацию.
b. Активный поиск: {} -> CRAG -> Ответ. Повторный поиск и/или поиск из новых источников данных (например, веб), если найденные документы не являются релевантными. Активный поиск означает, что система может активно повторно получать (Re-retrieve) или извлекать из новых источников данных (например, из Интернета), если результаты первоначального поиска неудовлетворительны.
- CRAG также появляется в активном поиске, что еще больше подчеркивает важность контекстуальной релевантности и итеративного поиска.
- Такие техники, как Self-RAG, RRR (Retrieval-Rewrite-Read), также могут иметь отношение к активному поиску, направленному на постоянную оптимизацию результатов поиска и качества ответов с помощью итеративного процесса поиска и генерации.

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

6. Поколение

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

a. Активный поиск (повторное появление): {} -> Ответ -> Самостоятельный поиск, RRR -> Повторное написание вопроса и/или повторный поиск документов. активный поиск также играет важную роль на этапе генерации.
- Self-RAG (Self-Retrieval Augmented Generation) - это метод генерации с дополненным самопоиском, который позволяет генеративной модели активно выполнять поиск по мере необходимости в процессе генерации ответа и корректировать стратегию генерации на основе результатов поиска. - RRR (Retrieval-Rewrite-Read) - это итеративный процесс генерации, который может включать такие этапы, как поиск, переписывание вопроса и чтение документа, чтобы оптимизировать качество ответа в ходе нескольких итераций.
- Использование качества генерации для обоснования повторного написания вопросов и/или повторного поиска документов: подчеркивается, что качество сгенерированных ответов может быть использовано для обоснования повторного написания вопросов и повторного поиска документов, образуя замкнутый процесс оптимизации.

Подведение итогов этапа генерации: этап генерации является ключевым этапом в окончательном выводе ответов. Технологии активного поиска и самопоисковой генерации (Self-RAG, RRR) делают процесс генерации более интеллектуальным и контролируемым и позволяют генерировать более точные и удобные для пользователя ответы.

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

Ключевые моменты и тенденции.

• Поддержка нескольких баз данных: система поддерживает реляционную базу данных, базу данных графов и векторную базу данных, которые могут обрабатывать различные типы данных и требования к запросам.
• Оптимизация и перевод запросов: расширение возможностей системы по обработке сложных и семантических запросов с помощью таких методов, как декомпозиция запросов и генерация псевдодокументов.
• Интеллектуальная маршрутизация: маршрутные решения с использованием LLM и семантического сходства для интеллектуального выбора источников данных и планирования задач.
• Разнообразие оптимизаций индексирования: от чанкинга, множественного представления, выделенного встраивания до иерархического индекса, отражающего разнообразие стратегий индексирования и глубокой оптимизации.
• Уточнение поиска и проактивность: от алгоритмов сортировки до проактивного поиска - система стремится предоставить высококачественные и релевантные результаты поиска.
• Глубокая интеграция генерации и поиска: Self-RAG, RRR и другие техники показывают, что фаза генерации больше не является простым сращиванием информации, а глубоко интегрирована с процессом поиска, образуя замкнутый цикл итеративной оптимизации.

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

Ссылки:
[1] GitHub: https://github.com/bRAGAI/bRAG-langchain/
[2] https://bragai.dev/