Контекстуальный поиск в RAG: что скрывает показатель в 67%, каковы его затраты и когда он терпит неудачу.
Контекстуальный поиск для RAG: как использование префиксов решает проблему одиноких фрагментов, почему показатель 67% отражает три изменения, что экономит кэширование промптов и когда оно терпит неудачу.
Источники: Your RAG Chunk Doesn’t Know Whose Revenue Grew 3% — Contextual Retrieval
«Доход компании вырос на 3% по сравнению с предыдущим кварталом». Векторная база данных может хранить тысячи подобных предложений, причем каждое из них функционально бесполезно, пока не станет ясно, о какой компании и о каком квартале идет речь.
Проблема не в модели, которая формирует окончательный ответ, а в фрагменте текста, попавшем в индекс без указания идентификатора. Любая система RAG, построенная на документах, контрактах, технической документации или исходном коде, уязвима, поскольку эти корпуса текстов повторяют одни и те же лингвистические шаблоны в десятках мест, не предоставляя механизма для различения этих повторений.
Средство лечения дешевое. Его стоимость измеряется в долларах за миллион токенов, и для его создания требуется всего одно сгенерированное предложение, написанное один раз во время построения индекса. В тестах Anthropic такой префикс сокращал количество неудачных поисков до 67%. Эта цифра скрывает определенную структуру, а случай использования, выбранный для демонстрации, впоследствии привлек противопример. Кроме того, существуют четыре настройки, при которых затраты трудно оправдать.
Краткое изложение основной идеи
Когда индекс разделяет документы на блоки по несколько сотен токенов, некоторые из этих блоков теряют свою тему и временные рамки. Фраза «Доход вырос на 3%» не указывает ни компанию, ни квартал, и ни одна модель встраивания не может восстановить эту информацию, поскольку она отсутствует в тексте.
Метод контекстуального поиска решает проблему один раз, во время индексации. Модели языка показывают полный документ вместе с одним фрагментом, после чего она генерирует короткий вступительный префикс длиной от пятидесяти до ста токенов, в котором указывается, что представляет собой фрагмент, кого он касается и когда.
Во многих кратких краткосодержаниях пропускается второй этап, который на самом деле является ключевым. Обогащённый текст подаётся в векторный индекс и в индекс BM25 — лексический ранжер, существовавший ещё до появления эмбеддингов и сопоставляющий точные слова, а не их смысл. Таким образом, одна процедура улучшает обе части поисковой системы, при этом затраты возникают только при индексации, а не с каждым запросом.
По результатам оценки компании Anthropic, один только префикс с эмбеддингами сократил количество неудачных поисков на 35%. Полная система с использованием BM25 и повторного ранжирования сократила их на 67%. Кэширование промптов позволяет сохранять низкие затраты, поскольку весь документ читается только один раз, а не заново для каждого фрагмента.
Эта техника не универсальна, и именно в этом её интерес. Во-первых, механизм и сам запрос.
Префикс, задающий идентичность фрагменту
Интуиция возникает раньше механики. Фрагмент, взятый из документа, подобен странице, вырванной из папки без заголовка, номера дела или даты. Если читать его изолированно, невозможно понять, у какой компании вырос доход и когда. Модель встраивания сталкивается с аналогичной ситуацией, только у неё нет способа это отметить.
Механизм восстанавливает отсутствующий заголовок. Во время индексации модель получает два входных данных — полный исходный документ и один из его фрагментов, — и у неё есть одна задача: написать краткий контекст, который поместит этот фрагмент в целое.
Запрос от Anthropic помещается в несколько строк:
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the
overall document for the purposes of improving search retrieval of the
chunk. Answer only with the succinct context and nothing else.
Если применить это к примеру фрагмента, результат может выглядеть так: «Этот фрагмент взят из документа SEC, касающегося результатов деятельности компании ACME Corp за второй квартал 2023 года; доход в предыдущем квартале составил 314 миллионов долларов». Сразу после этого следует предложение о росте на 3%. Примерно сто токенов преобразуют этот отдельный фрагмент в запись с ключом.
Затем обогащённый текст записывается в два индекса: один — индекс вкладок (Contextual Embeddings), другой — индекс ключевых слов (Contextual BM25). Благодаря указанию полного названия ACME в каждом фрагменте алгоритм BM25 может находить информацию о компании на любой странице отчёта, тогда как раньше о ней упоминалось только на титульном листе.
Это тоже не была первая попытка. Компания Anthropic ранее сообщала о экспериментах с общими резюме документов, привязанными к фрагментам, которые давали «очень ограниченную пользу», а также о методах HyDE и индексации на основе резюме, которые тоже оказались не очень эффективными (Anthropic, сентябрь 2024 г.). В итоге остался только префикс.
Различие между резюме и префиксом заключается в механизме их функционирования. Одно резюме используется для всех фрагментов документа, поэтому оно не может отличить фрагмент А от фрагмента Б в одном и том же годовом отчете, в то время как каждый префикс создается специально для своего местоположения в документе.
Корпуса данных, состоящие из отчетов, контрактов, технической документации или кодовой базы, где одна и та же лингвистическая структура встречается во многих местах, — именно там сегодня теряются фрагменты документов. Уже сам префикс для вкладки данных позволяет снизить количество ошибок на 35%, и это лишь первый уровень оптимизации.
Лестница внутри одного числа
Часто цитируется показатель «67%» как результат применения одной-единственной техники. Однако опубликованная таблица показывает другие данные; этот процесс лучше описывается как постепенное улучшение, а не как мгновенный скачок.
Результаты измеряются по формуле один минус recall@20 — это доля запросов, в которых правильный фрагмент не попал в топ-20. Компания Anthropic называет это коэффициентом неудач и приводит его для кодовых баз, художественных произведений, статей arXiv и научных публикаций.
Четыре конфигурации строятся друг на друге:
- Базовая конфигурация с обычными вкладками для сырых фрагментов: 5,7% запросов не удаются.
- Только с контекстуальными вкладками: 3,7%, что на 35% меньше благодаря самому префиксу.
- С добавлением контекстуального алгоритма BM25: 2,9%, что в сумме даёт снижение на 49%, причём дополнительный эффект достигается за счёт индекса ключевых слов.
- С добавлением функции переранжирования: 1,9%, именно отсюда берётся показатель 67%, благодаря последнему этапу обработки.
Модель переранкинга — это вторая модель, которая совместно обрабатывает запрос и кандидатские фрагменты. Она работает медленнее, чем при первом прохождении, но гораздо точнее. В данном случае она сократила количество кандидатов с 150 до двадцати. Все четыре показателя относятся к наиболее эффективной конфигурации встраивания в тесте — Gemini Text 004 — и не являются средним значением среди всех моделей встраивания, которые пробовались компанией Anthropic.
Такое разделение влияет на решение, а не только на описание процесса. Команда, которая уже использует гибридный поиск и переранкинг в производстве, может ожидать, что только контекстуализация позволит добиться показателя около тридцати пяти процентов вместо шестидесяти семи, поскольку два других уровня уже оплачиваются. Считать этот показатель единственным фактором — это распространенная ошибка; значительная часть снижения обусловлена обычной работой стандартных компонентов по поиску информации.
В треде на Hacker News приводится важное замечание: никто не опубликовал результатов работы простой версии алгоритма BM25 в том же тесте без какой-либо контекстуализации. Без этих данных невозможно определить, насколько рост эффективности до 49% обусловлен контекстом в лексическом индексе, а насколько — простым гибридным поиском.
Ловушка при цитировании цифр
Любой, кто цитирует эти результаты, также может попасть в ловушку расчётов. В руководстве Anthropic приводится более маленький набор данных, включающий девять кодовых баз и 248 запросов, оценённых по другому показателю: Pass@20 вырастает с 90% для базовой версии до 97% для полной системы. Разные корпуса, разные метрики, поэтому смешивание этих цифр с предыдущими — это просто ошибка.
Это снижение эффективности не бесплатно. Оно стоит денег при индексации, но один из механизмов позволяет сделать эту стоимость ближе к одному доллару, чем к тысяче.
Почему один доллар, а не тысяча
Рассмотрим наивный подход. Документ из 8 000 токенов делится на десять частей. Без какой-либо оптимизации при каждом запросе полностью перечитывается весь документ, поэтому одинаковый текст обрабатывается десять раз для описания десяти разных абзацев.
Именно такая стоимость мешала реализации этой идеи в течение многих лет. Люди считали её методом грубой силы и отклоняли её при составлении бюджета задолго до того, как была измерена её преимущества с точки зрения качества.
Кэширование промптов меняет расчёты в одном аспекте. Документ передаётся один раз в виде фиксированного префикса. Первый запрос влечёт за собой запись в кэш по цене примерно в 1,25 раза выше базовой, тогда как каждый последующий запрос к этому документу влечёт за собой чтение из кэша по цене примерно в десятую часть от базовой.
При средних размерах фрагментов и документов стоимость контекстуализации составляет 1,02 доллара за миллион токенов исходного текста. Эта цифра приводится вместе с параметрами, с которыми она рассчитывается — фрагментами по 800 токенов и документами по 8 000 токенов, для которых показатели стоимости встречаются крайне редко. Это позволяет пересчитать значения с использованием локальных данных вместо слепого доверия к имеющимся данным.
В примере из кулинарной книги, включающем 737 фрагментов, почти 62% токенов исходного текста были взяты из кэша. Общая стоимость снизилась с примерно 9,20 долларов до примерно 2,85 долларов. Улучшение качества модели не стало причиной экономии в два с половиной раза — причиной стало чтение документа всего один раз.
Деталь порядка, которая решает всё
Практический нюанс определяет, воплотится ли что-либо из этого в жизнь. Кэширование работает на основе совпадения префиксов, поэтому все фрагменты одного документа должны обрабатываться подряд, чтобы можно было повторно использовать одну запись кэша. Параллелизм между документами допустим — по одному рабочему на документ, — но смешивание фрагментов из нескольких документов в одной очереди недопустимо. Типичная наивная схема обработки распределяет фрагменты по общему пулу потоков, в результате чего кэш используется лишь эпизодически, и приходится платить полную стоимость.
К этой информации также стоит добавить предупреждение. Сумма в $1,02 отражает цены на модель 2024 года и не является постоянной величиной. Следующее поколение этой модели стоит в четыре раза дороже, поэтому использование этой цифры сегодня без пересчёта будет отражать устаревшую информацию.
С экономической точки зрения всё выглядит отлично для документов, предназначенных для подачи в SEC, именно такого типа документов и использовалось в качестве примера. Однако кто-то протестировал именно этот тип документов и получил противоположный результат.
Яркий пример, не прошедший собственное тестирование
Здесь начинается та часть, которую обычно пропускают в кратких обзорах.
В иллюстрации использовался фрагмент из документа, поданного в SEC, но список измеряемых доменов не включает такие документы. В нем упоминаются кодовые базы, художественная литература, arXiv и научные публикации, поэтому финансовые документы служат лишь примером для описания ситуации, а не тестовым корпусом.
Другие исследователи восполнили этот пробел и пришли к противоположному выводу. Инженеры Snowflake (Tarakad, Yu, Samdani, Merrick, март 2025 г.) использовали примерно 23 000 подлинных документов типа 10-K и 10-Q в качестве корпуса и оценивали эффективность своей системы на основе примерно 500 вручную составленных запросов.
Дополнение каждого фрагмента подробным, уникальным резюме, написанным моделью — что команда называла контекстуальным поиском — привело к снижению оценок на 5,8 балла для одной модели и на 0,4 — для другой. В итоге были потери, при этом затраты на вычисления значительно возросли.
Когда дешевые метаданные превосходят дорогую модель
Более интересным является то, что сработало в том же эксперименте. Введение метаданных на уровне документа — а именно названия компании, даты подачи и типа формы — позволило повысить точность ответов с примерно 50 до 60% до диапазона 72–75%, причем при этом вообще не использовалась языковая модель.
Этот контраст наглядно иллюстрирует урок. Проблема была реальной, поскольку алгоритм действительно не знал названия компании. Однако самое дешевое решение оказалось эффективнее самого дорогого, поскольку название компании остается неизменным на протяжении всей процедуры подачи документа, а для его добавления не требуется никакая модель.
Это сравнение не является точной репликацией, и об этом следует открыто говорить. Snowflake использовал собственные параметры запроса, модель встраивания, размер блоков данных и методы оценки, поэтому результаты нельзя сравнивать напрямую, как будто они получены с одного и того же инструмента. Тем не менее речь идет о одном и том же типе документов, и именно поэтому это сравнение имеет значение.
Ещё два результата снижают уровень энтузиазма. Исследование 2026 года, основанное на T²-RAGBench и не связанное с исследованием Snowflake, тестировало способность систем к контекстуализации финансовых документов с таблицами. Было установлено, что при плотном поиске улучшение показателя recall@5 составило 2,8 процентных пункта, а при гибридном поиске — 2,2 процентных пункта (arXiv). Это улучшение реально и воспроизводимо, но оно далеко не достигает 67%.
В том же тесте, включающем более 23 000 запросов к 7 318 документам, также был сделан вывод, который должен вызвать беспокойство у всех, кто работает с отчётами: большинство оставшихся ошибок связаны с несоответствиями в структуре таблиц. Текстовый префикс здесь не помогает, поскольку он лишь точно обозначает фрагмент, который остаётся неразборчивым.
Второй момент касается вычислительных ресурсов. В исследовании ConTEB (2025) метод в стиле Anthropic сравнивался с моделью эмбеддингов, обученной специально для этой цели. Обученная модель показала незначительно более высокие результаты в среднем и обрабатывала каждый документ примерно в сто раз быстрее (arXiv). Различия в качестве незначительны: подход с префиксами однозначно превосходит другие методы на некоторых наборах данных, таких как корпус страховых документов, но уступает им с небольшим отрывом на других. На самом деле обученная модель обеспечивает снижение затрат на вычисления.
Существует и альтернативный подход. Технология Late Chunking (Jina AI, сентябрь 2024 г.) решает ту же проблему на более низком уровне путем эмбеддингования всего документа и его разделения на части только после обработки с помощью трансформера, без использования языковой модели. Ее структурным недостатком является отсутствие дополнений в индекс ключевых слов, из-за чего теряется половина преимуществ, которые предоставляет метод Contextual BM25.
Для большинства корпусов корпоративных данных именно эта асимметрия, а не разница в метриках, скорее всего, определяет выбор. Это субъективное решение, и приводимый эталон ConTEB не тестирует его напрямую, поскольку BM25 не входит в список компонентов, оцениваемых им.
Как только пример, предназначенный для демонстрации, оказывается противопримером, возникает важный вопрос: где именно техника не оправдывает себя и как можно проверить конкретный корпус за пять минут.
Пять минут тестирования перед любыми расходами
Начните с тестирования, а не с реализации. Возьмите десять случайных фрагментов из индекса и прочитайте каждый из них по отдельности. Если можно сказать, о чем каждый фрагмент и откуда он взят, значит, у них уже есть контекст, и добавление префикса приведёт лишь к увеличению количества токенов, но не к получению дополнительной информации.
Для тестирования не требуется код, и оно занимает пять минут. Это также единственное доказательство, основанное на реальных данных, а не на данных кого-то другого.
Четыре задокументированных случая, когда эта техника не помогает:
- Корпус из менее чем двухсот тысяч токенов. Собственная рекомендация Anthropic для такого масштаба — включить всю базу знаний в запрос и полностью обойтись без поиска. Контекстуализация предназначена для ситуаций, когда корпус не помещается в окно контекста.
- Фрагменты, которые уже самостоятельны. Пары вопросов и ответов из FAQ, карточки продуктов и статьи словаря сами указывают на свою тему, поэтому префикс лишь повторяет её.
- Корпус, который часто меняется. Расходы возникают только один раз, если документы стабильны. Документы, пересматриваемые еженедельно, оплачиваются снова каждую неделю.
- Таблицы и финансовые отчеты. Если проблема заключается в структуре таблицы, а не в отсутствии названия компании, фрагмент описывается точно, но остается неразборчивым.
Форматирование вмещается в три строки. Небольшой, стабильный корпус подходит для длинных контекстов с использованием кэширования. Большой корпус с неоднозначными фрагментами подходит для контекстуального поиска. Короткие, самодостаточные записи подходят для обычного гибридного поиска без дополнительных затрат.
Порядок внедрения имеет значение, и именно это чаще всего приводит к разочарованию. Контекстуализация увеличивает ценность гибридного поиска, но не заменяет его. Команда, у которой отсутствуют технологии BM25 и механизмы переранжирования, должна сначала их внедрить; игнорирование этого порядка означает покупку третьего уровня, пока первый все еще отсутствует.
Рассчитайте затраты заранее, до внедрения, а не после. Формула известна, размеры фрагментов и документов также известны, и единственной настоящей неизвестной является то, действительно ли процесс достигает кэша.
Что взять с собой на обзор дизайна
Вернемся к первому предложению. Фраза «Доходы выросли на 3%» никогда не была неверной. В ней отсутствовал субъект. Решением не стало ни более совершенное моделирование, ни лучшее встраивание данных, а лишь добавление одного заголовка во время индексации.
- Как бы ни была сильна модель генерации ответов, фрагмент без контекста бесполезен. Причина заключается в процессе индексации, а не в галлюцинациях.
- Три метода вместе дают результат в 67%, а не один. Один только префикс уже приносит около тридцати пяти процентов, а гибридный поиск с переранжированием покрывает оставшуюся часть.
- Кэширование промптов сделало эту технику доступной, а не более сильную модель; экономия исчезает без обработки документов по отдельности.
- У типа документа, использованного в примере, существует задокументированный контрпример: в документах, предоставляемых SEC, дешевая метаинформация документов показала лучшие результаты, чем дорогое вызов модели для каждого фрагмента.
- Пятиминутная проверка реального индекса имеет большее значение, чем любая заголовочная новость. Прочитайте десять фрагментов по отдельности.
На практике это сводится к трём последовательным действиям: проведите тест на десять фрагментов, проверьте, соответствует ли корпус одному из четырёх отрицательных случаев, и только затем рассчитайте стоимость индексации с использованием опубликованной формулы. Бюджет требуется только на третий шаг, а первые два помогают определить, стоит ли его запрашивать.
Существует одно серьезное ограничение, которого невозможно избежать. Anthropic опубликовала разбивку результатов в приложении в виде статического PDF, а не в виде сырого набора данных, и независимые команды, пытавшиеся воспроизвести эти цифры, считают это проблемой воспроизводимости. Кроме того, крайне мало первичных оценок, проведенных на корпусах данных на языках, отличных от английского. Пока эти пробелы не будут устранены, все приведенные здесь данные основаны на конкретных условиях, а не на законах физики, причем сегодня больше всего не хватает измерений, полученных в процессе работы с корпусами данных на языках, отличных от английского.
Связанные материалы
- Практические рекомендации: переход от RAG к производственному использованию: проблемы на всех этапах на примерах реальных проектов — Подробное руководство по применению практических рекомендаций при переходе от технологии RAG к производственному использованию, включающее информацию о контрактах, проверках и готовых фрагментах кода для команд, внедряющих эту модель.