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-кэш на диск → тысячи запросов с субсекундным ответом без векторной БД. При правке регламента — пересборка кэша.

Связано с

• 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 — родственный приём (кэш префикса промпта)

Открытые вопросы

• практический порог размера базы для CAG на доступном железе (VRAM vs длина контекста)?
• стратегии частичной инвалидации/обновления KV-кэша без полного пересчёта?