Автоматизация технической поддержки: кейс RAG-ассистента и Битрикс24

Ко мне обратилась торговая компания с задачей автоматизировать часть технической поддержки.

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

На первый взгляд, задача выглядела просто: подключить чат-бот для технической поддержки и загрузить в него готовые ответы.

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

В результате было разработано решение на основе RAG: ассистент ищет информацию во внутренней базе знаний, формирует ответ и передаёт сложные обращения специалисту. Для работы с диалогами и операторами систему интегрировали с Битрикс24.

Исходная задача

Основная нагрузка на службу поддержки складывалась из повторяющихся обращений двух типов:

• вопросы об ограничениях аккаунта;
• вопросы о порядке и условиях верификации.

Сами ответы не требовали сложной технической диагностики. В большинстве случаев специалист открывал внутреннюю инструкцию, находил нужный раздел и пересказывал его клиенту.

Проблема была не в отсутствии информации, а в способе работы с ней.

Документы существовали отдельно от канала поддержки. Сотрудники тратили время на поиск, а формулировки ответов могли различаться в зависимости от того, кто обрабатывал обращение.

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

Это ограничение стало основой всей архитектуры.

Почему не подошёл обычный чат-бот

Сценарный бот работает хорошо, когда пользователь выбирает один из заранее известных вариантов:

1. нажимает кнопку;
2. переходит по заданной ветке;
3. получает подготовленный ответ;
4. при необходимости вызывает оператора.

Такой подход предсказуем и относительно прост в сопровождении. Если вопросов немного, а формулировки пользователей почти не меняются, усложнять систему не стоит.

В этом проекте ситуация была другой.

Один вопрос мог звучать по-разному:

• Почему мне недоступна функция?
• Какие ограничения действуют для моего аккаунта?
• Что нужно для прохождения проверки?
• Почему верификация не завершилась?
• Какие документы можно предоставить?
• Что изменится после подтверждения данных?

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

Поэтому обычный чат-бот для технической поддержки был заменён на более гибкую схему: система должна понимать смысл вопроса и находить ответ в корпоративной базе знаний.

Какое решение было разработано

Решение состояло из четырёх основных компонентов:

• Битрикс24 как рабочая среда службы поддержки;
• внутренней базы знаний;
• RAG-сервиса для поиска информации и подготовки ответа;
• механизма передачи обращения специалисту.

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

В реализованном процессе обращение проходило следующий маршрут:

1. Клиент отправлял вопрос в подключённый канал поддержки.
2. Обращение поступало в Битрикс24.
3. Сообщение передавалось RAG-ассистенту.
4. Система искала подходящие материалы во внутренней базе знаний.
5. Если находился однозначный ответ, ассистент формировал сообщение для клиента.
6. Если информации было недостаточно или вопрос выходил за установленные границы, диалог передавался специалисту.

Так автоматизация процессов технической поддержки была ограничена теми действиями, которые можно контролировать и проверять.

Ассистент не принимал решение о статусе аккаунта и не изменял данные клиента. Он объяснял действующие правила и помогал найти нужную информацию.

Роль Битрикс24 в архитектуре

Битрикс24 использовался как интерфейс работы с обращениями.

В нём сохранялась история диалога, распределялись сообщения и подключались сотрудники поддержки. Собственный бот связывал открытую линию с внешним RAG-сервисом.

Роли систем были разделены:

• Битрикс24 принимал обращение и управлял диалогом;
• RAG-сервис искал информацию и формировал ответ;
• база знаний содержала утверждённые правила и инструкции;
• специалист принимал нестандартные решения.

Это разделение было принципиальным.

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

Битрикс24 не должен был самостоятельно интерпретировать внутренние документы. Языковая модель не должна была управлять очередями поддержки. RAG-сервис не должен был принимать решения, требующие полномочий сотрудника.

Каждый компонент выполнял свою часть процесса.

Подготовка базы знаний

Основной объём работы оказался связан не с подключением модели, а с подготовкой документов.

До запуска ассистента нужно было проверить:

• какие инструкции продолжают действовать;
• нет ли нескольких версий одного правила;
• какие документы предназначены только для сотрудников;
• какие ответы можно показывать клиентам;
• от каких параметров аккаунта зависит результат;
• кто отвечает за обновление каждого раздела.

Если в базе знаний находятся противоречащие друг другу документы, RAG не устранит противоречие. Он лишь найдёт один или несколько похожих фрагментов и передаст их модели.

Модель может сформулировать такой ответ уверенно. Но уверенная формулировка ещё не делает информацию правильной.

Поэтому документы были приведены к структуре, пригодной для поиска:

• один вопрос — один утверждённый ответ;
• устаревшие версии исключаются из индекса;
• у документа есть владелец;
• фиксируется дата актуализации;
• внутренние комментарии отделяются от клиентской инструкции;
• разные условия применения описываются явно.

На этом этапе стало понятно, что ИИ в технической поддержке не заменяет работу с корпоративными знаниями. Наоборот, он делает все проблемы базы знаний заметнее.

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

Как ограничили работу ассистента

Ассистент проектировался не как замена специалиста, а как ограниченная первая линия поддержки.

Он мог:

• определить тему обращения;
• найти подходящий документ;
• сформировать ответ на основе найденного материала;
• задать уточняющий вопрос;
• передать диалог сотруднику;
• сохранить информацию об использованном источнике.

Он не должен был:

• придумывать ответ при отсутствии документа;
• объединять противоречащие инструкции;
• принимать решение о верификации;
• изменять данные аккаунта;
• обещать клиенту результат проверки;
• раскрывать внутренние материалы;
• продолжать диалог, если ситуация требует участия сотрудника.

Главное правило выглядело просто: если надёжного ответа в базе знаний нет, ассистент не отвечает от себя.

Это один из ключевых принципов безопасной автоматизации технической поддержки. Модель должна уметь не только формулировать ответы, но и останавливаться.

Защита внутренних данных

Внутренняя база знаний содержала материалы с разным уровнем доступа. Поэтому было недостаточно написать в инструкции модели: «не показывай конфиденциальную информацию».

Проверка доступа должна происходить до того, как документ попадёт в контекст языковой модели.

Архитектура учитывала несколько уровней защиты:

• поиск выполняется только по разрешённым разделам;
• модель получает минимально необходимый фрагмент;
• персональные данные не передаются без необходимости;
• источник каждого ответа сохраняется в журнале;
• закрытые инструкции отделяются от материалов для клиентов;
• спорные случаи передаются специалисту.

Если система сначала извлекла закрытый документ, а затем попросила модель не пересказывать его клиенту, защита уже реализована неправильно.

Модель не должна видеть данные, которые не нужны ей для выполнения конкретной задачи.

Когда обращение передавалось специалисту

Передача человеку была предусмотрена как штатный этап процесса, а не как ошибка системы.

Ассистент прекращал самостоятельную обработку, если:

• в базе знаний не находился подходящий ответ;
• найденные документы противоречили друг другу;
• вопрос зависел от данных конкретного аккаунта;
• требовалось изменить статус или настройки;
• клиент оспаривал полученную информацию;
• ситуация не соответствовала стандартному регламенту;
• пользователь прямо просил подключить специалиста;
• предыдущий ответ не решил проблему.

При передаче специалист получал не пустой диалог, а уже собранный контекст:

• исходный вопрос;
• уточнения клиента;
• определённую категорию обращения;
• найденные материалы;
• отправленные ответы;
• причину эскалации.

Это уменьшало количество повторных вопросов со стороны сотрудника. Ему не приходилось восстанавливать весь разговор с начала.

Что проверяли перед запуском

До подключения ассистента ко всем обращениям был ограничен контур пилота.

Для проверки использовались типовые вопросы об аккаунтах и верификации. Отдельно тестировались ситуации, в которых система не должна была отвечать самостоятельно.

Проверка включала:

Качество поиска

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

Корректность ответа

Соответствует ли текст найденному источнику и не добавляет ли модель неподтверждённые условия.

Работа с разными формулировками

Распознаёт ли система один и тот же вопрос, заданный разными словами.

Эскалация

Передаёт ли ассистент обращение человеку, когда данных недостаточно или требуется индивидуальное решение.

Контекст для специалиста

Получает ли сотрудник историю вопроса, найденные материалы и причину передачи.

Актуальность знаний

Исключены ли из поиска старые версии документов и можно ли обновлять базу без изменения всей системы.

Доля диалогов, завершённых без сотрудника, не использовалась как единственный критерий качества.

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

Результат

После внедрения типовые обращения об ограничениях аккаунта и верификации стали обрабатываться через RAG-ассистента.

Система принимает вопрос в Битрикс24, ищет информацию во внутренней базе знаний и формирует ответ на основе утверждённых документов. Если вопрос требует проверки данных или индивидуального решения, диалог передаётся специалисту.

В результате сотрудники поддержки меньше времени тратят на повторение стандартных ответов и могут сосредоточиться на сложных случаях.

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

Переносимый результат здесь другой: процесс был разделён между системой и человеком по понятным правилам.

Что показал этот кейс

Главная сложность подобных проектов находится не в выборе языковой модели.

Модель можно заменить. Базу знаний, ответственность сотрудников и правила эскалации заменить значительно сложнее.

Из проекта можно выделить несколько практических выводов.

Автоматизировать нужно конкретную группу обращений

Формулировка «автоматизировать поддержку» слишком широкая. Для пилота лучше выбрать один тип вопросов, для которого уже существуют утверждённые ответы.

RAG не исправляет плохие документы

Если инструкции устарели или противоречат друг другу, ассистент будет воспроизводить эти проблемы в диалоге с клиентом.

Битрикс24 и RAG решают разные задачи

Битрикс24 управляет каналами, диалогами и работой сотрудников. RAG отвечает за поиск по корпоративным знаниям. Объединение этих компонентов даёт управляемый процесс.

Эскалация важнее автономности

Хорошая система автоматизации технической поддержки не пытается ответить на любой вопрос. Она понимает границы и вовремя передаёт задачу специалисту.

Иногда достаточно обычного бота

Если вопросов мало, а ответы фиксированы, RAG может оказаться избыточным. Сначала стоит проверить, нельзя ли решить задачу правилами, кнопками и простым workflow.

Сравнение таких подходов подробнее разобрано в статье о том, когда использовать автоматизацию с помощью ИИ, а когда достаточно обычных правил.

С чего начинать похожий проект

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

Сначала нужно взять реальные обращения и разделить их на три группы:

1. ответ существует и не зависит от контекста;
2. ответ существует, но требует уточняющих данных;
3. решение может принять только специалист.

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

После этого можно оценивать состояние базы знаний, интеграций, права доступа и границы пилота.

Если в поддержке накопилось много повторяющейся ручной работы, на аудите бизнес-процессов для внедрения ИИ можно определить, нужен ли компании RAG-ассистент, обычный чат-бот или сначала требуется изменить сам процесс работы с обращениями.

Частые вопросы

Можно ли реализовать такой ассистент внутри Битрикс24?

Битрикс24 может принимать и распределять обращения, подключать ботов к открытым линиям и передавать диалог сотруднику. Поиск по внутренней базе знаний и генерация ответа могут выполняться отдельным RAG-сервисом, подключённым через API.

Чем RAG-ассистент отличается от обычного чат-бота?

Обычный бот следует заранее заданному сценарию. RAG-ассистент ищет информацию в корпоративных документах и может отвечать на разные формулировки одного вопроса.

Когда RAG не нужен?

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

Может ли ассистент самостоятельно менять данные аккаунта?

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

Как снизить риск неправильных ответов?

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