Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
После отбора данных для разреженного кэша модель может отвечать точнее, если убрать позиционные разрывы между сохранёнными фрагментами. В препринте Wanyang Hong и Zhaoning Zhang, который не проходил рецензирование и где числа получены самими авторами, RoPERelay улучшил качество в 32 из 36 сравнений. Для систем с длинной памятью это добавляет отдельный этап оптимизации после отбора, не требуя менять его алгоритм.
Удалённые токены продолжают влиять на сохранённые
При генерации модель хранит кэш ключей и значений (KV-кэш), чтобы не пересчитывать уже обработанный текст. В длинной истории такой кэш занимает много памяти, поэтому алгоритмы отбора оставляют только состояния, которые считают полезными.
Однако сохранённые состояния обычно не меняют исходные координаты. Если между двумя полезными фрагментами находились удалённые токены, в позиционном пространстве остаётся разрыв, хотя самих токенов в кэше уже нет.
Это существенно для моделей с RoPE — вращательным кодированием позиций. RoPE поворачивает векторы запросов и ключей в зависимости от позиции, поэтому расстояние между координатами влияет на то, насколько хорошо текущий запрос совпадёт с сохранённым ключом. Алгоритм отбора может оставить правильный факт, но модель всё равно прочитает его хуже из-за прежнего расстояния.
Авторы отделили этот эффект от качества отбора. В каждой паре опытов сохранялись одинаковые ключи, значения, порядок исходных фрагментов и объём кэша. Менялись только координаты и связанные с ними фазы RoPE. Такой дизайн показывает, что выигрыш даёт не скрытое повторное извлечение данных, а другое расположение уже выбранного содержимого.
RoPERelay переносит ключи в компактное пространство
RoPERelay сортирует сохранённые состояния по их месту в исходной истории и назначает им последовательные координаты без промежутков. Хронология остаётся прежней: ранний факт по-прежнему располагается перед его поздним уточнением, даже если алгоритм отбора оценил уточнение выше.
Одной замены номеров недостаточно, поскольку ключи уже содержат поворот RoPE для старой позиции. Метод снимает исходный поворот и применяет новый, соответствующий компактной координате. Значения при этом не меняются, а историю не нужно снова прогонять через модель.
Длины сохранённой последовательности могут различаться между слоями и головами внимания. RoPERelay выравнивает их конечные точки, после чего ставит текущий вопрос сразу за общей границей истории. Ответ продолжает ту же последовательность координат. Это важно: если уплотнить только ключи, но оставить запрос на старой позиции, расстояние между ними станет ещё больше и качество упадёт.
На Llama с BM25 в LongMemEval-S точность выросла с 23,6% до 35,4%. Результат оказался выше режима с полной историей, который набрал 27,4%, хотя RoPERelay не возвращал удалённые состояния. На другом сочетании модели и алгоритма отбора прирост достиг 14,5 процентного пункта. Полное время обработки запроса выросло не более чем примерно на 3% в проверенных конфигурациях.
Работу проверяли на Llama-3.1-8B-Instruct и Qwen2-7B-Instruct, шести алгоритмах отбора и трёх задачах на долговременную память. Основные опыты сохраняли десятую часть исторических токенов. В двух задачах ответы оценивала модель-оценщик, которая не знала вариант метода, а PersonaMem-128K использовал объективную точность выбора ответа.
В план стоит добавить этап после отбора, но не замену архитектуры
RoPERelay применим там, где продукт уже сжимает KV-кэш модели с RoPE и сохраняет исходные позиции выбранных состояний. Метод не меняет правила отбора, не увеличивает бюджет истории и не требует повторно обрабатывать удалённый текст. Поэтому его можно оформить как отдельный преобразователь между алгоритмом отбора и обработкой нового вопроса.
Для внедрения понадобятся ключи, исходные позиции и маски допустимых состояний. Реализация должна правильно снять и заново применить фазы RoPE, выровнять границы между головами и продолжить координаты во время генерации. Ошибка в синхронизации ключей и запросов способна уничтожить весь выигрыш от уплотнения.
Менять сам алгоритм отбора только из-за этой работы не стоит. RoPERelay помогал BM25, SnapKV, PyramidKV, H2O, CaM и ChunkKV, но эффект зависел от задачи и сочетания компонентов; на LongMTBench+ некоторые варианты отвечали хуже. Проверять нужно парой опытов на одном и том же выбранном кэше, иначе влияние новых координат смешается с изменением содержимого.
Практический вывод уже достаточно узкий: после настройки полноты и бюджета разреженного кэша остаётся ещё один независимый рычаг. Если полезные состояния сохранились, но модель плохо связывает их с текущим запросом, компактные координаты могут дать прирост без дополнительной памяти. Для моделей другого масштаба, иных позиционных кодировок и задач вне проверенного набора вывод пока не установлен.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
