CAG

Суть

RAG ищет релевантные чанки на каждый запрос. CAG один раз «прогревает» контекст: весь корпус загружается в окно, attention-состояния (K/V) кэшируются, дальше запросы обрабатываются по готовому кэшу без retrieval. Стало возможным благодаря длинным контекстным окнам (200K–1M+ токенов).

Зачем это нужно

Убирает retrieval-latency и ошибки выбора документов, упрощает стек (нет векторной БД, чанкинга, реранкера). Модель видит корпус целиком → лучше связывает факты, не теряет фрагмент на этапе поиска. Но применимо, только если база влезает в окно и редко меняется.

Как работает

• Prefill (один раз): весь корпус токенизируется и прогоняется через модель; ключи/значения (K/V) каждого слоя сохраняются как KV-кэш (KV Cache) на диск/в память.
• Запрос: модель не пересчитывает attention по всей базе — читает готовый KV-кэш, вычисляет только токены запроса (cross-attention к предвычисленному контексту). Отсюда субсекундный инференс на повторных запросах.
• Cache reset: после ответа токены запроса/ответа отсекаются → кэш возвращается в исходное состояние для следующей сессии без повторного prefill.
• Опирается на длинный контекст (Context Window) и prefix/KV-кэширование (Prompt Caching).

Ограничения (когда CAG не подходит)

• Статичность: любое изменение источника → инвалидация и пересчёт всего KV-кэша (дорогой prefill) → не для динамичных данных (котировки, склад).
• VRAM/масштаб: несжатый KV для ~1M токенов ≈ 20+ ГБ; нужен предел размера базы (ориентир < ~500K–1M токенов), иначе дорогие GPU или агрессивное квантование кэша (с потерей точности).
• «Lost-in-the-middle»: факты в середине длинного контекста извлекаются хуже, чем на краях.
• Слабая source attribution: ответ из диффузного внимания по всему тексту → труднее цитировать конкретный фрагмент, чем у RAG (ссылки на чанки).
• Безопасность: вся база постоянно в активной памяти → риск context poisoning.

Пример

Стабильный корпоративный регламент / мануал (< размера окна, меняется редко): один prefill → KV-кэш на диск → тысячи запросов с субсекундным ответом без векторной БД. При правке регламента — пересборка кэша.

Частичная инвалидация кэша: чем это решается

Сверка 2026-08. Корень проблемы в авторегрессивности: изменение одного токена обесценивает кэш всё, что идёт после него, поэтому наивный ответ — пересчитывать хвост — и оказывается дорогим ровно тогда, когда база большая. Направления работ два, и они предполагают разную цену внедрения.

Селективный пересчёт на инференсе. Кэш переиспользуется целиком, а пересчитывается небольшое подмножество токенов — те, у которых из-за изменения контекста «поехало» перекрёстное внимание. Так устроены CacheBlend и родственные подходы; они не требуют трогать модель и потому применимы поверх готового рантайма.

Модульный кэш вместо префиксного. Второе направление отказывается от требования, чтобы переиспользуемая часть была именно префиксом: сегменты кэшируются независимо и собираются в нужном порядке (PromptCache и работы про обобщённое переиспользование, которое обсуждается и в vLLM). Это ближе всего к тому, что нужно CAG: база знаний естественно распадается на независимые документы, и обновление одного не должно инвалидировать остальные.

Через дообучение. Третий путь — KVLink, Block-Attention, CacheClip — учит модель терпимее относиться к склейке независимо посчитанных сегментов. Работает лучше, но требует дообучения, то есть выходит за рамки «поставил и пользуюсь».

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

Связано с

• RAG — retrieval на запрос vs предзагруженный кэш; CAG — альтернатива для small/stable
• Agentic RAG — третий подход кластера: итеративный агентный retrieval (vs предзагруженный кэш CAG)
• RAG vs CAG vs Agentic RAG — критерии выбора между тремя подходами
• KV Cache — механизм, на котором стоит CAG (кэш K/V)
• Context Window — CAG возможен только если корпус влезает в окно
• Prompt Caching — родственный приём (кэш префикса промпта)
• Semantic Cache — кэш готовых ответов; инвалидация там точечная, по тегу, а не пересчётом целиком