Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Сжатый кэш ключей и значений (KV-кэш) научились не терять продолжение строк, которые модель дословно копирует из длинного контекста. В препринте Linfeng Dong, который не прошёл рецензирование и приводит числа из собственных замеров, KVFetch поднял результат задачи на дословное копирование с 0,8 до 78,4. Для систем с идентификаторами, полями документов и фрагментами кода это меняет архитектуру компрессии: одной оценки смысловой важности токенов недостаточно.
Почему компрессия находит строку, но теряет её середину
Во время генерации KV-кэш хранит представления токенов из контекста, чтобы модель не пересчитывала их на каждом шаге. Длинный контекст раздувает этот кэш, поэтому компрессоры оставляют позиции, которые считают важными для текущего запроса, а остальные удаляют или выгружают.
Такой отбор хорошо работает, когда модели нужно найти фрагмент по смыслу. Но UUID, значение поля JSON или имя переменной устроены иначе: начало строки помогает найти нужное место, а следующие символы сами по себе почти ничего не значат. Компрессор сохраняет начало, модель приступает к правильному ответу, затем доходит до удалённой позиции и необратимо сбивается.
Работа называет этот сбой последовательным забыванием. Более точная оценка важности не возвращает уже удалённую позицию, а увеличение бюджета не гарантирует, что компрессор сохранит именно середину литеральной строки. Методы, которые сворачивают удалённые записи в обобщённое представление, могут приблизить общий вклад контекста, но не восстановить точную последовательность символов.
Авторы разделяют два способа обращения к памяти. Первый ищет позиции по содержанию: какие токены связаны с текущим запросом. Второй следует по порядку: если модель читает конкретную позицию, скоро ей, вероятно, понадобятся соседние. Существующие компрессоры в основном реализуют первый способ, тогда как KVFetch добавляет второй.
Как KVFetch возвращает следующие позиции
KVFetch не удаляет все отвергнутые записи окончательно. Редкие токены и последовательности с низкой самостоятельной значимостью попадают в холодный слой с четырёхбитным хранением. Его объём ограничен 5% длины входа, а записи индексируются по исходной позиции.
Во время генерации система следит, куда приходится пик внимания модели. Если этот указатель несколько шагов движется вперёд по исходному тексту, KVFetch распознаёт последовательное чтение. Тогда он заранее возвращает ближайшие позиции из холодного слоя в активный кэш.
Каждая добавленная запись заменяет одну из менее нужных активных записей. Число позиций, которые участвуют во внимании, поэтому не растёт: меняется содержимое кэша, а не его размер. Когда модель не копирует текст последовательно, механизм остаётся выключенным.
KVFetch не требует обучения и не меняет способ, которым основной компрессор оценивает токены. Однако ему нужны три части одновременно: отбор кандидатов в холодный слой, распознавание последовательного чтения и подгрузка продолжения. В экспериментах отключение любой из них возвращало исходный сбой.
Механизм чинит продолжение, но не поиск начала. Если базовый компрессор не сохранил позицию, с которой начинается нужный фрагмент, траектория чтения не возникнет и подгрузка не включится. Он также не помогает, когда модель находит несколько похожих значений и выбирает неверное: это ошибка различения кандидатов, а не потеря середины строки.
Когда результат стоит учитывать в архитектуре
Метод проверяли на RULER-16K и LongBench с моделями Qwen2.5-7B-Instruct, Qwen3-4B-Instruct и Llama-3.1-8B-Instruct. Основное сравнение уравнивало общий бюджет памяти, причём базовому компрессору выделяли больше активного пространства, чтобы холодный слой KVFetch не давал скрытого преимущества.
На RULER-16K средний результат по набору задач вырос на 8,43 пункта. Выигрыш сосредоточился там, где ответ требовал пройти по контексту последовательно; на задачах LongBench, ориентированных на понимание текста, канал почти не включался и существенного ухудшения не дал. Полный KV-кэш всё ещё показывал более высокий результат, поэтому KVFetch устраняет отдельный класс ошибок, а не всю потерю качества от компрессии.
Объём вычислений для внимания остался прежним, но управление холодным слоем не бесплатно. В тестовой конфигурации задержка шага выросла на 4,8%, а дополнительное хранилище заняло 0,36% размера полного KV-кэша. Эти расходы возникают ради точного копирования, а не ради общего улучшения ответов.
Командам с поисковой генерацией, извлечением структурированных полей и дополнением кода стоит отдельно проверять длинные UUID, номера транзакций, суммы и имена переменных. Практический тест должен различать две ситуации: модель не нашла нужный фрагмент или начала копировать правильно и сбилась посередине. KVFetch рассчитан только на вторую.
Если продукт использует компрессию ради длинного контекста, а единичная ошибка в идентификаторе недопустима, канал последовательного доступа стоит закладывать рядом с отбором по содержанию. Для сценариев, где модель пересказывает документ и не обязана воспроизводить строки дословно, работа не даёт основания менять текущий компрессор.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
