значение точек в предложениях при обучении документов с помощью Doc2Vec

Сомнение - 1

Я тренирую Doc2Vec с 150000 документами. Поскольку эти документы относятся к юридической сфере, их действительно сложно очистить и подготовить для дальнейшего обучения. Поэтому я решил удалить все точки из документа. Сказав это, я не понимаю, как параметр Window_size в doc2vec теперь распознает предложения. В вопросе представлены два представления: Doc2Vec: Differentiate Sentence and Document

  1. Алгоритм просто работает с кусками текста, не имея представления о том, что может быть предложением / абзацем / документом и т. Д.
  2. Для токенизации даже характерно сохранение знаков препинания, таких как точки между предложениями, в качестве отдельных токенов.

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

Сомнение-2

Список документов, которые я отбраковал, варьируется от 500 до 5500 токенов, поэтому мой подход к тому, чтобы иметь документы довольно одинакового размера для обучения doc2vec и даже для сокращения словарного запаса: Рассмотрим документ размером более 1500 токенов, в этом случае я использую First 50 до 400 жетонов + от 600 до 1000 жетонов + последние 250 жетонов. Мотивация для такого подхода взята из статьи, связанной с классификацией документов с использованием BERT, где последовательность из 512 токенов была сгенерирована следующим образом.

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

Обновление - я только что видел корпус common_text, используемый gensim, в ссылке на руководство https://radimrehurek.com/gensim/models/doc2vec.html и обнаружил, что документы в этом корпусе являются просто символами слов и не содержат знаков препинания. например:

from gensim.test.utils import common_texts, common_dictionary, common_corpus

print(common_texts[0:10])

Выход:

[['human', 'interface', 'computer'], ['survey', 'user', 'computer', 'system', 'response', 'time'], ['eps', 'user', 'interface', 'system'], ['system', 'human', 'system', 'eps'], ['user', 'response', 'time'], ['trees'], ['graph', 'trees'], ['graph', 'minors', 'trees'], ['graph', 'minors', 'survey']]

То же самое было сделано в учебнике https://radimrehurek.com/gensim/auto_examples/tutorials/run_doc2vec_lee.html. Так что мой подход к удалению точек в документе действителен, если да, то как будет работать параметр окна, потому что в документации он определен следующим образом: window (int, optional) - Максимальное расстояние между текущим и прогнозируемым словом в предложении .


person shrikanth singh    schedule 05.04.2020    source источник


Ответы (1)


Некоторые люди сохраняют точки и другие знаки препинания как отдельные знаки, некоторые их удаляют.

Не существует однозначно «правильного» подхода, и в зависимости от ваших конечных целей один или другой может немного повлиять на качество документа-вектора. Так что пока просто делайте то, что для вас проще всего, а потом, если у вас будет время, вы можете оценить альтернативный подход, чтобы увидеть, поможет ли он.

Несмотря на любую ссылку на «предложения» в документации, классы _1 _ / _ 2_ / etc в gensim не имеют никакого понимания предложений или особой чувствительности к пунктуации. Они просто видят переданные вами списки токенов как отдельные элементы в корпусе. Итак, если вы оставите периоды, как в коротком тексте вроде ...

['the', 'cat', 'was', 'orange', '.', 'it', 'meowed', '.']

... тогда строка '.' - это просто еще одно псевдослово, которое получит вектор, и окна обучения будут проходить через него, как и любое другое слово. (И 'meowed' будет находиться на расстоянии 5 жетонов от 'cat' и, таким образом, будет иметь некоторое влияние, если window=5.)

Я не совсем понимаю, что вы имеете в виду, говоря «используйте первые 50–400 токенов + 600–1000 токенов + последние 250 токенов». Doc2Vec отлично работает с текстами на 10000 токенов. (Больше токенов будет молча игнорироваться из-за внутреннего ограничения реализации gensim.) Нет необходимости или типично разбивать документы на более мелкие фрагменты, если у вас нет другой потребности в моделировании более мелких фрагментов текста.

Крошечный common_texts набор списков слов - это надуманный набор данных игрушечного размера для демонстрации базового использования кода - это не пример рекомендуемых практик. Демонстрации, основанные на корпусе Lee, также являются кратким вступлением к крошечному и простому подходу, которого едва хватает для демонстрации базового использования и результатов. Это токенизация текста - с помощью служебного метода simple_preprocess() - можно попробовать, но не «правильно» или «лучше» по сравнению со всеми другими возможностями.

person gojomo    schedule 05.04.2020
comment
Большое спасибо за такое подробное объяснение. Я хотел объединить определенные фрагменты документов, чтобы уменьшить размер каждого документа, поскольку размеры варьируются от 500 до 5500 токенов. Но после вашей рекомендации использовать весь документ как таковой, я это сделаю. - person shrikanth singh; 06.04.2020