Большие языковые модели (LLM) уже массово выходят в промышленную эксплуатацию, но рост автономности ИИ-систем идет заметно медленнее, чем разговоры о нем. По данным исследования «Инфосистемы Джет» и Smart Ranking, LLM используют или пилотируют 86% крупных российских компаний, тогда как полностью автономные ИИ-агенты работают в промышленной эксплуатации только у 8%. Олег Скуратович, технический проектный менеджер в СВОЙ Тех (ИТ-кластер финтех-группы СВОЙ), рассказал, почему после первых успешных сценариев дальнейшая автоматизация усложняется, где на самом деле рождаются ошибки, которые выглядят как ошибка LLM, и почему участие человека все чаще становится частью архитектуры, а не ее ограничением.
Первые сценарии дают основную часть эффекта
По словам эксперта, команда анализировала данные примерно за год промышленной эксплуатации. Такой период сглаживает сезонность и разовые всплески нагрузки. Выяснилось, что основной поток обращений закрывают всего несколько типовых сценариев. Около 72% обращений пришлось на шесть частых причин обращения, среди которых статус платежа и заявки, подтверждение операции, назначение времени связи, навигация по процессу и перевод на специалиста. После их автоматизации нагрузка на первую линию снизилась примерно на 24%, а среднее время ожидания сократилось почти на треть.
Дальше эффект начал заметно падать. Первые 20-30% автоматизированных сценариев дали больше 70% всей итоговой экономии операционного времени. «Мы зафиксировали для себя простую вещь. Каждый следующий сценарий нужно оценивать не по тому, можно ли его технически автоматизировать, а по тому, какой дополнительный эффект для бизнеса он реально даст». Так объясняет свой подход Олег Скуратович.
LLM – только один слой системы
Ошибка, которую эксперт называет самой частой на старте проектов, — это уверенность, что LLM способна заменить архитектуру целиком. По его наблюдениям, зрелая система в финтехе — это не «модель плюс телефония», а набор слоев, где каждый отвечает за свою часть риска. Систему формируют распознавание речи, определение намерения, маршрутизация запроса (routing), обращение к внутренним системам за фактами через API (программный интерфейс для обмена данными между системами), база знаний, комплаенс-ограничения и голосовой слой. И только поверх всего этого работает LLM, которая формулирует ответ, но не выдумывает факты.
«Если подключить LLM напрямую к телефонии или CRM, на демонстрации это выглядит эффектно. Ответы звучат живо, диалог кажется естественным. Но без маршрутизации, доступа к данным и ограничений получается не умный агент, а убедительный, но ненадежный интерфейс. В регулируемой среде это уже риск, а не просто недочет». Так поясняет Олег Скуратович.
По его словам, любая команда на этом пути сталкивается с тремя развилками, которые лучше обсудить до пилота, а не после. Сколько проверок и обращений к данным допустимо ради точности ответа в обмен на скорость. Насколько жестко задавать маршруты диалога в обмен на естественность речи. И сколько можно сэкономить на логировании и обновлении базы знаний, не потеряв управляемость системы.
Automation rate не показывает реальный эффект
Отдельная проблема – это метрика automation rate, доля обращений, обработанных без участия сотрудника. Она не всегда отражает реальную экономию. Бот может провести диалог самостоятельно, но не решить вопрос клиента, и тот обратится повторно. Формально сценарий будет «автоматизирован», хотя нагрузка на сотрудников не снизится. Поэтому команда стала считать сценарий закрытым только тогда, когда клиент получил нужный результат и после этого сотрудник ему не потребовался. Отдельно отслеживали незавершенные диалоги, повторные обращения и жалобы.
Похожий сдвиг фокуса заметен и на банковском рынке в целом. По данным Frank RG и BSS, доля максимальных оценок роботам выросла до 75%, но клиенты по-прежнему отмечают недостаточное понимание запросов и нехватку гибкости в диалоге. То есть высокая доля автоматизации сама по себе не гарантирует довольного клиента.
Ошибка может возникнуть до ответа модели
Пожалуй, самый неожиданный вывод команды касается природы ошибок. Детальный разбор логов показал, что почти 43% зафиксированных сбоев концентрировались в одной точке перехода сценария. При этом сама LLM в этих диалогах могла правильно понимать запрос. Проблема возникала раньше. Система направляла модель отвечать там, где сначала требовалось получить факт из внутренней системы или передать разговор сотруднику.
«Внешне это выглядит как ошибка модели. Внутри почти всегда оказывается другое. Не тот маршрут, пустой ответ от API, устаревшая база знаний или передача сотруднику без контекста. Замена LLM в такой ситуации может улучшить формулировку, но не устранит причину сбоя», – рассказывает Олег.
После анализа проблемную точку в сценарии разделили на три ветки. Система может ответить самостоятельно, сначала получить факт или сразу передать обращение сотруднику.
Handoff становится частью архитектуры
Часть сценариев в компании сознательно не стали автоматизировать полностью. Это спорные и нестандартные ситуации, жалобы, юридически чувствительные обращения, случаи с несколькими трактовками и высокой ценой ошибки. Отдельная категория риска — это качество данных. Если внутренние системы возвращают неполную или противоречивую информацию, LLM не должна додумывать ответ за них.
«Если система не может однозначно определить ситуацию или получить достоверные данные, правильным решением будет раньше подключить сотрудника. Мы перестали считать handoff, то есть передачу диалога от бота сотруднику, неудачей ИИ-сервиса. Это одна из штатных веток архитектуры». Так говорит Олег Скуратович.
При этом сотрудник должен получать вместе с обращением уже собранный контекст, а не начинать разбор заново.
Такой подход соответствует и рекомендациям Банка России, который советует финансовым организациям обеспечивать возможность перехода от ИИ к сотруднику. Более 80% организаций, постоянно использующих ИИ, уже следуют этой рекомендации.
Иногда меньше автоматизации дает лучший результат
На одном из этапов проекта команда изменила логику части сложных сценариев и стала раньше подключать сотрудников. Формальный уровень автоматизации немного снизился. Зато повторных обращений стало примерно на 14% меньше, а жалоб почти на 20% меньше.
«Цель ИИ-сервиса не в том, чтобы максимально долго обходиться без человека, а в том, чтобы правильно завершать обращения и снимать реальную нагрузку с сотрудников». Так резюмирует Олег Скуратович, технический проектный менеджер в СВОЙ Тех.
По его мнению, при запуске и развитии ИИ-сервиса важно проверять не столько саму модель, сколько систему вокруг нее. Откуда LLM получает факты, что происходит при пустом или противоречивом ответе от внутренних систем, где проходит граница обязательного перехода на человека и какие метрики показывают не среднюю температуру по больнице, а точку реального сбоя. Чем шире становится автоматизация, тем меньше ее результат зависит от возможностей одной только модели. И тем больше — от архитектуры, качества данных и способности системы вовремя понять, когда задачу стоит решать не самостоятельно.