Нужно ли мне использовать распознавание именованных объектов (NER) при токенизации?
Я работаю над проектом НЛП по анализу настроений. Я использую SpaCy для токенизации предложений. Читая документацию, я узнал о NER. Я читал, что его можно использовать для извлечения объектов из текста для облегчения поиска пользователя.
Я пытаюсь понять, как воплотить это (если нужно) в процессе токенизации. Я привожу пример.
text = "Let's not forget that Apple Pay in 2014 required a brand new iPhone in order to use it. A significant portion of Apple's user base wasn't able to use it even if they wanted to. As each successive iPhone incorporated the technology and older iPhones were replaced the number of people who could use the technology increased."
sentence = sp(text) # sp = spacy.load('en_core_web_sm')
for word in sentence:
print(word.text)
# Let
# 's
# not
# forget
# that
# Apple
# Pay
# in
# etc...
for word in sentence.ents:
print(word.text + " _ " + word.label_ + " _ " + str(spacy.explain(word.label_)))
# Apple Pay _ ORG _ Companies, agencies, institutions, etc.
# 2014 _ DATE _ Absolute or relative dates or periods
# iPhone _ ORG _ Companies, agencies, institutions, etc.
# Apple _ ORG _ Companies, agencies, institutions, etc.
# iPhones _ ORG _ Companies, agencies, institutions, etc.
Первый цикл показывает, что «Apple» и «Pay» — это разные токены. При печати обнаруженных объектов во втором цикле он понимает, что «Применить оплату» — это ORG. Если да, то как я могу достичь этого (скажем так) «типа» токенизации?
Я думаю, не следует ли обозначить «Apple» и «Pay» одним словом, чтобы, когда я создаю свой классификатор, он распознавал его как сущность и не распознавал фрукт («Apple») и глагол ( 'Платить').
Ответы 1
Токенизация обычно представляет собой разделение предложения на слова или даже подслова. Я не уверен, что вы позже планируете делать с данными, но в НЛП принято придерживаться уровня документа, уровня предложения или уровня слова/токена. Наличие некоторого сочетания уровня токена и n-грамм (например, ["Apple Pay", "required", "an", "iPhone", "to", "use", "it", "."], на мой взгляд, не поможет вам в большинстве последующих случаев использования.
Если вы позже обучите классификатор (при условии, что вы говорите о точной настройке языковой модели на основе преобразователя для задачи классификации токенов), тогда вы будете использовать что-то вроде формата IOB для обработки n-грамм, например вот так:
Конечно, это зависит от вашего приложения, и прямое слияние с n-граммами может вам подойти. Если у вас есть приложение, в котором вы ищете часто встречающиеся n-граммы, вы можете использовать метрики коллокации для извлечения этих n-грамм, например с помощью CollocationFinder NLTK.
Или, как вы упомянули, используйте SpaCy либо для извлечения фрагментов существительных , либо распознавания именованных объектов. Для последнего вы можете получить доступ к атрибутам ent_type_ и ent_iob_ уровня токена , чтобы один раз перебрать токены в обработанных документах, а затем объединить эти n-граммы вместе на основе их IOB-тегов.
Если ваша цель — найти n-граммы, которые либо указывают на определенное настроение, либо являются целью определенного настроения, есть два основных варианта. 1) Вы можете маркировать тексты на уровне предложения или документа (например, как положительные, отрицательные или нейтральные), а затем независимо от этого извлекать из этих текстов часто встречающиеся n-граммы, фрагменты существительных или именованные сущности. А затем используйте статистику, чтобы найти n-граммы, которые коррелируют с конкретными настроениями. Для этого подхода было бы полезно заранее объединить n-граммы (или пометить каким-либо другим способом, какие из них являются частями).
2) Вы можете напрямую сформулировать задачу как задачу на уровне токена, аналогичную распознаванию именованных объектов, за исключением того, что классы - это не «Человек», «Организация» и т. д., а, например, «положительный», «отрицательный», «нейтральный». Посмотрите этот репозиторий, который я создал недавно для примера. При таком подходе вам следует хранить все отдельно на уровне токенов или даже на уровне исходной строки предложения, прежде чем передавать ее модели.
По моему личному опыту, второй подход работает лучше, но вам, вероятно, придется пометить свои собственные данные обучения, поскольку для этой задачи существует не так много предварительно обученных моделей. Первый подход означает дополнительную работу по объединению шагов и применению методов для извлечения n-грамм, но преимущество состоит в том, что существует множество корпусов и предварительно обученных моделей для анализа настроений на уровне документа или предложения.
У меня есть набор данных с комментариями YouTube и помеченными настроениями, и я хочу обучить модель на этих данных. Вот почему я ищу, как лучше всего обработать данные перед обучением модели.
Моя цель — провести анализ настроений. Порекомендовали бы вы мне объединить два токена в один, если они представляют собой одну сущность?