Почему ИИ-помощник не решит задачи клиентского сервиса

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

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

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

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

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

Зачастую память бота ограничена текущей сессией или, по крайней мере, конкретным каналом: например, у чат-бота не всегда есть доступ к звонкам и общей истории обращений. А значит, стоит человеку перейти в другой канал – контекст того, о чем договаривались, теряется.

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

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

Вот как это может выглядеть для клиентского сервиса:

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

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

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

Агент качества проверяет результат до того, как он попадет к клиенту: достоверны ли факты, соблюдены ли правила, корректен ли тон и нет ли риска раскрытия личных данных.

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

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

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

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

В результате удается снять ограничения одиночного помощника:

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

Например, клиент пишет: «Измените тариф на следующий месяц»

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

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

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

Например, клиент обращается из-за двойного списания за одну покупку.

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

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

Словом, если всех агентов запускать последовательно, это сильно растянет время.

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

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

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

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

Именно такой подход мы развиваем в BSS в рамках мультиагентной ИИ-платформы управления клиентским опытом – от отдельных ИИ-инструментов к единой системе, которая умеет принимать решения и доводить их до результата, который нужен клиенту.