​Поиск в тексте элементов семантической модели по определенным для них синонимам

Пример. Пусть мы занимаемся описанием intents для голосового ассистента. Мы создали простую семантическую модель, где определили некий набор элементов. Подробнее по ссылке. Среди прочих сущностей, мы описали элемент ”web user” co следующим набором синонимов:

• web user,
• site user,
• online user

Далее мы анализируем пользовательский запрос

Show me web user data

и пытаемся найти в нем сконфигурированные элементы модели.Как происходит поиск сущности “web user” в тексте запроса?

Все начинается с токенизации.

Токенизация

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

Зачем это нужно? Для того чтобы мы могли осуществлять поиск внутри текста по отдельным словам и словосочетаниям.

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

Пример. Составное слово “der Wintersport“ (Winter + Sport) — зимний спорт (зима + спорт).

Если необходимо найти слово “спорт“, вам придется каким-то образом разбить монолит “Wintersport“ для успешного поиска нужного слова внутри составного.

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

Идем дальше, нормализуем токены.

Леммы и стеммы

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

• Лемма — начальная словоформа.
• Стемма — основа слова. Она может быть получена с помощью различных алгоритмов, например с помощью алгоритма Портера.

Задача нормализации также успешно решена различными NLP продуктами и мы лишь пользуемся результатами их работы.

Зачем это делать? Для того чтобы сократить до разумного количества число синонимов, описывающих элементы модели.

Пример. Два предложения:

• Show me online user data
• Show me online users data

Разумеется понятие “web user” должно быть определено один раз для обоих случаев синонимом “online user“. Таким образом, нам следует искать заранее нормализованные синонимы среди также нормализованных слов (токенов) рассматриваемого предложения.

Примечание. В общем случае лучше всего осуществлять поиск в несколько итераций, например:

• пытаемся найти по оригинальной версии слов, далее
• по нормализованным версиям — стеммам, далее
• по нормализованным версиям — леммам

Что лучше использовать стеммы или леммы? Зависит от ситуации. Например, для русского языка стемминг работает хуже чем для ряда прочих из-за относительного большого количества случаев супплетивизма, таких как “идти — шла”. Данные словоформы одного слова просто не имеют общего корня, и тут нам на помощь приходит лемматизация.

С другой стороны процесс стемминга гораздо проще алгоритмически. Он не требует, что бывает важно, наличия полноценного NLP процессора ни на стороне где происходит загрузка синонимов, ни на стороне разбора запроса. Кроме того алгоритм стемминга не нуждается в контексте вопроса, зачастую необходимого для процесса лемматизации.

Обработка стоп-слов

Ок, мы нормализовали слова в тексте и теперь пытаемся осуществить среди них поиск по нормализованным синонимам разыскиваемых сущностей. Пусть, опираясь на определенные выше примеры, мы хотим отыскать элемент “web user” в следующем предложении:

Show me online users data

Для нас не составит труда найти сущность “web user” по синониму ”online user”, встреченному в запросе. А найдется ли элемент “web user” в таком запросе?

Show me online an user

Нет — не найдется.

Игнорируем корректность применения артикля в данном предложении.

Причина — у нас определен синоним “online user”, но не определен “online an user”.

Решение — мы должны искать совпадения лишь по значимым словам предложения, игнорируя стоп-слова. В нашем примере поиск должен осуществляться только в следующем наборе слов “show me online user”. Стоп-слово “an” должно быть проигнорировано при анализе.

Примечание

Когда пользователь системы определяет всевозможные синонимы, он может осознанно или случайно использовать стоп-слова в элементах своего списка. Не стоит запрещать ему делать это. Например задача найти в тексте название газеты “The Sun”. Мы не сможем найти его в тексте, заранее очищенном от стоп-слов. Таким образом, мы должны пытаться искать синонимы в два этапа: сначала среди всех слов и лишь затем исключив стоп-слова.

Итого, на этапе лингвистического анализа мы должны получить все токены предложения, размеченные флагами — является ли рассматриваемое слово стоп-словом или не является.Коллизии, возникающие при работе с синонимами

Пусть наша модель помимо элемента “web user” имеет еще одну описанную сущность: “компания“ с названием “americas multimedia online”. Как распознается следующий вопрос:

Americas multimedia online user?

В нем обнаружатся обе сущности:

• “americas multimedia online“ — ”компания”
• “online user“ — ”web user”

Человеку очевидно, что в данном примере следует оставить лишь элемент “компания”, а “web user” здесь не при чем. Но как разрешить возникшую коллизию алгоритмически?

В нашем примере это довольно просто. Должен “выигрывать“ синоним, а вместе с ним и сущность, содержащий большее количество слов — три слова для “americas multimedia online” против двух слов для “web user”.

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

Поиск “прерывистых“ синонимов

Возвращаемся к нашему примеру по нахождению сущности “web user”. Как нам найти и можем ли мы вообще обнаружить эту сущность в вопросе:

Give me users with status online?

Очевидно, что наиболее подходящий синоним среди всех определенных нами это — ”online user”. Но в рассматриваемом предложении изменен порядок слов в словосочетании, и, кроме того, между словами ”online” и “user” затесалось еще два — ”status” и “with”.

В DataLingvo мы предоставляем пользователям возможность настройки специального коэффициента — “JIGGLE_FACTOR”. Данный параметр определяет, на сколько позиций может быть сдвинуто слово в предложении относительно ожидаемой позиции в синониме, для того чтобы данный синоним был успешно распознан.

В предложении “Give me users with status online” слово “online“ сдвинуто на 4 позиции относительно расположения в исходном ожидаемом синониме ”online user”. Таким образом, настраивая систему, пользователь может определить насколько “строгим” должен быть поиск в пределах:

• от максимально строгого, когда порядок слов в синонимах жестко определен и не может быть изменен, то есть допустимый сдвиг между словами равен нулю
• до более “либерального”, позволяющего искать синонимы в тексте с учетом возможных перестановок.

Какой вариант стоит выбрать зависит исключительно от типа вашей модели.

Примечание. Необходимость использования системы приоритетов для выбора между потенциально найденными синонимами при поиске с перестановками актуальна как никогда. Изначально должны ”выигрывать” те синонимы, для которых сумма перестановок всех их токенов минимальна, но с другой стороны количество слов в синониме может в свою очередь перевешивать этот фактор, и так далее. Алгоритмы разрешения подобных коллизий могут быть достаточно нетривиальными, но все эти вопросы выходят за рамки примера.

Послесловие

Мы описали основные базовые шаги и принципы, по которым осуществляется поиск в тексте сущностей семантической модели, и были вынуждены отбросить ряд важных, но как надеемся, несущественных для понимания общей картины деталей. Данные принципы достаточно едины и в целом не зависят от поставщика NLP решения. Иногда задача разбора текста может быть упрощена — для некритичных систем, иногда должна быть существенно усложнена, но в целом все подобные системы имеют схожую структуру и опираются на единые принципы.