Как создать ИИ-агента для клиентского сервиса за несколько минут

Зачем заменять сценарных ботов агентами, и как их разработать с минимумом программирования – пошагово, с примерами

На связи компания–разработчик ИИ-инструментов для клиентского сервиса. Наши голосовые помощники уже работают в МФЦ и линии 122 в десятках регионах РФ, а также в компаниях от ритейла до банков и страхования.

В статье разберем, зачем и как создается ИИ-агент для клиентской поддержки.

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

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

Для начала краткий экскурс по тому, как устроен ИИ-агент. Основные компоненты:

Таким образом, ему не нужно прописывать каждую формулировку и последовательность действий. Далее разберем три причины, почему такое устройство часто эффективнее сценарных ботов.

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

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

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

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

Это сразу дает эффект – например, когда мы заменили сценарного бота по нескольким тематикам в одном банке на связку LLM с RAG, индекс удовлетворенности клиента (CSI) вырос с 3,75 до 4,83.

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

Например, клиент хочет вернуть товар.

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

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

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

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

Кстати, тестирование ИИ-поиска по базе знаний можно ускорить и проводить с помощью другой LLM. В нашем кейсе замена сценарного бота снизила трудоемкость автоматизации в 3 раза по сравнению с разработкой сценариев и обучением ML-моделей.

Итак, разобрались, зачем ИИ-агент нужен. Но механизм сложнее на порядки – наверняка и разработка занимает много времени?

На практике современный инструментарий позволяет собрать агента быстро.

Сначала нужно выбрать ИИ-модель в зависимости от того, насколько сложны задачи и какое качество ответов критично. Затем настроить температуру, которая влияет на то, насколько ответы будут стандартными или разнообразными, формальными или живыми.

Здесь же можно определить лимиты: сколько токенов максимум может сгенерировать агент, а также сколько раз он может обратиться к ИИ-модели в рамках одного запроса, а когда уже пора передать диалог оператору.

Такие настройки позволяют найти баланс между качеством консультации и ее стоимостью для компании – и дает возможность не потратить все ресурсы на ИИ.

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

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

Если у компании есть MCP-сервер, который адаптирует запрос агента к привычному интерфейсу системы (REST API, GraphQL, SQL, SDK, webhook или другому корпоративному протоколу), агент может воспользоваться им. В ином случае агент сможет подключиться к системам по обычному API.

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

Во-первых, в инструкциях задаются ситуации, когда передавать запрос на оператора. Например, если клиент этого попросил или если по доступной в корпоративных системах информации нельзя сформировать полный ответ.

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

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

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

Оценку основываем на нашем инструменте для разработки ИИ-помощников – в нем агента можно создать двумя способами.

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

Дальше остается лишь скорректировать инструменты подключения к внешним системам: проверить входные и выходные данные и при необходимости прописать код интеграции.

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

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

Также код нужен, если у системы нет готового коннектора, но есть API, база данных или внутренний сервис – тогда код становится «прослойкой» между агентом и этой системой.

Если у вас нет диалогов или хочется пройти весь путь с нуля, то необходимо:

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

Для сравнения, создание сценарного бота занимает около 3 часов: нужно разработать классификатор, прорисовать логику сценария (см первый раздел).

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

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