Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Предварительно сохранённые KV-кэши (кэши ключей и значений) разных документов научились исправлять перед ответом, чтобы модель увидела связи между фрагментами без полного повторного прохода по контексту. В препринте, который не рецензирован и где числа получили сами авторы, CacheRepair вошёл в границу лучших сочетаний качества и задержки в 11 из 12 проверенных сценариев. Для RAG-систем это добавляет промежуточный вариант между быстрым, но неточным объединением кэшей и дорогим повторным запуском основной LLM.
Почему готовые кэши теряют связи между документами
В RAG модель отвечает с опорой на найденные документы. До начала генерации она пропускает их токены через свои слои и сохраняет ключи и значения внимания в KV-кэше. Если одни и те же фрагменты встречаются во многих запросах, этот проход можно выполнить заранее и повторно использовать результат.
Проблема возникает при сборке ответа из нескольких фрагментов. Каждый кэш рассчитан независимо и ничего не знает о документах, которые окажутся перед ним в конкретном запросе. Простое объединение сохраняет информацию внутри фрагментов, но не восстанавливает внимание между ними.
Ошибка сосредоточена не только у границ. Сравнение независимо рассчитанного кэша с кэшем совместного прохода показало всплески в начале фрагментов и устойчивые полосы ошибки во внутренних позициях некоторых слоёв. Поэтому методы, которые повторно обрабатывают лишь несколько токенов у стыков, закрывают не всю разницу.
Как сеть исправляет кэш для замороженной LLM
CacheRepair оставляет основную LLM без изменений. Для каждого фрагмента система заранее рассчитывает кэш и удаляет из ключей локальное позиционное кодирование RoPE. Благодаря этому один кэш можно поставить в разные места и сочетать с разными документами.
Во время запроса система объединяет найденные кэши в нужном порядке. Отдельная компактная сеть получает сжатые признаки ключей и значений из слоёв основной модели, а также её замороженные векторные представления токенов. Это позволяет учитывать и содержимое готового кэша, и идентичность исходных токенов.
Внутри каждого фрагмента сеть разрешает вниманию идти в обе стороны. Между фрагментами информация движется только от более ранних к более поздним, как при обычной обработке контекста основной моделью. Исходные признаки кэша повторно подаются в каждый блок, чтобы сеть не потеряла их при преобразованиях.
На выходе CacheRepair предсказывает остаточную поправку для каждого токена документа, а не новый кэш целиком. Поправка прибавляется к сохранённым ключам и значениям, после чего ключи получают глобальные позиции. Исправленный кэш передают замороженной LLM, которая обрабатывает вопрос и генерирует ответ обычным способом.
Для обучения нужны парные примеры. Основная модель один раз рассчитывает документы независимо и один раз совместно; разница между кэшами становится целевым ответом. Отдельную сеть обучают для конкретной LLM на общем корпусе поиска, но затем один и тот же контрольный снимок используют на разных прикладных наборах. Сам вопрос в исправлении кэша не участвует.
Когда CacheRepair меняет архитектурный выбор
Метод проверили на Qwen2.5-3B-Instruct, Llama-3.1-8B-Instruct и Qwen2.5-14B-Instruct. Для MuSiQue, HotpotQA, MultiHop-RAG и TriviaQA взяли по 500 запросов. CacheRepair сравнивали с полным проходом Full Prefill, прямым повторным использованием кэша, выборочным пересчётом CacheBlend, EPIC и InfoFlow, а также с KV Packet.
Крупнейшие варианты CacheRepair сокращали медианное время до первого токена в 1,69–4,61 раза относительно Full Prefill. По сравнению с прямым объединением готовых кэшей средняя F1 выросла на 2,1–26,1 процентного пункта. F1 здесь показывает, насколько токены ответа совпали с эталоном. Время включает перенос кэша, его исправление, обработку основной моделью и выпуск первого токена.
Схема подходит архитектурам, где документы повторяются между запросами, а проход по найденному контексту заметно влияет на задержку. Команда может хранить кэш каждого фрагмента отдельно, собирать его под конкретную выдачу и тратить вычисления на компактную сеть вместо повторного запуска всей LLM по документам.
Цена такого решения — отдельная сеть для каждой целевой LLM. При смене основной модели нельзя считать прежний исправитель совместимым: его обучают на разнице кэшей именно этой модели и хранят вместе с её статистиками нормализации. Кроме того, подготовка требует совместных проходов по обучающим последовательностям, хотя во время запросов основная модель остаётся замороженной.
Работа не делает прямое повторное использование кэша безопасной заменой полного прохода. Она показывает более практичный способ поставить между ними управляемый слой: заранее кэшировать повторяющиеся документы, обучить исправитель под выбранную LLM и измерять качество вместе со временем до первого токена. Такой вариант стоит добавить в архитектурное сравнение, если RAG обслуживает устойчивый корпус, а не каждый раз получает полностью новый контекст.
Источники
Иллюстрация: рисунок из статьи «CacheRepair: Learning to Repair Cross-Chunk Context in RAG for KV Cache Fusion», Genglin Wang, Wangsong Yin, Yeerzhati Abudunuer и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
