Как человек, который некоторое время уже активно пытается заботать алгосы на собесы, очень рекомендую репу/курс

Понравилось, что есть краткая выжимка теории в тексте и сложность, чтобы не сидеть вечерами за просмотром получасовых видева

P.S. Главное помнить, что наименьшая сложность алгоритма при подходе «из центра-наружу»

NoPE: лучший позишн энкодинг — это тот, которого нет

Правда ли, что позиционное кодирование критически необходимо трансформерам? Оказывается, это справедливо только для энкодеров, а вот декодеры (GPT, LLaMA и тд) могут прекрасно работать и без него!

Похоже, что каузальные маски внимания (которые не позволяют заглядывать в правый контекст) сами по себе являются отличным источником информации о позиции токенов. И более того, трансформер БЕЗ позиционного кодирования лучше обобщается на размер контекста, выходящий за длину примеров из обучения, даже по сравнению с такими мудрёными методами, как Rotary или ALiBi.

P.S. Eсли вас на собеседовании спросят зачем нужнен позишн энкодинг в GPT — можете говорить, что не особо он и нужен 💁‍♂️

Статья, GitHub

LlamaRec: Two-Stage Recommendation using Large Language Models for Ranking [2023] - о том, как рекомендации превратили в ЕГЭ

Итак, какой пайплайн применения LLM для ранжирования придумали товарищи из NVIDIA:

1) Кандидатогенерация без LLM - сначала рекуррентная модель под названием LRURec кушает историю пользователя и в конце выдаёт распределение на следующий документ, из которого берётся топ-20. Обучается такая модель просто с помощью next item prediction.

2) На последней стадии работает уже языковая модель в формате теста.
В качестве промпта в модель подают список названий документов, с которыми взаимодействовал пользователь. Далее модель просят предсказать наилучший следующий документ.

Мы бы хотели получать от модели распределение на следующий документ, чтобы по нему можно было отсортировать выдачу, а также иметь возможность файнтюнить LLM, максимизируя вероятность верного айтема. Чтобы этого добиться, авторы кодируют каждый возможный айтем одной буквой. Таким образом, от модели требуется написать только 1 токен в качестве ответа, на вероятности которого мы и будем смотреть.

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

Таким образом, подобная модель стала бы неподъёмной для использования на том же размере пользовательской истории, и её пришлось бы применять на очень короткой истории. Дало ли бы это значимый ортогональный сигнал засчёт претрейна на данных из интернета? Не знаю, на мой взгляд проект выглядит слишком дорого и есть много более низковисящих фруктов.

@knowledge_accumulator

работа со стартапом из кремниевой долины чек:

- CTO дропаут из стенфорда, скорее всего младше тебя. говорят, умеет в фит-предикт
- инновационная разработка имеет мало общего с наукой. просто почему-то получилось
- аутсорс на ребятах из СНГ
- почему мы решили делать так? а мы просто believe so
- документация для лохов
- аутсорс на индийских ребятах
- после встречи присылаешь картинки с иллюстрацией подходов, про которые ты распинался, потому что так понятнее СТО
- в штате есть mle с опытом 30+ лет (Can you change the username on that AWS machine from “ubuntu” to my name? All my absolute paths in all my projects are broken because of this 👉🏻👈🏻)
- огромные счета за с3, который не заполнен даже наполовину
- при этом отчитываешься за использование гпу, где один час выходит 2-3 доллара
- никто не должен знать, какая модель от OpenAI лежит в основе всего решения
- метрики без хьюман эвала тоже для лохов
- ты прокачался в английском
- ты прокачался в лизании жопы вежливых дипломатичных ответах в письменном английском
- все жалеют юного СТО, потому что верят в продукт
- через год ты всё это повторишь, потому что “да ладно, не так плохо всё было”

SwitchHead: Accelerating Transformers with Mixture-of-Experts Attention
[Статья] [Код]

Смеси экспертов для MLP блоков были неоднократно с успехом применены в больших языковых моделях (в частности в недавно вышедшей Mixtral, и GPT-4 по слухам тоже ей является). Однако, кроме MLP в трансформере можно добиться ускорения за счет использования за счет части голов в MultiHeadAttention. На больших последовательностях Attention слои требуют много вычислений и памяти, и использование части голов даст некоторую экономию.

Даже если бы статья была анонимной, то по цитированиям Шмидхубера при каждом упоминании Attention, можно было бы угадать одного из авторов)

Метод

Наивный подход был бы следующий - иметь предиктор, который предсказывает скор для каждой головы и берет только с наибольшим скором. Однако, проблема в том, что при авторегрессивной генерации могут активироваться разные эксперты и в итоге придется все равно хранить кэш keys и values на все головы (проблема, правда, нынче лечится MultiQueryAttention).

Авторы предлагают следующее - иметь экспертов внутри каждой головы и активировать только часть экспертов на прямом проходе. В этом по сути и вся суть метода.

Эксперименты

Подход валидируют на TransformerXL, который обучают на С4/peS2o 100к шагов. Не самый типичный setting для 2023. Качество замеряют по перплексии на WikiText103, C4, peS2o.

В бейзлайновом трансформере 2 или 10 голов (с одинаковым числом параметров), в предложенном SwitchHead 2 головы с 5 экспертами. Во всех случаях смесь экспертов имеет столько же параметров, сколько и исходная модель. В разных конфигурациях Q, K, V и O проекции могут быть как разбиты на экспертов, так и нет. Перплексия везде примерно +/- одинаковая и будто бы метод не проигрывает сильно в качестве исходному трансформеру с 10 головами (и уверенно опережает двуглавый). Вопрос в том, правда, насколько хорош бейзлайн.

Сравниваются с работой MoA, при том же качестве их подход гораздо экономичнее по памяти, с экономией в ~4-5 раз, в то время, как у MoA выходит ~1.5-3 раза.

Далее, можно сделать MLP тоже экспертами и получить Switch-All модель.
И Switch-All при примерно той же перплексии расходует снова заметно меньше памяти.

Выводы

Специализация attention в трансформере - полезное направление, однако эксперименты выглядят не слишком убедительно. Нет и замеров ускорения, а лишь сравнение MACs между SwitchHead(All) и бейзлайном. Да и в популярном нынче MultiQueryAttention можно было бы активировать часть query проекций и иметь профит в плане памяти и вычислений.

Находка прошлой недели. Опять эти Microsoft релизнули что-то хайповое. Взяли мистраль, поучили 1000 шагов на контрастив, померили в сравнении с их E5 претреновой моделькой, целенаправленно обученной в виде dssm

Получился небольшой прирост, но много подводных камней. Нужны обязательно инструкции, да и в мультияз авторы не рекомендуют мистраль использовать. Но если вы хотите поморочиться с руссификацией и данные ваши подразумевают инструкции. По-моему очень крутое решение может получится

🤗Модель на hf

Unlimiformer c NeurIPS

github
paper

0️⃣ Проблемы?
Длинные последовательности, поэтому невозможность тренировки/долгого тюнинга

1️⃣ Решение?
Меняем cross-attention на индексирование с KNN, knn distances теперь станут как раз attention dot-product scores. В тестовом режиме главная задача заугментировать уже натренированную модель на последовательности разной длинны.

2️⃣ В чем плюсы?
generic approach: Не нужно тюнить. Не нужно добавлять веса. Индексы можно держать и на CPU. Авторы также предлагают разные способы тренировки и тюнинга. Например, юзать unlimformer только на инференсе и делать по нему early stopping.

3️⃣ Как делаем?
KNN на hidden States всех инпут токенов. Каждый блок с cross-attention обращается к KNN и берет только top-K input tokens.

Пайплайн:
- последовательности, что больше заданной длины, пилим на чанки с window size, берем вектора из серединки. Эта техника была тут предложена (’22).
- Создаем KNN index на encoded inputs, юзаем для этого Faiss. Dot-product это similarity metric для KNN index.
- На каждую cross attention head в декодере мы будем делать retrieval top-k.

5️⃣ Что с памятью?
Если у нас теперь задача это вылавливать Kbest set of keys, чтобы максимизировать attention, то, как и самурая у нас два пути (вебкам и айти):
- создать индексы для keys, HeWk, но Wk - head and layer specific, тогда нам нужно создать не один сет векторов, а сеты для keys и для values (2*L*H: L - кол-во декодер слоев, H - кол-во голов), больно и слишком дорого
- поменять порядок подсчета, теперь мы считаем (Hd * Wq * Wk)* He, то есть нам не нужно хранить и создавать отдельно head-layer индексы для keys, мы будем держать только encoder вектора.

Как говорят авторы: на 1млн 16 битных эмбеддингов 1024dim нам нужно будет 2gb памяти, та еще и на cpu можно.

6️⃣ Что по скорости? Ведь у нас дополнительно появляется индексирование.
Важно понимать, что на двух стульях тяжело усидеть и поэтому есть трейд-офф между памятью и speed. (Картинка внизу)

C Бартом реализовано все и буквально любую модель можете включить, а вот с T5 у меня завести пока что не вышло...

#grokaem_nlp