Первым делом, расскажу о своём любимом information retrieval для NLP. Так уж вышло, что волею судьбы, мне выпала честь развивать retrieval based dialogue system в одной крупной финансовой компании. И поэтому хайп, который творится вокруг chatGPT, докатился до меня весьма своеобразно. А именно, я стал думать как подобные механики использовать для улучшения retrieval свойств векторов нашей системы для ведения диалога. И конечно, во-первых, выдумал свой RL-critic подход для векторов (об этом думаю в след.раз), а во-вторых, докатился до статьи InstructOR, код.

Идея: Один эмбеддер, несколько таск.
У нас есть к примеру 3 задачи :
Question Answering, Information Retrieval, Toxic classification.

Мы хотим к запросу Х для каждой таски Yi, дать доп.инструкцию X'i (по сути мы даём больше информации /контекста). Далее, мы выдвигаем гипотезу, что в зависимости от доп инструкции состояние энкодера для каждой задачи будет зависеть от (X, X'i). Следовательно, гипотетически, мы повышаем поисковое разнообразие, сообщаем доп свойства и вообще точнее ищем или предсказываем метки. Окей, вроде, понятно. Как сообщить такие свойства?

Для начала, нужно правильно написать инструкции для каждого примера каждой таски. А именно иметь следующие блоки из шаблона:
1) Домен. В инструкции должно быть указание доменной информации. К примеру, вы рассматриваете задачу рубрикации статей, вам нужно указать тематики (да домен может быть не один).
2)Тип текста: тут пишем о том, инъекцию какого типа мы делаем. Сообщение, запрос, уточнение, извлекаемый текст и тд.
3) Задача. Указываем цель. Классификация намерения, сентимента или же поиск информации, ответ на вопрос.

При этом, читаю статью заметил, что для каждой задачи приведен пример только одной инструкции, которая её характеризует. См. Таблицу ниже. На самом деле, я думаю, их может быть на каждую задачу гораздо больше. И тут админ уже потирает руки над парой интересных идей, как это проапгрейдить. Привет статье. ;)

Вопрос с данными решили. Теперь нужно на уровне архитектуры заложить для пар запрос + инструкция/контекст нужное поведение. Для этого авторы работы приводят классический подход на основе metric/contrastive learning. Всё как я люблю:
1) Берём пары (X, X'i) в каждой задаче.
2) Отбираем из них парафразы и инструкции которые должны вести к одному результату : классу, ответу на запрос или документу и тп.
3) Проводим обучение dssm, которая сводит векторные представления ведущие к одному результату и разводят обратные. Для этого используют в качестве цели entropy_loss в котором в качестве оценки уверенности ставится cosine similarity между релевантными/противоположными парами запрос+инструкция.

З. Ы. Важно: Совершенно не обязательно, что инструкции в таких условных парафразах одинаковые, скорее наоборот. Также поведение энкодера меняется от задаче к задаче тк для каждой задачи мы имеем свою инструкцию.

Модели в основе: имхо любой энкодер, но тут T5-encoder в стиле GTR (тюн энкодера на dssm). При этом модель T5 предобучена изначально на web корпусе.
С вариациями моделей в разных размерах уже можно для EN языка ознакомиться в HF

Тренируют, как обычно разное и большое. Есть энкодеры от 330m до 1.3b параметров (привет, ChatGPT reward model) . Всё можно опять же посмотреть на обнимашках.

Обещают ап по трём сетам:
- MTEB ( 56 разнообразных сетов как BEIR, STS, etc.)
- BilBoard (сет для замера на оценки качества генерации ответа, но тут нет генератора, но и ответы ретривала они умеют мерить)
- Retrieval promt (как понял оценивает качества извлечения/поиска)

Естественно таблицы с метриками прилагаются.

#забавно
Заинтересовался темой - как генерировать бессмысленные входы для нейронок, которые не воспринимались бы ей бессмысленными. Отсюда родилась игра - придумать последовательность букв, которая не является словом русского языка, но переводится переводчиком в слово английского языка, это свойство сохраняется при удалении любого количества букв из последовательности.
Тут можно ещё конкретизировать:
- какие буквы допустимо удалять,
- потребовать, чтобы все слова в переводах были разными,
- потребовать, чтобы при добавлении любой буквы, это свойство уже терялось,
- найти максимальное по длине / по числу задействованных букв слово
и т.п.
Пример с гугл-переводчиком на картинке, с ним правда есть совсем вырожденная стратегия в составлении подобных слов:(

FROMAGe: самый простой способ сделать мультимодального чатбота

Авторам потребовалось всего 24 часа чтобы на 1 GPU обучить это чудо! Идея очень похожа на Flamingo, но ещё проще и не требует больших датасетов.

За основу взяли замороженные ViT и OPT, а чтобы склеить их вместе — добавляют два обучаемых линейных слоя для отображения эмбеддингов (text2image и image2text). Затем визуальные эмбеддинги картинок подаются вместо псевдо-текстовых токенов. Для поиска и вывода картинок добавляется новый спец-токен [RET].

Для обучения используют общедоступный датасет CC3M из пар картинка-текст. В качестве лосса: CrossEntropy по тексту + контрастив лосс для токена [RET] (поиск картинок).

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

P.S. Думаю, что если в GPT-4 добавят поддержку картинок, то это будет именно так.

Статья, GitHub, блог