Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Один компрессор контекста научили поддерживать разные степени сжатия и выбирать их отдельно для каждого входа. Команда The University of Tokyo и National Institute of Informatics показала, что такая модель сохраняет качество отдельных специализированных компрессоров; в препринте, который не прошёл рецензирование, приведены замеры самих авторов. Это позволяет развернуть один компрессор вместо набора моделей и менять расход памяти без повторного обучения.
Один набор весов работает с разными бюджетами
Мягкое сжатие контекста (soft context compression) заменяет исходный текст небольшим набором непрерывных токенов памяти. Кодировщик извлекает из документа нужную информацию, а замороженная LLM получает эти токены вместо полного текста.
Обычно число токенов памяти фиксируют при обучении. Если системе нужны экономный режим для простых документов и более подробный для сложных, приходится обучать и обслуживать несколько компрессоров. При этом каждый из них применяет один бюджет ко всем входам, хотя короткая справка и запутанный документ требуют разной детализации.
FlexComp меняет только схему обучения, а не устройство базового компрессора. Для каждого учебного примера система случайно выбирает один из поддерживаемых бюджетов. Кодировщик видит, сколько токенов памяти ему выделили, и учится заново упаковывать контекст под этот объём.
Это не обрезка одного большого представления. Кодировщик выполняет отдельный проход для выбранного бюджета: при малом объёме он сильнее отбирает главное, при большом может сохранить детали. На инференсе тот же набор весов работает во всех обученных режимах.
Каскад проверяет уверенность, предсказатель выбирает заранее
После обучения остаётся решить, какой бюджет выделить конкретному входу. FlexComp предлагает два варианта с разным балансом между качеством и вычислительными затратами.
Каскад начинает с самого сильного сжатия. Декодер строит ответ и оценивает свою уверенность по средней логарифмической вероятности токенов. Если уверенности недостаточно, система повторно кодирует контекст с большим бюджетом. Такой режим использует сигнал от самого ответа, но в сложном случае несколько раз запускает кодировщик и декодер.
Второй вариант — небольшой предсказатель бюджета. Он усредняет скрытые представления исходного контекста и до сжатия выбирает подходящее число токенов памяти. После этого система один раз кодирует документ и один раз получает ответ.
Предсказатель анализирует только контекст, без вопроса. Благодаря этому бюджет можно определить заранее и сохранить вместе с документом, но два разных вопроса к одному тексту получат одинаковую степень сжатия. Для приложений, где сложность зависит прежде всего от запроса, каскад даёт более точный управляющий сигнал.
Экономия появляется в KV-кэше, но повторные проходы надо считать отдельно
Каскад сохранил более 98% качества самого подробного режима при среднем сжатии до 266 раз. Предсказатель уступил ему в гибкости, зато укладывался в один проход и оставался в пределах 0,7 пункта F1 от подробного режима. F1 здесь измеряет совпадение токенов в предсказанном и эталонном ответах.
В пакетном инференсе предсказатель сократил контекстную часть KV-кэша на 50% и поднял общую скорость декодирования на 47%. KV-кэш хранит промежуточные ключи и значения внимания на время генерации, поэтому его сокращение освобождает память GPU и уменьшает объём чтения при каждом следующем токене.
Есть и менее очевидный результат: больший бюджет не всегда давал лучший ответ. Иногда подробное представление сохраняло соседние имена и связи, которые сбивали декодер, тогда как один токен памяти оставлял только смысл документа. Поэтому выбор бюджета нельзя свести к правилу «сложным входам больше, простым меньше» без проверки на данных продукта.
Метод проверяли на ICAE, 500xCompressor и SAC в задачах поиска ответа MRQA, включая данные из обучающих доменов и за их пределами. Основные опыты использовали Llama-3.2-1B, а перенос результата отдельно проверили на Llama-3.1-8B. Это границы вывода: работа показывает поведение мягких компрессоров в ответах по документам, а не любых способов сокращать промпты.
Для команды, которая уже планирует мягкое сжатие контекста, работа меняет архитектурный выбор: степень сжатия больше не обязательно фиксировать в модели. Практичный первый шаг — обучить один компрессор на нескольких рабочих бюджетах, а затем сравнить два маршрута на реальной нагрузке. Предсказатель подходит там, где важны предсказуемая задержка и пакетная обработка; каскад — там, где допустимы повторные проходы ради качества.
При оценке каскада стоит учитывать не только средний объём сжатого контекста, но и все повторные кодирования и декодирования. Для предсказателя важнее проверить, достаточно ли свойств документа для выбора бюджета или решение должно учитывать ещё и конкретный запрос.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
