Команда разработала ИИ-агента поддержки клиентов для SaaS‑продукта с примерно 4 млн активных пользователей в месяц. Чтобы сократить расходы на логический вывод, внедрили уровень маршрутизации: небольшая модель‑классификатор помечала входящие запросы как «простые» или «сложные» и перенаправляла их на соответствующую модель — дешёвую или более дорогую (capable).
Простые запросы (поиск учётной записи, вопросы о статусе выставления счетов, сброс пароля и т. д.) шли на дешёвую модель, которая стоила примерно четверть стоимости одного токена за модель capable. Сложные запросы (споры о возврате средств, устранение неполадок в интеграции и др.) обрабатывала модель capable. В течение репрезентативной недели производственного трафика распределение было примерно 65 % простых и 35 % сложных запросов.
За восемь недель команда завершила сборку системы, внедрила её постепенно (начиная с 5 % трафика и доведя до 100 % за шесть недель). К концу восьмой недели ежемесячные затраты на логические выводы снизились примерно до 40 % от предыдущего уровня. Финансовый директор выразил благодарность команде. Однако через три месяца стало заметно снижение удовлетворённости клиентов и рост оттока. Экономия в 100 тыс. долларов в месяц обернулась расходами на удержание клиентов и поддержку в размере 400–500 тыс. долларов в месяц.
Проблема заключалась в том, что существующая архитектура измерений не позволяла увидеть разрыв в качестве на разных уровнях маршрутизации. Например, классификатор не мог надёжно отделить «простой центр» запросов от «длинного хвоста» сложных и неоднозначных запросов. Запрос «откуда взялись мои деньги» мог быть как простым поиском по учётной записи, так и началом расследования мошенничества — дешёвая модель давала поверхностный ответ, который не соответствовал реальному намерению клиента.
После аудита двух других команд (в SaaS‑сегменте и в сфере финансовых технологий) выяснилось, что подобная схема встречается повсеместно: экономия средств очевидна, а потеря качества становится заметной лишь спустя несколько месяцев. Для своевременного выявления проблем предлагается изменить архитектуру измерений: разделять сигналы качества по уровням маршрутизации, дополнительно отбирать запросы из «длинного хвоста» для анализа, отслеживать изменение достоверности маршрутизации.
В качестве альтернативы предложен каскадный подход: каждый запрос сначала обрабатывается дешёвой моделью, которая выдаёт ответ с оценкой достоверности. Если уверенность модели в ответе высока, ответ сразу отправляется пользователю; если ниже порогового значения — запрос передаётся в надёжную модель. Такой подход позволяет снизить риск ошибок в сложных случаях и лучше контролировать качество обслуживания клиентов.
Подписаться в Макс
