От NLU-бота к ИИ-агенту: как мы пробили потолок автоматизации в поддержке крупного банка

Привет, Хабр! На связи команда Just AI.

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

Потолок NLU-ботов и цели автоматизации в банковском сервисе

Как и многие крупные компании, наш клиент-банк давно использовал NLU-бота (бот на основе распознавания намерений) для поддержки первой линии. Но со временем система, которая когда-то казалась эффективной, превратилась в источник проблем. Команда столкнулась с классической ситуацией:

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

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

• Непонимание контекста. Бот реагировал на последнее сообщение, но плохо понимал общую суть диалога. Пользователи часто попадали не в ту ветку, злились, и все это вело к негативу.

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

• повысить уровень автоматизации и снизить долю переводов на оператора;

• обеспечить быстрые ответы без потери качества;

• давать персонализированные ответы на основе данных клиента.

Почему ИИ-агент, а не NLU-бот

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

Классический NLU-бот — это, по сути, сложная система «если… то…», работающая по заранее прописанным правилам. 

ИИ-агент — это автономный исполнитель. Его работа строится на двух основных компонентах:

• «Мозг агента» — LLM (большая языковая модель), которая отвечает за понимание запроса, рассуждение и построение логики для достижения цели.

• «Руки» — инструменты — это набор функций, которые агент может вызывать. Например, сходить в базу данных банка, обратиться к API (программному интерфейсу) для получения транзакций и так далее.

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

Казалось бы, можно взять одного хорошо настроенного агента с детальной инструкцией (промптом) — и этого достаточно. В большинстве сценариев так и есть. Но банковский контекст накладывает жесткое требование: ответ должен быть не просто релевантным, а фактически точным. Любая галлюцинация — это репутационный риск. Один агент, каким бы хорошим он ни был, не дает нужного уровня контроля. Именно поэтому мы сразу проектировали систему как мультиагентную.

Архитектура нашего решения

Наша мультиагентная система состояла из двух агентов и набора функций, которые давали доступ к данным и бизнес-логике. Мы не можем раскрывать полный список из-за NDA (соглашения о неразглашении), но приведем типовые примеры таких функций:

• поиск одной или нескольких транзакций клиента;

• проверка активных кешбэк-программ и акций;

• расчет и проверка начисленного кешбэка для отдельной транзакции;

• проверка лимитов и условий программ;

• получение информации из базы знаний.

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

• Основной агент: его задача — вести диалог с клиентом, понимать его запрос и использовать инструменты для получения данных. 

• Агент-судья: это наш внутренний контроль качества. Он проверяет ответ основного агента, прежде чем тот уйдет клиенту. Если «Судья» видит галлюцинацию или неточность, он перенаправляет ответ обратно в первого агента и просит его переделать — в банковских сценариях такая проверка просто обязательна.

Собираем агентов для мультиагентной системы

Разберем, как собирается такая система на Just AI Agent Platform. Процесс очень наглядный и состоит из нескольких шагов. Можно забыть про сотни строк скриптового кода и запутанные ветки — здесь все строится на логических блоках.

Шаг 1: Собираем каркас на холсте

Все начинается с пустого холста — это наше рабочее пространство. Слева у нас есть палитра с четырьмя типами блоков:

• Агенты — это «мозг» нашей системы на основе LLM.

• Функции — те самые «руки», которые мы даем агенту.

• Триггеры — то, что запускает нашего агента. Чаще всего это сообщение в чате, но может быть и веб-хук, и письмо на почту.

• Технические блоки: отправка ответа, блоки с кодом и т.д.

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

Шаг 2: Настраиваем первого агента

Это самый важный этап, где мы заполняем несколько полей:

1. Модель: создаем интеграцию с LLM и выбираем эту LLM, которая будет «мозгом».

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

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

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

• Как работать с конкретными запросами клиентов по кешбэку.

• Как и когда использовать доступные ему функции.

• Как реагировать на нерелевантные вопросы, грубость и попытки взломать через промпт-инъекции (атаку через подмену инструкций).

• Бизнес-правила: любая  LLM обучена на широком массиве текстов, поэтому у нее  уже есть знания о разнообразных темах по умолчанию (например, о том, как работают банки или кешбэк «в общем»), но их часто нужно уточнять или переопределять под конкретный продукт. Поэтому в системном промпте мы можем дополнить недостающую информацию.

Чем детальнее инструкция, тем предсказуемее и точнее будет работать агент.

Шаг 3: Настраиваем функции

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

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

• get_transactions (user_id, store_name, date_range): получает транзакции клиента за определенный период.

• get_cashback_programs (user_id): узнает, какие кешбэк-программы активны у клиента.

• get_info_from_knowledge_base (query): ищет ответы на общие вопросы в базе знаний*

*Это лишь часть функций: полный список не приводим из-за NDA.

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

Шаг 4 Настраиваем второго Агента-судью. Путь такой же:

• Модель: создаем интеграцию с LLM и выбираем эту LLM, которая будет «мозгом».

• Роль: специалист банка.

• Цель: проверить ответ автоматического агента на вопрос пользователя.

• Описываем подробную инструкцию.                                                                                                                 

Шаг 5 Тестирование и отладка

После того как все готово, мы публикуем проект и запускаем тестовый виджет. Здесь мы можем вести диалог с агентом так, как это делал бы реальный клиент.

Для того, чтобы продемонстрировать решение клиенту мы собрали аналог личного кабинета банка — у нас там есть пользователь Андрей, у него есть активные программы кешбэка, список транзакций за неделю — те, за которые есть кешбэк, и за которые нет.

Именно на этом этапе мы проверяем, как агент справляется с разными формулировками. Пользователи, как вы знаете, часто пишут на разговорном языке, с ошибками и сленгом. Например: «Йо, покупал тут неделю назад курицу и яйца, кешбэк будет?».

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

• Какой запрос он получил.

• Как он его интерпретировал.

• Какую функцию он решил вызвать.

• С какими параметрами он ее вызвал.

• Какой ответ он получил от функции.

• Как он на основе этого ответа сгенерировал финальный текст для пользователя.

Логи — ключевой инструмент для отладки и дообучения агента через уточнение инструкций.

Старый бот на таком запросе бы споткнулся: сленговое «йо», отсутствие конкретного магазина, размытый временной диапазон «неделю назад» — любой из этих факторов мог привести не в ту ветку. Агент же делает следующее:

1. Он понимает запрос: речь идет о покупках продуктов питания за последнюю неделю, магазин не уточнен.

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

3. Из базы данных банка приходит информация: транзакция от 25 марта 2026 года в «Магните» на сумму 1122,57 ₽.

4. Агент видит, что у клиента активна программа «Категорийный кешбэк Продукты питания» со ставкой 5%. Считает: 1122,57 × 0,05 = 56,12 ₽.

5. Собирает все это в человеческий ответ: «Привет, Андрей! Я проверил твои покупки за последнюю неделю. Нашел транзакцию по категории «Продукты питания» от 25 марта в «Магните» на сумму 1122,57 ₽. По программе «Категорийный кешбэк Продукты питания» тебе начислят 5% — это 56,12 ₽. Кешбэк будет начислен в следующем месяце».

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

Агент вызывает ту же функцию get_transactions, находит платеж в Мосэнерго на 10 000 ₽ и определяет категорию — «коммунальные услуги». Дальше он обращается к бизнес-правилам из инструкции и отвечает: «Эта категория не участвует в программах лояльности, кешбэк начислен не будет».

Это важный момент: агент не просто извлекает данные, он применяет правила. Никакой ветки сценария под «оплату ЖКХ» нет — есть инструкция с логикой, и агент сам разбирается, что к ней относится.

Результаты в цифрах

Конечно, самое интересное — это то, как внедрение агента отразилось на реальных бизнес-метриках. Но сначала — о том, как именно мы это измеряли, потому что тестирование ИИ-агента принципиально отличается от тестирования NLU-бота.

Как устроено тестирование

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

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

• Предобработка: отсеивали неполные и бессмысленные диалоги, приводили их в формат, читаемый языковой моделью — сообщения с ролями user, assistant, system.

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

• Разметка: добавляли теги для навигации — например, почему NLU-бот не решил вопрос, или суммаризацию цели клиента.

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

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

Оговорка про выбор модели

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

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

Итак, цифры

• Нагрузка на операторов снизилась более чем на 13%.

• Качество диалогов улучшилось почти в 1.5 раза, а точность понимания вопроса, даже со сленгом и опечатками, выросла на 20%. Клиенты стали получать релевантные ответы быстрее.

• Автоматизация: уровень решения вопросов без участия человека вырос с ~37% до показателей, сопоставимых с работой опытного оператора — 64,2%.

Вывод

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

Наши главные выводы от этого проекта: 

Главная сложность — это, конечно, галлюцинации LLM. Нельзя просто дать модели доступ к данным и ждать чуда. Обязательно проверяем и контролируем. 

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

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

Надеемся, этот разбор был полезен. Готовы ответить на вопросы в комментариях!

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