Почему AI ≠ ML. На примере диалога с машиной на естественном языке

CEO "Наносемантики" Станислав Ашманов о том, где и как машинное обучение приносит пользу чат-ботам, какие есть вокруг этого мифы и завышенные ожидания.

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

Хайп «машин лёнина» последних лет полностью убедил большинство людей ИТ-отрасли в том, что ИИ – это когда мы находим где-нибудь гигантскую Big Data, скармливаем её ИИ, а он потом там самостоятельно находит «инсайты» и оптимальные решения любых проблем.

Почему ИИ – это не обязательно машинное обучение, мы бы хотели рассказать на примере того, в чём разбираемся хорошо. Мы, компания «Наносемантика», занимаемся созданием чат-ботов уже больше пятнадцати лет. Ниже я покажу, где и как машинное обучение приносит пользу чат-ботам, какие есть вокруг этого мифы и завышенные ожидания.

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

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

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

Хорошо спроектированный и обученный чат-бот в состоянии дать существенную экономию расходов на «белковых» операторов: в некоторых из наших кейсов чат-боту удавалось взять на себя 50-80% всех входящих запросов, и тем самым сильно сэкономить клиентам деньги и снизить загрузку линий.

Чат-бот должен решать несколько задач:

• знать ответы на максимум информационных запросов («какие у вас есть тарифы», «где ближайший офис», «как сменить оператора с сохранением номера»),

• уметь распознать и исполнить транзакционный запрос («хочу сменить тариф», «какой у меня баланс»), выполнив запрос в базу данных CRM и/или биллинговую систему,

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

Как именно реализовано распознавание типов запросов и как наполняется и обновляется база знаний бота — специфика реализации.

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

В современном «модном» машинном обучении чат-ботов распознавание типов запросов называется intent recognition («распознавание намерения»), «ведение» диалога по скрипту или диалоговому дереву – dialogue management, а выделение параметров из реплик пользователя (например, имён, названий тарифов, мобильных номеров и пр.) – slot filling («заполнение значений переменных»).

Все эти стадии в своих проектах мы реализуем с помощью основанного на правилах и алгоритмах (rule-based) подхода, или «правильного» подхода: возможные вопросы пользователей описываются с помощью шаблонов с кванторами – на языке описания диалогов, похожем на регулярные выражения.

Это то, как Джозеф Вейценбаум учил свою Элизу, – первого в истории виртуального собеседника, то, как изначально был задуман известный язык AIML (Artificial Intelligence Mark-up Language). Это всё придумано в прошлом веке. Но пока это тот единственный в мире подход к человеко-машинному диалогу на естественном языке, который на данный момент хорошо и предсказуемо работает.

Существуют открытые средства для построения rule-based чат-ботов – например, проект ChatScript.

Наш собственный язык называется Dialogue Language, он мощнее, проще и удобнее AIML, но пока не доступен для сторонних разработчиков.

Основанные на правилах чат-боты делаются так:

• Постановка задачи. Мы определяем с заказчиком, какие общие задачи у бота, каково его позиционирование, на какие типы вопросов должен отвечать чат-бот (обычно помогает то, что у заказчика есть FAQ, сайт, внутренняя база знаний). Кроме того, обязательно проектируется личность чат-бота (характер, стиль, область знаний пр.).

• Создание обобщающих шаблонов и деревьев диалогов. Дата-инженеры (специалисты по базам знаний) на специальном языке пишут шаблоны, которые нужны для распознавания возможных вопросов. Шаблон может покрывать сотни тысяч возможных правильных языковых конструкций, которые в принципе могут прийти в голову носителю языка. Шаблоны затем объединяются в диалоговые деревья, с запоминанием контекста и извлечённых переменных.

• Извлечение параметров запроса. В процессе диалога всегда возникает потребность извлечь данные из запроса пользователя (сделать slot filling). Это решается с помощью распознавания именованных сущностей (named entity recognition), реализовано может быть по-разному.

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

Дальше следует внутреннее и внешнее тестирование, внедрение чат-бота к заказчику, развёртывание его в нашем облаке или на серверах заказчика.

В целом, вроде бы ничего хитрого. Но дьявол – в деталях.

Основная претензия к rule-based подходу – это обычно недовольство тем, что нужно писать шаблоны. Как правило, это не нравится программистам или руководителям IT, бывшим программистам. Кроме инстинктивного ощущения, что «Это же ерунда – всё вручную писать», есть чёткая претензия: «Да вы что, невозможно ведь все варианты формулировок заранее продумать – это огромная работа, которая даст очень низкую полноту ответов».

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

Что касается "Наносемантики", то у нас за 15 лет накоплены огромные базы шаблонов и словарная база для различных отраслей и предметных областей (банки, авиаперевозки, ритейл, страхование и пр.). В общем-то, это наша ключевая интеллектуальная собственность, важнее собственного движка чат-бота и языка Dialogue Language.

Поэтому, например, имея такую базу, нового банковского чат-бота нам сделать очень просто, а освоение новой тематики (например, «ритейл») требует всего дополнительных 1-2 месяцев работы двух дата-инженеров.

В противоположность к описанному rule-based подходу, при машинном обучении чат-ботов предполагается такая схема работы:

• Берём данные. Мы берём у клиента журналы сотен тысяч диалогов из контактного центра.

• Чистим эти данные (что значит чистим – объясним ниже).

• Размечаем. В почищенных данных размечаем intent’ы: каждую реплику относим к конкретному типу.

• Обучаем. Скармливаем базу «реплика + intent» алгоритму машинного обучения. Какому именно – не очень принципиально, обычно это SVM (метод опорных векторов) или DSSM (глубоко структурированная семантическая модель), с предварительной векторизацией слов.

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

В нужные моменты, для транзакционных запросов, чат-бот извлекает значения переменных параметров с помощью упомянутого выше распознавания объектов (named entity recognition), как и в rule-based подходе.

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

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

• Данные чувствительные. Если база есть, клиент может не иметь возможности передать её нам, не нарушая закон о персональных данных. Потребуется на стороне клиента почистить базу, удалив любые данные, позволяющие идентифицировать клиентов клиента.

• В базе – мусор. Если база у клиента есть, и он её почистил, то дальше есть проблема чистки базы от конкретных ответов конкретным людям: в ответе на вопрос «Какой у меня баланс телефона?» в базе данных будет конкретная сумма для клиента –«256 рублей», которая из обучающей выборки, конечно, должна быть убрана. Иначе мы на вопрос Пети о балансе в сентябре 2018 года ответим балансом Маши на декабрь 2016 года.

• В данных нет обращений во внешние БД. Для обработки транзакционных запросов, должна происходить транзакция – обращение к внешнему сервису. В журналах диалогов этих обращений нет, есть только ответы про то, какой был у Маши баланс в 2016 году. Эту логику машинным обучением не реализовать, всё равно разработчику нужно анализировать логи разговоров и встраивать в диалоги чат-бота обращения к биллингу, CRM и пр.

• Разметка всё равно ручная. Если мы почистили базу, остаётся задача разметки intent’ов – это большой ручной труд. Да, разметчикам можно иногда платить в 2-3 раза меньше, чем дата-инженерам, но, во-первых, с разметчиками трудно работать в принципе – они очень неаккуратно размечают. А кроме того, дата-инженер в целом решает более маленькую по объёму задачу: глядя на примеры диалогов, вопросов FAQ и пр., понять, что и как клиент может спросить и написать мощный шаблон. Наши обычные enterprise-проекты мы реализуем за 2-3 месяца, задействуя 2-3 дата-инженеров. Это не такие уж и гигантские масштабы работы.

• Принципиальная неполнота данных. Надо понимать, что какие бы ни были большие наборы журналов диалогов, они принципиально неполны: носитель языка в состоянии задать вопрос – абсолютно грамотный и органичный – которого не было в прошлом. Если в запросе пять слов, у каждого из которых несколько синонимов, то количество возможных вариантов – десятки тысяч на один запрос. Часто доля новых запросов – это десятки процентов в месяц. Бот, обученный на журналах прошлых диалогов, не сможет покрыть все новые вопросы и даст ошибку. Именно в этом месте написание шаблонов с хорошим покрытием и вариативностью имеет огромное преимущество перед машинным обучением «по площадям».

• Плохое ведение фокуса диалога. Распознавание «интентов» на каждом этапе – не то же самое, что дерево диалога с запоминанием ответов и контекста. Для высокоответственных применений такое «угадывание» интента не подходит.

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

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

Если вам кто-нибудь говорит, что делает хорошо работающего чат-бота полностью на нейросетях или машинном обучении – знайте, что вас обманывают. Или этот чат-бот не работает хорошо, или там машинного обучения – 5% от всей системы.

Но машинное обучение может приносить (и приносит нам) пользу в следующих задачах:

• Исправление опечаток во входных фразах

• Подбор синонимов к словам для помощи дата-инженеру в процессе разработки

• Кластеризация логов контактного центра для выявления частотных запросов в помощь дата-инженеру

• Автоматические ответы для FAQ-ботов (интересная технология – расскажем в отдельной статье)

• Нечёткий поиск по парам вопрос-ответ для информационных запросов.

Это всё полезные применения, которые экономят время разработки и повышают итоговое качество чат-бота.

Целью этой статьи было рассказать, почему не стоит ждать лёгкого и быстрого успеха от машинного обучения в области чат-ботов:

• Чат-бот не может быть реализован полностью на машинном обучении: машинное обучение – это небольшая добавка к системе, повышающая эффективность разработки.

• Чат-ботов можно и нужно делать на rule-based подходе: это работает, это вполне подъёмная задача, это гарантирует качество.

• Искусственный интеллект – это не только машинное обучение, пример – чат-боты на правилах (кроме того, есть экспертные системы, логика и другие области, помимо машинного обучения).

Хайп машинного обучения добрался до нашей отрасли. Может быть, доберётся и до вашей.