Это бонусный материл в серии о внедрении LLM в клиентские сервисы. Если в прошлых трех статьях я подробно разбирал удачные моменты, архитектуру и правильные шаги, то этот текст решил целиком посвятить разбору наших ошибок и факапов. Сейчас – менее красивая часть и реальный опыт PM: что происходит после демо, когда AI-пилот пытаются превратить в промышленную систему и команда сталкивается со скрытыми техническими проблемами.

На демо всё выглядело почти идеально. Бот отвечал живо, бизнес видел прогресс, команда сравнивала модели и крутила промпты. Потом пришли реальные пользователи, реальные данные и реальные ограничения. И выяснилось неприятное: мы лечили не то.

В какой-то момент команда уже всерьёз обсуждала замену модели. Казалось, что проблема в качестве генерации: ответы были уверенные, но иногда неверные. После разбора логов оказалось, что в части диалогов LLM вообще не должна была отвечать. Routing отправлял пользователя в ветку answer, хотя API возвращал partial, а сценарий должен был уходить в handoff.

Самые дорогие ошибки жили не в LLM. Они жили в routing, API, handoff, базе знаний, метриках и compliance-слое. Модель просто красиво озвучивала проблемы, которые система создала раньше.

Перелом случился, когда мы перестали спрашивать: «Почему LLM ответила неправильно?» – и начали спрашивать иначе: «Почему система вообще поставила модель в ситуацию, где правильного ответа у неё быть не могло?»

Вывод неприятный, но полезный: сильная LLM не компенсирует слабую архитектуру. Если у системы нет нормального routing, владельца knowledge base и понятного handoff, сравнение моделей часто становится дорогим отвлекающим манёвром.

Этот текст завершает первую и вторую части трилогии о внедрении LLM в клиентские сервисы. Если раньше мы обсуждали ИИ-агентов и базовую архитектуру, то третья статья получилась самая «бизнесовая» в цикле.

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

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

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

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

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

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