Как стать автором
Обновить
144
0
Давид Дале @cointegrated

Разработчик / Аналитик / Data Scientist / NLPшник

Отправить сообщение

Интересный подход с усреднением эмбеддингов токенов «внутри слова». Насколько часто он оправдан и встречается ли в реальных задачах, могли бы рассказать? 

Время от времени вижу этот подход в статьях про NER и другой sequence tagging, когда нужно ставить метки именно на слова или словосочетания, а не отдельные токены. Кажется вполне оправданным и очень простым. Можно рассматривать его в аналогии с FastText, где эмбеддинг слова вычисляется как среднее из эмбеддингов его n-грамм.

Насколько лучше это работает при двупроходном усреднении, сначала по вложениям токенов внутри слова, а потом по вложениям самих слов?

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

В качестве метрики расстояния между предложениями не смотрели в сторону word movers distance?

Смотрел, конечно, как и на её трансформерные аналоги типа bertscore. На тех задачах, на которых я сравнивал, они проигрывали косинусной близости из USE и LaBSE.

А можно ещё раз, как вы тут выделили "простые задачи"?

Я пытаюсь понять, за счёт какой операции, например, у модели hashing_1000 вышел скор 0.74 на задачах "not ner", и пока не могу.

Я под S (sentence) имел в виду первые 8 задач (все, кроме NER), а S+W (sentence + word) – все 10 задач, включая NER.

Но мне не кажется, что NER – это "сложно", а всё остальное – "просто". Самая интеллектуально сложная задача тут – это, наверное, NLI, ибо там реально бывает нужно логику включать.

Спасибо за новые каверзные вопросы! (:

Это скорость именно всего "энкодера" + легковесной модели поверх, верно?

Только энкодера

Это на каком CPU?

CPU из Google colab с такими характеристиками

Hidden text
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per core:  2
Core(s) per socket:  1
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               79
Model name:          Intel(R) Xeon(R) CPU @ 2.20GHz
Stepping:            0
CPU MHz:             2199.998
BogoMIPS:            4399.99
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            56320K
NUMA node0 CPU(s):   0,1

Это же для большинства моделей запуск на PyTorch (кроме ft и подобного)?

Верно. Осознаю, что можно было вместо этого ONNX Runtime включить, или ещё какую-то оптимизацию сделать. Думаю, что все трансформерные модели это ускорит примерно одинаково, так что их ранжирование не изменится. Ну и FastText в любом случае будет быстрее)

Если да, то сколько потоков процессора вы выставляете для тестов

Использовал дефолтное значение: 1 поток.

Есть ли зависимости оптимального или минимально адекватного числа потоков в зависимости от размера модели?

Не исследовал этого. Буду рад, если такое исследование появится :)

Какая используется GPU?

Стандартная колабовская: Tesla P100-PCIE-16GB

Как-то контролируется сравнимость результатов по скорости

Я в каждую из моделей подавал по одному предложению последовательно (т.е. измерял именно скорость обработки одного предложения, а не throughput с возможной параллелизацией). Ну и сравнивал все модели на одной и той же выборке предложений, так что друг с другом они сравнимы. Зависимость скорости от длины предложений не измерял, но это тоже интересно будет в следующих сериях попробовать.

Очень жду выпуска с разбором метрик и сравнением всех вышеупомянутых моделей по метрикам)

А есть примеры конкретных кластеров и их саммари? Любопытно посмотреть)

Я и вся команда YaLM надеемся, что эта статья мотивирует русскоязычное DL community посвятить время исследованию и использованию больших моделей в NLP.

А вы YALM в открытый доступ релизить собираетесь, или пусть русскоязычное DL community сидит исключительно на моделях от Сбера?

Если говорить про права и ответственность за сгенерированный текст, то в посте два случая описаны:

  1. Человек пишет пост, робот предлагает человеку перефразированный текст, человек жмёт "принять новый вариант" либо "оставить как было". В первом случае человек сам согласился с переписанным вариантом текста, и потому и права, и ответственность за этот текст - на нём. Примерно как если бы робот предложил исправить опечатки. Во втором случае перефразированный текст вообще никуда не выкладывается.

  2. Бот намеревается отправить юзеру токсичный текст, но вместо этого отправляет менее токсичный, перефразированный. В этом случае (как и без детоксификации) права и ответственность за текст - на владельце бота.

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

Нет, T5 использует relative position embeddings, поэтому тексты могут быть неограниченной длины. Правда, сложность там всё равно квадратичная от длины входа, поэтому на длинных текстах модель будет работать медленно.

А так вообще вчера специально для этой задачи Silero выложили модель: https://habr.com/ru/post/581946/

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

Модель моя, и обучал я её конкретно под sequence classification, поэтому под token classification она ожидаемо так себе.

Но маленький BERT для token classification тоже на очереди на создание)

Не вполне соглашусь: всё-таки будильники ставит и свет включает Алиса вполне как ассистент. Но да, её возможности как кастомизируемого ассистента, к сожалению, пока весьма ограничены.

Нет повести печальнее на свете!

Да, задача была хоть как-то квантизировать летающее в воздухе знание)
Будет круто, если кто-то сможет каталоги Маруси и Салюта подобным образом прошерстить.

А про что ещё хочется?)

А для каких важных практических задач вы определяете национальность по ФИО?)

скачать модельку, распаковать и создать докер конетйнер

Ну вот хочется как раз запускать не в контейнере, а как питоновский модуль.
Но вообще — спасибо большое.
Работа огонь!
Два вопроса:
1. Вы сравнивали ваш вариант BERT+LSTM с вариантом «просто пофайнтюнить BERT»?
2. Есть ли пример в духе «как в 2 строки кода расставить запятые в моём тексте»?
Да, инференс такая процедура ускорить не помогает, потому что «расчёт» эмбеддингов — это lookup, его сложность от размера словаря не зависит.

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

Да, надо править и веса нейросети, и токенайзер. Из токенайзера выкинуть лишние токены, из весов - лишние строки матриц входных и выходных эмбеддингов.

Я разбирал это в англоязычном посте про T5 (кстати, надо ли его переводить на русский?), там есть примеры кода, как это делать: https://cointegrated.medium.com/how-to-adapt-a-multilingual-t5-model-for-a-single-language-b9f94f3d9c90

Для BERT'а алгоритм даже чуть проще, чем для T5, поскольку словарь токенизатора в берте хранится как текстовый файлик, а не бинарь.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность