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

Гибридная архитектура голосового бота в финтехе — это не «NLU + LLM», а набор слоёв, где каждый отвечает за свою часть риска и пользы: ASR (Automatic Speech Recognition – автоматическое распознавание речи), NLU, routing, API, knowledge, compliance, voice и LLM-оркестрация. В такой системе самое слабое звено почти всегда важнее самой сильной модели. Если knowledge устарела, API не даёт факты, а routing не умеет передавать на человека, никакая LLM не спасёт.  

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

Что находится вокруг LLM в реальной архитектуре

Таблица ниже — сжатое сравнение ключевых компонентов такой архитектуры. Это не «единственно верный стандарт», а практическое обобщение исходного кейса, рекомендаций по управлению данными, принципов открытых API и исследовательских работ про retrieval (поиск/извлечение информации), tool use и voice systems. 

От routing до оркестрации

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

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

Третий слой — knowledge. И вот здесь команды часто допускают самую дорогую ошибку: считают, что база знаний — это просто «папка документов, прикреплённая к боту». Нет. Knowledge management — это система, которая включает: владельцев знаний, управление версиями, метаданные, процессы обновления, критерии качества и метрики результата. Рекомендации по управлению данными на финансовом рынке прямо говорят о жизненном цикле данных, необходимости документирования, обеспечении качества, безопасности и доверия к данным. Исследования показывают ту же мысль, но более технически: если система плохо ищет нужную информацию и хранит её неструктурированно, даже сильная модель не сможет стабильно давать точные и проверяемые ответы.

Четвёртый слой — compliance. Здесь особенно опасно путать «хороший промпт» с настоящим управлением риском. Промпт может попросить модель быть вежливой. Но он не заменяет прозрачность, не гарантирует право клиента отказаться от ИИ-взаимодействия, не обеспечивает пересмотр решений, не подменяет требования к информационной безопасности и не создаёт сам собой политику управления рисками. Этический кодекс регулятора по ИИ на финансовом рынке прямо перечисляет эти принципы: человекоцентричность, прозрачность, безопасность, проверку качества, мониторинг, конфиденциальность, непрерывность деятельности и ответственное управление рисками. 

Пятый слой — voice. И тут у бизнеса часто случается подмена ожиданий. Когда люди говорят: «Хотим, чтобы бот разговаривал естественно», они почти никогда не имеют в виду только тембр голоса. Обычно речь о другом: чтобы бот не ждал театральной паузы, не срывал реплику клиента, переживал перебивания, не говорил как диктор автоответчика. Современные исследования full-duplex dialogue systems (системы диалога, которые умеют говорить и слушать одновременно, как люди в живом разговоре) это хорошо показывают: естественность завязана на то, как система справляется с перебиваниями, короткими сигналами внимания (типа: «угу», «да», «понял», «секунду»), задержками, сменой очереди реплик и эмоциальный тон общения. Более того, опубликованные бенчмарки показывают, что даже продвинутые системы всё ещё заметно сыпятся при частых перебиваниях и шуме. То есть «сделать красивый TTS» — это ещё далеко не значит «сделать живой разговор». 

Шестой слой — собственно оркестрация LLM. Мне здесь нравится очень приземлённая формулировка: модель в зрелой системе — не мозг всей платформы, а слой смысловой сборки. Она получает допустимый контекст, вызывает разрешённые инструменты, обращается к знаниям, формулирует ответ понятным языком, проходит через фильтры и, если надо, без истерики отдаёт разговор человеку. Такая роль действительно ближе всего к тому, что показывают и практики работы с внешними данными, и исследования про tool use. Модель сильна тогда, когда у неё есть описанные инструменты, понятные границы и измеримое качество.

Трудные решения на пути к продакшену 

Отсюда вытекают три практических компромисса (trade-off), которые лучше обсудить заранее, а не после пилота.

• задержка ответа (latency) против точности. Чем больше проверок, поиска по базе знаний (retrieval) и обращений к внешним системам, тем выше задержка, но тем ниже вероятность выдать уверенно неверный ответ.

• управляемость против разговорной свободы. Чем жёстче заданы правила и маршруты диалога, тем безопаснее система, но тем менее естественно она звучит.

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

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

Вредные советы

На этом фоне довольно легко перечислить анти-паттерны. 

1. подключить LLM напрямую к телефонии и ждать магии. 

2. считать CRM и API необязательными, потому что «модель и так всё объяснит».

3. прикрутить к боту папку с PDF и назвать это knowledge management.

4. вынести комплаенс в промпт. 

5. измерять успех только качеством распознавания речи и не смотреть на корректность фактов, handoff и complaint-sensitive точки. Все эти ошибки выглядят по-разному, но корень у них один: моделью пытаются заменить архитектуру.  

Вывод. Гибридная архитектура в финтехе хороша не потому, что сочетает много модных терминов, а потому, что каждому слою возвращает его нормальную ответственность. ASR должен слышать, routing — направлять, API — давать факты, knowledge — поддерживать актуальность, compliance — держать рамку, а LLM — говорить по-человечески. Когда роли разделены, система становится не только умнее, но и взрослее.