Зачем готовить документы заранее и чем это отличается от RAG
Когда десятки сотрудников день за днём обращаются к одному относительно стабильному справочнику, в основе всех их диалогов с моделью лежит один и тот же базовый текст. Подготовка этого текста нужна не ради какого-то одного ответа — к ней можно возвращаться при самых разных запросах. И здесь расходятся два маршрута работы с источником.
Посмотрим на первый вопрос сотрудника: «Как подать заявку на отпуск?». В более привычном подходе RAG (Retrieval-Augmented Generation) конкретные фрагменты справочника под запрос отбирают после того, как вопрос уже прозвучал. Сначала поисковый механизм выбирает в справочнике фрагменты, подходящие к теме отпуска. Этот отбор может работать как обычный текстовый поиск по совпадению слов (например, алгоритм BM25) или как векторный поиск по смысловой близости. Затем найденные абзацы передают языковой модели вместе с вопросом, и модель генерирует ответ.
В подходе CAG, описанном авторами исходной статьи и репозитория, последовательность действий другая. Подходящий набор документов ( в нашем примере весь справочник целиком) загружают в контекст модели и обрабатывают заранее, ещё до появления пользовательских запросов. Когда сотрудник спрашивает про заявку на отпуск, отдельный поиск по документам не запускается: новый вопрос сразу поступает к модели, у которой уже есть подготовленное состояние справочника, и модель на этой основе генерирует ответ.
Оба маршрута доставляют модели сведения из справочника, но по-разному организуют их подачу к моменту вопроса. Само по себе это различие описывает устройство процесса, а не доказывает, что один способ всегда быстрее, дешевле или качественнее другого.
Оба подхода не исключают друг друга. Авторы исследования о CAG прямо предлагают гибридный вариант: базовый набор документов можно подготовить заранее, а выборочный поиск подключать только для редких случаев или специфических запросов. В самой работе такая схема предложена как архитектурная возможность, но отдельно в экспериментах не измерялась. В то же время возможность комбинировать подходы не означает, что без поиска нельзя обойтись при любом крупном или меняющемся источнике.
Если в CAG поиск под каждый запрос не выполняется, а ответ всё равно формулируется под конкретный вопрос, разберём, что именно система сохраняет после предварительной обработки справочника и как это помогает отвечать на следующие, совершенно другие вопросы.
«Как подать заявку на отпуск?»
Вопрос сотрудника о порядке отпуска.
Два самостоятельных маршрута ответа на один вопрос
RAG
Поиск под вопрос
Справочник сотрудников
Источник для выбора фрагментов.
После получения вопроса
Выбрать нужные абзацы
По словам или векторной близости.
Найденные фрагменты справочника
Модель составляет ответ
Новый текст по вопросу
CAG
Общая подготовка заранее
До появления вопросов
Правила и справочник целиком
Подходящий набор, который помещается в контекст.
Подготовленное KV-состояние
Сохранённые вычисления для правил и справочника.
После получения вопроса
- KV-состояние из подготовки → модели
- Новый вопрос об отпуске → модели
Модель составляет ответ
Новый текст по вопросу
В CAG повторно используют вычисления для входного текста. Веса модели при этом не меняются; готовый ответ заранее не хранится.
Что хранится в KV-кеше и как появляется новый ответ
Если вопросы сотрудников ещё не заданы, заготовить на них готовые ответы нельзя. Чтобы понять, что именно система сохраняет заранее, разделим роли участников процесса. Приложение передаёт текст справочника языковой модели и сохраняет результат его первичной обработки в виде состояния, пригодного для повторного использования. Модель использует это состояние, чтобы обработать конкретный вопрос и сгенерировать ответ. Сотрудник получает сформулированный ответ на свой запрос.
Здесь работают три связанных понятия:
- Контекст — это весь входной объём текста, который доступен модели при обработке запроса: системные инструкции, текст справочника и сам вопрос человека.
- Префикс — неизменная начальная часть этого контекста. В нашем примере префиксом выступают системные правила и текст справочника сотрудников, которые одинаковы для всех обращений.
- KV-кеш (key-value cache) — сохранённые промежуточные математические состояния механизма внимания (ключи и значения), которые модель вычисляет для каждого фрагмента текста при чтении контекста.
Когда приложение заранее прогоняет справочник через модель, та проходит по всему тексту префикса и рассчитывает для него состояния внимания. Именно эти промежуточные вычисления сохраняются в KV-кеше. Как устроено такое сохранение состояний, подробно описано в документации Hugging Face и OpenAI. KV-кеш — это не коллекция заранее написанных ответов, не обычный архив текстовых файлов и не универсально переносимый между разными моделями пакет знаний. В нём лежат внутренние расчёты конкретной модели для уже прочитанного начала входа.
Посмотрим, что происходит дальше, когда в систему приходит второй, независимый от первого вопрос: «Как подать расходы после командировки?». Источник сведений остаётся прежним, но тема запроса изменилась, поэтому старый ответ об отпуске здесь не подойдёт.
Приложению не нужно заново прогонять через модель весь справочник: в активной ветке эталонной реализации CAG подготовленное состояние уже находится в памяти. Хотя при первичной подготовке кеш может записываться и в файл на диске, во время ответов на вопросы система работает с состоянием в оперативной памяти, не перечитывая файл на каждом запросе.
Модель берёт этот готовый KV-кеш префикса, достраивает вычисления только для нового вопроса о командировке и шаг за шагом генерирует новые токены ответа. Кеш не отменяет генерацию и сам по себе не гарантирует безошибочный ответ.
Пока модель читает вопрос об отпуске и генерирует ответ на него, новые вычисления дописываются в конец общего состояния — после подготовленного префикса образуется накопленный «хвост» конкретного диалога. Если оставить его на месте, следующий независимый вопрос о командировочных расходах пойдёт поверх чужого диалога. Поэтому в исходной работе и её программном коде перед каждым новым независимым вопросом выполняется сброс (clean_up): система обрезает накопленный хвост вопроса и ответа обратно до исходной длины подготовленного справочника. В результате в памяти остаётся только чистая базовая подготовка префикса.
Такой возврат к исходной длине префикса решает узкую техническую задачу внутри эталонной реализации, но у него есть чёткие границы. Во-первых, обрезка хвоста не обновляет сам справочник, если в компании изменились правила, и сама по себе не доказывает безопасность, изоляцию разных пользователей или разграничение прав доступа. Во-вторых, вся описанная работа со справочником происходит исключительно на этапе генерации (inference) без изменения весов нейросети: сохранение KV-кеша не обучает модель и не означает, что она «поняла» или навсегда выучила документ. Наконец, сам по себе этот механизм — в отличие от полноценных систем долговременной памяти — не решает, какие сведения из диалогов с пользователями нужно отбирать, обновлять и переносить в будущие сессии, хотя сами системы памяти тоже могут использовать кеширование как один из инструментов.
В CAG сочетаются заранее вычисленное состояние источника и генерация нового ответа. На практике рядом постоянно звучат похожие понятия: передача полного текста в окно модели, prompt caching у облачных провайдеров и кеширование готовых ответов. Разберёмся, чем эти механизмы отличаются друг от друга по своей задаче.
Системные правила и справочник
Модель заранее обрабатывает текст одной редакции.
Подготовленный префикс
KV-состояние правил и справочника. Вопросов и ответов здесь ещё нет.
Далее — два независимых вопроса в эталонной реализации CAG.
Тот же префиксПравила + справочник
Первый вопрос
«Как подать заявку на отпуск?»
Модель генерирует новый ответ.
В хвост дописываются вычисления вопроса и ответа.
Удалить только хвост
clean_up возвращает состояние к длине подготовленного префикса.
Тот же префиксПрежняя редакция
Вычисления первого вопроса и ответа удалены.
Тот же префиксПравила + справочник
Следующий вопрос
«Как подать расходы после командировки?»
Модель генерирует другой ответ.
Новый хвост содержит вычисления только этого вопроса и ответа.
Если изменился справочник
Новый текст → обработка моделью → подготовленное состояние для новой редакции.
Сброс хвоста не добавляет правки документа в старый кеш. Неизменившееся начало в некоторых схемах можно использовать повторно.
Это работа с вычислениями входа, без обучения весов. Подготовка требует ресурсов; сроки хранения и правила кеширования зависят от реализации.
Чем CAG отличается от полного контекста и других кешей
Когда говорят о работе по всему справочнику сразу и об экономии вычислений, возникает естественный вопрос: разве CAG — это не то же самое, что просто отправлять весь текст документа в каждом запросе или возвращать заранее сохранённый ответ?
Путаница возникает потому, что похожими словами называют разные этапы работы с запросом: состав входных данных, повторное использование промежуточных вычислений и возврат готового текста ответа. Разделим четыре соседних понятия по двум единым критериям: что именно система использует повторно и что происходит при поступлении нового вопроса.
| Подход или механизм | Что используют повторно | Что происходит при новом вопросе |
|---|---|---|
| Полный контекст без повторного использования вычислений | Те же исходные тексты документов | Текст справочника и новый вопрос заново проходят полный цикл вычислений модели, после чего генерируется новый ответ |
| CAG | Заранее вычисленное состояние (KV-кеш) подготовленного набора документов | Модель обрабатывает новый вопрос поверх готового состояния справочника и генерирует новый ответ |
| Prompt caching (кеширование префикса) | Вычисленное состояние совпадающего начала запроса (инструкций, примеров, документов или истории) | Модель досчитывает только изменившуюся часть входа и генерирует новый ответ |
| Семантический кеш ответов (на примере механизма Redis) | Готовый текст прежнего ответа при подходящем смысловом совпадении запроса | При срабатывании кеша система сразу возвращает сохранённый ответ без нового вызова языковой модели |
Эти четыре строки описывают свойства разного уровня и на практике могут сочетаться, а не только заменять друг друга.
Во-первых, «передать весь текст в контекст» и «заново вычислить его состояние» — разные действия. Авторы исходной статьи о CAG и её программного кода специально сравнивают свой подход с режимом, где полный справочный текст подаётся в модель и его KV-кеш пересчитывается непосредственно во время запроса. При этом условие «без повторного использования вычислений» относится только к этой конкретной строке сравнения, а не к любому полному контексту или RAG вообще. Если же вы работаете через облачный API и повторно отправляете в запросе один и тот же полный текст справочника, сервис провайдера может автоматически задействовать кеширование префикса на своей стороне. Поэтому сам факт повторной отправки текста в API ещё не доказывает, что модель каждый раз пересчитывает весь документ с нуля.
Во-вторых, из сопоставления источников следует различие между CAG и prompt caching. Это именно аналитическое разграничение ролей, а не жёсткий отраслевой стандарт терминологии. Prompt caching, описанный в документации OpenAI и Anthropic, — это технический механизм повторного использования вычислений для любого общего префикса: системных инструкций, примеров оформления или фоновых текстов. Он отлично работает и внутри RAG, когда неизменными остаются правила и шаблон в начале запроса, а найденные отрывки справочника меняются. CAG же описывает конкретную схему организации ответов по знаниям: весь подходящий набор документов заранее приводится в готовое состояние в контексте, чтобы отвечать на вопросы без этапа поиска.
В-третьих, совершенно иначе работает семантический кеш готовых ответов, устройство которого подробно разобрано в документации Redis. Здесь кешируется не состояние источника для будущих расчётов, а уже сформулированный в прошлом ответ.
Вернёмся к нашим вопросам по справочнику сотрудников. Когда вслед за вопросом об отпуске приходит вопрос о командировочных расходах, общий источник знаний у них один, но готовый ответ об отпуске бесполезен — нужен новый расчёт и новая генерация текста, что и делают CAG или prompt caching. Семантический кеш срабатывает только тогда, когда новый запрос по смыслу достаточно близок к уже заданному ранее.
Но даже высокая смысловая близость вопросов не гарантирует, что старый ответ подойдёт: в самой документации Redis прямо отмечено, что работа такого кеша зависит от настройки порога сходства и границ по метаданным, иначе похожий по форме вопрос может получить чужой или неточный ответ. Маркетинговые оценки скорости и экономии из материалов подобных сервисов нельзя переносить на CAG или наш пример со справочником.
Наконец, если вы используете кеширование префикса через облачные API, нельзя предполагать, что подготовленное состояние представляет собой универсальный файл, который можно свободно переносить между разными моделями и платформами. Судя по документации поставщиков по состоянию материалов на 19 октября 2026 года, правила включения и управления кешем заметно различаются. OpenAI описывает автоматическое кеширование совпадающих префиксов для поддерживаемых моделей. Anthropic использует явную разметку блоков через параметр cache_control и контрольные точки. В базовом описании контекстного кеширования Google показан механизм неявного (implicit) кеширования и рекомендации выносить общий префикс в начало запроса. Такое описание само по себе не означает отсутствия у платформы других режимов управления кешем или временем его жизни. Это разные интерфейсы и условия совпадения префиксов, а не единый переносимый стандарт.
Мы развели сами тексты документов, сохранённые вычисления модели и готовые ответы на прошлые запросы. Теперь возникает следующий практический вопрос: к какой именно редакции справочника привязаны сохранённые в кеше вычисления, что произойдёт при изменении документа и какие технические ограничения остаются у подхода даже при подходящем источнике.
Что меняется при обновлении документов и где пределы подхода
Продолжим наш пример со справочником сотрудников и добавим в него одно событие: в компании обновили главу о подаче командировочных расходов. Что произойдёт, если сотрудник снова задаст вопрос по этой теме?
Как следует из самого устройства механизма в исходной статье, эталонном коде и правил работы с префиксами в документации OpenAI, сохранённый KV-кеш жёстко привязан к тому тексту префикса, который модель фактически обработала. Если правку внесли только во внешний документ, но не передали обновлённый текст модели, в ранее вычисленном состоянии новых сведений просто нет.
Здесь важно не путать две разные операции:
- Возврат к прежней подготовке (сброс хвоста) удаляет из памяти только накопленные вычисления предыдущего вопроса и ответа (
clean_up), возвращая систему к уже сохранённому состоянию справочника. Он сохраняет старую редакцию документа и никак не помогает узнать об изменениях. - Актуализация источника требует подать в модель обновлённый контекст и согласовать с ним сохранённое состояние. При этом полное перестроение всего кеша с нуля — не единственный теоретически возможный путь: поскольку префиксное совпадение работает последовательно от начала входа, неизменившаяся начальная часть до места правки в некоторых схемах может сохраняться, а пересчёта потребует затронутая часть и всё, что идёт после неё. Вопросы автоматического отслеживания правок в документах и сброса устаревшего кеша выходят за рамки исходной эталонной реализации.
Даже когда текст справочника стабилен и не требует частых правок, применимость подхода упирается в три практических условия.
1. Доступный контекст и память. Весь подготавливаемый набор документов должен помещаться в контекстное окно модели вместе с системными инструкциями, вопросом и будущим ответом (подробнее о том, как контекстное окно ограничивает вход модели, можно прочитать в отдельном разборе о контекстном окне).
Однако физическая вместимость окна — это ещё не всё. Авторы статьи о CAG и описания репозитория прямо относят размер базы знаний и длину контекста к ограничениям метода, а документация Hugging Face подчёркивает, что хранение KV-кеша требует заметного объёма памяти и на длинных последовательностях повышает вычислительные затраты. Кроме того, даже если все документы формально поместились во вход модели, на очень длинном контексте способность модели точно использовать все детали текста может снижаться.
2. Затраты на подготовку и реальное повторное использование. Предварительный расчёт KV-кеша для большого справочника сам по себе требует времени и вычислений — эта подготовка не бесплатна. Выигрыш возникает только тогда, когда один и тот же подготовленный префикс действительно переиспользуется многократно (происходит фактическое попадание в кеш — cache hit), а в каждом новом запросе досчитывается лишь короткий вопрос.
3. Качество исходных сведений и самой генерации. Отказ от отдельного этапа поиска убирает характерные для него ошибки — например, когда поисковик не нашёл нужный абзац справочника или принёс нерелевантный кусок текста. Но отсутствие ошибок выбора фрагментов не доказывает безошибочность самого справочника, не заставляет модель идеально работать со всем объёмом длинного контекста и не отменяет вероятностную природу генерации (как отмечает OpenAI, каждый ответ всё равно создаётся заново, и даже одинаковые запросы не обязаны давать пословно совпадающий результат). Кеш ускоряет доступ к подготовленному состоянию документа, но не служит гарантией правильного ответа и не убирает все возможные задержки при генерации.
Именно в этих границах следует читать и экспериментальные результаты авторов исследования о CAG. В своих тестах на модели Llama 3.1 8B и выбранных конфигурациях датасетов SQuAD и HotPotQA авторы исключили этап поиска из рабочего цикла и получили более высокий показатель BERTScore в большинстве проверенных сценариев по сравнению с сопоставляемыми вариантами RAG. При этом нужно учитывать два ограничения: во-первых, метрика BERTScore оценивает смысловое сходство ответа модели с эталонным текстом в тесте, а не доказывает абсолютную фактическую безошибочность; во-вторых, эти результаты получены авторами на конкретных тестовых наборах и не означают, что CAG всегда лучше, быстрее или дешевле RAG на любой прикладной задаче.
В рассмотренном подходе CAG подходящий набор документов обрабатывают заранее, чтобы сохранить в KV-кеше вычисленное состояние источника, а ответ на каждый новый вопрос генерируют заново поверх этой подготовки. Поиск фрагментов под запрос (RAG) и возврат готового прошлого ответа (семантический кеш) решают соседние, но другие задачи. Даже после предварительной подготовки справочника нужно следить за актуальностью документов после правок, учитывать ограничения памяти и контекста и проверять качество генерируемых ответов.
Чтобы проверить, насколько прозрачной стала эта схема, попробуйте своими словами ответить на два вопроса: что именно остаётся сохранённым в системе между вопросом сотрудника об отпуске и вопросом о командировочных расходах — и почему после изменения главы справочника простого сброса предыдущего вопроса недостаточно, чтобы модель учла новые правила. А если захочется подробнее разобрать соседние механизмы, следующим шагом можно посмотреть материалы о том, как устроен подбор фрагментов в RAG и как контекстное окно ограничивает вход модели.
