D
"Почему не GPT-2?"
отсутствие многоязычной натренированной модели
отсутствие многоязычной натренированной модели
Size: a a a
2019 December 24
D
не совсем, много мусора
2019 December 25
D
и разумеется там нет XLM
OS
Но tf-idf не делает же слово вектором? В KMeans сложно будет результат передать.
У меня такая гипотеза - каждое слово превратить в вектор по fasttext, выделить топ 100 слов на каждого клиента например с помощью TF-IDF и разложить на 100 слов * 100 (размер вектора fasttext) и так получится 10000 колонок. Может что-то экономнее?
У меня такая гипотеза - каждое слово превратить в вектор по fasttext, выделить топ 100 слов на каждого клиента например с помощью TF-IDF и разложить на 100 слов * 100 (размер вектора fasttext) и так получится 10000 колонок. Может что-то экономнее?
Можно посчитать тфидф слова в каждом документе и получить вектор длины (кол-во документов)
DB
Можно посчитать тфидф слова в каждом документе и получить вектор длины (кол-во документов)
Интересный способ, спасибо, попробую
D
так никто не подскажет по написанию скрипта файнтюна?
SZ
можно, только не забудь сделать один раз for l in doc2.get_pipe('ner').labels: doc1.get_pipe('ner').add_label(l)
чот такое не работает, пишет
AttributeError: 'spacy.tokens.doc.Doc' object has no attribute 'get_pipe'V
А какие требования на инференс модели, и как Вы препроцессите текст перед тем, как его скормить?
извините, не заметил сообщение. если ещё актуально...
инференс: не гонюсь за скоростью (пока что). без оптимизаций фичи извлекаются примерно со скоростью 3-4 документа в секунду (зависит от размера текстовой части и количества изображений; тестировал пока только на коротких тестах). вместо скорости целюсь в минимизацию занимаемой памяти и дискового пространства, как следствие - в возможность запускать на слабых машинах. под вопросом остаётся выбор алгоритма поиска по векторам - пока в тестовых целях использую bruteforce-поиск, но планирую использовать Annoy (в основном потому что эта библиотека позволяет строить и хранить индексы на диске и является кроссплатформенной).
препроцессинг текста: в итоге я перешёл с LASER на Multilingual Universal Sentence Encoder от гугла, так как эта модель работает шустрее. гугл велел особо о препроцессинге не париться, мол предобученная модель всё сделает сама, но я всё же разбиваю текст на параграфы в среднем около 10 тыс. символов (не SentencePiece-токенов, которыми оперирует модель), и обрабатываю только первые 1000 таких параграфов в документе. векторы параграфов потом усредняю.
инференс: не гонюсь за скоростью (пока что). без оптимизаций фичи извлекаются примерно со скоростью 3-4 документа в секунду (зависит от размера текстовой части и количества изображений; тестировал пока только на коротких тестах). вместо скорости целюсь в минимизацию занимаемой памяти и дискового пространства, как следствие - в возможность запускать на слабых машинах. под вопросом остаётся выбор алгоритма поиска по векторам - пока в тестовых целях использую bruteforce-поиск, но планирую использовать Annoy (в основном потому что эта библиотека позволяет строить и хранить индексы на диске и является кроссплатформенной).
препроцессинг текста: в итоге я перешёл с LASER на Multilingual Universal Sentence Encoder от гугла, так как эта модель работает шустрее. гугл велел особо о препроцессинге не париться, мол предобученная модель всё сделает сама, но я всё же разбиваю текст на параграфы в среднем около 10 тыс. символов (не SentencePiece-токенов, которыми оперирует модель), и обрабатываю только первые 1000 таких параграфов в документе. векторы параграфов потом усредняю.
V
для получения кросс-модальных векторов решил в итоге использовать подход с псевдосиамскими сетями, с применением функции потерь, описанной в https://arxiv.org/abs/1707.05612 . обучал на MS COCO с MobileNetV2 для извлечения фич из изображений, и Multilingual USE для текста. даже с аугментацией данных пока не удалось получить тех же результатов, что и в референсе (видимо из-за более слабых, не затюненных под один датасет моделей и меньшей размерности мультимодальных векторов) но top-5 recall для ранжирования "текст-изображение" и "изображение-текст" получился около 70%, что пока устраивает.
V
вместе с неплохим (пока что, для моих целей) кросс-модальным ранжированием наблюдаю деградацию мультимодальных векторов (по сравнению с исходными) в задаче ранжирования сущностей в одном домене ("текст-текст", "изображение-изображение"). это проблема, так как мне нужно вести и single domain, и cross-domain поиск в одном векторном пространстве...
V
может быть у кого-то есть идеи, как избежать подобной деградации? первое, что приходит на ум - обучать модель одновременно и на single domain и на cross-domain датасетах.
V
извините, не заметил сообщение. если ещё актуально...
инференс: не гонюсь за скоростью (пока что). без оптимизаций фичи извлекаются примерно со скоростью 3-4 документа в секунду (зависит от размера текстовой части и количества изображений; тестировал пока только на коротких тестах). вместо скорости целюсь в минимизацию занимаемой памяти и дискового пространства, как следствие - в возможность запускать на слабых машинах. под вопросом остаётся выбор алгоритма поиска по векторам - пока в тестовых целях использую bruteforce-поиск, но планирую использовать Annoy (в основном потому что эта библиотека позволяет строить и хранить индексы на диске и является кроссплатформенной).
препроцессинг текста: в итоге я перешёл с LASER на Multilingual Universal Sentence Encoder от гугла, так как эта модель работает шустрее. гугл велел особо о препроцессинге не париться, мол предобученная модель всё сделает сама, но я всё же разбиваю текст на параграфы в среднем около 10 тыс. символов (не SentencePiece-токенов, которыми оперирует модель), и обрабатываю только первые 1000 таких параграфов в документе. векторы параграфов потом усредняю.
инференс: не гонюсь за скоростью (пока что). без оптимизаций фичи извлекаются примерно со скоростью 3-4 документа в секунду (зависит от размера текстовой части и количества изображений; тестировал пока только на коротких тестах). вместо скорости целюсь в минимизацию занимаемой памяти и дискового пространства, как следствие - в возможность запускать на слабых машинах. под вопросом остаётся выбор алгоритма поиска по векторам - пока в тестовых целях использую bruteforce-поиск, но планирую использовать Annoy (в основном потому что эта библиотека позволяет строить и хранить индексы на диске и является кроссплатформенной).
препроцессинг текста: в итоге я перешёл с LASER на Multilingual Universal Sentence Encoder от гугла, так как эта модель работает шустрее. гугл велел особо о препроцессинге не париться, мол предобученная модель всё сделает сама, но я всё же разбиваю текст на параграфы в среднем около 10 тыс. символов (не SentencePiece-токенов, которыми оперирует модель), и обрабатываю только первые 1000 таких параграфов в документе. векторы параграфов потом усредняю.
а faiss не думали применить вместо annoy?
D
...судя по всему нет, всем как-то пофиг
B
V
а faiss не думали применить вместо annoy?
думал, но faiss не кроссплатформенный, и с хранением индексов на диске у него сложнее.
V
...судя по всему нет, всем как-то пофиг
видимо никто эту модель не файнтюнил, или нет времени/возможности подсказать.
VB
видимо никто эту модель не файнтюнил, или нет времени/возможности подсказать.
Мы USE файнтюним много, но я если честно вопрос не уловил
V
Мы USE файнтюним много, но я если честно вопрос не уловил
тут человек спрашивал про файнтюн XLM и грустил, что ему никто не отвечает
V
это я не про свою задачу