Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Существующие тесты завышают точность RAG-систем, которые повторно используют KV-кэш фрагментов. В нерецензированном препринте, где числа получены самими авторами, работа Huawei Technologies и ETH Zurich показывает: до 42% итогового F1 могут давать запросы, на которые обычная обработка полного контекста вообще не ответила. Значит, выбирать способ ускорения RAG по одному сводному показателю рискованно: он не отделяет сохранённую точность от случайно улучшившихся ответов.
Почему общий F1 не измеряет сохранённую точность
RAG-система добавляет к запросу найденные текстовые фрагменты. Перед генерацией модель обрабатывает весь ввод и сохраняет ключи и значения внимания в KV-кэше; эта стадия называется предварительным заполнением. Чем длиннее контекст, тем больше времени она занимает.
Переиспользование позволяет один раз вычислить KV-кэш каждого фрагмента, а затем подставлять его в новые запросы. Но сохранённое состояние не учитывает соседние фрагменты из нового контекста. Методы компенсируют это, повторно вычисляя состояния части токенов, однако приближение может изменить ответ.
Обычно такие методы сравнивают по F1 — показателю совпадения ожидаемого и полученного ответа. Проблема в том, что общий F1 смешивает несколько разных случаев. Метод может получить баллы там, где полная обработка контекста ошиблась, где модель уже знала ответ из обучения или где короткий вариант ответа легко угадать.
Авторы предлагают оставлять в тесте только содержательное подмножество запросов. Для этого запрос должен пройти три проверки:
- модель правильно отвечает после полной обработки предоставленного контекста;
- без контекста модель не находит ответ;
- ответ нельзя свести к выбору между двумя очевидными вариантами.
Такой тест отвечает на узкий, но полезный вопрос: какую долю исходной точности сохранило переиспользование кэша. На трёх наборах вопросов из LongBench фильтрация последовательно ухудшала относительные результаты CacheBlend и FusionRAG. Именно отфильтрованные запросы создавали впечатление, что приближённая обработка ближе к полной, чем она была на задачах, где требовалось прочитать контекст.
Boxoffice проверяет кэш в меняющемся контексте
Одной фильтрации недостаточно. В распространённых наборах соседние фрагменты часто относятся к одной теме, а многие фрагменты встречаются лишь в одном запросе. Такой материал плохо проверяет методы, которые сохраняют кэш при первом появлении фрагмента и используют его позже.
Авторы создали генератор Boxoffice на вымышленном корпусе о фильмах. Модель не может извлечь эти факты из памяти обучения, а полная обработка контекста заранее должна давать правильный ответ. Генератор управляет тем, какие фрагменты повторяются и с каким окружением они появляются.
Ключевой сценарий — устаревший кэш. Один и тот же фрагмент сначала обрабатывается среди документов, которые задают ему одну роль, а затем попадает в контекст с противоположной ролью. Сохранённые связи между фрагментами начинают мешать, хотя сам текст не изменился.
Два почти одинаковых запуска одного метода дали относительный F1 от 0,98 до 0,00 только из-за контекста, в котором кэш сохранили впервые. В этих опытах методы повторно вычисляли состояния 15% токенов. Результат показывает, что для «тёплого» кэша важна не только доля повторного вычисления, но и история каждого сохранённого состояния.
Boxoffice также создаёт запросы целиком из уже встречавшихся фрагментов. Это позволяет сравнивать стратегии, которые держат одну версию кэша, с методами, сохраняющими несколько версий для разных предшествующих контекстов. Обычный набор вопросов может почти не активировать эту разницу.
Что меняется в планах команд с RAG
Работа не доказывает, что конкретный способ переиспользования KV-кэша всегда хуже другого. Она меняет критерий приёмки: ускорение следует измерять только вместе с потерей точности на запросах, где модель действительно использует предоставленные документы.
В испытательном контуре стоит сохранить полную обработку контекста как эталон. Затем нужно отдельно отсеять вопросы, которые эталон не решает, проверить ответы без документов и убрать задания с высокой вероятностью угадывания. Сводный F1 по исходному набору можно оставить для совместимости, но не использовать как основной показатель качества кэша.
Для методов, которые сохраняют контекстно-зависимые состояния, нужен ещё один класс испытаний: один документ повторяется среди разных и конфликтующих соседей. Следует менять порядок запросов и контекст первого заполнения кэша. Если результат зависит от истории, одной версии состояния на фрагмент может быть недостаточно.
Границы проверки достаточно узкие: основной эксперимент охватывает ответы на вопросы, три открытые модели примерно на 8 млрд параметров и методы с выборочным повторным вычислением. Устойчивость основных эффектов дополнительно проверяли на Qwen3-32B, а Boxoffice строится вокруг одного синтетического корпуса и нескольких шаблонов запросов. Поэтому методика подходит как дополнительный тест для RAG, но не заменяет испытания на данных и нагрузке конкретного продукта.
Для команды практический итог прост: если переиспользование KV-кэша входит в план оптимизации задержки, до выбора реализации нужно зафиксировать эталонные ответы, воспроизвести повторение документов между запросами и проверить зависимость от истории кэша. Без этого выигрыш во времени можно принять за сохранение качества, которого на рабочих запросах нет.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.



