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

В Elafris мы создали платформу искусственного интеллекта с красивыми и понятными виртуальными агентами. Они общаются с пользователями по различным каналам, от Facebook Messenger, SMS и Интернета до голосовых устройств с помощью Amazon Alexa и Google Home. Нашими клиентами являются крупные страховые компании, которым мы помогаем создавать свои собственные версии виртуальных помощников Elafris. Платформа AI нацелена на расширение трех основных областей, которые затрагивают конечного пользователя страховой компании: обслуживание клиентов, консультирование страхового агента и случайный чат для установления взаимопонимания. Хотя каждая из этих задач должна работать согласованно, чтобы служить держателю страхового полиса, каждая область требует своего собственного подхода для успешного развития.

Ниже мы описываем модули в нашем сервисе, как каждый из них построен, подходы, которые мы выбрали, и обоснование этого выбора. Мы также делимся своим опытом анализа различных инструментов - когда генеративные нейронные сети - не лучший выбор; почему мы используем Word2vec вместо Doc2vec; очарование и ужас ChatScript и так далее.

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

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

- Многие слова, фразы и выражения неоднозначны. Типичный пример находится в меме ниже.

  • Для правильной интерпретации значений слов необходим контекст. Однако любая платформа искусственного интеллекта, которая задает клиенту уточняющие вопросы, может показаться неуклюжей. Более сложные решения позволяют элегантно переключиться на любую тему по запросу пользователя и правильно ответить на любой вопрос.
  • Часто в живой речи и случайном общении люди либо пренебрегают правилами грамматики, либо отвечают так кратко, что практически невозможно составить полную формальную структуру предложения.
  • Чтобы ответить на запрос пользователя, иногда необходимо сопоставить его запрос с ответом на часто задаваемые вопросы. Мы не можем просто полагаться на похожие слова или фразы, совпадающие между запросом и ответом, но должны действительно убедиться, что ответ имеет правильное значение для ответа на запрос.

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

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

Начать разговор - Диспетчер диалогов

Задача Dialog Manager в платформе Elafris AI заключается в программном моделировании взаимодействия между клиентом и действующим агентом. Подобно действующему агенту обслуживания клиентов, Dialog Manager направляет пользователя через сценарий разговора к некоторой полезной цели.

Чтобы выполнить это моделирование, сначала выясните, чего хочет пользователь, например, рассчитайте стоимость страховки автомобиля. Затем определите информацию, требуемую от пользователя или из других источников, такую ​​как адрес и другие данные пользователя, а также информацию о водителях и автомобилях. Наконец, сервис должен доставить полезный ответ пользователю, заполнить форму и предоставить клиенту результат этой задачи. Одно предупреждение - сервис также должен избегать вопросов пользователям, на которые он уже ответил.

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

Основные типы узлов

  • Узлы, которые ждут, пока очередь доходит до них, а затем появляются в сообщениях.
  • Узлы, которые ждут, пока пользователь проявит определенное намерение (например, пользователь напишет: «Я хочу получить страховку»).
  • Узлы, которые ждут подтверждения данных пользователя, а затем сохраняют их.
  • Узлы, реализующие различные алгоритмические конструкции, такие как циклы, ветвление и т.п.

Если узел закрыт, управление не будет передано ему снова, и пользователь не увидит уже заданных вопросов. Следовательно, если мы выполним поиск в глубину на таком графе, мы найдем первый открытый узел. Этот первый открытый узел содержит вопрос, на который пользователь должен ответить следующим. Это повторяется до тех пор, пока все узлы не будут закрыты.

В качестве альтернативы, когда пользователь отвечает на вопросы, которые генерирует Dialog Manager, открытые узлы в графе постепенно закрываются. Как только все открытые узлы закрыты, пользователь полностью выполнил предписанный сценарий. Затем пользователю предоставляется результат, такой как список доступных страховых полисов и их премии.

"Я уже все сказал!"

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

"И кстати…"

Диспетчер диалогов также имеет возможность общаться по нескольким темам одновременно. Например, пользователь говорит: «Я хочу получить страховку». Разговор продолжается вопросами и ответами. Затем, не завершая этот диалог, пользователь заявляет: «Я хочу произвести платеж по одной из других моих политик». В таких случаях диспетчер диалогов сохраняет контекст первой темы и переключается на новый сценарий. Затем, как только второй будет завершен, Dialog Manager предложит возобновить предыдущий диалог, вернувшись к той точке первого сценария, где он был прерван.

Закрытие узлов не означает, что ответы нельзя изменить. Есть возможность вернуться к вопросам, на которые пользователь ответил ранее. Система сохраняет снимок графика при получении каждого сообщения от клиента, что позволяет вернуться к предыдущей точке разговора.

Какие варианты?

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

Наш Dialog Manager создается на Python с использованием фреймворка Tornado, поскольку наши AI-модули изначально были написаны как единый сервис. Язык программирования был выбран таким образом, чтобы все можно было реализовать, не тратя лишние ресурсы на общение.

«Давай определимся» - Служба распознавания

Платформа Elafris способна обмениваться данными по множеству каналов, но все разделы AI полностью независимы от клиента. Все коммуникации происходят только в форме прокси-текста. Диспетчер диалогов передает службе распознавания контекст, ответ пользователя и собранные данные. Служба распознавания отвечает за распознавание намерений пользователя и извлечение необходимых данных.

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

«Расскажи по порядку» - Менеджер по распознаванию

Менеджер распознавания отвечает за все основные этапы распознавания смысла речи: токенизацию, лемматизацию и т. Д. Он также определяет порядок экстракторов (объектов, распознающих сущности и знаки в текстах), какие сообщения будут пропущены, и когда это произойдет. необходимо прекратить процесс распознавания и вернуть готовый результат. Это позволяет запускать только необходимые экстракторы в наиболее типичном порядке.

Если мы спросим имя пользователя, было бы логично проверить, появилось ли это имя в ответе пользователя. Предположим, что имя содержится в ответе, а в ответе больше нет полезного текста, что означает, что на этом этапе распознавание может быть завершено. Если в ответ включены дополнительные полезные сущности, распознавание необходимо продолжить. Скорее всего, человек указал дополнительные личные данные. Соответственно, экстрактор обработки персональных данных должен будет запустить ответ.

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

«Теперь мы понимаем» - Экстракторы.

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

Для оптимальной работы любой сложной системы необходимо комбинировать подходы. Элафрис следовала этому принципу при разработке и внедрении экстракторов. Ниже приведены основные принципы, которые мы использовали в экстракторах Elafris.

  1. Используйте микросервисы, разработанные Elafris, которые содержат машинное обучение. Экстракторы отправляют сообщение этой службе, иногда дополняя его информацией, имеющейся у экстракторов, и возвращают результат.
  2. Используйте теги частей речи (POS), синтаксический анализ, семантический анализ (например, определение намерения пользователя по глаголу сообщения).
  3. Воспользуйтесь полнотекстовым поиском, который поможет найти в сообщениях марку и модель автомобиля.
  4. Используйте регулярные выражения и шаблоны ответов.
  5. Используйте сторонние API (например, Google Maps API или SmartyStreets).
  6. Дословный поиск предложений (например, если человек дает краткий ответ вроде «да», нет смысла передавать его через алгоритмы машинного обучения для поиска намерения).

Также в экстракторах мы используем готовые решения для обработки естественного языка (NLP).

Какие варианты?

Мы исследовали библиотеки NLTK, Stanford CoreNLP и SpaCy. Популярность NLTK очевидна сразу - он первым появился в поиске Google для обработки естественного языка. С ним интересно экспериментировать, создавая прототипы решений, он имеет обширную функциональность и довольно прост. Однако при разработке готовых к производству решений его производительность не соответствует требованиям, предъявляемым к продуктам корпоративного уровня.

Stanford CoreNLP - еще одно хорошо известное предложение NLP, но у него есть серьезный недостаток для любого нетривиального проекта - он тянет за собой легкость и скорость виртуальной машины Java (JVM). Эта библиотека NLP работает в десять раз быстрее, чем NLTK, и предлагает гораздо лучшие словари. Если сравнивать Stanford CoreNLP и SpaCy, последний намного проще в использовании.

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

«Раньше как было…»

Служба распознавания Elafris не всегда состояла из двух частей. Первоначальный вариант был самым тривиальным. Мы по очереди экспериментировали с разными экстракторами и работали, чтобы выяснить, есть ли в тексте какие-то определенные параметры или намерения. Эти ранние итерации не имели ничего общего с ИИ. Это был подход, основанный исключительно на правилах. Сложность, с которой мы столкнулись, заключалась в том, что одно и то же намерение можно выразить множеством способов, каждый из которых должен быть идентифицирован и описан в правилах. При этом необходимо учитывать контекст, поскольку одна и та же фраза от пользователя может потребовать разных действий в зависимости от вопроса, на который был дан ответ. Например, из диалога «Вы женаты?» Пользователь может ответить: «На два года». Из этого ответа мы можем сделать вывод, что пользователь женат (семейное положение - это логическое значение). Тем не менее, тот же ответ на диалог «Как давно вы управляете этой машиной?» - «На два года» решение должно извлекать значение «2 года», но не делать никаких выводов о семейном положении.

С самого начала наша команда понимала, что поддержка решения, основанного на правилах, потребует огромных усилий и инвестиций. С увеличением количества поддерживаемых намерений количество правил будет расти намного быстрее, чем в аналогичной системе машинного обучения. Однако с точки зрения бизнеса мы сначала стремились запустить минимально жизнеспособный продукт (MVP), чтобы показать его полезность и ценность для бизнеса. Подход, основанный на правилах, позволил Elafris быстро продемонстрировать ценность. Команда продолжила использовать MVP на основе правил, параллельно работая над моделью машинного обучения распознавания намерений. После запуска подход машинного обучения вскоре начал давать удовлетворительные результаты, и компания Elafris отошла от подхода, основанного на правилах.

Для большинства случаев извлечения информации Elafris использовал ChatScript. Эта технология предоставляет собственный декларативный язык, который позволяет создавать шаблоны извлечения данных на естественном языке. Благодаря скрытому WordNet это решение является очень мощным. Например, в шаблоне распознавания можно указать цвет, а WordNet распознает любое суженное понятие, такое как красный. В то время ChatScript ничем не отличался от WordNet. Вскоре Элафрис обнаружил, что ChatScript плохо написан и полон ошибок. Включение ChatScript сделало реализацию сложной логики практически невозможной. Команда определила, что недостатки ChatScript перевешивают его преимущества, и отказалась от него в пользу библиотек NLP на Python.

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

"Чего ты хочешь?" - Классификатор намерений

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

Существует множество подходов к классификации намерений на основе нейронных сетей, в частности, на основе рекуррентной долговременной кратковременной памяти (LSTM) / закрытого рекуррентного блока (GRU). Они зарекомендовали себя в недавних исследованиях, но у них также есть общий недостаток, они требуют очень большого образца для правильной работы. На небольших объемах данных такие нейронные сети либо сложно обучить, либо они дают неудовлетворительные результаты. То же самое и с Фреймворком Fast Text от Facebook. Элафрис изучил структуру Facebook, потому что это современное решение для работы с короткими и средними фразами.

Учебные образцы Elafris очень высокого качества: специальная группа лингвистов создает наборы данных фраз. Они являются носителями английского языка и обладают специальными знаниями в области страхования. Однако наши выборки данных все еще относительно малы. Команда Elafris работала над расширением наших собственных наборов данных общедоступными наборами данных. Результаты не соответствовали нашим требованиям. Элафрис исследовал сбор наборов данных фраз с помощью сервисов внештатных сотрудников, таких как Amazon Mechanical Turk, но этот метод также оказался неэффективным; результат оказался особенно низкого качества, и всю работу пришлось полностью перепроверить.

Элафрис продолжал искать решение, которое работало бы на небольших образцах. Классификатор Random Forest показал данные высокого качества при обучении на данных, которые были преобразованы в векторы с помощью нашей модели набора слов. С помощью кросс-валидации наша команда подобрала оптимальные параметры. Среди преимуществ этой модели - более высокая скорость и меньший требуемый размер набора данных, а также относительная простота развертывания и дополнительного обучения.

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

«Об этом всегда спрашивают» - FAQ

У многих наших клиентов есть разделы часто задаваемых вопросов. Цель состоит в том, чтобы предоставить пользователям ответы прямо с платформы AI. Для достижения этой цели необходимо создать решение, которое (а) распознает запрос FAQ и (б) находит наиболее релевантный ответ в базе данных, а © доставляет ответ пользователю.

Существует ряд моделей, обученных на Стэнфордском наборе данных вопросов и ответов (SQuAD). Эти модели хорошо работают, когда текст ответа из FAQ содержит слова из вопроса пользователя. Например, предположим, что в FAQ сказано: Фродо сказал, что отнесет кольцо в Мордор, но не знал, как добраться туда. Если пользователь спросит: Где Фродо берет Кольцо?, Система ответит: В Мордор.

Наш сценарий в целом был другим. Например, на два похожих запроса: «Могу ли я заплатить?» и «Могу ли я платить онлайн?» платформа ИИ должна реагировать иначе. В первом случае человеку предлагается форма оплаты или он входит в поток платежей. Во втором случае система отвечает: «Да, вы можете платить онлайн. Вот ссылка, по которой вы можете заплатить ".

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

Другое решение - подход Doc2vec. Эта стратегия превращает большой текст в векторное представление, которое затем сравнивается с другими документами в том же формате, что затем вычисляет коэффициент подобия. Для целевого использования продукта от этого подхода тоже пришлось отказаться. Он ориентирован на длинные тексты, но наши пользователи в основном взаимодействуют, используя вопросы, а ответы состоят из одного, а иногда и двух предложений.

Наша стратегия была основана на двух шагах. Сначала, используя встраивание, мы переводим каждое слово в предложении в векторы, используя модель Google Word2vec. Затем мы рассматриваем средний вектор по всем словам, представляя одно предложение как один вектор. Во-вторых, мы берем вектор вопросов и находим вектор ответов в базе данных часто задаваемых вопросов, который наиболее точно соответствует вектору вопроса, в нашем случае косинус.

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

"И говорить?" - Болтовня

Иногда пользователь пишет что-то совершенно неактуальное, например: «Сегодня хорошая погода». Этот тип фраз не входит в область, на которую мы ориентируемся для клиентов нашей страховой компании. Однако, чтобы конечный пользователь чувствовал себя естественно, система должна разумно реагировать, демонстрируя интеллект нашей системы.

Для решения таких задач платформа Elafris использует комбинацию подходов, описанных выше. Ответы основаны либо на простых решениях, основанных на правилах, либо на генеративных нейронных сетях. Элафрис стремился быстро создавать прототипы, поэтому команда взяла общедоступный набор данных из Интернета и использовала подход, очень похожий на тот, который использовался для FAQ. Например, если пользователь написал что-то о погоде, наша система использует алгоритм, сравнивающий векторные представления сообщения и векторные представления из общедоступного набора данных, чтобы сравнить два предложения для определенной меры косинуса. С помощью этого метода наша система ищет в общедоступном наборе данных документ, который максимально приближен к теме погоды.

Обучение

Сейчас у нас нет цели создать платформу искусственного интеллекта, которая бы училась на каждом сообщении, полученном от клиентов. Во-первых, опыт показывает, что это путь к быстрой смерти (вспомните, как IBM Watson пришлось стереть базу данных, потому что он начал диагностировать с помощью нецензурных слов, а платформе Microsoft Twitter-AI удалось стать расистской за один день. ). Во-вторых, мы стремимся максимально закрыть задачи страховых компаний; Самообучающаяся платформа искусственного интеллекта не является нашей бизнес-целью. Мы написали ряд инструментов для наших лингвистов и команды QA, с помощью которых они могут вручную обучать платформы AI, изучать диалоги и переписку с пользователями во время пост-модерации.

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

Планы

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

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

Еще одна функция, над которой мы работаем, - это обработка обратной связи. После завершения диалога с платформой AI мы спрашиваем пользователей, удовлетворительна ли услуга виртуального агента. Если анализ настроений распознает отзывы пользователей как положительные, система предлагает пользователю поделиться своим мнением о связанных социальных сетях. Если анализ показывает, что пользователь отреагировал отрицательно, платформа AI разъясняет, что было неудовлетворительным, и обрабатывает отзывы, говоря пользователю: «Спасибо. Мы будем работать над улучшением на основе ваших отзывов ». но не предлагает делиться отзывами в социальных сетях.

Один из ключей к тому, чтобы сделать общение с платформой AI как можно более естественным, - это сделать платформу AI модульной и расширить набор доступных ей реакций. Мы работаем над этими улучшениями. Возможно, благодаря этому драйву пользователи готовы искренне принять нашу платформу AI в качестве страхового агента. Следующий шаг - поблагодарить человека за саму платформу ИИ.

Первоначально опубликовано на www.elafris.com.