Как Timeweb Cloud построил AI‑ассистента для техподдержки и превратил его в SaaS‑платформу

Служба поддержки Timeweb Cloud — это не типовой FAQ. Клиенты обращаются с техническими вопросами: диагностика серверов, консультации по бэкапам, настройка DNS. Каждый ответ требует погружения в инфраструктуру клиента, и заготовленные шаблоны не работают.

С ростом бизнеса количество обращений увеличивалось, а найти и обучить технических специалистов поддержки становилось сложнее. К этому добавлялись сезонные пики нагрузок, когда команде физически было непросто справляться с потоком обращений. И отдельный вызов: клиенты ассоциируют ботов с некачественным сервисом — если ответ выглядит как ответ бота, доверие падает.

У Timeweb Cloud уже был опыт внедрения ассистентов в службу поддержки. Первый вариант — базовый сценарный ассистент, который умел отвечать на простые вопросы, но пользовался спросом лишь у 16% клиентов.

После этого попробовали ассистента на базе LLM — он порадовал пользователей более живым общением, однако нагрузку на службу поддержки не снизил: он не был интегрирован с внутренними системами и не умел работать с динамическими данными. Только 64% клиентов были удовлетворены его ответами.

Два захода показали, что нужен усовершенствованный подход. Команде нужен был узкоспециализированный эксперт, а не абстрактный собеседник. Именно это привело к созданию GenAI-ассистента на базе RAG, который способен работать с техническими запросами. Он стал основой для SaaS-платформы.

Команда начала с выбора LLM — на старте перепробовали практически все доступные варианты. Модели оценивали по двум критериям: качество и скорость ответа, а также стоимость. Для адаптации под контекст компании сделали собственный поиск по базе знаний через RAG.

Параллельно выстраивали базу знаний. Выработали шесть принципов, которые влияют на качество ответов.

1. Единый смысл. Например, есть 15 пунктов. Важно, чтобы все они были релевантны одной теме и хранились в едином файле — без дробления на несколько отдельных документов. Одновременно стоит избегать смешивания в одном файле разнородных фрагментов текста, не связанных между собой по смыслу. Это дает точность и полноту ответов модели. Пример: в кейсе с ценообразованием все данные о ценах должны находиться в одном файле. Смешивать их с другой информацией не стоит — модель может подтянуть соседний текст в ответ, и результат окажется нерелевантным.

2. Структурированность. LLM хорошо воспринимают четкую организацию текста — например, списки.

3. Лаконичность. Емкий текст без воды. Избыточные детали в базе = шум в ответе.

4. Чистота формата. Все данные конвертируются в Markdown — это помогает избежать проблем с лишними символами в ответах модели.

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

6. Знать ограничения. Опыт показал, что RAG плохо работает с цифрами. Команда планирует решать это через MCP.

На этом же этапе команда выделила 5 тематик, в которых клиенты задают вопросы чаще всего, и установила целевой уровень качества — 90%.

Ассистента запустили в режиме «стажера»: он готовил черновик ответа, но перед отправкой клиенту текст проверяли сотрудники поддержки, которые работали на линии. Они решали, подходит ответ или нет и выбирали, отклонить ответ или принять. Такой подход позволил поднять качество с 74% до 92% без риска для клиентского опыта.

На третьем этапе команда перешла от одного ассистента к системе из трех специализированных агентов:

➔ Агент для сегментации: когда клиент обращается в поддержку, то AI автоматически присваивает тему обращения. Все темы ранее самостоятельно размечены.

➔ Агент для ответа: ассистент получает обращение в уже обозначенной тематике и формирует текст ответа. Использует нужные ему данные по конкретной теме.

➔ Агент для эскалации: если вопрос не может быть решен ассистентом (такие кейсы также разметили в системном промте помощника), то он эскалирует обращение человеку.

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

Это стоит делать непрерывно: система требует регулярного ухода. С помощью инструмента можно оценить качество работы (по лайкам, времени ответа и пр.) и понять, устраивает ли решение.

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

Также продумали глубокую интеграцию в продукт: система использует связку LLM + RAG для генерации точных и полезных ответов.

Ассистент работает автономно. Команда контролирует сложные или нестандартные сценарии и оценивает каждый по нескольким параметрам:

• Вопрос клиента
• Ответ ассистента
• Действие ассистента
• Понимание проблемы
• Наличие критичных ошибок
• Наличие НЕкритичных ошибок
• Структура общения
• Язык общения

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

У каждой модели свои особенности: одна склонна к выдумыванию, другая лучше или хуже следует инструкциям, поэтому набор эталонных тестов критичен.

Когда команда добавляет новый тематический контент, ассистент временно возвращается в режим «стажера» — решение об отправке снова принимают саппорты и промпт-инженеры.

Отдельной задачей стало внедрение ассистента в команду. На старте саппорты волновались, что AI заменит их. Общались с каждым по отдельности, объясняя, как решение поможет, а не заберет работу. Каждый месяц делились метриками.

Результат — ассистента воспринимают как полноценного коллегу. Саппорты сами эскалируют проблемы, которые замечают в его ответах, — дополнительный канал обратной связи поверх формального QA. Так, база знаний ассистента постоянно наполняется новыми данными. Основа — не только общие обновления, но и исправленные ошибки ассистента.

Во время DDoS-атаки на инфраструктуру ассистент самостоятельно обработал около 1000 тикетов за 10 минут — определил затронутых клиентов и проконсультировал каждого, сняв с команды более 50% нагрузки, которую люди обрабатывали бы несколько дней.

AI-ассистент особенно эффективен в подобных ситуациях, когда формируется очередь из обращений. Время ответа поддержки может увеличиваться — это напрямую влияет на восприятие сервиса со стороны клиентов. Благодаря ассистенту скорость и качество ответов не снижаются. Он автоматически информирует об изменениях в тикетах и чатах.

Ассистент, который команда строила для себя, стал основой отдельного продукта — SaaS-платформы для создания AI-помощников. 

Timeweb Cloud стал первым и самым требовательным пользователем собственного решения. Это позволило быстро находить слабые места и дорабатывать платформу под реальные сценарии — до того, как ее увидели внешние клиенты.

Сейчас платформой пользуются компании из разных сегментов. Аналитика:

• Почти 50% всех развертываний приходится на автоматизацию продаж и клиентского сервиса в e-commerce и других сферах, связанных с массовым обслуживанием. Например, AI-консультанты круглосуточно обрабатывают запросы в интернет-магазинах — на сайтах, приложениях или в соцсетях.
• 25% агентов решает внутренние корпоративные задачи, такие как анализ документации и данных. Так, один из клиентов провайдера внедрил AI‑категоризатор для проведения тендеров: он автоматизировал анализ и классификацию заявок, формирование лотов и другие этапы подготовки.
• Порядка 15% AI-помощников создаются веб-студиями и digital-агентствами как дополнительная опция к разрабатываемым цифровым продуктам.
• Более 10% используются в сервисах для работы с текстами, например, для специализированных переводов.
• Оставшаяся доля приходится на задачи HR, продуктовой аналитики и маркетинга.

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

Создать агента несложно, но нужно четко понимать под какую задачу и как потом поддерживать. Бизнес‑процессы меняются, их нужно оперативно отражать в работе агента. Кроме того, рынок моделей динамичен: некоторые решения прекращают поддержку. Например, старые версии GPT уже не обновляются.

RAG – самый простой способ адаптировать модель под свои задачи. Проблема галлюцинаций решается загрузкой релевантных файлов, использованием RAG‑технологий и примерами правильных ответов. Качество системы зависит не только от модели, а еще и от структуры базы знаний и точности поиска. Это позволяет получить предсказуемый результат без дообучения и быстро запустить MVP.

Нужно постоянно работать над качеством ответов и экспериментировать с моделями. Модели быстро эволюционируют от релиза к релизу, поэтому важно регулярно проводить эксперименты, не останавливаться на достигнутом, адаптировать решения под текущие задачи.

Без MCP решения сложно масштабировать. Это основа для стандартизации работы с инструментами и контекстом. Протокол позволяет контролировать поведение агентов и переиспользовать интеграции. На первой линии поддержки можно неплохо автоматизировать базовые информационные процессы и без MCP, но на второй линии без него — никуда.