В прошлом материале мы подробно разобрали кейс внедрения ИИ-ассистента. Сегодня пойдем глубже и препарируем саму архитектуру системы, которая позволяет боту оставаться полезным и безопасным в жестких рамках финтеха.
Гибридная архитектура голосового бота в финтехе — это не «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.
Компонент | За что отвечает | Что ломается, если компонент слабый | На что смотреть в эксплуатации |
ASR | Превращает речь в текст | Бот неверно понимает запрос уже на входе | Ошибки распознавания, устойчивость к шуму, время до первого понятного текста |
NLU | Определяет намерение и базовый контекст | Система плохо маршрутизирует простые сценарии | Точность intent’ов (намерения пользователя), доля нераспознанных запросов |
Routing | Решает, кто и как ведёт диалог дальше | Петли, потерянные клиенты, нарушения правил контакта | Доля корректных маршрутов, качество handoff (передача диалога оператору), ошибки по времени и частоте контактов |
API / tools | Достаёт факты и запускает действия | Красивые, но ложные ответы | Успешность вызовов, latency (задержка ответов), качество возврата ошибок |
Knowledge | Даёт нормативные и продуктовые знания | Общие, пустые или устаревшие ответы | Актуальность контента, полнота, качество retrieval |
Compliance | Ограничивает рамки общения и риски | Нарушения раскрытия, ПД, некорректные ответы | Наличие opening (стартовая фраза), логов, правил эскалации, контролей качества |
Voice layer | Делает разговор естественным | Бот звучит как автоинформатор и сыпется на перебиваниях | Interruption handling (обработка перебиваний), паузы, время до начала полезного ответа |
LLM orchestration | Собирает контекст, формулирует ответ, вызывает разрешённые инструменты | Модель либо говорит слишком свободно, либо бесполезно формально | Точность по сценариям, доля честных отказов, стабильность при длинном контексте |
От 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) против операционной зрелости. Сокращение расходов на логирование, оценку качества, обновление базы знаний и мониторинг напрямую снижает управляемость и стабильность системы.
Но именно эти вещи потом и определяют, превращается пилот в продукт или нет. Это уже не цитата из закона, а прямой практический вывод из исходного кейса, требований к данным и исследований по голосовым системам.
Вредные советы
На этом фоне довольно легко перечислить анти-паттерны.
подключить LLM напрямую к телефонии и ждать магии.
считать CRM и API необязательными, потому что «модель и так всё объяснит».
прикрутить к боту папку с PDF и назвать это knowledge management.
вынести комплаенс в промпт.
измерять успех только качеством распознавания речи и не смотреть на корректность фактов, handoff и complaint-sensitive точки. Все эти ошибки выглядят по-разному, но корень у них один: моделью пытаются заменить архитектуру.
Вывод. Гибридная архитектура в финтехе хороша не потому, что сочетает много модных терминов, а потому, что каждому слою возвращает его нормальную ответственность. ASR должен слышать, routing — направлять, API — давать факты, knowledge — поддерживать актуальность, compliance — держать рамку, а LLM — говорить по-человечески. Когда роли разделены, система становится не только умнее, но и взрослее.
