19 сентября 2024 года Anthropic опубликовала инженерный разбор Contextual Retrieval — приёма для систем retrieval-augmented generation (RAG), который меняет не модель-ответчик, а то, как документы попадают в индекс. Базовая идея проста: перед созданием эмбеддингов и BM25-индекса каждому чанку добавляют короткое пояснение, сгенерированное по всему документу. Для практиков это важно потому, что многие промахи RAG возникают не из-за слабой LLM, а из-за того, что ретривер видит обезличенный фрагмент без указания автора, даты, сущности или роли раздела.
Коротко
- Contextual Retrieval — это preprocessing на этапе индексации. Он не заменяет RAG, а добавляет каждому чанку «ситуирующий» контекст перед embeddings и BM25.
- Главный эффект — меньше промахов ретривера. По данным Anthropic, усреднённо по протестированным источникам Contextual Embeddings снизили долю неудачных top-20 retrieval на 35%; в посте компании также заявлены 49% для связки с Contextual BM25 и 67% для связки с reranking.
- Публичный cookbook показывает практический выигрыш на кодовых базах. В демонстрационном ноутбуке Anthropic для 9 codebases и 248 запросов Pass@10 вырос с 87.15% до 92.34% после contextual embeddings и до 95.26% после reranking.
- Исторический и текущий артефакты не совпадают дословно. В анонсе от 19 сентября 2024 года указан Claude 3 Haiku для генерации контекста, а в версии cookbook, доступной 13 августа 2026 года, в коде стоит alias
claude-haiku-4-5. - Важно не переоценивать метод. Улучшение retrieval не гарантирует пропорционального улучшения финального ответа: это показывают и работы о long context, и исследования о «sufficient context» в RAG.
Контекст: какую проблему решает Contextual Retrieval
Классический RAG, в формулировке работы Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, строится так: документы индексируются, по запросу находится набор релевантных фрагментов, а затем модель отвечает с опорой на них. На практике это почти всегда означает разрезание документов на чанки, потому что целиком индексировать и подмешивать большие документы дорого и неудобно.
Проблема в том, что при разрезании теряется локальный смысл. Фраза вроде «рост составил 3% по сравнению с прошлым кварталом» без имени компании, периода и типа отчёта оказывается слабым объектом для поиска. Anthropic в инженерном посте называет это центральным изъяном традиционного RAG: система убирает контекст именно в тот момент, когда пытается сделать поиск эффективным.
Альтернатива «просто дать модели больше текста» тоже не всегда работает. Lost in the Middle показывает, что модели хуже используют релевантную информацию, если она затеряна внутри длинного контекста. Работа In Defense of RAG in the Era of Long-Context Language Models отдельно указывает на типичный компромисс: по мере добавления чанков качество ответа сначала растёт, а потом падает, потому что лишние фрагменты начинают отвлекать модель.
Метод: что именно сделала Anthropic
Суть Contextual Retrieval не в новом ретривере, а в новом представлении чанка. Вместо того чтобы индексировать фрагмент в изоляции, система сначала просит LLM кратко описать место этого фрагмента в полном документе, а затем добавляет это описание к самому чанку.
<document>полный документ</document>
<chunk>текущий чанк</chunk>
Сформируй короткий контекст, который объясняет, что это за фрагмент,
к какому объекту, периоду или разделу он относится и почему он важен для поиска.
Верни только этот контекст.В посте Anthropic от 19 сентября 2024 года сказано, что для генерации такого контекста использовался Claude 3 Haiku, а сам префикс обычно добавлял 50–100 токенов на чанк. В версии cookbook, опубликованной 13 сентября 2024 года и доступной 13 августа 2026 года, пример кода уже использует alias claude-haiku-4-5. Это важная историческая оговорка: сама идея метода не меняется, но воспроизводимая реализация в публичном notebook со временем обновляется.
- Разбивка документа. Документ режется на чанки.
- Ситуирование чанка. LLM читает полный документ и пишет короткое описание для конкретного фрагмента.
- Контекстуализация. Это описание добавляется к исходному чанку.
- Индексация. Контекстуализированный текст идёт и в векторный индекс, и в лексический индекс BM25.
- Поиск и при необходимости reranking. На запросе можно искать по embeddings, по BM25, объединять результаты и затем переупорядочивать кандидаты.
Почему это работает технически? Потому что к фрагменту возвращаются скрытые якоря: сущность, время, тип документа, название раздела, предмет обсуждения. Для embeddings это делает вектор более содержательным. Для BM25 это добавляет ключевые слова и точные маркеры, которых не было в самом кусочке текста.
В cookbook Anthropic показана конкретная реализация гибридного поиска: система берёт top-150 результатов из semantic search и top-150 из BM25, затем объединяет их через weighted Reciprocal Rank Fusion с весами 80% для semantic и 20% для BM25. Это не обязательная часть самой идеи Contextual Retrieval, а публичный reference-пайплайн.
С reranking есть ещё одна тонкость. В инженерном посте лучший результат описан как связка Contextual Embeddings + Contextual BM25 + reranking, где сначала поднимают 150 кандидатов, а в модель передают итоговые 20. Но в текущем cookbook reranking сделан проще: он строится только поверх contextual embeddings, без полного hybrid pipeline, и сначала достаёт k*10 кандидатов, а затем использует rerank-english-v3.0 от Cohere.
Результаты
У Anthropic есть как минимум два публичных набора результатов, и их нельзя смешивать без оговорок. Инженерный пост показывает кросс-доменную оценку по нескольким типам корпусов и использует метрику 1 – recall@20, то есть долю случаев, когда нужный фрагмент не попал в top-20. Cookbook показывает отдельную демонстрацию на 9 кодовых базах с метрикой Pass@k.
Кросс-доменные числа из анонса Anthropic
| Настройка | Метрика | Результат | Как читать |
|---|---|---|---|
| Базовый retrieval | 1 – recall@20 | 5.7% | Доля случаев, где релевантный чанк не попал в top-20 |
| + Contextual Embeddings | 1 – recall@20 | 3.7% | Снижение failure rate на 35% |
| + Contextual Embeddings + Contextual BM25 | 1 – recall@20 | 2.9% | По данным самого поста Anthropic, снижение на 49% |
| + Contextual Embeddings + Contextual BM25 + reranking | 1 – recall@20 | 1.9% | По данным самого поста Anthropic, снижение на 67% |
Для этих графиков Anthropic использовала корпуса четырёх типов — codebases, fiction, arXiv papers, Science papers — и, по внутренней оценке компании, лучшую из протестированных конфигураций эмбеддингов, Gemini Text 004. Важно: именно числа 49% и 67% доступны нам только из поста компании, поэтому их корректно читать как заявление Anthropic о собственной оценке, а не как независимо подтверждённый бенчмарк.
Демонстрационный notebook Anthropic на кодовых базах
| Подход | Pass@5 | Pass@10 | Pass@20 |
|---|---|---|---|
| Baseline RAG | 80.92% | 87.15% | 90.06% |
| + Contextual Embeddings | 88.12% | 92.34% | 94.29% |
| + Contextual BM25 hybrid search | 88.86% | 92.31% | 95.23% |
| + Reranking поверх contextual embeddings | 92.15% | 95.26% | 97.45% |
Этот notebook использует 9 codebases, 248 queries и заранее подготовленный набор «golden chunks». В raw-версии notebook также видно, что в датасете обрабатывается 737 chunks. Важно и другое: текущая страница cookbook содержит внутреннее несоответствие. Исполненный вывод ячеек для hybrid search показывает 88.86 / 92.31 / 95.23, а более поздняя markdown-сводка на той же странице — 86.43 / 93.21 / 94.99. В статье выше использованы числа из stdout notebook, потому что они привязаны к конкретному запуску внутри опубликованного артефакта.
Из двух публичных материалов устойчиво повторяется одно и то же наблюдение: добавление контекста к чанкам само по себе даёт основной прирост. Это видно и в среднем результате на разных доменах, и в codebase-демонстрации Anthropic.
Интерпретация
Наш комментарий
С инженерной точки зрения Contextual Retrieval — это удачный пример index-time intelligence: вы тратите токены один раз при загрузке корпуса, чтобы уменьшить число промахов на каждом последующем запросе. Это отличается и от long-context стратегии «засунуть всё в prompt», и от query-time трюков вроде HyDE, где вычисление происходит на каждом поиске.
Особенно логично метод выглядит там, где локальные фрагменты плохо понятны без окружения: в кодовых базах, отчётах, договорах, RFC, policy-документах, технической документации, инцидентных постмортемах. В таких корпусах короткий чанк часто содержит местоимения, ссылки на внутренние сущности, аббревиатуры и номера разделов. Контекстуализация превращает такой фрагмент в более самодостаточную единицу поиска.
Есть и более тонкий эффект. Обычный hybrid search сочетает семантический и лексический сигнал уже после индексации. Anthropic делает шаг раньше: сначала улучшает сам объект индексации, а уже потом применяет hybrid search и reranking. Поэтому метод совместим почти с любым зрелым RAG-стеком: заменить нужно не всю архитектуру, а ingestion pipeline.
Ограничения и критика
- Основные свидетельства — от самой Anthropic. Инженерный пост и cookbook полезны, но это не рецензируемая статья и не независимая репликация. В использованных нами источниках нет отдельной внешней работы, которая бы воспроизвела headline-результаты Anthropic на том же наборе доменов и с той же методикой.
- Нельзя напрямую сравнивать все опубликованные числа. Пост использует 1 – recall@20 на нескольких доменах, cookbook — Pass@k на codebases. Это разные наборы данных, разные метрики и разные пайплайны.
- Публичный cookbook изменяем. Между анонсом 2024 года и версией, доступной 13 августа 2026 года, в коде поменялись модельные alias и окружение примера. Для исторического разбора важно не подменять анонс поздней редакцией notebook.
- Есть документальная несогласованность внутри самого notebook. У hybrid search расходятся числа в stdout и в итоговой markdown-сводке. Для практической репликации это сигнал: смотреть нужно не только текстовые выводы, но и сырые результаты ячеек.
- Retrieval quality не равна answer quality. Работа Sufficient Context показывает, что ошибки RAG связаны не только с поиском: даже при достаточном контексте модели могут ошибаться, а при недостаточном — отвечать вместо отказа. Lost in the Middle и In Defense of RAG дополнительно напоминают, что лишние фрагменты могут ухудшать использование контекста на стадии генерации.
- У метода есть технические компромиссы. Контекстуализация увеличивает размер индексируемого текста, а cookbook отдельно предупреждает о риске усечения, если embedding-модель имеет жёсткий лимит входа. Reranking даёт дополнительное качество, но добавляет отдельный runtime-шаг и внешнюю зависимость.
Вывод
Contextual Retrieval от Anthropic — не новый класс модели и не «магия long context», а аккуратный инженерный приём: вернуть чанку ту информацию, которую система сама же потеряла при разрезании документа. Внутренние результаты Anthropic выглядят убедительно именно как аргумент за более умный ingestion в RAG. Но практический вывод должен быть трезвым: метод стоит тестировать в своём корпусе, своей схеме chunking, со своими embeddings и своей метрикой ответа, а не только метрикой retrieval.
Источники
- Anthropic — Introducing Contextual Retrieval (2024)
- Claude Cookbook — Enhancing RAG with contextual retrieval (2024)
- anthropics/claude-cookbooks — capabilities/contextual-embeddings/guide.ipynb
- Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020)
- Liu et al. — Lost in the Middle: How Language Models Use Long Contexts (2023)
- Yu, Xu, Akkiraju — In Defense of RAG in the Era of Long-Context Language Models (2024)
- Joren et al. — Sufficient Context: A New Lens on Retrieval Augmented Generation Systems (2024)
FAQ
Это альтернатива BM25 и embeddings?
Нет. В версии Anthropic Contextual Retrieval не заменяет ни embeddings, ни BM25. Он улучшает сам текст, который идёт в оба индекса.
Чем это отличается от summary indexing?
Здесь к каждому чанку добавляется локальный контекст именно для этого чанка, а не один общий summary на документ. Поэтому сохраняется точность привязки к конкретному фрагменту.
Нужен ли reranking, если уже есть contextual embeddings?
Не всегда. И пост Anthropic, и cookbook показывают, что основной выигрыш часто приходит уже после contextual embeddings. Reranking полезен, когда вы готовы платить дополнительной сложностью и задержкой ради последних процентов качества retrieval.
Заменяет ли Contextual Retrieval длинное окно контекста?
Скорее нет. Это другой компромисс. Long context уменьшает потребность в агрессивном retrieval, а Contextual Retrieval повышает качество самого поиска. На практике оба подхода нередко комбинируют.