Компьютерная лингвистика

NLP pipeline включает несколько отдельных питоновских пакетов. Эти пакеты реализуют часть типовой функциональности для NLP - токенизация, лемматизация, частеречная разметка и т.д. Эта группа может использоваться (и используется) независимо от чатбота.

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

Далее - текущее состояние для пакетов из первой группы.
( Collapse )

В наборе NLP модулей для чатбота добавился очередной - NP chunker. Его прототип я уже кратко описывал тут. Для удобства использования в разных проектах чанкер именных групп выделен в отдельный модуль ruchunker.

В чатботе он позволяет делать следующее. Допустим, пользователь вводит вопрос:
( Collapse )

В репозиторий "NLP Datasets" выложен датасет для тренировки NP чанкера.

NP chunker - это вариант shallow parser'а, извлекающего из предлождений группы существительного (noun phrases). Вот результаты разметки нескольких предложений для иллюстрации идеи:
( Collapse )

По поводу вот этого корпуса https://parus-proj.github.io/PaRuS/

Архив с корпусом в формате Conll после распаковки имеет размер около 130 Гб. То есть данных много. Закономерный вопрос - насколько качественны эти данные, учитывая, что ручной модерации они не подвергались в силу объема.

Я сделал небольшой лексический анализ. Искал словоформы, которые отсутствуют в лексиконе Грамматического Словаря. Видно, что данные в какой-то степени грязные. Например, есть "существительные" (лемма + слово):
( Collapse )

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

1) Расширен и частично переработан набор intent'ов. По результатам предварительного анализа типичных вопросов в датасете "Mail.ru Ответы", добавлены несколько новых интентов для частых запросов в чатботах, например 'определение объекта на фотографии', 'поиск книги по описанию', 'odqa - вопросы к Википедии' и т.д.

2) Для этих интентов сделаны заготовки сценариев, в которых в будущем можно будет реализовать соответствующие skill'ы с детальной обработкой вариантов запросов. Например, в ответ на реплику "помоги решить задачу по математике" чатбот сейчас выдаст: "Мастер помощи с домашними заданиями еще не реализован!". По этой реплике можно найти исходник соответствующего сценария в файле rules.yaml.

3) Запуск новых сценариев для skill'ов происходит в случае, если не получилось найти ответ в базе фактов или FAQ. Например, для вопроса "Что такое хрусталик?" бот выдаст ответ из FAQ, а для вопроса "Что такое бензокаин?" будет запущен odqa-сценарий.
( Collapse )

Две новые фичи в этом релизе чатбота:
( Collapse )

Чтобы проверить расширенные возможности rule-driven ядра чатбота, я попробовал написать простую текстовую игру-угадайку.

Получились вот такие диалоги:
( Collapse )

В движок чатбота, в его rule-driven подсистему, добавлены две экспериментальные возможности. Собранный докер с этой версией бота выложен тут.

Обе возможности относятся к приоритетным правилам генерации реплики бота. Эти правила срабатывают до того, как в дело вступает стандартный механизм подбора ответа в FAQ или релевантного факта в базе знаний. В файле правил rules.yaml они находятся в секции с незамысловатым именем "rules".
( Collapse )

Пробежался глазами по логам чатбота одной очень, очень крупной компании. И вот что бросается в эти самые глаза. Процентов 15 сообщений сводится к "мне нужен специалист а не робот".

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

Второе следствие взросления технологии - взломы корпоративного чатбота через вербальный канал, а-ля "Белая трость калибра 7.62". Найдется умная голова, которая придумает грамматический эксплойт для махины из парсеров, нейросеток и регулярок, пролезет через микросервисы и доберется до БД.

В результате интерференции родилась такая мысль, надо ее застолбить :)

Задача

Вот, допустим, есть у нас некая MDM система, которая помимо прочего в рамках ETL процедуры должна уметь забирать описания товара из какой-нибудь 1C. Данные, как это водится, грязные. Вводят их вручную менеджеры, операторы склада или бухгалтеры. А даже если вводят специально выделенные люди (aka "эксперты НСИ"), то могут быть свои забавные способы впихнуть в короткую текстовую строку самую разную информацию. Хотя, казалось бы, для некоторых материальных сущностей эти описания регламентируются ГОСТами и т.д.
( Collapse )