Привет, Хабр!
Меня зовут Наталья Корсакова, я руководитель департамента лингвистической разработки MWS AI (входит в МТС Web Services и разрабатывает ИИ-продукты и решения как для экосистемы МТС, так и для рынка). На последнем Conversations AI в Питере на пару с Еленой Деликановой (это наш тимлид разработчиков-лингвистов) мы рассказали, как прикручивали LLM к чат-ботам МТС. Так мы надеялись улучшить лояльность клиентов (абонентов МТС), ускорить разработку и упростить поддержку громоздких диалоговых систем. По многочисленным просьбам излага��м наш опыт в тексте.
Спойлер: оказалось, что нельзя просто так взять и заменить тысячи строк кода на промпты. То есть можно, но жизнь разработчикам это не упростит, а в некоторых случаях даже усложнит. Однако работа наша оказалась небесполезной: мы поняли, что нужен баланс между традиционной логикой бота и генеративкой, и пришли к идее гибридной архитектуры. Но обо всем по порядку.
От скриптов к генерации
Боты от MWS AI (в прошлом MTS AI) работают с 2017 года. С ними абоненты МТС общаются в чатах и кол-центрах, — с точки зрения размеров кода и по объемам входящего трафика это одни из крупнейших продуктов на рынке.
Их суммарная аудитория — более 80 миллионов пользователей, в пиковые дни они обрабатывают до 500 тысяч обращений в сутки.
К 2023 году возможности классических скриптов во многом были исчерпаны: мы автоматизировали почти все типовые запросы, рост бизнес-метрик замедлился. Кроме того, кодовая база ботов стала очень громоздкой. Мы активно экспериментировали с ML-моделями, проверяли разные гипотезы, которые, увы, не особо меняли общую картину. Тут-то мы и решили, что надо прикрутить LLM. Генеративные AI-инструменты развиваются семимильными шагами, так что это показалось нам следующим естественным этапом эволюции диалоговых ботов.
Перед запуском пилота мы сформулировали две основные гипотезы:
Улучшение пользовательских метрик (tNPS и Gross)
LLM должна помочь боту давать более точные и «человечные» ответы за счет лучшего понимания естественного языка и контекста. Тогда клиенты будут довольнее, а процент успешно автоматизированных обращений вырастет.
Ускорение разработки и упрощение поддержки
Вместо использования сложного алгоритма в коде на JAICP DSL часть логики можно описывать простыми текстовыми промптами для LLM. То есть основная идея — облегчить жизнь разработчикам, которым не придется тратить сотни часов на сотни строк кода.
Интеграция в сценарии
Эксперимент по внедрению LLM стартовал в конце 2024 года. Пилот длился около двух с половиной месяцев. Для него мы использовали свою собственную большую языковую модель — Cotype.
Мы выбрали несколько разных по сложности сценариев: от очень простого, не требующего никаких внешних интеграций (чтобы оценить работу самой модели), до одного из самых сложных интеграционных (чтобы по максимуму выявить узкие места). Раньше эти сценарии были жестко прописаны в коде: какие методы вызывать, как обрабатывать их ответы, что и как должен говорить бот в зависимости от условий. Тепе��ь же нужно было описать логику сценариев в виде промптов для языковой модели, чтобы она сама формулировала ответы.
При этом мы понимали, что просто перенести имеющуюся логику в промпты — не лучшая идея: это могло бы помочь проверить гипотезу про ускорение разработки, но вряд ли сильно улучшило бы пользовательский опыт. Поэтому параллельно решили провести рефакторинг логики выбранных сценариев. Для этого мы использовали опыт топовых операторов-людей — изучили их актуальные инструкции и проанализировали диалоги с высокими оценками от клиентов.
В пилотной архитектуре LLM стала надстройкой над уже работающим ботом. Наши ассистенты базируются на диалоговой платформе с гибридной системой распознавания интентов: входящие сообщения классифицируются набором правил и ML-моделей, после чего выбирается соответствующий сценарий. Решено было сохранить существующую схему классификации на входе, а языковую модель подключить на следующем этапе — для уточнения запроса пользователя (если это необходимо) и формирования ответа.
Проще говоря, бот по-прежнему распознает намерение пользователя как один из 400 существующих интентов и выбирает сценарий. Но для ряда тематик вместо фиксированных фраз вызывается развернутый в безопасном контуре LLM-сервис с подготовленным промптом, где есть необходимый контекст диалога. Модель генерирует ответ, и он возвращается пользователю. Такой подход позволил ограничить область применения LLM самыми подходящими случаями и не отправлять те запросы, где она заведомо не нужна. К тому же это обеспечивает резервный вариант: если что-то пойдет не так, можно вернуться к прежней логике ответа на уровне платформы.
Звучит гладко, не правда ли? Но на деле мы сразу столкнулись с рядом серьезных проблем.
Первые сложности
Проблема № 1
Мы понимали, что LLM на первых порах будет требовать гораздо больше времени для формирования ответа. Классический бот с жесткими сценариями отвечает на простые вопросы меньше чем за секунду, а с подключением генеративной модели время ответа выросло в несколько раз. Если в текстовых каналах еще можно выделить пару дополнительных секунд «на подумать», то для голосового ассистента такая задержка критична: пользователь на линии слышит долгую тишину и начинает беспокоиться, а то и злиться — лояльность летит вниз.
Мы придумали обходной маневр: чтобы скрыть паузу, мы научили бота сразу же произносить краткую преамбулу типа «Сейчас проверю информацию…» перед выдачей основного ответа. Такая уловка чуть сгладила ощущение зависания. Но понятно, что идеальный голосовой ассистент должен отвечать практически мгновенно, без заметных пауз. Это решение выглядит скорее временной мерой: нужно либо ускорять саму модель, либо придумывать передачу сообщения частями, чем мы и планируем заняться. В рамках короткого пилота внедрить streaming-выдачу мы не успели, поэтому проблема скорости пока осталась узким местом использования LLM в ботах.
Проблема № 2
Известная особенность больших языковых моделей — галлюцинации, когда модель придумывает несуществующие факты или инструкции. В контексте клиентского сервиса это может быть очень неприятно. Бот должен давать достоверные и уместные ответы, а не отсебятину. Однако поначалу LLM иногда все-таки выдавала лишнее, а в некоторых случаях вела себя так, что кто-то мог воспринять ее ответ как пассивную агрессию.
Для сервиса поддержки такой тон и контент, конечно, катастрофа, и это очень плохо влияет на метрики. Так что мы экспериментировали с промптами: добавляли строгие инструкции и ограничения в текст запроса к модели, старались сузить ей пространство для фантазии. Где-то в промптах даже приходилось прибегать к угрозам: обещать модельке наложить на нее штраф в 10 тыс. долларов, а когда она и после этого не слушалась — поднимать штрафы до 100 тыс. баксов. Ну или отдельный жанр угроз для LLM — обещание катастрофы с обязательной благодарностью в конце: «Только не отвечай так, а то нас всех СМОЕТ К ЧЕРТЯМ! Спасибо».
Все это в итоге помогло, но сделало промпты ужасно громоздкими. Они разрастались, включая все новые уточнения и правила. В какой-то момент в команде мы стали называть наши инструкции пятым томом «Войны и мира». Ирония в том, что в итоге огромный многострочный промпт уже мало чем отличался от сложного кода сценария, от которого так хотелось уйти. Его сложно читать и поддерживать: через неделю автор такого промпта сам с трудом вспоминал, как он устроен и что нужно поправить, а некоторые части инструкций могли противоречить друг другу.
Надежда на то, что переход на LLM упростит разработку, таяла, как наши нервные клетки. Снижения сложности и ускорения Time to Market мы, увы, не увидели — напротив, создание и отладка LLM-сценариев занимали больше времени, чем классический скрипт.
Проблема № 3
Еще одно последствие генеративной природы искусственного интеллекта — отсутствие детерминизма. Сценарии на правилах всегда предсказуемы: вводишь строгий запрос — получаешь строгий ответ. С LLM же один и тот же запрос может быть сформулирован разными словами, а небольшое изменение контекста может кардинально изменить выдачу. Это стало особенным вызовом для команды Q&A. Как тестировать сценарий, у которого нет жестко заданного эталонного результата? Раньше тестировщик знал: шаг 1 — сказать фразу X, шаг 2 — получить ответ Y. Сейчас в тест-кейсе приходится писать: «Убедиться, что ответ звучит по смыслу адекватно и не противоречит общей инструкции». Но критерии адекватности субъективны, а главное — каждый прогон диалога может дать разный результат. Появился элемент вероятности там, где раньше была строгая определенность. В итоге на проверку одной ветки диалога стало уходить больше времени, требовались дополнительные прогоны, и это тоже тормозило Time to Market.
Проблема № 4
Кроме того, выяснилось, что есть классы задач, которые очень просто решаются привычным кодом, но вызывают затруднения у языковой модели. Элементарная арифметика, проверки по справочникам, работа с датами — это то, что в классическом сценарии делается одной строчкой кода или условием. А LLM ради этого приходится снабжать особыми инструкциями или писать дополнительный парсер сгенерированного сообщения, иначе модель может споткнуть��я на ровном месте. Подключать генерацию для таких случаев явно избыточно — как забивать гвозди микроскопом.
Первые результаты
Итак, по части ускорения разработки первые итерации нас больше разочаровали. Объем работы не снизился, просто вместо кода надо было писать промпты и отлаживать Cotype вручную. Время вывода изменений в продакшен даже выросло чуть ли не в два раза по сравнению с обычным подходом из-за всех непредвиденных итераций допиливания промптов, поиска баланса между точностью и человечностью и расширенного тестирования. Пришлось признать, что мы были слишком оптимистичны и недооценили ряд подводных камней, рассчитывая быстро заменить правила на нейросеть.
Но на ошибках (и слезах разработчиков) учатся, поэтому мы все-таки считаем пилот успешным: есть и рост метрик, и ценные выводы.
Во-первых, опыт пользователей действительно улучшился. Ответы стали заметно богаче по языку, более человечными. Модель умеет лучше держать контекст диалога, не повторяет односложно заранее заготовленные фразы, а старается понятно объяснить суть. Бот начал проявлять больше эмпатии и дружелюбия.
Во-вторых, целевые метрики показали рост. По итогам пилота зафиксировано повышение удовлетворенности пользователей и доли автоматизированных обращений на 5-10% (в зависимости от сценария и канала). Рекордным этот результат не назовешь, но это устойчивый положительный эффект, на который мы и рассчитывали в рамках пилота. Так подтвердилась первая гипотеза: LLM действительно принесла выгоду для бизнеса, пусть пока и умеренную. А главное, стало понятно, что подход можно масштабировать (после модификаций).
В чем сила, брат? В гибридной архитектуре
Проанализировав итоги пилота, мы пересмотрели подход к роли LLM в архитектуре бота. Главный вывод: нельзя просто взять и выкинуть весь старый код, заменив его магической нейросетью. Нужен баланс между традиционной логикой и генеративкой. Все-таки даже самая умная модель не панацея: ей по-прежнему нужен структурированный каркас сценария и ручное управление на сложных участках.
Команда пришла к идее гибридной архитектуры, где сочетаются сильные стороны обоих подходов. Что это значит на практике? Например, некоторые вещи проще и надежнее оставить в виде кода: многоуровневые проверки условий, о��работку результатов вызова API, сложные расчеты — словом, то, где алгоритмы справляются быстро и без ошибок. Зато формулирование финального ответа пользователю лучше доверить Cotype, потому что у модели несравнимо больше гибкости в языковом выражении и учете контекста.
Более того, родилась идея создать DSL для работы с LLM — специализированный язык описания логики диалога, понятный и человеку, и ИИ. Это мог бы быть набор специальных меток и конструкций, которым модель обучена следовать. Например, вместо длинных разъяснений на естественном языке в промпте можно писать структурированный псевдокод, а LLM уже интерпретировала бы его при генерации ответа. Такой подход позволяет избежать путаницы в работе с генеративной моделью и одновременно облегчает жизнь разработчикам, делая промпты более читаемыми и структурированными.
От «болталки» до агентной экосистемы
Успех пилота (при всех оговорках) вдохновил команду: мозговой штурм родил десятки идей, как еще можно использовать GenAI в рамках клиентского сервиса. Многие из этих гипотез уже в процессе проверки. Вот несколько наиболее интересных направлений.
Свободный диалог и неочевидные запросы
Клиентские боты неизбежно сталкиваются с вопросами, которые выходят за рамки прописанных сценариев и даже профиля деятельности компании. Пользователя может интересовать что угодно — от бытовых советов до вопросов о смысле жизни. Раньше на такие обращения бот либо отвечал вежливой отговоркой, либо переводил на оператора. Но подключение LLM открывает возможность поддержать диалог на отвлеченные темы. ИИ-оператор на базе языковой модели способен ответить на произвольный вопрос пользователя или просто поболтать, если это уместно. Конечно, нужно контролировать качество и тематику этих ответов, но сама возможность сделать бота более разговорчивым — огромный плюс к лояльности клиентов. Поэтому мы подумали, что можно задействовать LLM как мозг для режима «болталки» (в разумных пределах, чтобы не уходить в совсем сторонние темы).
Саммари для операторов
Понятно, что сейчас даже самый умный агент не сможет закрыть 100% клиентских обращений. Всегда будут какие-то нестандартные ситуации, где нужна помощь оператора-человека. При этом самая первая линия поддержки — это все равно бот. И пользователь уже мог успеть раскрыть ему тему обращения и даже какие-то детали. Если придется повторять то же самое для оператора, это повлияет и на лояльность клиента, и на время, которое оператор потратит на обслуживание. Поэтому мы с коллегами из Департамента клиентского сервиса МТС запустили пилот по передаче операторам саммари диалога с ботом. LLM с такой задачей справляется на ура.
Результаты превзошли наши ожидания. Мы рассчитывали сократить среднее время обработки вызова (AHT) на 8 секунд и поднять tNPS на 1%, а получили сокращение AHT на 11 секунд и повышение tNPS на 1,3%. Не менее важны и положительные отзывы от операторов:
Раньше мы читали, как клиенты ругаются на робота, а сейчас сразу вкратце видим причину обращения, так что да, удобно!
Был пример с подробно расписанным предложением, очень помогло быстро понять клиента.
Я теперь меньше пугаюсь: звездочек (мата) нет, оскорблений тоже — только суть проблемы.
Обработка длинных запросов
Еще один кейс, где LLM обещают быть полезными: многословные обращения. Некоторые люди, особенно пожилые, могут описывать свою проблему длинным рассказом на несколько абзацев, упоминая кучу деталей. Обычные алгоритмы классификации начинают тонуть в такой простыне текста — из нее можно извлечь несколько разных ключевых слов, которые укажут на разные намерения, и будет совершенно непонятно, что именно важно. Языковая модель отлично подходит для резюмирования и извлечения сути из пользовательского запроса. Она может прочитать длинное обращение и одним предложением сформулировать, какой вопрос задает человек. Затем этот вывод можно подставить в стандартную классификацию или сразу подобрать нужный сценарий. Таким способом длинные запросы будут правильно маршрутизироваться, вместо того чтобы сразу отправляться к оператору-человеку из-за неопределенности.
Персонализированные рекомендации
Наш бот умеет рекомендовать продукты компании (тарифы, услуги и тому подобное) на основе запросов от пользователя. Сейчас рекомендации строятся по заданным правилам: например, если в разговоре упомянуто A, то нужно предложить услугу B. Но LLM дает рекомендации более интеллектуально и гибко. Она может учитывать контекст диалога, тон пользователя, сочетание упомянутых фактов. На этой основе можно точнее подбирать совет или продукт под потребности человека. В индустрии уже есть успешные примеры использования больших языковых моделей для рекомендаций, и команда планирует испытать такой подход. Например, не просто подобрать тариф по паре параметров, а объяснить преимущества подходящего предложения, сравнить с другими — фактически провести мини-консультацию, как это сделал бы продавец-человек.
Аналитика диалогов
Помимо непосредственного общения с клиентом, искусственный интеллект может помочь программистам и аналитикам в бэк-офисных задачах. Очень интересный кейс — анализ причин, почему пользователи переводятся на оператора-человека. Когда бот не справляется, бывает трудно сразу понять, что пошло не так. Приходится читать логи и вручную классифицировать причины. LLM же можно обучить просматривать диалоги, которые завершились переводом на человека, и вычленять основную причину отказа бота. Например: «непонятный вопрос про техническую проблему» или «клиент недоволен ответом, требует подтверждения от человека». Такие инсайты помогут оперативно улучшать сценарии бота, закрывать пробелы в базе знаний и так далее. Также LLM может ускорить разметку новых данных, генерировать вариативные фразы для новых интентов — иными словами, работать как ассистент самой команды разработки.
AI-агенты и разделение компетенций
Впереди у нас исследование более радикальной концепции — AI-агентов. Речь идет о переходе от одного монолитного бота ко множеству специализированных LLM-агентов, каждый из которых отвечает за определенную тему или функцию. Это очень горячая тема.
Небольшие агентные ИИ-системы, наделенные инструментами (доступом к API, базам данных и тому подобному), могут совместно решать сложные задачи. В контексте клиентск��го сервиса это могло бы выглядеть так: вместо единого цифрового помощника, который знает понемногу обо всем, у компании есть целая экосистема агентов. Например, один агент отвечает только на вопросы по мобильной связи, другой — по финансовым услугам, третий — по технической поддержке. Они могут обмениваться информацией, перенаправлять клиента между собой или подключаться параллельно. Каждый агент при этом обучен глубоко в своей области и умеет пользоваться конкретными инструментами (например, проверять баланс, менять тариф или оформлять заявку на вызов мастера).
Такой подход потенциально упростит каждого отдельного бота (ведь область его знаний ограничена), но потребует надежной оркестрации между агентами. Мы уже начали прорабатывать архитектуру таких систем. Это следующий шаг эволюции: сравнить, что окажется эффективнее и удобнее для пользователей — усовершенствованный классический бот с LLM «на подхвате» или распределенная сеть узких ИИ-экспертов.
