RAG и CAG, простое объяснение: кэширование промптов
Перевод поста Акшая о RAG vs CAG и полной статьи «Prompt caching, clearly explained» — о том, как кэширование промптов снижает стоимость и ускоряет агентные системы.
Перевод публикации Akshay 🚀. Оригинал: https://x.com/akshay_pachaar/status/2056714042455343160
RAG vs CAG — простое объяснение
RAG — отличная штука, но у него есть серьёзная проблема:
каждый запрос обращается к векторной базе данных. Даже за статической информацией, которая не менялась месяцами.
Это дорого, медленно и лишено необходимости.
Cache-Augmented Generation (CAG) решает эту проблему: модель может «помнить» статическую информацию напрямую в своей key-value (KV) памяти.
На практике RAG и CAG можно объединять, чтобы получить лучшее из обоих подходов.
Вот как это работает:
RAG + CAG делит ваши знания на два слоя:
- Статические данные — политики, документация — один раз кэшируются в KV-памяти модели.
- Динамические данные — свежие обновления, живые документы — подтягиваются через retrieval.
Это даёт более быстрый инференс, меньшие затраты и меньше дублирования.
Ключевой приём — избирательно подходить к тому, что вы кэшируете.
Кэшируйте только статичные, ценные знания, которые редко меняются. Если кэшировать всё подряд, вы упрётесь в лимиты контекста. Разделение данных на «холодные» — пригодные для кэша — и «горячие» — которые лучше получать через retrieval — делает систему надёжной.
Начать можно уже сегодня: OpenAI и Anthropic уже поддерживают prompt caching в своих API.
Ниже — моя недавняя статья о кэшировании промптов, если хотите разобраться глубже.
Вы уже пробовали CAG в продакшене?
Ниже я цитирую статью, которую написал о кэшировании промптов и о том, как Claude Code достигает 92% cache hit rate. Почитайте.
Кэширование промптов — простое объяснение
Кейс о том, как Claude достигает 92% попаданий в кэш
Каждый раз, когда AI-агент делает шаг, он платит налог.
Он заново перечитывает всё с нуля.
Системные инструкции. Определения инструментов. Контекст проекта, который он уже загружал три хода назад. Всё это. На каждом отдельном ходу.
Это и есть налог на контекст. А для долгих агентных workflow он часто становится самой дорогой строкой во всей AI-инфраструктуре.
Вот математика: системный промпт на 20 000 токенов, который работает 50 ходов, означает 1 миллион токенов избыточных вычислений, оплаченных по полной цене и не создающих никакой новой ценности.
Решение — кэширование промптов. Но чтобы использовать его правильно, нужно понимать, что на самом деле происходит под капотом.
Начните с того, что меняется, и того, что не меняется
Прежде чем что-либо оптимизировать, нужно ясно представить структуру промпта агента — его контекста.
Каждый запрос, который отправляет ваш агент, состоит из двух принципиально разных частей:
Статический префикс: системные инструкции, определения инструментов, контекст проекта, правила поведения. Этот контент идентичен на каждом ходу одной сессии.
Динамический хвост: сообщения пользователя, результаты работы инструментов, наблюдения из терминала. Это уникально для каждого запроса и растёт по мере развития разговора.
Это различие решает всё. Статический префикс — дорогая часть, которую вы снова и снова пересчитываете без причины. Динамический хвост — единственная часть, которой действительно нужны свежие вычисления.
Кэширование промптов работает так: математическое состояние статического префикса сохраняется, чтобы будущие запросы могли полностью пропустить его повторное вычисление. Вы платите за обработку этого префикса один раз. Каждый следующий ход читает его из памяти.
Почему это работает: что на самом деле делает трансформер
Чтобы по-настоящему понять, почему кэширование так эффективно, нужно понимать, что происходит внутри модели, когда она читает ваш промпт.
У каждого inference-запроса к LLM есть две фазы:
Фаза 1: Prefill
На этой фазе модель обрабатывает весь входной промпт. Она ограничена вычислениями: выполняет плотные матричные умножения по каждому токену в контексте. Модель читает всё и строит представление этого контекста. Это медленная и дорогая фаза.
Фаза 2: Decode
На этой фазе модель генерирует выходные токены — по одному за раз. Здесь ограничение уже не столько в вычислениях, сколько в памяти: модель большую часть времени читает ранее вычисленное состояние, а не выполняет тяжёлые расчёты.
Во время фазы prefill трансформер строит для каждого токена три вектора: Query, Key и Value. Механизм внимания использует их, чтобы определить, как каждый токен связан со всеми остальными токенами в последовательности.
Ключевое наблюдение вот в чём: векторы Key и Value зависят только от токенов, которые были до них. После того как они рассчитаны для конкретного префикса, их больше не нужно менять.
Иллюстрация ниже наглядно объясняет то, что мы только что обсудили:
Без кэширования эти Key-Value тензоры выбрасываются сразу после завершения запроса. Следующий запрос начинается с нуля и снова пересчитывает их для всех 20 000 токенов.
KV-кэширование решает эту проблему, сохраняя эти тензоры. Инфраструктура держит их на inference-серверах и индексирует по криптографическому хэшу входного текста. Когда приходит новый запрос с тем же префиксом, хэш совпадает, тензоры немедленно извлекаются, и модель пропускает все эти вычисления.
Это снижает вычислительную сложность с O(n²) на каждый сгенерированный токен до O(n). Для префикса в 20 000 токенов, повторённого на 50 ходах, это огромная экономия.
Экономика
Понимание структуры цен — то, что делает это архитектурное решение настолько важным.
Вот как Anthropic оценивает кэширование в разных семействах моделей:
Три числа, которые стоит запомнить:
- Чтение из кэша стоит 10% от базовой цены входных токенов — скидка 90% на каждый токен, прочитанный из кэша.
- Запись в кэш стоит на 25% дороже базовой цены входных токенов — небольшая надбавка за сохранение KV-тензоров.
- Расширенное кэширование на 1 час стоит 2× базовой цены.
Математика сходится только если доля попаданий в кэш остаётся высокой. И это подводит нас к лучшему реальному примеру того, как это выглядит на практике.
Claude Code: разбор 30-минутной сессии
Claude Code построен вокруг одной цели: держать кэш горячим.
Чтобы понять, что это означает на практике, пройдёмся по типичной 30-минутной coding-сессии и точно отследим, за что выставляется счёт, а за что нет.
Минута 0: старт сессии
Claude Code загружает системный промпт и определения инструментов. Он также читает файл CLAUDE.md в корне вашего проекта — там описаны кодовая база и соглашения. Такой payload регулярно превышает 20 000 токенов.
Это самый дорогой момент всей сессии. Каждый токен новый. Но вы платите эту цену только один раз.
Минуты 1–5: первые команды
Вы вводите первую инструкцию — например: «посмотри auth-модуль и предложи улучшения».
Claude Code запускает Explore Subagent. Он перемещается по кодовой базе, открывает файлы, выполняет grep-команды и формирует картину релевантного кода. Всё это добавляется в динамический хвост.
А статическая основа на 20 000 токенов? Уже в кэше. Она читается обратно по $0.30/MTok вместо $3.00/MTok. Вы платите только за новые outputs инструментов и своё сообщение.
Минуты 6–15: глубокая работа
Plan Subagent получает результаты от Explore Subagent. Вместо того чтобы передавать сырые результаты дословно — что без необходимости раздуло бы динамический хвост, — Claude Code передаёт краткое резюме. Так suffix остаётся управляемым, а кэш — эффективным.
Планировщик создаёт структурированный план реализации. Вы просматриваете его, одобряете, и Claude Code начинает вносить изменения. Каждый ход в этом цикле читает 20 000-токенный префикс из кэша. Каждое попадание в кэш сбрасывает TTL, поддерживая кэш тёплым для будущих ходов.
Минуты 16–25: итерации
Вы просите внести корректировки. Claude Code пересматривает подход. Больше вызовов инструментов, больше вывода из терминала. Динамический хвост растёт, но он представляет только новый, уникальный контент этой сессии.
К этому моменту сессия уже обработала сотни тысяч токенов суммарно. Но 20 000-токенная основа на каждом ходу читалась из кэша.
Минута 28: запуск /cost
Без кэширования такая сессия легко переваливает за 2 миллиона токенов. По тарифам Sonnet 4.5 это около $6.00.
При эффективном кэшировании:
- подавляющее большинство токенов читается из кэша по $0.30/MTok;
- заново вычисляются только новые токены динамического хвоста.
На практике можно ожидать снижения стоимости одной задачи примерно на 80%+. А теперь умножьте это на каждого пользователя, каждый день.
Если подытожить, вот как выглядит layout системного промпта по мере продолжения сессии:
Правило, которое ломает всё
Вот самая контринтуитивная вещь в кэшировании промптов.
1 + 2 = 3. Но 2 + 1 — это cache miss.
Инфраструктура хэширует промпт. Хэш — это криптографический идентификатор. Он меняется, если меняется что-либо в порядке элементов, даже если это просто те же два элемента, переставленные местами. Кэш пуст. Весь префикс пересчитывается по полной цене.
Из этого следуют три правила:
- Не добавляйте и не убирайте инструменты во время сессии. Кэшированный префикс включает инструменты. Изменение набора инструментов делает всё, что идёт после него, бесполезным для кэша.
- Никогда не переключайте модели посреди сессии. Кэши привязаны к конкретной модели. Переход на более дешёвую модель в середине разговора требует заново построить весь кэш.
- Никогда не меняйте префикс, чтобы изменить состояние. Вместо этого Claude Code добавляет тег к следующему сообщению пользователя, который напоминает системе нужную информацию. Префикс не меняется.
Что это означает для вас
Всё выше объясняет, как Claude Code работает с кэшированием. Те же правила применимы, если вы создаёте собственного агента.
Вот как стоит структурировать промпты:
- Вверху — системные инструкции и правила. Не меняйте их посреди сессии.
- Заранее загрузите все инструменты, которые понадобятся. Не добавляйте и не убирайте их.
- После этого — retrieved context и документы. Статичные на время сессии.
- Внизу — история разговора и outputs инструментов.
При включённом auto-caching точка break-point автоматически движется вперёд по мере продолжения разговора.
Claude Code сам управляет своим кэшем. Anthropic только что добавила auto-caching в свой API, так что вы можете сделать то же самое для собственного агента.
Без auto-caching вам приходилось помнить, где находятся границы токенов. Неправильная граница означала, что вы не попадали в кэш.
Используйте cache-safe forking, чтобы сжимать контекст при приближении к лимиту. Используйте тот же системный промпт, инструменты и разговор, а затем добавляйте compaction как новое сообщение.
Вызов compaction выглядит почти так же, как предыдущий. Кэшированный префикс используется снова. Единственное, что оплачивается как новое, — инструкция на compaction.
Чтобы понять, работает ли API как нужно, следите за этими тремя полями в каждом ответе:
- cache_creation_input_tokens: токены, помещённые в память.
- cache_read_input_tokens: токены, прочитанные из памяти.
- input_tokens: токены, обработанные обычным образом.
Оценка эффективности кэша — это количество прочитанных из кэша токенов по сравнению с количеством токенов, использованных для создания кэша. Следите за ней так же, как следите за uptime.
Главные выводы
Кэширование промптов — это не функция, которую просто включают. Это архитектурная дисциплина, вокруг которой строят систему.
Claude Code — лучший пример того, как это выглядит, когда сделано в большом масштабе.
Доля попаданий в кэш — 92%. Снижение затрат — 81%.
Это blueprint для тех, кто создаёт агентов. Налог на контекст нельзя игнорировать — он существует. Важно только одно: платите ли вы его или избавляетесь от него.