Комментарии 19
Спасибо за интересный обзор. Очень похоже на то, что разработчики скрестили трансформеры с rnn. Это выглядит особенно иронично на фоне названия статьи про трансформеры "Attention Is All You Need". Получается "Is Not All You Need" :)
Это просто логическое продолжение эволюции сетей.
Настоящее скрещивание трансформеров с RNN это RetNet, где вместо квадратичного attention используется т.н. retention с линейной сложностью от длины последовательности. Задумка там любопытнейшая - они так поменяли граф вычислений, что стало возможно производить инференс одного токена за константное время, как в обычной RNN, но при этом обучать его можно как трансформер - параллельно. Получили в итоге многократный рост метрик производительности и расхода памяти как в обучении, так и в инференсе.
Значит ли это, что на основе титана, уже можно реализовать генерацию 3д моделей деталей промышленных роботов в CAD?
Ну так Titan получается - тот же трансформер, но слегка усложнённый. Добавлена долговременная память, в которую попадают "удивившие" сеть факты.
Странно что до этого подобное ещё никто не реализовал.
Конечно реализовывали. Это просто ещё один вариант линейной rnn (типа mambы, разных линейных attentionов и тд). Собственно, тут в скриншотах из статьи целая пачка их приведена. По сути друг от друга они отличаются только тем, какое аффинное преобразование применяется к предыдущему состоянию при поступлении нового токена (но на самом деле это тоже немаловажный момент, т.к. в зависимости от этого преобразования можно получить возможность решать задачи из NC1, либо остаться в TC0, ну и конечно "качество" памяти тоже будет меняться).
Хотя я уже что-то не особо уверен что это ещё один linear rnn. Статья написана отвратительно если честно, я не могу понять, является ли механизм памяти, который там приводится в явном виде (в конце пейпера) - это то что подразумевается в остальной статье и используется в бенчмарках (в т.ч. упоминается что между чанками есть нелинейные зависимости, однако где они в этой формулировке я так и не увидел)
Для меня описанный механизм выглядит аналогично ручному обогащению контекста выжимками из предшествующих сообщений. Но естественно не на уровне матриц нейронных связей, а в виде текста добавляемого к аромату.
Уже есть репозиторий на гитхаб с реализацией MAC на основе статьи https://github.com/lucidrains/titans-pytorch
.
Именно основываясь на этих связях модель может глобально понимать тексты, которые читает, а затем один за одним предсказывать следующие токены, из которых получаются осмысленные ответы на ваш запрос.
Вы допустили несколько опечаток в
Именно благодаря такому построению связей многие ко многим модель избавляют от необходимости понимать текст для предсказания следующего токена. Модель действует просто как болванчик в Китайской Комнате. (читай Ложная Слепота Питера Уоттса.
Другими словами, у нас есть некоторый core – стандартное внимание с ограниченным окном, которое применяется, например, к последнему сообщению в диалоге; – и модуль, который хранит важную информацию из "далекого прошлого". Эта важная информация может быть постоянной (модуль постоянной памяти) или обновляться прямо во время инференса (модуль долгосрочной памяти).
Похожий механизм реализуется в виде доп инструментов в text-generation-webui. См. напр., плагин Twin Book или всякие плагины персистентной памяти. В принципе можно наверное периодически делать саммэри и пихать его в любое место контекста. Но это конечно не онлайн решение.
Ну и в итоге в конце статьи указано, что самый эффективный вариант - память как контекст. И этот вариант худо - бедно реализуется и с текущими архитектурами. Хотелось бы узнать есть ли принципиальная разница между ручным наполнением контекста запрошенным выжимками и предложенной Гуглом архитектурой. И пожалуйста без токса вида "а вы вообще статью читали".
Для контекста. Например, в ядре Линукс вот столько токенов на текущий момент, если взять всю кодовую базу в один файл и посчитать токенизатором для GPT-4o: 456 479 607
Ну и пара примеров «маленького» софта: VS Code 31 062 093 , Moodle 73 021 682
Цифры примерные, так как подходы к счёту токенов есть разные, как и к созданию файла с кодовой базой, но порядок величины можно узнать, хотя и различия в подходах будут составлять внушительное количество токенов (миллионы). В данном случае при подсчёте использовался такой подход: в начале файла дерево кодовой базы, далее с переносом строки содержимое всех файлов подряд (рекурсивный обход, как и в случае с деревом) в формате <file_name.file_extension>```\n<file_content>\n```\n\n, что добавляет лишние строки (например, количество строк для ядра Линукс выросло с реальных 30 млн (информация с Википедии) до 40 млн, следовательно выросло и количество токенов), но это необходимо для разделения содержимого файлов и общей «читаемости» файла со всей кодовой базой... Также можно было бы встраивать содержимое прямо в дерево, но это сделало бы дерево прерывистым и некрасивым.
Итак, я написал статью, если кому интересно: https://habr.com/ru/articles/875022/
По сути это очень похоже на рассуждающую o1, только у этой контекст каждый раз новый, а память от старого. Я думаю именно поэтому их последняя gemini так хороша в рассуждениях.
Ждем следующую итерацию, когда они догадаются весь контекст несколько раз прокручивать, чтобы снизить деградацию памяти.
Google представили Titan: архитектуру нейросетей, которая может стать новой серебряной пулей LLM