Почему одного ИИ-бота недостаточно для обслуживания клиентов

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

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

Дирижер не играет

Удобная аналогия: солист и оркестр. Солист импровизирует в одиночку, его ошибку слышат все, и исправить ее некому. В оркестре у каждой партии свой инструмент и своя задача, а дирижер держит партитуру и знает, кому и когда вступать.

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

Архитектура платформы: каналы контакта, оркестратор, специализированные агенты, сквозные слои и оператор

Шесть ролей

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

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

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

• Агент-исполнитель проводит операции в учетных системах: платежи, заявки, смену тарифа. Его главный риск в необратимости действий, поэтому операции с деньгами и персональными данными он выполняет только из закрытого перечня, с подтверждением и точкой отката;

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

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

• Агент эскалации передает обращение оператору с полным контекстом и помогает ему по ходу разговора. Если передать обращение без накопленных сведений, вся предыдущая работа системы обесценивается.

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

Как агенты передают работу

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

• Жесткий граф переходов. Маршруты прописаны заранее, как партитура: предсказуемо, легко проверяется, дешево. Для промышленных систем это выбор по умолчанию.

• Маршрутизация силами модели. Модель сама решает, кому передать задачу. Гибко, но допустимо лишь под присмотром контролера качества и с резервным сценарием;

• Свободное взаимодействие агентов. Максимальная гибкость и максимальный риск: зацикливание и неконтролируемый рост затрат. Без жестких ограничителей в эксплуатации не применяется.

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

В любом варианте обязательны три элемента:

• предел числа шагов, чтобы агенты не гоняли обращение по кругу;

• передача накопленного состояния вместо старта с чистого листа;

• заранее определенная точка отката на случай сбоя исполнителя.

Оператор как штатный сценарий

Перевод диалога на сотрудника заранее спроектирован как один из маршрутов. Эскалация происходит по известным правилам: высокая цена ошибки и необратимость операции, низкая уверенность модели, чувствительная тема (жалоба, подозрение на мошенничество), прямая просьба клиента, требования регулятора.

Передача обращения оператору: когда передаем и что передаем

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

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

Пилот против промышленной системы

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

С чего начинать

Зачем вообще дробить систему на агентов? Разделение ролей позволяет проверять каждый компонент отдельно, по-разному защищать ответы и операции и видеть, что происходит внутри. У монолитного ассистента всего этого нет.
Сколько агентов нужно? Ровно столько, сколько у вас действительно разных зон ответственности и показателей качества, и ни одним больше. Система из многих агентов ради моды быстро превращается в дорогой хаос. Разделение ролей под управлением оркестратора с четкими правилами, напротив, зрелая инженерная практика. Начинать стоит с памяти о диалоге, вынесенной из модели, набора эталонных диалогов для проверки каждого изменения и четкой границы, за которой в работу вступает человек. Число агентов определится само.

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