Сначала архитектура, потом «магия»: наш путь от сценарных голосовых ботов к умным ассистентам

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

Есть популярный миф. Мол, сначала бот живёт на жёстких сценариях. Потом к нему подключают LLM — и он сам превращается в почти живого собеседника. Звучит красиво. В реальности так не работает. Если посмотреть на реальные проекты в финтехе, всё происходит гораздо проще и… скучнее.

Этот материал — результат работы технической команды СВОЙ Тех. Как Project Manager, я прошел с коллегами путь от простых блок-схем до гибридных систем и хочу поделиться реальным опытом ^[1] того, что остается «за кадром» красивых презентаций об искусственном интеллекте ^[2].

Рутина, которая строит фундамент

Сначала берут скрипты и раскладывают их в понятную логику ^[3]: блок-схемы, интенты и их вероятности. Потом долго донастраивают — смотрят отчёты, правят ответы, снова проверяют. Это довольно рутинный этап, но без него никуда. Дальше начинают добавлять реальные компоненты: маршрутизацию звонков, интеграции через API, аналитику. Система постепенно перестаёт быть просто набором фраз и начинает работать с реальными данными. И только после этого появляется LLM. Сначала на ограниченных сценариях, потом шире. И вот в этот момент разговор действительно становится более живым. Но важно другое: это происходит не вместо архитектуры, а потому что архитектура уже есть.

Почему мы не отказываемся от сценариев

Почему сценарные боты до сих пор живы? Потому что в реальных задачах важна не только «красивая речь». Важно, чтобы система вела себя предсказуемо, чтобы её можно было проверить и заранее понять, что она скажет в каждой ситуации. В финтехе это особенно чувствуется.

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

Когда сценарии начинают «трещать по швам»

Но у этого подхода есть предел. Со временем вариантов фраз становится слишком много, исключения растут быстрее, чем команда успевает их описывать, и сценарии начинают разваливаться. При этом бизнесу уже нужен не формальный ответ, а нормальный разговор: проверить платёж, объяснить статус, провести клиента по нескольким шагам и не потерять контекст. Именно здесь и появляется потребность ^[4] в LLM. 

Важно не перепутать её роль. Модель — не источник фактов и не «мозг системы». Её задача — понимать речь, удерживать контекст, принимать решения и формулировать ответ. Факты при этом должны приходить из систем — через API и сервисы. Когда это разделение соблюдается, всё работает предсказуемо. Когда нет — система начинает звучать уверенно, но ошибаться. С этого места обычно и начинается архитектура.

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

Риски «быстрого» внедрения

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

Есть и ещё один момент, про который часто вспоминают слишком поздно — персональные данные. Закон требует чётко понимать, какие данные обрабатываются и зачем, не собирать лишнее и следить за их актуальностью.

В поисках баланса

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

Чек-лист для команды: как не перепутать демо с рабочей системой

• Сначала рисуйте маршруты, а уже потом спорьте о моделях.

• Разделяйте факты и формулировки: факты должны приходить из внутренних систем, а LLM должна только объяснять и собирать ответ.

• Стройте knowledge management как процесс с владельцами, версиями и метриками, а не как папку из PDF.

• Юридические аспекты и правила перевода на человека — это не приложение к ТЗ, а обязательная часть проработки решения.

• Оценивайте не абстрактное «качество модели», а долю реально завершённых сценариев, точность фактов и качество handoff.

• Инфраструктуру выбирайте не по моде, а по тому, где лучше соблюдаются требования к данным, SLA.

• Советуйтесь со специалистами по информационной безопасности, чтобы реализация проекта не несла дополнительных или скрытых рисков.

Вывод

В итоге переход к LLM — это не история про «было просто, стало умно». Это скорее про усложнение системы. Появляется ещё один слой, который хорошо работает с языком: понимает, что говорит человек, понимает, что говорит человек, и корректно формулирует ответ.

Но всё остальное никуда не исчезает. Маршруты, данные, правила и ответственность по-прежнему остаются на уровне архитектуры. И если их не продумать, одна только модель ситуацию не спасёт.