Comments 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.
Прошу прощения за использование этой не совсем понятной аббревиатуры.
Рейтинг русскоязычных энкодеров предложений