ИИ, который слышит клиента: как Cloud.ru перестроил техподдержку и сделал её проактивной

Алена Дробышевская
Директор блока клиентского успеха
Cloud.ru
1. Алена, какие альтернативные подходы к организации технической поддержки рассматривались до внедрения AI-решений, и почему был выбран именно этот путь?
Алена Дробышевская: При проектировании ИИ-ассистента Copilot для инженеров техподдержки мы не начинали с выбора конкретных технологий или моделей. Мы опирались на практический опыт автоматизации поддержки в разных отраслях, который из раза в раз подтверждал: универсальных решений не существует. Архитектура должна выстраиваться вокруг специфики бизнеса, а не наоборот.
Первым этапом стал анализ десятков тысяч обращений клиентов. Мы хотели понять, какие механики сработают в нашей предметной области, а какие — нет.
Классический подход к автоматизации строится вокруг сценариев и классификации интентов: система определяет намерение пользователя и запускает заранее подготовленный маршрут. Это эффективно в сервисах с ограниченным набором типовых вопросов. Но мы поддерживаем сразу несколько независимых облачных платформ. Вопросы клиентов часто похожи, но требуют разных решений в зависимости от продукта, архитектуры или конфигурации инфраструктуры. Один и тот же запрос может относиться к Kubernetes, виртуальным машинам, сети, AI-сервисам или объектному хранилищу.
Дополнительная сложность — объем знаний. Наша база включает более 25 тысяч технических статей по 200+ облачным сервисам. Заранее описать все варианты вопросов и решений в виде сценариев невозможно: их количество исчислялось бы десятками тысяч, а поддержка превратилась бы в отдельный громоздкий проект.
Поэтому классическая схема «интент → сценарий» у нас не работает. Даже определив тему обращения, модель должна найти актуальную информацию в нескольких источниках, сопоставить данные, учесть контекст и только потом предложить решение.
Мы отказались от идеи «запрограммировать все ответы». Вместо этого мы научили систему действовать как опытный инженер: понять вопрос, определить недостающие знания, обратиться к источникам, проанализировать материалы и сформировать рекомендацию.
2. Как устроен и работает сервис?
Алена Дробышевская: Архитектура проекта объединяет RAG и агентные механизмы. ИИ последовательно анализирует обращение, обращается к базам знаний, сравнивает данные и предлагает решение с учетом ситуации клиента.
Мы не противопоставляем генеративный ИИ классическим методам, а используем гибридный подход:
- Классические модели и сценарии применяются там, где задача хорошо формализована (обработка спама, простая маршрутизация, чёткие регламенты). Они быстрее и дешевле.
- Агентная система подключается там, где требуется глубокое понимание технического контекста, анализ нескольких источников и вариативность решений.
Такая комбинация технологий — наиболее зрелый подход к автоматизации сложной B2B-поддержки. Мы подбираем инструмент под конкретную задачу, за счет чего повысили качество поддержки, ускорили обработку и сохранили высокий уровень клиентского опыта.
3. Как робот понимает, кто ему пишет — суровый программист или вежливый директор? Заявлено, что система сама подстраивает стиль под каждого клиента. Как это реализовано технически?
Алена Дробышевская: Система не пытается угадать должность собеседника. Она анализирует историю коммуникации с клиентом и формирует его языковой портрет.
За это отвечает набор специализированных ИИ-агентов:
● один определяет манеру общения;
● второй — предпочитаемый объем и структуру ответа;
● третий оценивает уровень владения предметной областью;
● отдельные агенты анализируют эмоциональную составляющую и форматирование.
На выходе получается набор рекомендаций по ведению диалога. Отдельный агент объединяет их в стратегию взаимодействия — небольшой промпт, который автоматически передается ИИ-агентам и Copilot инженера.
Для одного собеседника ответ будет лаконичным и сугубо техническим, для другого — подробным, с пояснением причин и следующих шагов.
4. Планирует ли компания масштабировать систему динамического Tone of Voice на другие языки?
Алена Дробышевская: Решая задачу мультиязычности, мы в первую очередь научились переводить с одного профессионального языка на другой: DevOps-инженер, архитектор и руководитель бизнеса часто смотрят на одну и ту же проблему по-разному.
Архитектура сервиса практически не зависит от конкретного языка. Языковой портрет строится на универсальных характеристиках: краткость или подробность, глубина погружения в детали, уровень формальности.
При масштабировании переписывать систему не требуется — современные LLM изначально мультиязычны. Наша задача — адаптировать промпты, проверить качество на реальных диалогах и учесть культурные особенности деловой коммуникации. Мы масштабируем правила общения, а не саму технологию.
5. Какие метрики используются для оценки качества работы ИИ-ассистента в долгосрочной перспективе?
Алена Дробышевская: Главная метрика для нас — NPS и обратная связь от клиентов. Также мы отслеживаем CSAT в разных точках взаимодействия.
Помимо клиентских метрик, мы оцениваем работу самих AI-систем с помощью AutoEval и LLM-as-a-Judge. Они позволяют автоматически проверять качество диалога и агентной логики «под капотом»: выбор инструментов, интерпретацию контекста, оптимальность шагов.
Каждого ИИ-агента мы оцениваем по трем направлениям:
1. Удовлетворенность клиентов;
2. Качество диалога;
3. Качество принятия решений и использования инструментов.
Мы планируем запуск самообучающихся агентов, которые смогут автоматически находить причины своих ошибок и корректировать работу.
Ещё один критически важный блок — качество и полнота базы знаний, документации и инструкций. Мы регулярно измеряем процент покрываемых обращений.
Среди внутренних и бизнес-метрик мы отслеживаем:
● Time-to-Market — скорость внедрения новых ИИ-сервисов и агентов;
● SUS-опросы инженеров — оценка удобства интерфейсов и пользовательского опыта команды;
● Contact Rate — количество обращений в поддержку.
Долгосрочная цель — переход от реактивной поддержки к проактивной: ИИ должен сам обнаруживать потенциальные проблемы и устранять их до того, как клиент откроет тикет.
6. Какую конкретно модель искусственного интеллекта вы применяете и почему?
Алена Дробышевская: У нас нет единой универсальной модели. Архитектура изначально проектировалась так, чтобы быстро тестировать и подбирать модели под конкретные сценарии.
В качестве платформы инференса используется собственная разработка — Cloud.ru Evolution AI Factory. Она позволяет подключать новые LLM, проводить A/B-тестирование и заменять модели без изменения бизнес-логики. Раз в три месяца мы проводим сравнительные испытания актуальных LLM на наших доменных задачах.
Перед запуском сервиса мы оцениваем несколько моделей по качеству, скорости и стоимости инференса. Так же через AutoEval и LLM-as-a-Judge
Сейчас в работе используется ансамбль моделей:
● Qwen 3.5 397B — для сложных задач, требующих глубокого анализа и рассуждений;
● Qwen 3.6 35B — для менее ресурсоемких сценариев, где критична скорость;
● GigaChat — для отдельных классов задач.
Наш принцип — выбирать не самую крупную модель, а наиболее подходящую. Это обеспечит баланс качества, стоимости и гибкости.
7. Какие потенциальные риски и ограничения существуют при автоматизации 50% задач отдела поддержки?
Алена Дробышевская: Главный риск — автоматизировать то, что автоматизировать пока не нужно. У нас нет цели заменить инженеров или нарастить процент автоматизации любой ценой. Автоматизировать стоит только те сценарии, где ИИ справляется лучше и быстрее человека.
Прогноз Gartner о том, что к 2029 году агентный ИИ сможет автономно обрабатывать до 80% типовых обращений, для нас скорее ориентир. Жесткого целевого процента не существует: если оптимальный баланс окажется на уровне 60% — значит, так тому и быть. Наш KPI — клиентский опыт, а не автоматизация ради автоматизации.
Ключевые риски внедрения:
- Потеря доверия: если ИИ несколько раз ошибается, клиенты и инженеры перестают им пользоваться.
- Внедрение ради тренда: автоматизация без четкого ответа на вопрос «станет ли клиенту лучше?»
8. Какие решения против этих рисков вы используете?
Алена Дробышевская: Большинство защитных механизмов у нас уже работают:
1. Человек в контуре (Human-in-the-loop): любой новый агент сначала работает в режиме Copilot (ассистент инженера) и проходит валидацию, прежде чем получить автономию;
2. Многоуровневая оценка качества: автоматическая проверка логики агентов и диалогов с помощью AutoEval и LLM-as-a-Judge;
3. Непрерывное обучение: каждый неудачный кейс разбирается. По его итогам корректируются промпты, агентная логика или статьи в базе знаний;
4. Ограничение ответственности: ИИ не принимает самостоятельных решений в критических сценариях, влияющих на безопасность, доступность сервисов или сохранность данных. В таких задачах ИИ лишь готовит аналитику и рекомендации для инженера.
Модульная архитектура платформы позволяет оперативно менять модели и логику агентов без переработки всей системы.
9. Как происходит обучение новых сотрудников работе с AI-инструментом и сколько времени требуется для достижения оптимальной эффективности?
Алена Дробышевская:
В Cloud.ru создан отдельный проект по ИИ-евангелизму. Он направлен не просто на изучение кнопок в интерфейсе, а на формирование инженерной культуры использования ИИ в ежедневной работе.
10. Какие критерии используются для определения, когда обращение должно быть передано от AI-агента к живому инженеру?
Алена Дробышевская: Передача обращения строится на анализе контекста. Перед обработкой агенты собирают историю взаимодействия, определяют тематику и выявляют интент запроса. После этого оркестратор решает, кто эффективнее справится с задачей — ИИ или инженерная команда.
В облачной инфраструктуре за разные компоненты отвечают разные подразделения: первая–третья линии, сетевые инженеры, специалисты дата-центров, продуктовые команды, пресейл. Главная сложность — интеллектуальная маршрутизация: быстро направить тикет профильному специалисту.
Передача обращения инженеру — это не сбой ИИ, а выбор наиболее оптимального пути решения конкретной проблемы.
11. Какие механизмы предусмотрены для предотвращения ошибок в работе ИИ-системы?
Алена Дробышевская:
Безошибочного ИИ не существует. Наша задача — минимизировать вероятность ошибок и их последствия. Главный инструмент здесь — непрерывная обратная связь. Мы разбираем каждую ошибку (причина в модели, промпте, логике или документации) и вносим правки. Для нас ИИ — постоянно развивающаяся инженерная система.
12. Что вы вынесли или наметили для себя на будущее по итогам участия в премии?
Алена Дробышевская:
Самый неожиданный результат — прямо на церемонии вручения мы нашли бэкенд-разработчика в команду. Долго искали специалиста, познакомились на мероприятии, и теперь он работает с нами. Так что участие принесло очень практическую пользу.
13. Что бы вы рекомендовали тем, кто еще ни разу не участвовал в премии CX Awards и сомневается в подаче заявки?
Алена Дробышевская:
Стоит попробовать. Когда ежедневно погружен в рутину, кажется, что ничего особенного не происходит. Участие в премии — отличный повод остановиться, оглянуться назад и оценить пройденный путь.
Кроме того, важен нетворкинг. Профильные мероприятия — это прежде всего люди, и один случайный разговор в кулуарах может дать больше, чем вся официальная программа.