Сначала рассмотрим конфигурацию стандартного поиска Base Retriever, а после — более продвинутые подходы RAG: Maximum Marginal Relevance Search (MMR), MultiQuery, Hypothetical Document Embeddings (HyDE) и Reranking.

1. Base Retriever

• При инициализации класса Retriever, можно указать различные параметры. Например: параметр k позволяет зафиксировать количество документов, возвращаемых в результате поиска — по умолчанию 4.

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

2. MMR

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

Чтобы такого не происходило, можно воспользоваться специальным алгоритмом поиска и ранжирования Maximum Marginal Relevance Search (MMR). Он учитывает релевантность каждого документа и «новизну» информации в нём относительно отобранных ранее.

MMR позволяет получить релевантные и при этом максимально насыщенные информацией документы без дублирования.

3. MultiQuery

Как мы помним, основная функция RAG — поиск наиболее релевантной информации для решения задачи. Часто задача формулируется в виде запроса, по которому и осуществляется поиск. Но не всегда получается найти документы и получить полный, корректный ответ по отдельному запросу.

Чтобы повысить качество поиска и получить максимально релевантную информацию из базы, можно воспользоваться методом MultiQueryRetriever.

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

4. HyDE

Ещё один способ модернизации RAG — Hypothetical Document Embeddings (HyDE). Его суть в том, чтобы до того, как проводить поиск релевантных документов, по запросу генерировать гипотетический, необязательно достоверный документ, который похож на потенциальный ответ. А уже затем на основе сгенерированного документа проводится отбор релевантных текстов.

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

В GigaChain этот подход реализуется с помощью специального эмбедера - HypotheticalDocumentEmbedder.

В отличии от стандартной функции эмбединга, HypotheticalDocumentEmbedder поддерживает два метода генерации векторных представлений:

• embed_documents — для стандартного отображения документов в эмбединги;
• embed_query — для отображения в эмбединг не самого запроса, а текста, который сгенерирует модель в качестве гипотетического документа.

Таким образом, для документов в БД эмбединги считаются стандартным способом, а при поиске релевантных документов для запроса вызывается функция embed_query, реализующая концепцию HyDE.

5. Reranking

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

Есть два подхода, чтобы получить меры близости текстовых сущностей:

• с помощью bi-encoderов: они кодируют каждую сущность один раз, для получения расстояния применяя разные математические функции над парой векторных представлений отдельных элементов;
• с помощью cross-encoderов: они подсчитывают меру близости сразу для пары элементов, поэтому нужно производить подсчёт расстояния для каждой отдельной пары текстов.

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

В подходе Reranking (или иначе Two-Stage Retrieval) последовательно применяются два и более алгоритмов поиска и ранжирования релевантных документов.

Например, на первой стадии можно выполнить поиск классическим эмбедером, отобрать топ-100 документов, а затем применить cross-encoder, переранжировать 100 документов и выделить из них топ-5 самых релевантных.

В GigaChain рализована нативная поддержка Cohere Reranker — это платный API, с помощью которого можно реализовать переранжирование документов, отобранных на первом этапе.

Впрочем, существуют и open-source cross-encoder-ы, позволяющие достичь схожих результатов, например, модель bge-reranker-large, доступная на HuggingFace.

Рассмотрим пример её реализации. Мы инициализируем модель bge-reranker-large и с её помощью посчитаем расстояние от запроса до каждого из подаваемых на вход документов. Затем документы ранжируются по убыванию близости, и в результате нам возвращается топ-5 самых близких запросов:

Полный пайплайн будет выглядеть так. На первом этапе мы осуществляем поиск топ-100 релевантных документов с помощью стандартного Retriever. Затем, чтобы получить топ-100 документов, затем cross-encoder-ом выделяем топ-5 самых релевантных:

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

Резюмируем:

• RAG-подходы могут существенно улучшить результаты модели без необходимости её дообучения и переобучения.
• Для решения каждой задачи нужно построить индивидуальный RAG-пайплайн, учитывающий конкретные требования к результату.
• Мы рассмотрели базовое устройство векторных баз данных, реализацию стандартного и продвинутых способов поиска и ранжирования данных.
• При этом постоянно появляются новые подходы, которые развивают идею генерации ответов с расширенным поиском. Следите за ними на LangChain, в репозитории GigaChain и отслеживайте свежие статьи на профильных площадках.