AI для разбора обращений: как собрать очередь для службы поддержки
В общей очереди поддержки смешаны вопросы о доступе, оплате и сбоях. Сотрудник читает каждое обращение, выбирает отдел и переносит карточку. LLM может подготовить эту сортировку по свободному тексту. Полезный первый проект получается, когда система умеет отправить неоднозначное обращение на разбор и показывает, почему выбрала очередь.
Сначала опишите работу очередей
Начните с существующих правил распределения. Для каждой очереди запишите, какие вопросы она принимает, кому передаёт спорные случаи и какие поля нужны сотруднику для первого действия. Категория «техническое» слишком широка, если доступом занимается одна группа, а неисправностью интеграции — другая.
Соберите обращения без персональных данных и попросите опытного сотрудника разложить их по очередям. Ошибки текущего ручного процесса не стоит автоматически превращать в эталон. Для спорных сообщений зафиксируйте причину разногласия: не хватает информации, пересекаются зоны ответственности или в одном сообщении две независимые задачи.
Дайте модели короткий проверяемый результат
Вместо длинного рассуждения попросите вернуть категорию, короткое основание и сведения, которых не хватает. Для категории задайте закрытый набор значений и отдельный вариант unknown. Причину выбора показывайте сотруднику рядом с исходным текстом: она помогает быстро заметить ошибку вроде «оплата» из-за слова «счёт» в сообщении о входе в аккаунт.
Проверка формата не подтверждает правильность маршрута. После разбора ответа примените правила процесса. Например, если в обращении одновременно оплата и доступ, карточка попадает на ручную сортировку. Если модель выбрала допустимую категорию, но не указала обязательный номер заказа, можно запросить уточнение, сохранив предварительный маршрут.
Отделите решение модели от политики очереди
Ниже две карточки представляют уже полученные ответы классификатора. Функция решает, можно ли применять маршрут автоматически. Для неоднозначного обращения выбирается ручной разбор. В рабочем приложении проверка находится между LLM-вызовом и API системы обращений.
allowed = {"access": "identity", "billing": "finance", "integration": "engineering"}
def route(prediction):
topics = prediction.get("topics", [])
if len(topics) != 1 or topics[0] not in allowed:
return "manual_review"
return allowed[topics[0]]
predictions = [{"topics": ["access"]}, {"topics": ["billing", "access"]}]
routes = [route(p) for p in predictions]
assert routes == ["identity", "manual_review"]
print(routes)
Оценивайте ошибки с учётом работы поддержки
Для каждой категории посчитайте, сколько назначений оказалось правильными и сколько обращений отправлено в чужую очередь. Отдельно измерьте долю ручного разбора. Хорошая точность на десяти автоматически выбранных сообщениях мало помогает, если остальные девяносто система не обработала.
Сравните цену ошибок. Вопрос о возврате, отправленный в общий отдел, может задержаться на час; обращение о блокировке критичного доступа требует другого порядка реакции. Срочность извлекайте отдельно от категории, с понятными критериями и возможностью сотрудника её изменить. Не связывайте «модель уверена» с правом пропустить обязательную процедуру.
Запустите классификатор рядом с существующим процессом. Сотрудник продолжает назначать очередь, а приложение сохраняет предложенный и выбранный маршруты. Разбирайте расхождения по причинам, затем обновляйте описание категорий и набор примеров. Переобучение или смена модели нужны только после понимания повторяющегося дефекта.
На следующем этапе можно автоматически обрабатывать подтверждённые классы обращений. Для остальных сохраните простой путь ручного решения. Полезный результат пилота — очередь, в которой сотрудник быстрее начинает работу и видит спорные случаи, а не только процент совпадений классификатора.
Продолжить проект на практике
Следующий шаг — связать классификацию, ручную очередь и инструменты поддержки в явный процесс. В платном курсе AI Agents PRO вы спроектируете состояние агента и workflow в LangGraph, подключите внешние API и добавите собственные проверки качества. Так отдельный классификатор можно развить в проверяемый сервис обработки обращений.
Откройте программу курса и выберите следующий этап своего проекта.
По теме: План AI-агента и исполнение: какие проверки ставить между ними.
Продолжить на практике
- AI Agents PRO: LangGraph, AutoGen и LLMOps в продакшне ↗
Практический курс по AI-агентам. Соберёте продакшн RAG-сервис: от индекса и графа состояний до API, Docker, метрик качества и контроля стоимости. Плюс профессиональные блоки: LangGraph/AutoGen, Qdrant/FAISS+rerank, eval (RAGAS/custom), quality-гейты, OpenTelemetry+Prometheus/Grafana, CI/CD, ретраи/DLQ/идемпотентность, PII/RBAC.
