Comments 13
Читая о mem-векторах, невольно ловишь себя на мысли, что это одна из тех технологий, которые могут либо перевернуть наше представление о работе с языковыми моделями, либо остаться интересной, но непрактичной идеей.
Главное преимущество, которое сразу бросается в глаза — это возможность кардинально увеличить объём информации, доступной модели. Вместо того чтобы дробить документы на кусочки, которые помещаются в ограниченное окно контекста, мы просто загружаем в модель несколько mem-векторов — и вот она уже "знает" содержимое целой библиотеки. Особенно занимает перспектива обновлять знания модели без её переобучения. Это могло бы решить одну из самых болезненных проблем современных LLM — их статичность после обучения.
Но вот что действительно заставляет задуматься — практическая реализация. Нынешний процесс создания mem-векторов трудоёмкий и медленный. Пока не будет найден способ быстро генерировать эти векторы (через специальный энкодер), технология останется уделом лабораторий.
Ещё вопрос: как поведёт себя модель, когда в её "памяти" окажутся противоречивые данные из разных mem-векторов? Не приведёт ли это к ещё большим проблемам с галлюцинациями?
В общем, технология действительно выглядит многообещающей.
В статье предложен способ генерации - другой моделью. Это, можно сказать, дефолтный вариант на все случаи жизни в 21 веке...
Для хорошей генерации потребуется модель сопоставимого размера, может быть её можно сделать не обучая с нуля, а путем дообучения нескольких слоёв.
Кроме того, есть масса перспектив, от возможности использовать отдельное пространство для ключей (если хранить знания ключ-значение и вытягивать их по необходимости из огромной библиотеки, что-то вроде позиционного экнодинга, только семантического отдельного пространства - модель как бы умеет обращаться к своей памяти и умеет запоминать новую информацию и так же умеет тренироваться и обучать себя новому поведению - фактически все, что было до этого - это пролог, а сейчас начнется первая глава), до поиска новых знаний и уникальной информации, тонкой настройки для пользователей или тренировки своего поведения... сейчас появится целый зоопарк токенов разного назначения под разные задачи... модульные трансформеры с памятью и дообучением!
... любой предсказательный модель можно превратить в без потерь компрессор, и наоборот.
Это точно вы написали?
Ссылки на перевод нет, поэтому, вероятно, это ваш личный ход мыслей.
<Kuja> я те в сто тыщ раз сожму инфу.
<Kuja> попроси меня рассказать сюжет СантаБарбары - я тебе отвечу - херня.
Как тяжело читать когда одно и тоже пережевывают несколько раз. Этот текст можно было сжать x10 раз без каких либо алгоритмов сжатия.
А насчет сжатия в x100500 раз есть вопрос. Какова длина вектора, какое соотношение длины вектора к тексту в байтах? А не числа векторов к числу токенов. А то кому то может показаться что одна точка в пространстве это что то около одного бита :)
Я сам исследую модели трансформеров в СколТехе, занимаюсь ими больше 8 лет. Статья написана в исследовательском ключе для исследователей, не на широкую публику, хотя и с сохранением читаемости. Там в целом доступно и понятно обозначены точки роста и вдохновение для будущих исследователей, чтобы максимально ускорить процесс. Не поверите, насколько эта тема может изменить мир через пару лет... по этому не скупился на токены )
По поводу ваших вопросов:
1. Какова длина вектора -- вектор памяти (как описано в статье) подается вместо одного обычного вектора (который, обычно, несет слово или часть слова или букву), размерность тут не меняется, это ровно один токен, только немного не стандартный (обычно токены транслируются из текста по словарю -- а тут мы создаем новый, который модель раньше не видела, но который она может "понять" -- причем эту способность в модели не закладывали, если специально проектировать их архитектуру под эту задачу -- это может все поменять..)
2. В данном стучае говорилось, что один вектор/токен это около 700-2000 чисел с плавающей запятой, т.е. десятки тысяч бит (что избыточно, но так надо для нейросетей, чтобы закодировать "смысл" этого слова и его семантику)
У моделей с сотнями миллиардов параметров есть ограничение на "контекстное окно" на несколько десятков тысяч таких токенов, т.е. учитывая около 1 КБ / токен мы передаем ей на вход от 10 до 100 МБ в виде входящей последовательности (текст, картинки, голос)... причем это эквивалентно всего лишь 100-500 КБ текстовой информации... в этом сейчас затык на обучение еще больших моделей... надо менять архитектуру, иначе требуется суперкомпьютер (около 1 ТБ сверхбыстрой памяти на то, чтобы хранить все веса и текущие активации - на запуск одной модели, которая выдает только 100-200 токенов ответа в секунду)... а в статье предлагается поменять архитектуру в сторону, когда эффективность вырастет на 2-3 порядка и параллельно позволяет интегрировать другие плюшки... (базы знаний, хранение истории, дообучение под задачу -- за счет токенов памяти)
Удачи в ваших исследованиях!
Люди склонны выдумывать себе проблемы, а потом героически их решать.
Какой вообще смысл грузить все эти 10000 векторов контекста в модель?
Смысл нулевой абсолютно, там соседние вектора почти не отличаются друг от друга, и каждый из них несет вполне себе понимание контекста.
Достаточно использовать весьма ограниченное количество токенов, на первом уровне трансформера ближайшие, на втором - каждый второй, на третьем - каждый четвертый
На шестнадцатом - каждый 32000ый
При нормальном обучении и достаточной емкости вектора эмбединга эти вектора сами по себе впитают весь контекст своего уровня, без необходимости что то создавать дополнительное
Я пробовал использовать 32 токена - такую модель довольно просто обучить на обычной видеокарте, результаты вполне сравнимы с тем что получается у авторов из Language Modeling Is Compression
(для их игрушечных моделек, для миллиардных ресурсов нет)
Кстати, если вы посмотрите на результаты работы, то там есть еще один интересный вывод - модель с токенезацией работает хуже чем модель работающая напрямую с байтами
Да вроде как выше написали вполне понятный ответ на ваши вопросы
на первом уровне трансформера ближайшие, на втором - каждый второй, на третьем - каждый четвертый
Это atrous-свёртка. Шаг равен 2^i. Я тоже пробовал на небольших последовательностях в микромодели. Если бы она была годна для больших, то её бы использовали.
Atrous Spatial Pyramid Pooling
https://paperswithcode.com/method/aspp
Трансформеры это как минимум не свертка
В случае свертки использовать dilation может и не имеет смысла, по крайней мере на задачах классификации, там уменьшение разрешения вполне естественная операция - которая кстати ведет ровно к тому же, на каждом уровне берется окно в два раза шире
В случае же трансформера использование только части токенов на порядки повышает скорость обучения при небольшой (на самом деле не знаю какой и есть ли вообще) деградации качества.
И что же, вы считаете, если на 100млн параметров трансформер нормально сходится, то на миллиард перестанет сходится? Это вряд ли.
Кстати для изображений это даже более важно чем для текста, если рассматривать изображение как последовательность токенов, то никакой разумный трансформер не будет в состоянии учесть все предыдущие токены. Отсюда опять все эти костыли, когда за токен принимается кусок 16х16 или сначала используется сверточная нейросеть. Ну костыль же?
Но это же так естественно использовать в качестве соседей не все токены, а лишь какую то выборку - точки на расстоянии 1,3,7 и тд, тогда получается относительно небольшое количество соседей по которым идет обогащение, при этом уже на 8 уровнях пиксель получает полную информацию для генерации. На картинке пример - слева там начальная последовательность-изображение, справа реальное, по центру то что предсказала нейросеть-трансофрмер. Ну круто же! Это не мутный автоэнкодер или вае, реальная же цифра получилась. При этом такая генерация работает сильно быстрее чем всякие диффузеры, так что готовьтесь, скоро картинка как последовательность станет трендом. Главное от обогащения по всем токенам уйти
Вряд ли mem-вектор будет обрабатываться трансформером так же как несжатая последовательность. То есть, не получится подать на вход mem-вектор, кодирующий [В лесу родилась ёлочка], и спросить [Где родилась ёлочка?]. Mem - это "seed" (скорее даже, набор поправок), а не сжатое семантическое представление предложения. Для ответа потребуется раскодировать вектор в последовательность, тем самым потребив ограниченную память контекста.
Mem-векторы: как сохранить 1500 токенов в одном векторе и зачем это нужно