Mem-векторы: как сохранить 1500 токенов в одном векторе и зачем это нужно

От сжатия текста к mem-векторам: новая веха в языковых моделях

Каждый, кто работал с большими языковыми моделями (LLM), знает про ограничение длины контекста: модель не может напрямую обработать текст, превышающий определённое число токенов. Это накладывает ограничения на работу с длинными документами и обширным контекстом. Но что если бы мы могли упаковать длинный текст в один-единственный вектор и скормить его модели как обычный токен? Звучит фантастично, однако свежие исследования показывают, что это возможно – такие “mem-векторы” позволяют сохранить сотни и даже полторы тысячи токенов информации в одном эмбеддинге. Это принципиально иной подход, нежели классическое сжатие данных, и он сулит интересные применения.

Mem-вектор (от “memory vector”) – это специально обученный вектор, который хранит содержание целого текста. Идея в том, что если модель умеет предсказывать текст, то можно подобрать такой вектор на входе, при котором замороженная (неизменяемая) LLM сама декодирует исходный текст. Иначе говоря, mem-вектор играет роль «семени», из которого предобученная модель порождает заложенное в нём сообщение. В этой статье разберём, как это работает, почему вообще возможно “запихнуть” роман в один вектор и какие ограничения при этом появляются. Также сравним mem-подход с классическими алгоритмами сжатия (Huffman, арифметическое кодирование, zlib и др.), обсудим последние научные работы на эту тему и возможные применения: от Retrieval-Augmented Generation (RAG) до передачи новых знаний замороженным моделям. Центральная мысль: mem-векторы – это не просто компрессия текста, а способ напрямую скормить модели смысл и знания, минуя последовательное чтение токенов.

Один вектор вместо тысячи слов: идея и обучение mem-вектора

Как же заставить одну точку в эмбеддинг-пространстве содержать в себе длинный текст? Ключ – использовать предобученную языковую модель как декодер. Представим, что у нас есть замороженная LLM, скажем Llama, которую мы не дообучаем, а лишь добавляем к её словарю новый специальный токен [mem] с trainable-эмбеддингом. Этот [mem] изначально случайный, но мы будем его тюнить (обучать) под конкретный текст. Процесс такой: подаём модели последовательность, начинающуюся с [mem], а дальше заставляем модель предсказывать целевой текст длиной токенов. Параметры модели не меняем, мы оптимизируем только вектор эмбеддинга [mem] так, чтобы вероятность сгенерировать именно наш текст была максимальной. После сходящегося обучения получаем фиксированный вектор – mem-вектор этого текста. На инференсе стоит модели начать генерацию с этого вектора, как она выдаст тот самый текст.

Схематичное изображение принципа mem-вектора.

Слева: длинная последовательность токенов заменяется одним обучаемым токеном [mem] (горящий квадратик). Предобученная LLM (большой жёлтый блок со снежинкой, указывающей на «заморозку» параметров) принимает [mem] на вход и должна самостоятельно воспроизвести исходную последовательность . Обучается только эмбеддинг [mem] под каждый конкретный текст (отдельно для каждого сообщения). Справа: экспериментально измеренное максимальное число токенов, которое помещается в один входной вектор, для разных языковых моделей.*

Интересно, что подобные попытки «упихнуть» много информации в сокращённый prompt предпринимаются давно. Например, методы Prefix-Tuning, Prompt Tuning и др. позволяют сокращать или заменять текстовые подсказки на небольшое число обучаемых векторов (префиксов). С их помощью удалось достичь впечатляющих коэффициентов сжатия – порядка x500 (токенов -> векторы) при обучении с 8-миллиардной моделью, однако то сжатие неполное (lossy): модель вжимает смысл длинного промпта, достаточный для решения задачи, но не обязуется воспроизвести исходный текст дословно. Если требовать именно потокенного восстановления текста (т.е. без потерь), такие методы обычно укладываются лишь в ~10-кратное сжатие. Mem-векторы же нацелены на полное восстановление текста – по сути, это подход к безопасному сжатию с помощью самой языковой модели. И как показали эксперименты, потенциал здесь гораздо выше ожидаемого.

Совсем свежая работа Kuratov et al. (2025) напрямую исследовала пределы такого сжатия, заменив сложный энкодер простым градиентным спуском по одному вектору. Они продемонстрировали, что один-единственный входной вектор способен без потерь кодировать последовательность длиной до 1568 токенов (для Llama 8B) – то есть компрессия примерно x1500! Это на два порядка выше, чем достигалось ранее, и сопоставимо с теоретическим пределом. Более того, если не ограничиваться одним вектором, можно масштабироваться почти линейно: скажем, 2 вектора – около 3000 токенов, 16 векторов – свыше 7000 токенов. По сути, несколько [mem]-токенов могут сыграть роль внешней памяти для модели.

Как такое возможно? Ведь 1568 токенов – это огромный фрагмент текста, обычное сжатие которого (gzip и пр.) вряд ли дало бы 1500-кратное уменьшение длины. Разгадка в том, что LLM обладает знанием языка и мира, а значит, ей не нужно, чтобы mem-вектор «вложил внутрь себя» каждый бит исходных данных. Модель сама восполнит предсказуемые фразы и общие места; вектору надо лишь «подсказать» модели те специфические детали, которые она сама по себе не угадает. Выходит своего рода симбиоз: предобученная модель берёт на себя часть работы по сжатию, экономя место в векторе. Именно поэтому mem-вектор работает: он не хранит весь текст побитно, а направляет модель так, чтобы она сгенерировала нужный текст.

Однако если вставить совсем уж случайный или новый для модели текст, справится ли один вектор? Исследования показывают, что до определённого предела – да. Одно из удивительных открытий Kuratov et al.: даже абсолютно новые данные (например, фанфики, появившиеся после обучения модели, или просто случайные последовательности слов) сжимаются mem-вектором почти так же эффективно, как привычные тексты. Крупная модель (Llama-3.1-8B) уверенно хранит в одном векторе ~800 случайных токенов, которых она никогда не видела. Это говорит о том, что способность к сжатию здесь не основана лишь на “узнавании” знакомых фраз, а действительно отражает большую ёмкость непрерывного представления. Один обучаемый вектор предоставляет «языково-независимую» память, способную хранить совершенно новые тексты или даже цепочки случайных слов. Разумеется, чем более хаотичен текст, тем меньше токенов удастся идеально закодировать в один вектор – но до порога в ~800 токенов даже случайности поддаются сжатию.

Энтропия и пределы ёмкости: почему не все тексты ужимаются одинаково

Добиться таких поразительных результатов помогает сама теория информации. Ещё Клод Шеннон показал, что любой оптимальный метод сжатия достигает среднего числа бит на символ, равного энтропии источника (распределения символов). Проще говоря, минимально возможный размер сжатого сообщения определяется непредсказуемостью содержимого. Языковая модель – это как раз предсказатель текста; она оценивает распределение вероятностей для следующего токена. Если текст легко предсказать (низкая энтропия по модели), то и кодировать его коротко легче. Если же текст для модели неожиданен, его априорная энтропия высока, и никакая магия не впихнёт его в сверхмалый объём без потерь – придётся передавать много информации.

В случае mem-векторов роль «кодировщика» выполняет обученный эмбеддинг, а «декодер» – сама LLM. Можно представить, что вектор старается уменьшить неопределённость модели относительно данного текста. И действительно, в упомянутой работе вводится показатель Information Gain – выигрыш в информации, который даёт mem-вектор, снижая кросс-энтропию (логарифмическую потерю) на последовательности. Оказалось, что у каждой модели есть порог информационной ёмкости, выраженный в битах: если исходная энтропия текста (без всякого conditioning) ниже этого порога, то mem-вектор способен полностью снять неопределённость и точно восстановить текст. Иначе говоря, модель сможет его сжать без потерь. Этот порог примерно соответствует тем самым максимальным длинам текстов, наблюдаемым в экспериментах (обозначается красной линией на графиках в их статье). Когда же требуемой информации больше, чем может уместиться в одном векторе, происходит частичное сжатие: mem-вектор всё равно понижает кросс-энтропию текста, но уже не до нуля ошибок – модель будет генерировать наиболее вероятный вариант, не полностью совпадающий с оригиналом.

От чего зависит, «сколько бит» информации нужно на конкретный текст? От сложности и новизны содержания. Можно говорить об токеновой энтропии и семантической энтропии. Первая отражает, насколько непредсказуемы конкретные слова/токены для модели. Например, общие слова вроде “the”, “и” модель и так угадает, их не нужно жёстко кодировать. А вот редкое имя или случайная последовательность символов потребует уделить ей бóльшую долю ресурсов вектора – иначе модель выдаст что-то более привычное. Семантическая же энтропия касается смысла: если факт или событие уже заложено в знаниях модели, для неё это менее сюрпризно. Пример: модель знает, что столицей Франции является Париж. Если оригинальный текст гласит “столица Франции – Париж”, то модель и без подсказок правильно продолжит фразу, затратив минимум «информации» из вектора. Но если в тексте утверждается “столица Франции – Лион” (наоборот, неожиданный или ложный факт), то mem-вектору придётся изрядно потрудиться, чтобы заставить модель вывести именно «Лион» (ведь её знание противоречит этому). Проще говоря, чем более нестандартен или детализирован текст, тем больше информации нужно вписать в вектор, и тем скорее достигнется предел его ёмкости.

Другой аспект – тональность и стиль. Модель может генерировать грамматически правильный текст, но не угадает авторский стиль или эмоцию, если они не типичны. Поэтому, чтобы восстановить точно такой же тон повествования, mem-вектор должен закодировать и эти нюансы – от выбираемой лексики до пунктуации и ритма. Информационная плотность текста тоже играет роль: вода и канцеляризмы сжимаются легко (модель сама их вставит при необходимости), а лаконичный текст, насыщенный фактами, требует больше "творческих" бит. По сути, mem-вектор должен передать модели всё, что она не сможет предсказать из общего опыта и своих знаний.

Чтобы визуализировать это, можно представить текст, где одни фрагменты очевидны модели, а другие – нет. Например, возьмём предложение:

«В 1927 году изобретатель Фило Фарнсуорт впервые передал электронное телевизионное изображение.»

Для современной модели эта фраза частично знакома: сама конструкция "в X году изобретатель Y сделал Z" типична, и модель, зная историю телевидения, вероятно, знает факт про Фарнсуорта. Но она могла не запомнить точный год. Токены с высокой энтропией здесь – «1927» (конкретная дата) и, возможно, имя «Фарнсуорт», если оно не настолько распространено. Mem-вектору пришлось бы выделить «ресурс» именно под эти токены, в то время как слова «передал первое электронное телевизионное изображение» модель сама предскажет почти правильно по контексту. Если бы вместо реального факта мы вставили заведомо неизвестный модели биты информации – скажем, случайное число или вымышленное имя – то доля вектора, ушедшая на их кодирование, сильно возросла бы.

Таким образом, ёмкость mem-вектора ограничена энтропией текста. На практике это значит, что не длина сама по себе, а информативность содержания лимитирует, сколько токенов можно упаковать. В эксперименте для каждой модели строилась зависимость: кросс-энтропия текста без условного вектора vs. кросс-энтропия при условии наилучшего mem-вектора. Получились почти прямые линии: прибавка информации от вектора – величина постоянная для данной модели (т.е. “infogain” одинаков), пока не достигнут порог. Если исходный текст менее «сложный», чем этот порог – он сжимается полностью (точки ниже порога на графике). А более сложные тексты всегда остаются чуть выше порога, сколько их ни компрессируй одним вектором. Более мощные модели имеют и более высокий порог (они и сами предсказывают лучше, и эмбеддинги у них длиннее). Например, крошечная Pythia-160M могла упаковать без потерь тексты ~80 токенов длиной, а Llama-3.1-8B – порядка 500+ токенов из художественного текста PG-19 и до ~800 токенов случайного словесного “шума”. Если же дать Llama-8B несколько mem-векторов, она кодирует и 3000, и 7000 токенов, пока не упрётся уже в собственный лимит контекста.

Важно подчеркнуть, что mem-вектор – это не магия и не “странный новый тип памяти” в сетях, а проявление известного принципа: хорошая прогностическая модель = хороший компрессор данных. LLM за счёт обучения на огромных корпусах стала отличным предсказателем текста, а значит, способна сжимать информацию об этом тексте до близкого энтропийному пределу, запоминая только отклонения, новые факты и знания. Если бы мы реализовали классическое арифметическое кодирование на основе предсказаний той же модели, мы бы по сути получили столь же компактное представление (но в виде битового потока). Mem-вектор – альтернативный путь: вместо вывода последовательности бит мы настраиваем вход модели (её непрерывное состояние) таким образом, чтобы та выдала нужное сообщение. Грубо говоря, мы “зашиваем” сжатый код прямо в нейронный вектор. Конечно, этот код сложно читать человеку, но он понятен машине – в этом его сила.

Классические методы сжатия vs. сжатие знания моделью

Поставим mem-вектор в контекст привычных алгоритмов сжатия. В традиционном сжатии, будь то Huffman, LZ, zlib или другие, компрессор и декомпрессор явно обмениваются информацией в битовом виде. Например, Хаффман-код назначает чаще встречающимся символам более короткие коды, реже – длинные, тем самым в среднем экономя место. Арифметическое кодирование идёт дальше: оно достигает теоретического минимума, используя вероятности следования символов. В идеале, если у нас есть идеальная языковая модель-предсказатель, можно кодировать текст с плотностью, равной его энтропии по этой модели (Shannon-limit). Это и делают передовые ML-компрессоры: например, трансформеры, совмещённые с арифметическим кодированием, уже демонстрируют отличные результаты на сжатии текстов. Однако все эти алгоритмы выдадут вам поток бит/байтов, который затем нужно декодировать.

Mem-вектор кардинально отличается формой представления. Это не последовательность бит, а одна точка в пространстве высоких размерностей. Эта точка имеет чрезвычайно большую информационную ёмкость (за счёт непрерывных координат, которые можно записать с высокой точностью). Например, обычный эмбеддинг размерности 2048 из 16-битных чис несёт 32768 бит информации, чего достаточно, чтобы закодировать около 1931 токен из словаря 128k без потерь! Конечно, классические методы тоже могли бы сжать ~2000 токенов (в зависимости от содержания) в ~4 КБ данных, так что по чисто объёму байтов mem-вектор не победит хороший zip-архив. Но тут цель иная – минимизировать длину последовательности для модели, а не размер файла на диске. Один mem-вектор всегда будет для модели одним токеном, сколько бы бит в нём ни заключалось. Это значит, что с точки зрения затрат на инференс мы получаем колоссальное выигрыш: модель обработает 1500 токенов текста, как будто прочитала 1 токен. Разница экспоненциальная, учитывая квадратичную сложность self-attention.

Есть и другая сторона: кто выполняет работу по сжатию. В классических алгоритмах компрессор тратит вычисления на то, чтобы проанализировать данные и выплюнуть сжатый код (декодер потом тратит ещё чуть-чуть, чтобы разжать). В случае с mem-вектором, бóльшая часть работы отдана самой LLM. Можно сказать, мы воспользовались тем, что модель уже натренирована “сжимать мир” в свои параметры. Вес модели – это как бы разбухший архив знаний о языке и фактах. Поэтому, когда дело доходит до конкретного текста, нам остаётся лишь докинуть недостающее: mem-вектор содержит дифференциальную поправку, которая нужна, чтобы модель воспроизвела именно нашу последовательность, а не просто самый вероятный для неё текст. В итоге компрессор (оптимизатор) находит эту поправку, а основное «распаковочное» устройство – сама LLM – уже было создано заранее.

Стоит отметить, что mem-вектор привязан к конкретной модели. Он сработает только на той LLM, для которой обучен, и бессмыслен для другой. Это как сжатие с помощью специфичного алгоритма: без знания алгоритма (тут – модели) данные не восстановить. Зато, в отличие от self-contained архива, mem-вектор вовлекает внутреннее знание модели. Например, если модель знает, что «unicorn» – мифическое существо, а «розовый» – это pink, то чтобы закодировать фразу «розовый единорог» на выходе, mem-вектору не нужно хранить в себе понятия “розовый” и “единорог” – он может выдать сигналы, которые активируют у модели соответствующие концепты. В каком-то смысле mem-вектор пользуется “общим словарём” с моделью, только словарь этот – не явный список, а многомерное пространство значений.

С практической точки зрения, обычный zip-файл, конечно, удобнее: его можно переслать кому угодно, и тот распакует без 175-миллиардного трансформера под рукой. Mem-векторы же пока скорее исследовательский инструмент и способ взглянуть на модели иначе. Но даже в прикладном плане они могут найти нишу, о чём далее.

Свежие исследования: рекорды, теория и реализованные прототипы

Идея сжимать последовательность токенов в плотное векторное представление витала в NLP давно. Ранние работы над сентенс-эмбеддингами и автоэнкодерами текста ставили целью поймать «суть» предложения или абзаца в фиксированный вектор. Однако там речь чаще про семантическое представление (для поиска или сравнения значений), а не про дословное восстановление текста. Тем не менее, они заложили базу методов для обучения энкодер-декодерных моделей, которые компрессируют текст. Современные же LLM столкнулись с практической проблемой: контекст короткий, а вычисления дорогие. Отсюда интерес к плотным промптам: учёные экспериментировали с заменой длинного ввода небольшим набором обучаемых векторов, называемых по-разному – prompt tuning, prefix tokens, токены памяти и т.д.. Эти подходы показали, что даже большие отрезки текста можно сжать без критической потери информации для решаемой задачи, если модель достаточно умна. Так, Lester et al. (2021) продемонстрировали, что 20 обучаемых токенов-префиксов могут заменить текстовый промпт при переносе модели на новую задачу. Li & Liang (2021) ввели термин «prefix tuning», добившись, чтобы GPT-2 генерировал требуемый стиль текста, используя всего ~100 дополнительных эмбеддингов вместо полноценной fine-tuning модели.

Однако вплоть до недавнего времени казалось, что полностью восстановить оригинальный текст из короткого вектора нереально, если сжатие сильнее чем 10:1. Прорыв случился с работой «Cramming 1568 tokens into a single vector…» (2025) от группы из AIRI/MIPT. Они отказались от попыток обучить универсальный энкодер, а просто стали оптимизировать вектор под каждый образец (да, медленно – зато без компромиссов). Их результаты мы частично уже приводили: одиночный mem-вектор вместил до ~1500 токенов текста, а 32 вектора – целую главу в 2016 токенов для модели Pythia, что равно её максимальному контексту. В случае 1-вектора для разных моделей получилась шкала (см. график ниже): начиная от ~80 токенов для 160-миллионной Pythia и доходя до ~500 токенов для Llama-3B и ~1000+ токенов для Llama-8B. Отличается и тип текста: случайные слова компрессируются хуже (но всё же сотни токенов укладываются), литературные тексты лучше, а специализированные фанфики – примерно так же, как и обучающие PG-19, что показало отсутствие преимущества “знакомых” данных. Иными словами, модель сжимает не за счёт прямого запоминания конкретных кусков, а за счёт общей статистики языка. Авторы также проверили, насколько длина эмбеддинга (размерность) влияет против качества модели: маленькие модели страдают не только от меньшего d_model, но и от худшего next-token прогноза. Большие же имеют и высокую точность предсказания, и большее непрерывное пространство – оба фактора увеличивают максимальную емкость mem-векторов.

Максимальная длина текста (в токенах), которую разные модели способны безошибочно декодировать из одного входного вектора*. По оси X – модель (с указанием размера параметров), по оси Y – число токенов исходного текста. Синими точками показаны экспериментальные данные для различных LLM; над точками подписан достигнутый максимум. Красной звёздой отмечен рекорд – 1568 токенов, сжатых в один вектор для модели Llama-3.1-8B. Видно, что ёмкость растёт как с увеличением масштабов модели, так и при переходе от устаревших архитектур (Pythia, OPT) к более совершенным (Llama, Meta Llama 3.1). Например, Llama-1.3B даёт рывок вперёд относительно OPT-1.3B при схожем размере, а у экспериментальной модификации Llama (“Sheared”) ёмкость даже выше, чем у базовой версии того же масштаба.*

Ещё одна интересная недавняя работа – «Language Modeling Is Compression» (Delétang et al., 2023). В ней авторы акцентируют внимание на фундаментальном родстве между задачей моделирования языка и задачей сжатия данных. Они показывают, что большие модели действительно становятся универсальными компрессорами: например, модель Chinchilla 70B (обученная на тексте) смогла сжать изображения ImageNet до 43% от исходного объёма и аудиозаписи LibriSpeech до 16% – обойдя профильные алгоритмы PNG (58%) и FLAC (30%) соответственно! Это впечатляющий результат, демонстрирующий, что LLM ухватывают статистическую структуру данных даже вне текстовой области. И хотя напрямую mem-векторы там не рассматривались, работа подкрепляет нашу историю: если модель столь хорошо предсказывает разнообразные данные, она тем самым обеспечивает колоссальное сжатие. В самом деле, существует теоретическое утверждение, что любую предсказательную модель можно превратить в компрессор информации без потерь, и наоборот. По сути, обучение модели максимально вероятно воспроизводить данные равносильно минимизации длины их оптимального кода. Поэтому использование LLM для сжатия – логичный шаг. Delétang et al. также обсуждают, как рассматривать in-context learning (обучение на примерах в контексте) как форму сжатия обучающих данных внутри промпта. Если посмотреть под этим углом, становится понятнее, почему увеличения контекста и улучшения архитектур так важны – это ведь расширение способности модели “компрессировать” нужную информацию у себя в скрытом состоянии. Mem-векторы прекрасно вписываются в эту парадигму: они максимально используют потенциал сжатия, заключённый в текущих параметрах LLM.

Отметим и другие смежные направления. Архитектуры с внешней памятью (Memory-augmented Transformers) уже интегрируют специальные эмбеддинги, служащие для хранения и передачи информации между сегментами контекста. Пример – модель RMT (Recurrent Memory Transformer) от тех же авторов Kuratov et al.: она добавляет несколько обучаемых токенов-памяти, которые переносятся из одного блока текста в следующий, позволяя модели как бы бесконечно продолжать контекст, запоминая суть предыдущего. Mem-вектор можно рассматривать как частный случай такой памяти, только «записанной» не путем обучения модели на большом корпусе, а под конкретный фрагмент. Интересно, что есть работы по latent space reasoning – решению задач целиком во внутреннем латентном пространстве модели. Вместо генерации длинных цепочек рассуждений токен за токеном, модель учат переходить от сразу от вопроса к ответу через последовательность скрытых состояний. Высокоёмкие эмбеддинги помогают подобным подходам, и mem-векторы здесь могут сыграть роль переносчиков информации между шагами рассуждения. Это напоминает, как человек решает задачу “в уме”, не проговаривая все мысли вслух.

В целом, область обучаемых “кусочков памяти” для LLM сейчас на подъёме. В конце 2024 и 2025 появляются работы, где для больших моделей разрабатывают модули долгосрочной памяти: кто-то через дополнительные слои, кто-то через специальные токены. Например, архитектура MemGPT или система Mem0 (2025) пытаются обеспечить диалоговым агентам долговременную память о прошлых разговорах, сжимая и структурируя информацию. Хотя эти решения пока больше опираются на классическое суммирование контекста, в будущем они могут использовать и метод прямого кодирования знаний в векторах. Уже сейчас есть успешные попытки передачи нового знания в замороженную модель через дообучение эмбеддингов (т.н. model patching): модель не трогаем, зато подбираем для неё специальный “вспоминающий” prompt или вектор, который навязывает ей новые факты. Mem-вектор мог бы хранить, к примеру, свежие сведения, появившиеся после тренировки модели, и подмешиваться к запросу, чтобы модель их учла.

Применения: удлинение контекста, RAG, передача знаний

Какие практические выгоды можно извлечь из mem-векторов, помимо академического интереса? Рассмотрим несколько направлений:

1. Расширение контекста LLM и динамический контекст. Если один токен способен представить собой страницу текста, то очевидно напрашивается идея использовать mem-векторы для эффективного увеличения контекстного окна. Например, у нас есть Language Model с контекстом 2048 токенов, и задача – обрабатывать документ в 30k токенов. Вместо того чтобы пытаться увеличить позиционное окно или дробить документ, мы могли бы сжать части документа в mem-векторы и подать модели последовательность таких векторов. Исследования показывают, что при использовании нескольких [mem] эффективность складывается почти линейно. Значит, условные 15 mem-векторов могут представить текст из 15 тысяч токенов. Модель, получив на вход эти 15 токенов-эмбеддингов, развернёт их во внутреннее представление, эквивалентное чтению исходного документа. Конечно, на практике пока для этого каждого mem нужно обучать градиентным спуском отдельно, что небыстро. Но можно вообразить и более быстрый энкодер, обученный генерировать mem-векторы приближённо. В любом случае, подход сулит серьезную экономию вычислений на инференсе: не нужно обрабатывать всю длинную последовательность стандартным трансформером с квадратичной сложностью – достаточно прогнать несколько векторов через модель.

2. Retrieval-Augmented Generation (RAG) с векторными знаниями. В RAG-моделях сейчас популярна схема: внешняя база знаний (например, все документы) хранится для поиска по ключевым словам или семантическим эмбеддингам; по запросу наиболее релевантные тексты извлекаются и добавляются в промпт модели, после чего она генерирует ответ. Узкое место – объем вставляемого контекста. Если найденные документы длинные, их приходится сокращать или выбирается лишь топ-3, что может упустить часть инфы. Mem-векторы способны радикально повысить масштаб: мы можем заранее для каждого документа вычислить его mem-вектор (то есть компрессировать содержание документа в эмбеддинг, понятный данной LLM). Тогда на этапе запроса вместо длинного текста в контекст добавляется его mem-вектор. Модель фактически “читает” документ, раскодируя из вектора основное. Это позволило бы помещать в контекст десятки и сотни документов, не беспокоясь о лимите токенов! Более того, mem-вектора документов можно подготавливать офлайн и хранить в той же базе, а при поиске сразу выдавать нужные. Конечно, такой подход должен учитываться: модель, скорее всего, будет стремиться воспроизвести документ полностью, ведь mem-вектор именно на это её настраивает. Чтобы заставить её ответить на вопрос, надо вместе с mem-вектором дать и сам вопрос, а генерацию направить на ответ. Потенциально, модель сможет интегрировать знание из mem-вектора в свой вывод (например, ответить, опираясь на факты из сжатого документа, не повторяя его целиком). Это направление требует экспериментов: как лучше структурировать вход с mem-векторами, чтобы получить осмысленный ответ? Тем не менее, очевидно, что RAG мог бы выиграть от возможности держать больше знаний «под рукой» у модели без растягивания контекста.

3. Передача новых знаний и обновление замороженных моделей. Большие модели дорого переобучать, и часто возникает задача довнести новые факты. Метод с mem-векторами предлагает элегантное решение: загрузить новое знание в модель через память. Представьте, что у нас есть LLM, обученная до 2021 года, и нам нужно научить её понятиям и событиям 2022-2025 годов. Вместо полноценной дообучения или ручного добавления длинных справок при каждом запросе, можно подготовить набор mem-векторов, каждый из которых кодирует определённый блок новых знаний (например, описание технологии, биографию человека, свежие научные данные). Затем эти векторы можно при необходимости добавлять в промпт. По сути, модель будет воспринимать их как если бы сама читала об этих фактах – разница лишь в том, что чтение происходит через скрытое состояние. В научной литературе уже описаны случаи «knowledge injection» с помощью prompt tuning: когда для новой информации к модели подбирается специальный контекст-префикс, заставляющий её давать ответ с учётом этой информации. Mem-векторы делают то же самое, но компактнее и потенциално надёжнее (ведь они обучены воспроизводить именно нужное знание). Интересно, что mem-вектор может даже противоречить изначальным знаниям модели и переубеждать её на лету. Пример со столицей: модель думает, что Paris, но mem-вектор содержит “France capital is Lyon” – и модель выдаст Лион, несмотря на встроенное знание. То есть mem-векторы дают своего рода превосходство над внутренней памятью модели на этапе генерации, что ценно для коррекции ошибок и обновления фактов.

4. Скрытая передача смысла между моделями или модулями. Коммуникация “векторами знаний” может найти применение в сложных ML-системах. Например, один модуль (или агент) прочёл документ и хочет передать суть другому модулю, не раскрывая подробности прямым текстом (или просто экономя время). Он мог бы выдать mem-вектор этого документа, который другой модуль (при наличии той же модели-декомпрессора) расшифрует. Это чем-то похоже на то, как люди передают друг другу конспекты или ссылки вместо полного текста. Mem-вектор здесь выступает как контейнер смысла, понятный только “посвящённым” (владельцам модели). Замечу, однако, что это не шифрование – злоумышленник с той же LLM может тоже восстановить текст из вашего mem-вектора. Но как способ сжать передачу – очень даже.

5. Мультимодальные применения. Хотя тема нашей статьи – текст, нельзя не упомянуть, что подход может обобщаться. Если есть модель, способная по некоторому вектору порождать данные определённой модальности, можно учить векторы на восстановление картинок, аудио и т.д. Кстати, генеративное сжатие изображений уже исследуется: диффузионные модели или GANы могут служить своего рода декодерами, а код – это латентные векторы. Отличие mem-векторов в том, что они непосредственно “скармливаются” универсальной модели. Есть интересные работы, где большим языковым моделям дают подключку к визуальным данным через специальные проекции. По сути, embedding картинки подаётся в LLM, и она описывает изображение текстом (пример – X-Fusion (2025) и др.). Mem-вектор мог бы представлять, скажем, описание изображения, и модель бы генерировала словесное описание или даже смоделированную сцену. Здесь грань между модальностями стирается: всё становится “текстом” для универсальной модели, просто очень сжатым. Такие идеи пока в зачатке, но движение идёт к унификации представлений.

Заключение: будущее за «памятью» моделей?

Мы рассмотрели концепцию mem-векторов – плотных векторных представлений, способных хранить большие куски текста, и выяснили, что современные языковые модели обладают неожиданно высокой ёмкостью латентного пространства. Mem-вектор – это сжатие текста до предела, используя знания модели о языке и мире. Эта технология показывает: вместо того, чтобы увеличивать модель или контекст, можно научиться эффективнее пользоваться уже имеющимися входами, наполняя один вектор максимумом информации.

Стоит подчеркнуть, что mem-векторы – не просто трюк для сжатия, но и концептуальный инструмент. Они превращают пассивное «чтение токенов» в активную загрузку знаний. С их помощью можно напрямую вводить в модель новые данные, контролировать её поведение или передавать ей смысл, минуя языковой барьер. Это словно мы нашли способ говорить с моделью на её собственном внутреннем «языке векторов».

Конечно, предстоит решить множество практических вопросов. Пока что получение mem-вектора требует оптимизации для каждого текста – это не то, что можно сделать на лету в диалоговом режиме. Но в перспективе возможно создание энкодеров или схем, быстро вычисляющих такие представления. Важна и интерпретируемость: хочется понимать, за счёт чего вектор кодирует те или иные аспекты текста. Будущие исследования, вероятно, раскроют, как различные части эмбеддинга отвечают за факты, стиль, тон и др., и можно ли редактировать содержимое памяти на уровне компонентов (например, поправить одно слово, не пересчитвая весь вектор с нуля).

Вывод: mem-векторы открывают дверь к новым способам взаимодействия с языковыми моделями. Мы видим в них не просто способ ужать текст для экономии, а базовый механизм передачи смыслов. Возможно, через несколько лет будет обычным делом, что помимо самого генеративного движка LLM у нас есть ещё и внешняя «память» в виде набора обучаемых векторов, куда можно что-то записать и потом предоставить модели для размышления. И тогда фраза «умещает роман в одном векторе» станет не фигуральной, а вполне буквальной – и чрезвычайно полезной в практике больших AI-систем.

Ссылки:

• Kuratov, Arkhipov et al. (2025), “Cramming 1568 Tokens into a Single Vector and Back Again: Exploring the Limits of Embedding Space Capacity” – исследование пределов ёмкости эмбеддингов, введение понятия [mem]-векторов, сжатие до 1500+ токенов.

• Delétang et al. (2023), “Language Modeling Is Compression” – связь между моделированием языка и сжатием, LLM как универсальные компрессоры, впечатляющие примеры сжатия изображений и аудио большой моделью.

• Lester et al. (2021), Li & Liang (2021) – работы по prompt tuning/prefix tuning, где обучаемые вектора используются для условного управления моделями (сжатие подсказок, перенос на новые задачи).

• Bulatov et al. (2022), RMT: Recurrent Memory Transformer – архитектура трансформера с рекуррентной памятью (дополнительные токены для передачи информации между сегментами).

• Hao et al. (2024), latent space reasoning – исследование выполнения многошаговых рассуждений в латентном пространстве высокоёмких эмбеддингов без явного вывода промежуточных токенов.

• Репозиторий yurakuratov/hidden_capacity на GitHub – код и ноутбуки для воспроизведения экспериментов со сжатием текста в векторы (включая визуализацию результатов, графики, упомянутые в статье).