Два года назад мы запустили бота поддержки, чтобы упростить работу специалистов клиентского сервиса. Поначалу бот закрывал только 18% обращений, и в остальных случаях переводил запрос на оператора. Чтобы увеличить число вопросов, на которые бот может ответить самостоятельно, мы навели порядок в базе знаний и автоматизировали ее обновление. Сейчас бот закрывает 45% обращений в поддержку.
Меня зовут Тимофей Столяров. Я работаю AI‑продакт‑менеджером в Mindbox и отвечаю за то, чтобы рутинные и сложные процессы в компании можно было делегировать нейросетям. Недавно я писал, как мы запустили бота поддержки своими силами. В этой статье расскажу, как нам удалось расширить его кругозор.
Почему решили прокачивать базу знаний для бота поддержки
Первую версию бота мы запустили за три месяца как MVP. Он работал по типовой для AI‑ассистентов схеме: анализировал запрос, обращался к базе знаний и формировал ответ. База состояла из статей help‑центра и Mindbox Журнала, документации для разработчиков и нескольких тысяч сырых диалогов поддержки. И хотя отвечал он качественно — CSAT его ответов составлял 90%, — ему, очевидно, не хватало источников информации и он закрывал лишь 18% обращений. Этот показатель надо было увеличивать.
Чтобы прокачивать базу знаний, мы могли обогащать ее новыми сырыми диалогами из поддержки. От этой идеи пришлось отказаться: за месяц их накапливается больше 5000, зачастую они пересекаются по темам и в каждом может решаться несколько вопросов пользователя. В итоге база переполняется разрозненной неполной информацией и боту все равно негде брать готовые ответы.
Тогда мы решили поменять структуру базы знаний. Переработали сырые диалоги в ограниченное число статей, которые ежемесячно дополняем информацией из новых диалогов поддержки. Чтобы писать и обновлять статьи вручную, потребовалась бы небольшая редакция из 3–5 авторов, поэтому мы делегировали эту задачу нейросети.
Как спроектировали новую структуру базы знаний: статьи и FAQ вместо сырых диалогов поддержки
Сейчас в базе хранятся материалы, разбитые на 15 категорий:
— по продуктовым разделам Mindbox: email, SMS, программа лояльности, сценарии;
— по сервисным вопросам.
Для лучшей детализации мы разделили категории на подкатегории, каждая из которых посвящена отдельной теме. Например, продуктовая категория «Мобильные приложения» делится на подкатегории: «Интеграцию мобильного приложения», «Создание пушей», «Доставляемость».
А сервисная категория «Поломки и доступность» делится на подкатегории «Доступность интерфейса», «Производительность админки», «Доступность API», «Фоновые операции».
Список подкатегорий составили вручную: сгруппировали завершенные диалоги по темам обращения, а затем распределили их по продуктовым разделам. В итоге получили 120 подкатегорий.
Каждая подкатегория объединяет в себе набор данных:
FAQ — набор нескольких пар «вопрос–ответ», извлеченных из диалогов. Например, в подкатегории про программу лояльности может быть больше 30 пар. Каждая из них закрывает один конкретный вопрос клиента.
Статью, которая содержит базовую информацию по теме, принципам работы и типичные сценарии. Генерируется автоматически на основе FAQ.
Указание, в каких еще источниках базы знаний искать ответ или не искать вообще. Например, если клиент спрашивает про маркетинг, бессмысленно лезть в техническую документацию для разработчиков, но можно поискать ответ в соответствующей статье help-центра.
Пара «вопрос–ответ»
«Можно ли изменить категорию у уже созданного статуса заказа или статуса позиции заказа в Mindbox?»
Нет. В Mindbox категорию у уже созданного статуса нельзя менять через редактирование, даже если удалить действия с этим статусом. Блокировка поля категории после создания статуса не снимается удалением истории.
Как исправить категорию
Нужно пересоздать статус:
Остановите передачу новых заказов или действий с этим статусом, иначе зависимые сущности будут появляться снова.
Удалите действия, в которых использовался этот статус.
Уберите использование статуса из сущностей, которые блокируют удаление статуса.
Удалите сам статус.
Создайте статус заново с нужной категорией.
Что может блокировать удаление статуса
Статус может не удаляться не только из-за действий, но и из-за других зависимостей в Mindbox. В диалоге подтвердилось, что удаление блокируют, в частности:
активные сценарии;
сценарии в черновике;
рассылки в процессе.
Если статус не удаляется
Если после остановки передачи и удаления действий статус всё равно не удаляется, проверьте, не используется ли он в сценариях и текущих рассылках. Пока такая зависимость существует, пересоздать статус с тем же внешним идентификатором не получится.
Важно
Если внешний идентификатор статуса жёстко зашит во внешней системе, рабочий путь — именно удалить старый статус и создать его заново с тем же внешним идентификатором и правильной категорией. Создание второго статуса с новым идентификатором в таком случае не решает задачу интеграции.
Когда клиент обращается в бот, AI анализирует вопрос и определяет его подкатегорию. Затем инструменты векторного и семантического поиска находят близкие по смыслу материалы. Темы подкатегорий пересекаются, и на этом этапе поиск может вернуть лишнее. Например, вместе со статьей про маркетинг выдать статью про интеграцию. Чтобы выбрать более подходящие для ответа статьи, на следующем шаге AI ранжирует найденный материал и отсекает все, что не связано с вопросом напрямую. В агент попадают только материалы с оценкой «подходит».
В результате бот формирует ответ на основе:
— релевантных пар из FAQ нужной подкатегории;
— статьи по теме;
— информации из help‑центра, материалов из Mindbox Журнала и технической документации.
Как генерируем и обновляем базу знаний: метод «снежного кома»
Новую базу знаний собираем автоматически: AI-модель читает новые диалоги поддержки и на их основе создает или дополняет FAQ и статьи. Таким образом, база обогащается за счет новых обращений в поддержку.
Мы называем этот процесс «снежным комом». Он состоит из четырех этапов.
Этап 1: классифицируем обращения в поддержку. Все новые диалоги автоматически загружаются в нейросеть. AI распределяет их по подкатегориям и отсеивает те обращения, где непонятно, какой был вопрос и как он решился.
Этап 2: фильтруем диалоги. Для обогащения базы знаний отбираем только те диалоги, в которые подключался оператор‑человек: в них может быть информация, которой еще нет в базе знаний, раз бот не справился сам.
Этап 3: решаем, нужно ли менять базу знаний. Для нового диалога и вычисленной подкатегории находим текущую статью и FAQ в базе, если они есть. Нейросеть решает, нужно ли обновить материал на основе обрабатываемого диалога. Возможные решения AI:
skip | Пропустить. Диалог не содержит новой информации, не относится к теме или предполагает косметические правки |
update | Добавить в FAQ новый пункт или дополнить существующий |
delete | Удалить пункт из FAQ: он дублирует другой по смыслу или описывает временный баг |
check | Пометить диалог для ручной валидации, если в нем есть данные, которые противоречат тому, что уже содержится в базе |
Этап 4: дополняем базу знаний. После того как нейросеть приняла решение, она вносит изменения в FAQ и статью.
Чтобы заставить AI‑модель корректно обновлять материалы, мы прошли типичный путь от общения с ней как с обычным человеком до подробной развернутой инструкции. Перечислю наши ключевые требования, которые должна выполнять модель:
— сразу же завершить работу, если диалог не относится к заданной теме;
— решить, стоит ли обновлять текущий перечень FAQ: добавить новые пары «вопрос‑ответ», переписать или удалить существующие;
— формулировать текст в мире клиента, а не писать в духе «ошибка 403 в webhook»;
— избегать дублирования пунктов в FAQ;
— сохранять существующие факты при обновлении пункта.
Как следим за качеством базы знаний, чтобы «снежный ком» не вышел из-под контроля
Метод «снежный ком» предполагает, что нейросеть каждый раз дополняет существующие версии статей. Если на предыдущей итерации модель допустила неточность в тексте или внесла избыточную информацию, то при обновлении она будет считать материал эталонным и наращивать его новыми ошибками и лишними деталями.
Для нас это болезненно проявляется в сложных продуктовых темах, где один и тот же вопрос клиента может иметь десятки разных объяснений. Например, когда клиент спрашивает «Почему не сработала акция?», специалисты поддержки выясняют подробности и находят причину проблемы конкретно у этого клиента. У одного могли быть некорректно настроены фильтры сегментации, у другого — неверно задан период акции, у третьего не выполнялось условие по минимальной сумме заказа. Модель документирует все эти обращения в FAQ о программе лояльности, посчитав, что в материалах на эту тему должно быть много деталей.
В итоге статья разрастается до 200+ пунктов и превращается в хаотичный набор частных случаев. А поскольку огромный текст каждый раз целиком попадает в контекст модели, стоимость обновления растет.
Чтобы остановить избыточное разрастание материалов, контролируем объем статей вручную и ограничиваем число диалогов из соответствующей подкатегории, которые попадают в обработку к AI.
А чтобы клиенты получали от бота полезные и корректные ответы, следим за качеством базы знаний и раз в месяц оцениваем его по случайной выборке материалов:
Модерируем FAQ, в которых обнаружились фактические ошибки. Например, нейросеть может дописать «костыльные» рекомендации, которые специалист поддержки дает клиенту в момент временного сбоя сервиса. В штатном режиме такие советы теряют актуальность и не работают, поэтому записи о них нужно выявлять и удалять из материалов.
Проверяем, чтобы каждый пункт в FAQ описывал только одну задачу клиента. Например, вопрос «Как настроить RFM‑отчет и запустить автоматический сценарий на сегмент клиентов оттока?» касается сразу трех тем. Такие вопросы дробим и уносим каждый в свою подкатегорию.
В дальнейшем планируем тщательнее контролировать качество материалов:
— все новые и дополненные статьи будут проверять внутренние эксперты. Ожидаем, что это потребует меньших затрат времени, чем создание статей с нуля;
— статьи, к которым редко обращается бот, будем удалять или переписывать вручную. Если материал не используется, значит, он бесполезен и зря занимает место в хранилище данных.
Чего добились: прокачали бота и снизили нагрузку техподдержки
Когда мы приводили в порядок базу знаний и настраивали ее автоматическое обновление, то стремились повысить число закрытых ботом обращений. Нам это удалось, и теперь бот закрывает 45% вопросов из первой линии поддержки.
Недавно бота подключили и ко второй линии — это внутренняя поддержка для самих сотрудников. Там он помогает специалистам первой линии и менеджерам по успеху клиентов находить информацию о продукте. Скоро планируем подключить бота к третьей линии — это поддержка для специалистов из второй. Там отвечают разработчики и помогают разобраться, как работает сервис. Рассчитываем, что на третьей линии бот снимет часть нагрузки с разработчиков: до них будут доходить только самые сложные вопросы.
А еще по MCP-протоколу мы открыли доступ к базе для корпоративных AI-инструментов. Теперь, прежде чем задавать вопрос техподдержке, сотрудники могут поискать ответ самостоятельно в чатах с AI.