Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Долгую память в Transformer оказалось необязательно хранить отдельно в каждом слое: основную работу выполняют несколько слоёв в начале и конце модели. В препринте, который не проходил рецензирование и приводит замеры самих авторов, архитектура Anchor сократила рекуррентное состояние в 16 раз. Для команд, которые разворачивают модели с длинным контекстом на своей инфраструктуре, это предлагает новый компромисс между расходом памяти и точностью извлечения.
Как нашли слои, отвечающие за долгий контекст
Anchor строится на гибриде двух механизмов. Скользящее окно позволяет каждому токену обращаться к недавнему фрагменту контекста, а обучение во время работы (Test-Time Training, TTT) записывает более старую информацию в рекуррентное состояние постоянного размера.
Авторы по очереди отключали каждый механизм в отдельных слоях и проверяли модель на Associative Recall. Этот тест требует найти связанную пару на большом расстоянии в контексте. Если после отключения росла ошибка, слой действительно участвовал в извлечении.
Скользящее окно оказалось полезно по всей глубине модели. Вклад TTT сосредоточился в первых двух и последних четырёх слоях, которые в работе назвали якорными. Отключение TTT в 26 промежуточных слоях почти не изменило перплексию — показатель того, насколько неуверенно модель предсказывает следующий токен, — но уменьшило постоянное состояние в 5,3 раза.
Обратная проверка дала более резкий результат: без TTT в якорных слоях перплексия на WikiText выросла в 48 раз. Значит, одинаковая память на каждом уровне не просто избыточна по размеру. Большая её часть почти не влияет на способность гибрида доставать информацию за пределами локального окна.
Как одна память обслуживает несколько слоёв
Удалить промежуточные состояния недостаточно: у оставшихся якорных слоёв тоже была собственная память. Анализ представлений показал, что эти состояния хранят близкую информацию, но выражают её в разных системах координат. Поэтому прямое копирование состояния между слоями не работает, хотя содержательно записи похожи.
Anchor назначает один слой писателем. Он обновляет общую память при обработке токенов, а остальные якорные слои только читают её. Перед чтением каждый слой пропускает состояние через собственное обучаемое линейное преобразование, которое растягивает и поворачивает представление под нужную систему координат.
Преобразования начинают обучение как тождественные: сначала читатели получают состояние без изменений, затем адаптируют только необходимые направления. Разбор обученных преобразований показывает, что поправка сосредоточена в небольшой части пространства. Это объясняет, почему одной записи хватает нескольким слоям и почему читателям не нужна полноценная отдельная память.
Для переноса предобученной модели авторы заменяют полное внимание гибридными слоями в два этапа. Сначала новая ветвь учится воспроизводить поведение исходной модели и одновременно предсказывать следующий токен. Затем модель адаптируют на длинных текстах PG-19. Одного совпадения выходов слоёв оказалось недостаточно: ошибка копирования уменьшалась, но способность моделировать язык разрушалась, поэтому задача следующего токена здесь служит необходимым ограничителем.
Когда Anchor меняет архитектурный план
На Llama-3.1-8B и Mistral-7B полнота извлечения оказалась в 2,3–3,1 раза выше, чем у LoLCATs. На MMLU преимущество составило 6,7–8,9 пункта, а задержка относительно полного внимания сократилась до 4,3 раза. Результат указывает, что при линеаризации модели стоит сначала проверить вклад памяти по слоям, а не автоматически добавлять состояние в каждый из них.
Проверки охватывают Associative Recall, WikiText, MMLU, RULER и поиск скрытого фрагмента в длинном контексте. На RULER при длине 16K Anchor уже уступил исходной модели и Lizard: общая память хуже удерживает далёкие элементы по мере роста контекста. Архитектура уменьшает стоимость длинного контекста, но пока не заменяет полное внимание там, где требуется одинаково надёжный доступ к любой позиции.
Работа меняет планы прежде всего команд, которые модифицируют веса и архитектуру модели, а затем обслуживают её самостоятельно. Anchor нельзя добавить как настройку при вызове готового API: нужны замена слоёв, обучение преобразований чтения и адаптация на длинных последовательностях. Практический следующий шаг — измерить вклад TTT по глубине на своей модели и данных; если память так же сосредоточена в нескольких слоях, общий бюджет состояния можно сократить до оптимизации серверных ядер.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
