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

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

Разработчики часто расширяют знания моделей ИИ с помощью Retrieval-Augmented Generation (RAG) - метода извлечения релевантной информации из базы знаний и прикрепления ее к подсказкам пользователя для значительного улучшения реакции модели. Проблема заключается в том, что традиционные RAG Программы теряют контекст при кодировании информации, что часто приводит к тому, что система не может извлечь соответствующую информацию из базы знаний.

В этой статье мы описываем подход, который может значительно улучшить этап поиска в RAG. Этот подход называется Contextual Retrieval и использует две подтехники: Contextual Embeddings и Contextual BM25. Этот подход позволяет сократить количество неудач при поиске на 491 TP3T, а в сочетании с реранжированием - на 671 TP3T. Эти улучшения значительно повышают точность поиска, что напрямую приводит к улучшению производительности при решении последующих задач.

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

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

Вы можете сделать это следующим образом Наш пример кода пользоваться Клод Разверните собственное решение для контекстного поиска.

Замечание о простом использовании длинных наконечников

Иногда самое простое решение оказывается самым лучшим. Если ваша база знаний не превышает 200 000 Token (около 500 страниц материала), вы можете включить всю базу знаний непосредственно в подсказки, предоставляемые модели, без необходимости использования RAG или аналогичного метода.

Несколько недель назад мы выпустили для Клода Кэш кияВ дополнение к новому API мы значительно ускорили и удешевили этот подход. Разработчики теперь могут кэшировать часто используемые подсказки между вызовами API, сокращая задержки более чем в 2 раза, а стоимость - до 90% (вы можете увидеть, как это работает, прочитав наш обзор Пример кода кэша подсказок (Понимание того, как это работает).

Однако по мере роста вашей базы знаний вам понадобится более масштабируемое решение, и именно здесь на помощь придет контекстный поиск. С этой предысторией мы разобрались, давайте перейдем к делу.

Основы RAG: расширение базы знаний

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

1. Декомпозиция базы знаний (корпуса документов) на более мелкие фрагменты текста, обычно не более нескольких сотен лексем; (слишком длинные блоки текста выражают больше смысла, т.е. являются слишком семантически насыщенными)
2. Сегменты преобразуются в векторные вкрапления, которые кодируют смысл с помощью модели вкрапления;
3. Храните эти вкрапления в векторной базе данных для поиска по семантическому сходству.

Во время работы, когда пользователь вводит запрос в модель, векторная база данных находит наиболее релевантный фрагмент на основе семантического сходства запроса. Затем наиболее релевантный фрагмент добавляется в подсказку, отправляемую генеративной модели (ответ на вопрос как контекст более крупной ссылки на модель).

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

BM25 Улучшение основано на концепции TF-IDF (Word Frequency-Inverse Document Frequency), которая измеряет важность слова в коллекции документов. BM25 предотвращает доминирование общих слов в результатах, принимая во внимание длину документа и применяя функцию насыщения к частоте слов.

Вот как работает BM25, когда семантическое встраивание не работает: Предположим, пользователь запрашивает в базе данных технической поддержки "код ошибки TS-999". （Модель (векторного) встраивания может найти общий контент о коде ошибки, но может пропустить точное совпадение "TS-999". Вместо этого BM25 ищет эту конкретную текстовую строку, чтобы идентифицировать соответствующий документ.

Комбинируя методы встраивания и BM25, программа RAG может более точно извлекать наиболее релевантные фрагменты, как показано ниже:

1. База знаний (корпус документов) разбивается на более мелкие фрагменты текста, обычно не превышающие нескольких сотен лексем;
2. Создайте TF-IDF-кодировки и семантические (векторные) вкрапления для этих сегментов;
3. Используйте BM25, чтобы найти лучший фрагмент на основе точного совпадения;
4. Используйте (векторное) встраивание для поиска сегментов с наибольшим семантическим сходством;
5. Результаты шагов (3) и (4) объединяются и удаляются с помощью техники слияния сортировок; например, специальной модели реорганизации Rerank 3.5.
6. Добавьте первые K сегментов к подсказке, чтобы сгенерировать ответ.

Сочетая модели BM25 и встраивания, традиционные системы RAG способны найти баланс между точным подбором терминов и более широким семантическим пониманием, обеспечивая более полные и точные результаты.

Стандартная система дополнения поиска (RAG), которая сочетает в себе встраивание и Best Match 25 (BM25) для извлечения информации. TF-IDF (Word Frequency-Inverse Document Frequency) измеряет важность слов и составляет основу BM25.

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

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

Контекстуальные трудности в традиционном RAG

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

Например, предположим, что в вашу базу знаний встроена финансовая информация (например, отчет Комиссии по ценным бумагам и биржам США), и вы получили следующий вопрос:"Каков будет рост выручки ACME Corporation во втором квартале 2023 года?"

Связанный блок может содержать следующий текст:"Выручка компании выросла на 3% по сравнению с предыдущим кварталом". Однако в самом блоке нет четкого указания на конкретные компании или соответствующие периоды времени, что затрудняет поиск нужной информации или ее эффективное использование.

Внедрение контекстного поиска

Контекстный поиск осуществляется путем добавления определенного блока к каждому блоку перед встраиванием.Интерпретационный контекст("Context Embedding") и создание индекса BM25 ("Context BM25") решает эту проблему.

Давайте вернемся к примеру сбора отчетов SEC. Вот пример того, как преобразуется блок:

original_chunk = "该公司的收入比上一季度增长了 3%。"
contextualized_chunk = "该块来自一份关于 ACME 公司 2023 年第二季度表现的 SEC 报告；上一季度的收入为 3.14 亿美元。该公司的收入比上一季度增长了 3%。"

Стоит отметить, что в прошлом было предложено множество других способов использования контекста для улучшения поиска. К ним относятся:Добавление общего резюме документа в блок(Мы экспериментировали и обнаружили, что выигрыш очень ограничен),Гипотетическое встраивание документов ответить пением Индексирование на основе абстракций(Мы оценили его и обнаружили, что производительность низкая). Эти методы отличаются от метода, предложенного в данной работе.

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

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

Этот метод эффективно решает проблему того, что когда содержимое текстового блока существует само по себе, отсутствие контекстного фона приводит к тому, что содержимое становится изолированным и бессмысленным.

Включение контекстного поиска

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

<document> 
{{WHOLE_DOCUMENT}} 
</document> 
这是我们希望置于整个文档中的块 
<chunk> 
{{CHUNK_CONTENT}} 
</chunk> 
请提供一个简短且简明的上下文，以便将该块置于整个文档的上下文中，从而改进块的搜索检索。仅回答简洁的上下文，不要包含其他内容。

Генерируемый контекстный текст обычно составляет 50-100 токенов и добавляется в блок перед встраиванием и перед созданием индекса BM25.

Эта прога должна ссылаться на полный документ, соответствующий текстовому блоку (который не должен быть больше 500 страниц, верно?). , в качестве кэша подсказок, чтобы точно сгенерировать контекст, связанный с текстовым блоком, относительно полного документа.

Это опирается на способность Клода кэширования, полный документ в качестве подсказки для кэширования ввода не нужно платить каждый раз, кэширование, просто заплатить один раз, так что программа для достижения предпосылок являютсяБольшая модель позволяет кэшировать длинные документыПодобными возможностями обладают такие модели, как DeepSeek.

На практике процесс предварительной обработки выглядит следующим образом:

Контекстный поиск - это метод предварительной обработки, который повышает точность поиска.

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

Снижение стоимости контекстного поиска с помощью кэширования подсказок

Поиск по контекстам Claude может быть выполнен с минимальными затратами благодаря специальной функции кэширования подсказок, о которой мы уже упоминали. Благодаря кэшированию подсказок вам не нужно передавать документы ссылок для каждого блока. Достаточно загрузить документ в кэш один раз, а затем ссылаться на ранее кэшированное содержимое. Если предположить, что на один блок приходится 800 токенов, на один документ - 8 тыс. токенов, на одну контекстную инструкцию - 50 токенов, а на один контекст блока - 100 токенов, тоЕдиновременная стоимость генерации контекстуализированного блока составляет $1.02 за миллион токенов документов..

методология

Мы провели эксперименты с различными областями знаний (кодовые базы, романы, статьи ArXiv, научные статьи), моделями встраивания, стратегиями поиска и метриками оценки. Мы провели эксперименты в Приложение II Примеры вопросов и ответов, которые мы использовали для каждого домена, приведены ниже.

На рисунке ниже показана средняя производительность по всем областям знаний при использовании наилучшей конфигурации встраивания (Gemini Text 004) и извлечении первых 20 фрагментов. В качестве метрики оценки мы использовали 1 минус recall@20, которая измеряет процент релевантных документов, которые не были найдены в первых 20 фрагментах. Полные результаты можно посмотреть в Приложении. Контекстуализация улучшает производительность в каждой комбинации встроенных источников, которые мы оценивали.

повышение производительности

Наши эксперименты показывают, что:

• Контекстное встраивание сократило количество отказов при поиске первых 20 фрагментов на 35%(5,7% → 3,7%).
• Сочетание контекстного встраивания и контекстного BM25 снизило частоту отказов при поиске первых 20 фрагментов на 49%(5.7% → 2.9%).

Сочетание контекстного встраивания и контекстного BM25 снизило частоту отказов при поиске первых 20 фрагментов на 49%.

Соображения по реализации

При внедрении контекстного поиска необходимо помнить о следующих моментах:

1. Границы фрагментов: Продумайте, как документ будет разбит на фрагменты. Выбор размера фрагмента, границ и перекрытия может повлиять на производительность поиска ^1^.
2. Встраивание моделей: Хотя контекстный поиск улучшает производительность всех протестированных нами моделей встраивания, некоторые модели могут получить больше преимуществ. Мы обнаружили, что Близнецы ответить пением Вояж Особенно эффективным является встраивание.
3. Пользовательские контекстные подсказки: Хотя предложенные нами общие подсказки работают хорошо, лучших результатов можно добиться, адаптировав подсказки к конкретным областям или случаям использования (например, включив глоссарий ключевых терминов, которые могут быть определены в других документах базы знаний).
4. Количество клипов: Добавление большего количества фрагментов в контекстное окно может повысить шансы на включение нужной информации. Однако слишком много информации может отвлекать модель, поэтому ее количество необходимо контролировать. Мы попробовали 5, 10 и 20 фрагментов и обнаружили, что 20 фрагментов работают лучше всего (подробности см. в Приложении), но стоит поэкспериментировать в зависимости от вашего случая использования.

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

Использование переупорядочивания для дальнейшего повышения производительности

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

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

1. Первоначальный поиск был проведен для получения наиболее вероятных релевантных сегментов (мы использовали первые 150);
2. Передайте первые N сегментов и запрос пользователя в модель переупорядочивания;
3. Модель переупорядочивания использовалась для оценки каждого клипа по релевантности и важности для подсказки, после чего были отобраны K лучших клипов (мы использовали 20 лучших);
4. Первые K сегментов передаются в качестве контекста в модель для создания конечного результата.

Сочетание контекстного поиска и переупорядочивания повышает точность поиска.

повышение производительности

На рынке представлены различные модели повторного заказа. Мы используем Реордер Cohere Выполнил тест. путешествие Кроме того, в комплект входит устройство для доработкино у нас не было времени проверить это. Наши эксперименты показывают, что добавление шага переупорядочивания может еще больше оптимизировать поиск в различных областях.

В частности, мы обнаружили, что переупорядочивание контекстных вкраплений и контекстных BM25 снижает частоту отказов при извлечении 20 лучших фрагментов на 671 TP3T (5,71 TP3T → 1,91 TP3T).

Упорядочивание контекстных вкраплений и контекстных BM25 снизило частоту отказов при поиске первых 20 фрагментов на 67%.

Соображения стоимости и задержки

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

вынести вердикт

Мы провели ряд тестов, сравнивая различные комбинации всех вышеперечисленных методов (модели встраивания, использование BM25, использование контекстного поиска, использование реордеров и количество K лучших найденных результатов), и провели эксперименты с различными типами наборов данных. Ниже приводится краткое изложение наших результатов:

1. Встраивание + BM25 лучше, чем просто встраивание;
2. Путешествие и Близнецы это модель встраивания, которая лучше всего показала себя в наших тестах;
3. Передача модели первых 20 сегментов более эффективна, чем передача только первых 10 или 5;
4. Добавление контекста к сегментам значительно повышает точность поиска;
5. Упорядочивание лучше, чем отсутствие упорядочивания;
6. Все эти преимущества можно суммировать: Для максимального повышения производительности мы можем использовать сочетание контекстного встраивания (из Voyage или Gemini), контекстного BM25, переупорядочивания шагов и добавления 20 фрагментов в подсказку.

Мы рекомендуем всем разработчикам, использующим базу знаний, использовать Наше практическое руководство Экспериментируйте с этими методами, чтобы открыть новые уровни производительности.

Приложение I

Ниже приведена разбивка результатов Retrievals @ 20 по наборам данных, встроенным провайдерам, BM25, используемым в сочетании со встроенными провайдерами, использованию контекстного поиска и использованию переупорядочивания.

Разбивка на наборы данных Retrievals @ 10 и @ 5, а также примеры вопросов и ответов для каждого набора данных см. Приложение II.

1 минус отзыв @ 20 для набора данных и результатов встроенного провайдера.

сноски

1. Чтобы узнать больше о стратегиях сегментации, ознакомьтесь со статьей эта ссылка ответить пением эта ссылка.