В один эмбеддинг можно впихнуть больше тысячи токенов, но что с этим не так? / forpes.ru

Главная
В один эмбеддинг можно впихнуть больше тысячи токенов, но что с этим не так?

В один эмбеддинг можно впихнуть больше тысячи токенов, но что с этим не так? +1

27.07.2026 06:12

MrSndmn 0 2900 Источник

Хабр, привет! Меня зовут Дмитрий Тарасов, я исследователь в лаборатории FusionBrain AIRI. Мы недавно свозили нашу свежую работу — “Progressive Cramming: Reliable Token Compression and What It Reveals” — на ICML 2026, и здесь я хочу рассказать, о чём она.

Начнём с почти магического факта. Год назад в замечательной работе “Cramming 1568 Tokens into a Single Vector and Back Again” моего коллеги по AIRI Юры Куратова и его команды было показано, что в один‑единственный входной эмбеддинг замороженной LLM можно «упаковать» до 1568 токенов текста так, что модель потом слово в слово его восстанавливает. Полторы тысячи токенов — это несколько абзацев — в одном векторе размерности несколько тысяч, невероятная плотность памяти. Разбор этой статьи уже был на хабре.

У нас этот результат вызвал не только восторг, но и подозрение. Одно дело — восстановить текст, и совсем другое — понимать его. Что, если «идеальная» реконструкция на самом деле не хранит смысл? В нашей статье мы:

покажем, что стандартный протокол token cramming скрывает катастрофические провалы, и предложим более честную процедуру — progressive cramming;
исследуем траектории оптимизации сжатых последовательностей;
и, самое интересное, покажем, что идеальная реконструкция не сохраняет способность модели рассуждать — а причина этого сидит в первых слоях трансформера.

Поехали.

Что не так со стандартным протоколом token cramming?

Сначала про задачу. Классический token cramming (буквально «впихивание токенов») выглядит так: у нас есть замороженная авторегрессионная модель и целевая последовательность токенов . Мы градиентным спуском подбираем один входной эмбеддинг $\mathbf{e}$ так, чтобы модель, получив его на вход, авторегрессионно восстановила весь текст. Веса модели не трогаем — учится только вектор $\mathbf{e}$ :

$\mathbf{e}^* = \arg\min_{\mathbf{e}} \; \Big[-\sum_{i=1}^{n} \log p_{\mathcal{M}}(x_i \mid \mathbf{e},\, x_1, \dots, x_{i-1})\Big].$

В предыдущей работе фиксировали бюджет токенов (например, сжимаем ровно 512, 1024, 1568 токенов) и считали успехом, когда точность реконструкции превышает 99% токенов. Причём в режиме teacher forcing, то есть подавая модели на каждом шаге правильный предыдущий токен, а не предсказанные моделью токены, которые могут быть с ошибкой.

И вот здесь кроется ловушка. Мы посмотрели, где именно располагается тот самый последний процент ошибок. Оказалось, что ошибки не распределены равномерно — они концентрируются в самом начале, на позициях 0 и 1. А для авторегрессионной генерации это фатально: стоит модели ошибиться на первом же токене — и весь дальнейший текст она генерирует, опираясь на неверный префикс. Одна ранняя ошибка ломает всю цепочку. Вероятнее всего, ошибка в первых токенах возникает из‑за того, что первые токены сложнее сжимать.

Мы проверили это в эксперименте: при переходе от teacher forcing к честному greedy‑декодированию «почти идеальное» сжатие рассыпается:

Модель	Тип	Токенов	Точность (TF)	Точность (greedy)
Llama-3.1-8B	Full cramming	1568	99.96%	40.4%
Llama-3.1-8B	Progressive	1438 ± 380	100%	100%
Pythia-1.4b	Full cramming	512	99.71%	44.2%
Pythia-1.4b	Progressive	430 ± 65	100%	100%

99.96% под teacher forcing — и всего 40% при реальной генерации. Разброс ±48% в последней колонке для full cramming означает буквально следующее: часть примеров восстанавливается идеально, а часть — вообще никак, в зависимости от того, повезло ли с первыми токенами.

Full cramming: под teacher forcing точность ~99%, но при жадной генерации ранняя ошибка каскадом рушит весь текст. — Схема full cramming. Под teacher forcing точность ~99% (сверху), но при жадной генерации ранняя ошибка каскадом рушит весь текст (снизу).

Вывод: фиксированный бюджет + порог точности 99% — ненадежная схема. Она не гарантирует, что текст реально будет восстановлен. А значит нам нужна другая процедура, которая гарантирует настоящую, 100%‑ную реконструкцию.

Метод Progressive Cramming

Идея простая. Вместо того чтобы сжимать фиксированное количество токенов, мы наращиваем последовательность по одному токену за раз:

Начинаем с одного токена и обучаем $\mathbf{e}^{(1)}$ до идеальной реконструкции.
Расширяем последовательность до , инициализируем новый эмбеддинг предыдущим решением $(\mathbf{e}^{(k)}\leftarrow \mathbf{e}^{(k-1)})$ и дообучаем под более длинный префикс.
Повторяем, пока идеальная реконструкция ещё достижима. Останавливаемся, когда уже не можем добавить новый токен без потери качества реконструкции.

Прогрессивное сжатие: замороженная модель, обучаемый эмбеддинг, тёплый старт между стадиями. — *Схема иллюстрирует метод прогрессивного сжатия*

Что нам это даёт? Во‑первых, честную границу. Мы останавливаемся ровно там, где сжатие перестаёт работать, — и получаем точную, посэмплово измеренную ёмкость. Во‑вторых, мы получаем 100% точность реконструкции, ведь по построению каждый сохранённый эмбеддинг восстанавливает свой префикс идеально. Наконец, в качестве бонуса нам достаются траектория оптимизации. Действительно, мы сохраняем эмбеддинг $\mathbf{e}^{(k)}$ на каждой стадии и получаем «след» того, как оптимизатор двигался в пространстве эмбеддингов по мере добавления новых токенов. Это отдельный богатый источник для анализа (о нём ниже).

Но за удобство приходится платить: progressive cramming примерно вдвое медленнее full cramming и плохо батчуется.

Насколько разные модели умеют сжимать

Мы прогнали progressive cramming на датасете PG19 и fanfics для четырёх семейств моделей. А ещё добавили один приём — низкоразмерную проекцию (low‑dimensional projection). Вместо того чтобы оптимизировать вектор во всей его размерности , мы параметризуем его как $\mathbf{e}=Wz+b$ , где коэффициенты живут в маленьком пространстве размерности $k\ll d$ , а обучаются для каждого примера. Это меняет геометрию оптимизации и, как оказалось, заметно поднимает ёмкость.

Низкоразмерная проекция: оптимизируем z в маленьком пространстве, а эмбеддинг получаем как Wz + b. — Схема низкоразмерной проекции. Оптимизируем в маленьком пространстве, а эмбеддинг получаем как . Вектор $e \in R^d$ параметризуется через коэффициенты $z \in R^k$ , где $k \ll d$ .

Наглядно эффект низкоразмерной проекции виден на анимации: оптимизатор перестаёт «залипать» в одном локальном минимуме и начинает перескакивать в новые локальные минимумы.

C низкоразмерной проекцией оптимизатор уходит из локального минимума и исследует несколько бассейнов реконструкции

Анимация: с низкоразмерной проекцией оптимизатор уходит из локального минимума и исследует несколько бассейнов реконструкции. — Раскадровка вышепоказанной анимации в одной картинке. Градиент цвета обозначает изменение со временем.

Увеличение ёмкости можно оценить через прирост запоминаемой информации (он же information gain), то есть то, на сколько бит падает суммарная кросс‑энтропия текста, если подать модели наш эмбеддинг. В цифрах этот прирост показывает таблица ниже:

Модель	Токенов (base)	Токенов (+low-dim)	Прирост
Llama-3.1-8B	1438	1697	1.2×
Pythia-1.4b	430	500	1.2×
SmolLM2-1.7B	335	957	2.9×
Gemma-3-4B	214	697	3.3×

Прирост неравномерный: у SmolLM2 и Gemma низкоразмерная проекция даёт почти трёхкратный скачок, а вместе с ним растёт и information gain: у SmolLM2, например, с 1208 до 3271 бит.

Траектории оптимизации живут в низкой размерности

Помните, я говорил, что progressive cramming даёт нам «след» оптимизатора? Давайте на него посмотрим.

Для каждого примера у нас есть последовательность эмбеддингов { $\mathbf{e}^{(k)}$ } — по одному на каждый новый сжатый токен. Мы прогнали по этой последовательности PCA и задались вопросом: сколько компонент нужно, чтобы объяснить 99% дисперсии этой траектории?

Ответ оказался неожиданно скромным: 30–100 компонент — и это при том, что сами эмбеддинги живут в пространстве размерности 2048–4096! То есть, хотя оптимизатор блуждает в тысячемерном пространстве, его путь фактически укладывается в тоненькое низкоразмерное подпространство. Причём, число компонент растёт с длиной текста логарифмически.

Число главных компонент, объясняющих 99% дисперсии траектории, медленно (примерно логарифмически) растёт с длиной префикса. — Число главных компонент, объясняющих 99% дисперсии траектории, медленно (примерно логарифмически) растёт с длиной префикса

Ещё нагляднее это видно на анимации: спроецируем траекторию на две первые главные компоненты (для примера с длиной 1000 токенов у Llama они объясняют 65.7% дисперсии) и покажем заодно «ландшафт точности» — области, где реконструкция почти идеальна.

Траектория оптимизации в проекции на PC1–PC2 и сжимающиеся области высокой точности

Точки — оптимизированный эмбеддинг на каждой длине префикса. Цветные области — «бассейны» высокой точности реконструкции. По мере роста текста бассейн сжимается — оптимизировать становится всё труднее.

Здесь есть тонкость, которую легко упустить. Низкая размерность — это свойство пути, а не множества решений. Мы проверили: если запустить оптимизацию для одного и того же префикса из одной точки, но с разными learning rate, получившиеся (одинаково хорошие!) решения оказываются в 1.5–1.6 раза дальше друг от друга, чем от старта, и почти ортогональны (хотя последнее не удивительно для пространства высокой размерности). То есть множество валидных эмбеддингов широкое и высокоразмерное — а low‑dim траектория лишь тонкий срез внутри него.

Реконструкция ≠ понимание

Теперь — к самому важному. Допустим, мы идеально сжали префикс в эмбеддинг. Если этот эмбеддинг честно кодирует смысл текста, то модель, получив его, должна не хуже решать задачи, связанные с этим текстом. Проверим?

Мы взяли стандартные бенчмарки с коротким контекстом — HellaSwag и ARC‑Easy — и сравнили два режима:

Base: обычный префикс на входе.
+Emb: наш сжатый эмбеддинг плюс тот же самый префикс в контексте.

Обратите внимание: во втором режиме оригинальный текст никуда не девается, он по‑прежнему в контексте. Мы всего лишь добавляем спереди сжимающий эмбеддинг. Если он кодирует что‑то осмысленное — точность должна как минимум не упасть.

Протокол likelihood-оценки: сжимающий эмбеддинг + префикс + варианты продолжения, ранжируемые по правдоподобию.

Ну, и цифры:

Модель	HellaSwag (Base)	HellaSwag (+Emb)	ARC-E (Base)	ARC-E (+Emb)
Pythia-1.4b	44.0%	37.6%	53.1%	49.1%
SmolLM2-1.7B	53.6%	37.0%	67.3%	56.0%
Llama-3.1-8B	61.9%	40.8%	63.5%	43.3%

Точность стабильно падает у всех моделей. Заметно — хотя и остаётся выше случайного угадывания (25% на этих четырёхвариантных задачах). Причём это именно эффект эмбеддинга, а не остаточных ошибок реконструкции: если ограничиться только идеально восстановленными примерами (а их 95–98%), картина не меняется.

Более того: на 5-shot MMLU (это уже генерация ответа, а не выбор из вариантов по правдоподобию) добавление сжимающего эмбеддинга приводит к падению точности практически до нуля: модель перестаёт выдавать адекватные ответы вообще. При этом случайный контрольный эмбеддинг (просто шум) сохраняет точность почти нетронутой. Значит, дело не в том, что мы подали «непонятный токен» — дело именно в оптимизированном эмбеддинге, который ломает семантическое понимание моделью сжатого контекста.

Вот он, парадокс: эмбеддинг, который идеально восстанавливает текст, при этом ломает способность модели этим текстом пользоваться. Идеальная реконструкция — это не гарантия сохранения смысла.

Разбираем механизм: причина — в первых слоях

Ок, реконструкция что‑то ломает. Но что именно и где? Чтобы установить причину, мы применили attention knockout: на выбранных слоях мы маскируем логиты внимания, направленные на компрессионный эмбеддинг, полностью убирая его влияние на этом слое, и смотрим, как это повлияет на качество реконструкции и на метрики бенчмарков. Ключевые эксперименты на Llama-3.1–8B (32 слоя):

Прямой кумулятивный (forward) — глушим эмбеддинг на слоях с 0-го по ‑й (от ранних к поздним).
Обратный кумулятивный (reverse) — глушим эмбеддинг на слоях с ‑го по последний (от поздних к ранним).

Прямой vs обратный куммулятивный knockout внимания на Llama-3.1-8B. — Прямой vs обратный кумулятивный knockout внимания на Llama-3.1–8B

Результат оказался красивым и однозначным: всё дело в forward/reverse‑асимметрии. Прямое глушение (сначала ранние слои) восстанавливает способность рассуждать буквально после первых нескольких слоёв. Обратное (сначала поздние) — почти не помогает, пока не дойдёт до ранних. Это и есть причинное доказательство: downstream‑провал вызывают взаимодействия в ранних слоях.

Мы воспроизвели эти результаты на Pythia-1.4B и SmolLM2-1.7B — картина та же. Получается, сжимающий эмбеддинг «рулит» моделью через ранние слои: эти взаимодействия необходимы для реконструкции, но именно они мешают модели нормально пользоваться контекстом.

Как ёмкость меняется с изменением архитектуры?

Чтобы получить оценки ёмкости в зависимости от количества слоев, мы брали первые слоев модели и дообучали на fineweb‑edu шагов. Ёмкость сжатия монотонно растёт и с числом сохранённых слоёв (глубина), и с размером модели (ширина).

Тепловая карта: число идеально сжатых токенов растёт и по глубине, и по ширине модели. — Тепловая карта: число идеально сжатых токенов растёт и по глубине, и по ширине модели

Тут видно сразу две закономерности:

Глубина. Внутри одного семейства число идеально сжатых токенов растёт с числом слоёв — примерно удваивается при удвоении глубины (например, для Qwen3-8B: 119 → 180 → 304 → 625 на 1/2/4/8 слоях).
Ширина. При одинаковой глубине более крупная модель сжимает больше (Qwen3-8B > Qwen3-4B > SmolLM3-3B на каждом ).

И эти оси частично взаимозаменяемы. 8-слойный Qwen3-8B (625 токенов) обгоняет полную 36-слойную Qwen3-4B (512)! А у SmolLM2 всего 8 первых слоёв (455 токенов) сжимают больше, чем полная модель (335). Скорее всего, это связано с дообучением, но это свойство не удалось воспроизвести на других моделях.

Два бонусных сюжета

1. Сложность токена предсказывается его «неожиданностью»

А можно ли предсказать заранее, какой токен будет «дорогим»? Оказалось — да. Surprisal токена (его неожиданность, $− log\ p$ по базовой модели) хорошо коррелирует с числом шагов, которое progressive cramming тратит на этот токен: корреляция Спирмена здесь в диапазоне 0.44–0.59. Чем неожиданнее токен для модели — тем дороже будет добавить этот токен к сжатой последовательности.

2. Температура кросс‑энтропии двигает компрессию по фронту «количество vs плотность»

Мы добавили в лосс реконструкции температуру : делим логиты на перед софтмаксом. «размягчает» распределение, а — заостряет. Тонкость в том, что критерий сходимости у нас — совпадение по argmax, а он инвариантен к любому положительному масштабированию логитов. Значит, температура не может изменить, какое решение достижимо в принципе, — она меняет только путь оптимизатора к нему. И вот что из этого вышло:

Проступают три чёткие тенденции: (i) число сжатых токенов образует перевёрнутую параболу с максимумом при (у Llama — аналогично, 1574 токена); (ii) а вот information gain максимален при более тёплом $T \approx 0.75$ — то есть «сколько токенов влезло» и «сколько информации несёт эмбеддинг» максимизируются при разных температурах; (iii) и длина траектории, и её размерность (PCA 99%) монотонно сжимаются с ростом .

Что это всё значит

Соберём выводы вместе:

Идеальная реконструкция — не гарантирует сохранение семантики.
Виноваты ранние слои.
Ёмкость связана с архитектурой модели.

Что дальше? Мы пока не знаем, как сделать эмбеддинг одновременно идеально восстановимым и семантически осмысленным — это, пожалуй, центральная нерешённая проблема. Progressive cramming дорог (примерно вдвое медленнее full cramming и плохо батчируется). А результаты с низкоразмерной проекцией намекают, что, возможно, есть алгоритмы оптимизации, которые бы могли найти точку, в которой можно было бы сжать и ещё большее количество токенов.

Спасибо, что дочитали!

Спасибо соавторам: Тимофею Лашукову, Елизавете Гончаровой и Андрею Кузнецову за проделанную работу! Спасибо коллегам и авторам оригинальной идеи крамминга: Юрию Куратову, Айдару Булатову, Михаилу Архипову и Михаилу Бурцеву за обсуждения.
И спасибо Марату Хамадееву за помощь в редактировании хабротекста!

Ссылки:

? Статья: Progressive Cramming: Reliable Token Compression and What It Reveals (ICML 2026)
? Исходная статья про крамминг: Cramming 1568 Tokens into a Single Vector and Back Again: Exploring the Limits of Embedding Space Capacity (ACL 2025)
? Код github.com/FusionBrainLab/progressive_cramming
? Датасет с траекториями оптимизации mrsndmn/progressive_cramming_trajectories
? Демо в Colab