В финтехе почти никогда не происходит по красивому сценарию, который обычно рисуют в презентациях: подключили LLM — и внезапно получили умного, почти «человеческого» голосового агента. Эта картинка слишком удобная, чтобы быть правдой. В реальности всё развивается намного медленнее и, если честно, местами довольно приземлённо.
Есть популярный миф. Мол, сначала бот живёт на жёстких сценариях. Потом к нему подключают LLM — и он сам превращается в почти живого собеседника. Звучит красиво. В реальности так не работает. Если посмотреть на реальные проекты в финтехе, всё происходит гораздо проще и… скучнее.
Этот материал — результат работы технической команды СВОЙ Тех. Как Project Manager, я прошел с коллегами путь от простых блок-схем до гибридных систем и хочу поделиться реальным опытом того, что остается «за кадром» красивых презентаций об искусственном интеллекте.
Рутина, которая строит фундамент
Сначала берут скрипты и раскладывают их в понятную логику: блок-схемы, интенты и их вероятности. Потом долго донастраивают — смотрят отчёты, правят ответы, снова проверяют. Это довольно рутинный этап, но без него никуда. Дальше начинают добавлять реальные компоненты: маршрутизацию звонков, интеграции через API, аналитику. Система постепенно перестаёт быть просто набором фраз и начинает работать с реальными данными. И только после этого появляется LLM. Сначала на ограниченных сценариях, потом шире. И вот в этот момент разговор действительно становится более живым. Но важно другое: это происходит не вместо архитектуры, а потому что архитектура уже есть.
Почему мы не отказываемся от сценариев
Почему сценарные боты до сих пор живы? Потому что в реальных задачах важна не только «красивая речь». Важно, чтобы система вела себя предсказуемо, чтобы её можно было проверить и заранее понять, что она скажет в каждой ситуации. В финтехе это особенно чувствуется.
Например, в задачах взыскания закон прямо задаёт правила: нужно сообщать, что это автоматизированный агент, нельзя звонить когда угодно, и всегда должна быть возможность переключиться на человека. Плюс требования по ИИ:клиент должен иметь возможность отказаться от взаимодействия с ним, результат можно пересмотреть, а качество — контролировать. В такой среде сценарный бот — это не пережиток прошлого, а способ держать всё под контролем.
Когда сценарии начинают «трещать по швам»
Но у этого подхода есть предел. Со временем вариантов фраз становится слишком много, исключения растут быстрее, чем команда успевает их описывать, и сценарии начинают разваливаться. При этом бизнесу уже нужен не формальный ответ, а нормальный разговор: проверить платёж, объяснить статус, провести клиента по нескольким шагам и не потерять контекст. Именно здесь и появляется потребность в LLM.
Важно не перепутать её роль. Модель — не источник фактов и не «мозг системы». Её задача — понимать речь, удерживать контекст, принимать решения и формулировать ответ. Факты при этом должны приходить из систем — через API и сервисы. Когда это разделение соблюдается, всё работает предсказуемо. Когда нет — система начинает звучать уверенно, но ошибаться. С этого места обычно и начинается архитектура.
Она выглядит не как замена одного блока другим, а как постепенное наращивание слоёв. Ниже — удобная схема такого перехода уже упрощённом виде, которую мы использовали для синхронизации работы команды.
Этап | Что появляется | Что остается жестким |
Сценарный этап | Скрипты, интенты, ключевые слова, ручная донастройка, запись диктора | Формулировки, переходы, проверка результата |
Интеграционный этап | Маршрутизация звонков (routing), API, аналитика | Маршруты звонков, разершённые действия, статусы |
Гибридный этап | База знаний, оркестрация запросов, более гибкое принятие решений, синтез речи с подстановкой переменных (ФИО, суммы) | Источник фактов, контроль ответа, передача на оператора (handoff) |
Этап с использованием LLM | естественная речь, понимание намерения, длинный контекст, вариативность, уникальность фраз, работа без предзаписи | Юридические ограничения, ограничения контекста, наблюдаемость |
Риски «быстрого» внедрения
Поэтому подключать LLM напрямую к телефонии или CRM — плохая идея. На демо это выглядит эффектно: ответы звучат живее, голос приятнее, диалог кажется более естественным. Но в реальной системе этого недостаточно. Если между моделью и источниками данных нет нормальной архитектуры — маршрутизации, API, слоя знаний и ограничений — получается не умный агент, а очень убедительный, но ненадёжный интерфейс. Он звучит уверенно, но может ошибаться, и в регулируемой среде это уже риск, а не просто недочёт.
Есть и ещё один момент, про который часто вспоминают слишком поздно — персональные данные. Закон требует чётко понимать, какие данные обрабатываются и зачем, не собирать лишнее и следить за их актуальностью.
В поисках баланса
При этом сам переход к LLM действительно даёт ценность. Разговор становится более естественным, команда меньше тратит времени на поддержку сценариев, а бот лучше справляется с нестандартными ситуациями. Но это работает только тогда, когда модель отвечает за формулировку ответа, а не за факты и не за правила взаимодействия. Когда это разделение соблюдается, система остаётся управляемой и при этом становится заметно удобнее для пользователя.
Чек-лист для команды: как не перепутать демо с рабочей системой
Сначала рисуйте маршруты, а уже потом спорьте о моделях.
Разделяйте факты и формулировки: факты должны приходить из внутренних систем, а LLM должна только объяснять и собирать ответ.
Стройте knowledge management как процесс с владельцами, версиями и метриками, а не как папку из PDF.
Юридические аспекты и правила перевода на человека — это не приложение к ТЗ, а обязательная часть проработки решения.
Оценивайте не абстрактное «качество модели», а долю реально завершённых сценариев, точность фактов и качество handoff.
Инфраструктуру выбирайте не по моде, а по тому, где лучше соблюдаются требования к данным, SLA.
Советуйтесь со специалистами по информационной безопасности, чтобы реализация проекта не несла дополнительных или скрытых рисков.
Вывод
В итоге переход к LLM — это не история про «было просто, стало умно». Это скорее про усложнение системы. Появляется ещё один слой, который хорошо работает с языком: понимает, что говорит человек, понимает, что говорит человек, и корректно формулирует ответ.
Но всё остальное никуда не исчезает. Маршруты, данные, правила и ответственность по-прежнему остаются на уровне архитектуры. И если их не продумать, одна только модель ситуацию не спасёт.