Написать тупого чат-бота несложно. Гораздо сложнее написать умный, который разумно отвечал бы на все, что вы его просите. Некоторые известные примеры: если человек упоминает Харрисона Форда, он, вероятно, имеет в виду не машину.

Существует три разных типа чат-ботов, и писать о каждом из них становится все труднее.

  1. Самые простые чат-боты - это просто удобный интерфейс командной строки: в Slack или Hipchat обычно есть команды с косой чертой. Разработчики настроят программу, которая просыпается до «/ build» всякий раз, когда она входит в комнату, которая извлекает последние исходные коды из git, компилирует их и показывает результаты модульных тестов. Поскольку это очень узкая область, в ней легко разобраться, и поскольку это выгодно программистам, всегда экономически выгодно потратить некоторое время программиста на улучшение чего-либо, что бесполезно.
  2. Следующими простейшими задачами являются боты-заказчики, которые контролируют диалог, никогда не позволяя пользователю отклоняться от утвержденного пути разговора. Если вы заказываете пиццу, бот может задавать вам вопросы о начинках и размерах, пока не получит все необходимое. По сути, это просто замена веб-формы с некоторыми полями, но на определенных рынках (например, в Китае), где есть почти универсальные чат-платформы, это может быть довольно удобно.
  3. Сложнее всего - это боты, которые не могут контролировать беседу и где пользователь может спросить что угодно.

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

Я провел быстрый опрос и нашел как минимум 50 стартапов, пытающихся написать ботов для службы поддержки различного типа. Это прибыльный рынок, потому что, если вы даже можете превратить 10% звонков в службу поддержки в чат с ботом, это может означать огромную экономию затрат на персонал. У меня есть клиент с более чем 150 штатными сотрудниками в их службе поддержки - можно сэкономить миллионы долларов.

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

Я видел три ловушки:

  • Некоторым стартапам не хватило смелости поверить в собственных разработчиков. Существует мнение, что у Microsoft, Facebook, Amazon, IBM и Google есть все ответы, и что если мы воспользуемся api.ai или wit.ai, или lex, или Watson, или что-то еще, что они создали в этом месяце, то останется лишь простое «знание службы поддержки». и личность », чтобы положить поверх него, как глазурь на торте. По сути, это не работает: по очень серьезным коммерческим причинам крупные игроки работают над технологией для ботов, которые заменяют веб-формы, и с этой предвзятостью возникает ряд ограничивающих предположений.
  • Многие стартапы (и более крупные компании) считают, что если вы просто извлечете достаточно данных из интрасети - например, проанализируете каждую статью в Confluence, - вы сможете дать пользователю точный ответ. Другие идут дальше и тоже пытаются очистить общественные форумы. Это не работает, потому что, во-первых, пользователи часто не могут очень хорошо объяснить свою проблему, поэтому заранее не хватает информации даже для того, чтобы понять, чего хочет пользователь; и, во-вторых, вы действительно читали, что ИТ-специалисты помещают в свои хранилища знаний?
  • Есть много разных вещей, которые могут пойти не так, и много разных способов решения проблемы. Если вы попытаетесь сделать своего чат-бота поддержки полностью автономным, способным ответить на что угодно, вы потратите много денег, обрабатывая странные маленькие угловые случаи, которые могут никогда не повториться.

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

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

Проблема в том, что в чате поддержки часто бывает трудно понять, о чем идет речь в каждом ответе службы поддержки. Есть некоторые техники, которые я реализовал (например, разделение на основе временной близости, @ упоминания и т. Д.). Консервативный подход - иметь отдельную комнату для обучения ботов, где происходят только чисто подготовленные разговоры. Использование этого подхода означает, что мы заменяем дорогих высокооплачиваемых программистов, пишущих код для обработки разговоров, стажером, пишущим некоторые текстовые чаты.

На самом деле не так уж и сложно найти стажера, который просто хочет провести весь день в чатах.

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

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

Существует множество научных статей и множество хорошо изученных передовых методов решения задач машинного обучения с текстом на естественном языке. Хорошие решения были найдены в машинах опорных векторов, архитектурах LTSM для глубоких нейронных сетей, встраивании предложений word2vec.

Оказывается, методы 1960-х годов работают достаточно хорошо, и вы можете написать решение за несколько часов. Я использовал модель набора слов в сочетании с логистической регрессией и получил вполне приемлемые результаты. (На этом этапе почти любой серьезный специалист по данным или гуру искусственного интеллекта справедливо должен хихикать на заднем плане, но терпите меня.)

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

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

Редко бывает, что первое, что говорит агент службы поддержки, - это полное и исчерпывающее решение проблемы. Итак, я добавил «память» для пользователя и агента. Что пользователь сказал перед тем, как он сказал последнее слово? Я реализовал это методом экспоненциального затухания. Если ваш вектор «памяти» был x, а последнее, что вы сказали, было y, тогда, когда вы скажете z, я обновлю вектор памяти до (x / 2 + y / 2). Затем после вашего следующего сообщения он станет (x / 4 + y / 4 + z / 2). Постепенно то, что вы сказали некоторое время назад, становится менее важным для предсказания того, что будет дальше.

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

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

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

И это все, что вам нужно сделать, чтобы сделать чат-бота на удивление успешным. Вы можете настроить, насколько уверенным должен быть чат-бот, прежде чем он заговорит (например, ничего не говорите, если вы не уверены на 95%, что ответите так, как это сделает агент службы поддержки). Вы можете выкинуть матрицу сильных сторон, чтобы понять, почему чат-бот решил дать ответ, когда он ошибается. Если ему нужно узнать что-то еще или он ошибается, вы можете просто дать ему еще один пример для работы.

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

Я выступал с этим докладом в Atlas Camp в Барселоне, и, надеюсь, мне удастся повторить его в Сан-Хосе позже в этом году. Вот видео: https://youtu.be/YMW27HjJPAw