Временный подход: поиск по ключевым словам спешит на помощь?

Многие разработчики пытались исправить эту проблему, добавляя поиск по ключевым словам (например, BM25) вместе с семантическим поиском. Это помогает, когда вы ищете конкретные термины, такие как коды ошибок. Введите «Ошибка TS-99», и поиск по ключевым словам укажет ее, в то время как чистый семантический поиск может вернуть общие руководства по устранению неполадок.

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

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

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

Давайте рассмотрим наш пример дохода:

Исходный фрагмент: «Выручка выросла на 3% по сравнению с предыдущим кварталом»

Контекстуализированный фрагмент: «Этот фрагмент взят из отчета о результатах деятельности корпорации Acme за второй квартал 2023 года. Выручка выросла на 3% по сравнению с предыдущим кварталом»

Теперь и ваша модель встраивания, и поиск по ключевым словам имеют полную картину. Когда кто-то ищет «доход Acme Q2 2023», оба поисковых механизма могут уверенно определить это как релевантный фрагмент.

Реализация: заставить LLM выполнять тяжелую работу

Вы можете подумать: «Отличная идея, но я не буду вручную добавлять контекст к тысячам фрагментов». Вот где реализация становится интересной. Anthropic предлагает использовать LLM (они рекомендуют свою эффективную модель Claude Haiku) для автоматической генерации этого контекста.

Вот процесс:

1. Возьмите ваш документ и разбейте его на части обычным способом.
2. Для каждого фрагмента отправьте как полный документ, так и конкретный фрагмент LLM
3. Используйте подсказку, которая инструктирует LLM о необходимости создания краткого контекстного утверждения.
4. Добавить этот контекст к исходному фрагменту
5. Создавайте вложения и обновляйте индекс BM25, используя эти обогащенные фрагменты

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

Цифры: действительно ли это работает?

Показатели Anthropic впечатляют. Используя только контекстные вложения, они увидели снижение частоты неудач поиска на 35% (с 5,7% до 3,7% для поиска топ-20). Когда они объединили контекстные вложения с контекстным BM25, улучшение подскочило до 49% меньше неудач.

Но вот где становится действительно интересно. Когда они добавили рераннер вдобавок ко всему, средний уровень ошибок поиска снизился с 5,7% до всего лишь 1,9%. Это огромное улучшение для того, что можно назвать этапом предварительной обработки и умной инженерией подсказок.

Компромиссы: бесплатного обеда не бывает

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

1. Большие фрагменты : каждый фрагмент увеличивается на 50–100 токенов, что немного уменьшает количество токенов, которые можно поместить в контекстное окно LLM.
2. Расходы на обработку : необходимо выполнить вызов LLM для каждого фрагмента во время индексации.
3. Накладные расходы на хранение : Ваша векторная база данных и поисковые индексы увеличиваются

Anthropic оценивает единовременную стоимость обработки примерно в $1,02 за миллион токенов. Это может показаться небольшим, но если вы имеете дело с миллионами документов, это складывается в сумму. Хорошей новостью является то, что такие функции, как оперативное кэширование, могут сократить это до 90%, особенно при обработке похожих документов.

Когда использовать контекстный поиск (а когда его лучше пропустить)

Вот практическое дерево решений:

Используйте контекстный поиск, когда:

• Ваши документы содержат несколько сущностей, периодов времени или контекстов.
• Вам нужна высокая точность для конкретных целевых запросов
• Ваша база знаний слишком велика для степеней LLM с длинным контекстом (более 200 тыс. токенов)
• Цена ошибок при поиске данных высока (например, юридические документы, финансовые отчеты).

Рассмотрите альтернативные варианты, если:

• Ваша база знаний мала (менее 200 тыс. токенов или 1 МБ, если вы используете Gemini, например) — просто используйте LLM с длинным контекстом
• Ваши документы уже хорошо структурированы и имеют понятный контекст
• Вы работаете с однородным контентом, фрагменты которого являются самостоятельными.

Советы по внедрению с передовой

На основе экспериментов Anthropic и предоставленного ими кода можно дать несколько практических советов:

1. Настройте контекстную подсказку : Подсказка для финансовых документов требует иного контекста, чем для технической документации. Экспериментируйте и повторяйте.
2. Выбирайте модель встраивания с умом : в ходе тестов лучше всего показала себя модель Gemini Text-004 от Google, а также хорошие результаты продемонстрировала модель встраивания Voyage.
3. Не экономьте на повторном ранжировании : сочетание контекстного поиска и повторного ранжирования показало наилучшие результаты. Рассмотрите возможность использования таких сервисов, как API повторного ранжирования Cohere.
4. Извлеките больше данных, затем отфильтруйте : Anthropic добился успеха, изначально извлекая 20 фрагментов, а затем используя повторное ранжирование для выбора лучших из них.
5. Тестируйте с вашими реальными данными : предоставленные контрольные показатели основаны на определенных наборах данных. Ваши результаты могут варьироваться в зависимости от типов документов и шаблонов запросов.

Общая картина: RAG не умер

С LLM, которые щеголяют все большими контекстными окнами, вы можете задаться вопросом, не устаревает ли RAG. Работа Anthropic говорит об обратном. Даже с контекстными окнами в 200 тыс.+ токенов RAG остается более экономически эффективным и масштабируемым для больших баз знаний. Контекстный поиск делает RAG лучше, а не устаревшим.

Подумайте об этом так: LLM с длинным контекстом — это как фотографическая память на все, что вы в данный момент смотрите. RAG — это как хорошо организованная библиотека с умным библиотекарем. Контекстный поиск только что дал этому библиотекарю гораздо лучший карточный каталог.

Подведение итогов: небольшие изменения, большое влияние

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

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

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