Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Долгий контекст LLM предложили обрабатывать быстрее, не рассчитывая внимание по всем сохранённым токенам. Метод HHR обошёл прежние способы разреженного внимания на LongBench и RULER; это нерецензированный препринт, и все числа в нём получили сами авторы. Для команд с собственной инфраструктурой запуска моделей это повод проверить двухступенчатый отбор ключей вместо одного хеш-поиска.
Почему расстояние Хэмминга пропускает важные ключи
Полное внимание сравнивает запрос с каждым ключом в контексте. Чем длиннее последовательность, тем больше таких сравнений приходится выполнять при генерации каждого следующего токена.
Разреженное внимание сокращает эту работу: сначала выбирает небольшой набор подходящих ключей, а точные вычисления проводит только для них. Хеш-методы кодируют запросы и ключи последовательностями битов, после чего считают расстояние Хэмминга — количество несовпадающих битов. Процессор выполняет такое сравнение быстрыми побитовыми операциями.
Проблема в том, что битовый код сохраняет в основном направление признаков, но теряет их величину. Оценка связи запроса с ключом зависит от обоих факторов: два вектора могут смотреть почти в одну сторону, но слабый по величине ключ получит низкую оценку. Хеш-поиск всё равно посчитает его близким и зря потратит ограниченный бюджет выборки.
Возможна и обратная ошибка. Ключ с крупными значениями признаков может сильно влиять на внимание, хотя его битовый код далёк от кода запроса. Тогда хеш-поиск отбрасывает значимый токен, а модель теряет часть нужного контекста.
Одна ошибка добавляет ложные совпадения, другая создаёт пропуски. Увеличение числа выбранных ключей помогает против пропусков, но одновременно возвращает лишние вычисления. HHR разделяет эти задачи между двумя этапами.
Два уровня маршрутизации решают разные ошибки
На первом этапе Geometry-Aware Key Routing объединяет соседние ключи в страницы. Для каждой страницы метод оценивает верхнюю границу: насколько высокий результат сравнения вообще может встретиться среди её ключей. Страницы с низкой границей отбрасываются целиком, а потенциально важные переходят дальше.
Качество такой границы зависит от того, как признаки распределены между координатами. HHR обучает отдельное ортогональное преобразование для каждой головы механизма внимания. Оно перераспределяет значения между координатами, но сохраняет точные результаты сравнения запросов и ключей.
Это позволяет сделать границы для слабых страниц теснее, не меняя само внимание. Первый этап прежде всего убирает ложные совпадения: похожие по направлению, но малозначимые ключи перестают занимать место в итоговой выборке.
На втором этапе Learned Hash Projection работает уже с ключами из оставшихся страниц. Вместо случайной проекции он обучает для каждой головы пространство, где расстояние Хэмминга лучше соответствует настоящему порядку значимости ключей. При обучении ориентиром служат точные оценки полного внимания, а при запуске модель снова использует компактные битовые коды.
Такое разделение важно для архитектуры метода. Страничная маршрутизация дёшево сокращает область поиска и сохраняет кандидатов с потенциально высокой оценкой. Обученная хеш-проекция затем точнее ранжирует отдельные ключи и возвращает те, которые обычное хеширование сочло бы слишком далёкими.
Когда HHR меняет планы запуска модели
Метод проверяли на моделях семейств Llama, Mistral и Qwen, на LongBench и RULER, при контексте до 128K. В сравнение вошли полное внимание, идеальный отбор по точным оценкам и несколько разреженных методов, включая MagicPIG, Loki и HATA. Это проверка локального запуска открытых моделей, а не готового внешнего API.
На LongBench HHR превысил лучший прежний результат в среднем на 1,10 пункта для модели семейства Llama. При самом длинном проверенном контексте декодирование ускорилось до 3,30 раза, а весь цикл обработки запроса и генерации — до 2,83 раза. На RULER крупнейший выигрыш над прежним лучшим методом составил 6,43 пункта.
Работа влияет на планы команд, у которых задержка возникает именно при генерации по длинному кешу ключей и значений. HHR требует доступа к внутренним слоям модели: нужно обучить преобразования для голов внимания, хранить страничные границы и встроить оба этапа в выбор ключей. Поэтому метод подходит для собственной инфраструктуры запуска, но не подключается как настройка к закрытой модели.
Проверка также задаёт границы вывода. HHR приблизился к полному вниманию, но сохранил разрыв с идеальным отбором по точным оценкам. Совместную работу с квантованием кеша в статье не изучали, поэтому команде, которая уже сжимает ключи и значения, потребуется отдельный эксперимент.
Практический вывод не в том, что любой хеш-поиск стоит заменить HHR. Работа показывает более узкий принцип: если битовый код теряет величину признаков, один этап ранжирования не исправляет одновременно ложные совпадения и пропуски. Для длинного контекста имеет смысл сначала отсечь слабые области по безопасной верхней границе, а уже затем применять обученный хеш-поиск.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
