Как стать автором
Обновить

Комментарии 19

Отличная статья, сразу максимальный репост.

Не супер фанат академических тестов, но иначе готовые энкодеры наверное реально никак не сравнить (кроме как на своей задаче) - ??.

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

А вот тут сразу вопросы:

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

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

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

  • Если да, то сколько потоков процессора вы выставляете для тестов, и насколько вообще процессор нагружен при таких тестах (по дефолту PyTorch кушает все процессоры и не всегда мягко говоря это максимально эффективно даже не по Парето, а вообще, там на маленьких моделях много потоков даже начинает вредить начиная с 6 потоков)?

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

PS

Да и может запостите в подвале где-то большую картинку со всеми подписями, а не только Парето-оптимальными?

И еще пара вопросов вдогонку:

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

  • Как-то контролируется сравнимость результатов по скорости (ведь время тут линейно зависит от длины предложений)?

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

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

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

Это на каком 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 с возможной параллелизацией). Ну и сравнивал все модели на одной и той же выборке предложений, так что друг с другом они сравнимы. Зависимость скорости от длины предложений не измерял, но это тоже интересно будет в следующих сериях попробовать.

В торче можно напороться на то, что если два раза (или 10) подать одно предложение, то скорость может отличаться на порядок.

В остальном, если предложения рандомные и не отличаются слишком сильно по длине, то такой подход нормальный, вроде яблоки с яблоками.

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

CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 2 Core(s) per socket: 1 Socket(s): 1

Дефолтное в торче вроде - это число доступных потоков процессора. У вас выше вроде два.

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

Для начала разделим задачи на "простые" и "сложные". Сложные - NER, простые - все остальные. По сути нужно ли модели "понимать" только слова или фразы (может автор имел в виду в табличках под этим S и S+W).

Получаем интересную картинку - "простые" подходы (н-граммные модели) почти не работают на "сложных" задачах, а "большие" модели лучше на 10% при разнице по скорости на 2 порядка:

Аналогичный анализ для "простых" задач:

И для наглядности корреляция "качества" на "простых задачах" от логарифма размера модели:

Опустим домыслы про то, что какие-то модели видимо очень хорошо оверфитятся на датасет в силу своей "простоты", но на "простых" задачах или автор очень хорошо оверфитнулся, или тестовые задачи "маленькие" или нграммные модели очень хорошо их решают (и оверфитятся в процессе).

Все это опирается на то, что надо по-хорошему проверять это все на лики, чего я делать конечно не буду. Но если ликов там нет, со всеми оговорками выше, выводы думаю очевидны =)

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

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

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

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

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

График теперь выглядит в соответствии с интуицией, но вывод про нграммные модели сохраняется:

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

Задачи, где нужно понимать "смысл" предложения, и нельзя просто оверфитнуться на какие-то конкретные слова или фразы из словаря.

Собственно вот, "классические" модели внизу, а выше они были даже в середине:

Интересный подход с усреднением эмбеддингов токенов «внутри слова».

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

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

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

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

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

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

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

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

Он не просто работает, а прекрасно работает на каких-то задачах. Одно время я очень часто его использовал и писал про это на канале. И что неплохо, у него хорошая устойчивость к ошибкам, опечаткам и словоформам.

Работает в основном на "простых" более менее задачах. Вместе с трансформерами пробовали, но супер разницы не увидели, и как-то дальше не стали копать.

Здравствуйте!
Вы проделали отличную работу, большое спасибо! Один вопрос:

Во-вторых, за счёт увеличения словаря сократилось число среднее токенов на один текст, а значит, модель стала быстрее работать на CPU

Я правильно понимаю, что чем больший размер словаря задан в качестве гиперпараметра при обучении токенизатора, тем больше токены в словаре будут словами/почти словами и, соответственно, чем меньше размер словаря, тем больше словарь будет состоять из самых частотных n-грам?
И именно за счёт этой особенности произошёл прирост по скорости на CPU?

Да, всё верно. Большой словарь => больше процент слов, которые токенизировались одним токеном, а не несколькими => входные последовательности стали в среднем короче (если измерять в токенах) => нейросеть стала быстрее их обрабатывать.

Спасибо за cointegrated/rubert-tiny2!

Я не мог отказать себе в удовольствии посмотреть, как она в сравнении с "старшей сестрой" cointegrated/rubert-tiny и со sberbank-ai/ruBERT-base на задачке определения релевантных/нерелевантных вопросов к коротким текстам. Сиамская сетка с замороженными весами bert, и пара обучаемых слоев работают с эмбеддингами токенов, 3-fold кроссвалидация.

cointegrated/rubert-tiny   mean f1 = 0.9474928352184623

cointegrated/rubert-tiny2 mean f1 = 0.9597176177090234

sberbank-ai/ruBERT-base mean f1 = 0.975931134016122

Получается, что увеличение размера в ~2 раза (45Мб у rubert-tiny и 112Мб у rubert-tiny2) докидывает одну сотую, а потом увеличение в 6 раз (680 Мб у ruBERT-base) докидывает еще полторы сотых в f1. Интересный trade-off. Можно еще учесть разницу на обучении, там затраты на инференс данных через эти берты примерно соотносится с их размером.

Спасибо за подборку моделей!
Очень был рад увидеть paraphrase-multilingual-mpnet-base-v2, которая обходит LaBSE на задаче STS. Но ещё я обрадовался, когда увидел её скорость работы на CPU. Но радость была недолгой :(


У меня есть небольшое уточнение: модель paraphrase-multilingual-mpnet-base-v2 в среднем обрабатывает одно предложение на CPU за 88.8 мс, а на GPU за 10.3 мс (близок к Вашему замеру). Получается очень большое расхождение с Вашими замерами скорости на CPU. Замеры делал в Google Colab.

Среднее количество слов в предложении - 5.6, средняя длина предложения в символах - 79.3.
Ещё раз спасибо за Ваш труд!

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

Как сказано в теле поста, я брал эмбеддинги слов из модели geowac_tokens_none_fasttextskipgram_300_5_2020 с RusVectores. Усреднял я эти эмбеддинги вот таким кодом:

Спасибо, большое! А про какую модель MUSE-3 идет речь в статье? Отсылок на первоисточник в статье я не нашел. Я нашел только версию MUSE от facebookresearch, но там вроде модель представлена в виде векторов слов. Можно ссылку на модель, которая использовалась в статье, или более подробно объяснить, что подразумевается под MUSE-3?

Под MUSE-3 я имел в виду не мультиязычные эмбеддинги слов от Меты, а мультиязычный энкодер предложений от Гугла: USE-multilingual-large.
Прошу прощения за использование этой не совсем понятной аббревиатуры.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории