Робот заменяет первую линию поддержки

Система частично выполняет функции первой линии поддержки — она анализирует поступающие запросы пользователей, которые жалуются на то, что что-то пошло не так. Запрос составляется на естественном языке, но с использованием классификатора проблем, состоящего из более чем 450 классов. Если робот считает, что он понял суть проблемы (это происходит приблизительно в 40% случаев), то он или назначает задание сотруднику второй линии, или передает запрос агенту с предложением своей версии произошедшего. Агент, получив рекомендации, соглашается или не соглашается с мнением робота и также передает запрос на вторую линию.

В среднем из двухсот ресторанов, обслуживаемых системой, в месяц приходит более 7 тыс. запросов. «Свою» часть работы робот делает за 22 секунды, тогда как у «живой» первой линии это занимало несколько минут. Первоначально роботу доверяли лишь составление рекомендаций, в последние три месяца — и самостоятельное назначение сотрудников, ответственных за обработку заявки. Из 40% заявок, по которым робот принял решение в последний месяц, в 16% случаев он сделал самостоятельное назначение, в 22% случаев — выдал верную рекомендацию и всего в 2% случаев — ошибся.

Computerworld Россия поговорил с Каштановым о проекте, его текущих возможностях и планах по развитию.

— Упоминавшиеся семь тысяч запросов в месяц приходят по всем каналам или через систему?

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

—  Какова пиковая нагрузка?

Около 500 запросов в день.

— Робот принимает решение за 22 секунды, он столько «думает» над заявкой?

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

—  Система принимает во внимание должность пользователя?

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

—  Реагирует ли робот на всплеск однотипных запросов — например, если из одного ресторана поступит много запросов одновременно, или из разных — но на одну и ту же тему?

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

—  И ее возможностей хватает?

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

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

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

— Сложно ли переобучить систему для работы в других областях? И насколько она масштабируема?

Сама методология универсальна и может использоваться во многих сферах. Где-то она может работать лучше, чем в ИТ, где-то хуже.

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

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

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

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

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

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