Маршрутизация тикетов



Предварительные требования

• Ключ API Claude и установленный Python SDK
• Доступ к вашей существующей системе тикетов поддержки и знакомство с ней
• Набор исторических тикетов поддержки для тестирования



Определите, стоит ли использовать Claude для маршрутизации тикетов

Вот некоторые ключевые индикаторы того, что вам следует использовать "large language model" (большую языковую модель), или LLM, такую как Claude, вместо традиционных подходов машинного обучения для вашей задачи классификации:



Создайте и разверните ваш рабочий процесс поддержки на основе LLM



Поймите ваш текущий подход к поддержке

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

Рассмотрите такие вопросы:

• Какие критерии используются для определения того, какое SLA/предложение услуг применяется?
• Используется ли маршрутизация тикетов для определения того, к какому уровню поддержки или специалисту по продукту направляется тикет?
• Существуют ли уже какие-либо автоматизированные правила или рабочие процессы? В каких случаях они не срабатывают?
• Как обрабатываются пограничные случаи или неоднозначные тикеты?
• Как команда приоритизирует тикеты?

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



Определите категории намерений пользователей

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

Вот несколько примеров категорий и подкатегорий намерений пользователей.

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



Установите критерии успеха

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

Вот некоторые стандартные критерии и эталоны при использовании LLM для маршрутизации тикетов поддержки:

Вот некоторые общие критерии успеха, которые могут быть полезны независимо от того, используется ли LLM:



Выберите подходящую модель Claude

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

Многие клиенты сочли claude-haiku-4-5-20251001 идеальной моделью для маршрутизации тикетов, поскольку это самая быстрая и экономически эффективная модель в семействе Claude 4, при этом обеспечивающая отличные результаты. Если ваша задача классификации требует глубокой предметной экспертизы, большого количества категорий намерений или сложных рассуждений, вы можете выбрать более крупную модель Sonnet.



Создайте сильную подсказку

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

Напишите подсказку для классификации тикетов. Первоначальная подсказка должна содержать содержимое запроса пользователя и возвращать как обоснование, так и намерение.

Вот пример подсказки для классификации при маршрутизации тикетов:

def classify_support_request(ticket_contents):
    # Определяем подсказку для задачи классификации
    classification_prompt = f"""You will be acting as a customer support ticket classification system. Your task is to analyze customer support requests and output the appropriate classification intent for each request, along with your reasoning.

        Here is the customer support request you need to classify:

        <request>{ticket_contents}</request>

        Please carefully analyze the above request to determine the customer's core intent and needs. Consider what the customer is asking for has concerns about.

        First, write out your reasoning and analysis of how to classify this request inside <reasoning> tags.

        Then, output the appropriate classification label for the request inside a <intent> tag. The valid intents are:
        <intents>
        <intent>Support, Feedback, Complaint</intent>
        <intent>Order Tracking</intent>
        <intent>Refund/Exchange</intent>
        </intents>

        A request may have ONLY ONE applicable intent. Only include the intent that is most applicable to the request.

        As an example, consider the following request:
        <request>Hello! I had high-speed fiber internet installed on Saturday and my installer, Kevin, was absolutely fantastic! Where can I send my positive review? Thanks for your help!</request>

        Here is an example of how your output should be formatted (for the above example request):
        <reasoning>The user seeks information in order to leave positive feedback.</reasoning>
        <intent>Support, Feedback, Complaint</intent>

        Here are a few more examples:
        <examples>
        <example 2>
        Example 2 Input:
        <request>I wanted to write and personally thank you for the compassion you showed towards my family during my father's funeral this past weekend. Your staff was so considerate and helpful throughout this whole process; it really took a load off our shoulders. The visitation brochures were beautiful. We'll never forget the kindness you showed us and we are so appreciative of how smoothly the proceedings went. Thank you, again, Amarantha Hill on behalf of the Hill Family.</request>

        Example 2 Output:
        <reasoning>User leaves a positive review of their experience.</reasoning>
        <intent>Support, Feedback, Complaint</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        Example 9 Input:
        <request>Your website keeps sending ad-popups that block the entire screen. It took me twenty minutes just to finally find the phone number to call and complain. How can I possibly access my account information with all of these popups? Can you access my account for me, since your website is broken? I need to know what the address is on file.</request>

        Example 9 Output:
        <reasoning>The user requests help accessing their web account information.</reasoning>
        <intent>Support, Feedback, Complaint</intent>
        </example 9>

        Remember to always include your classification reasoning before your actual intent output. The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """

Вот ключевые компоненты этой подсказки:

• Шаблон подсказки — это Python f-string, позволяющий вставить ticket_contents в теги <request>.
• Подсказка дает Claude четко определенную роль системы классификации, которая тщательно анализирует содержимое тикета, чтобы определить основное намерение и потребности клиента.
• Подсказка инструктирует Claude о правильном форматировании вывода, в данном случае — предоставить свое обоснование и анализ внутри тегов <reasoning>, за которыми следует соответствующая метка классификации внутри тегов <intent>.
• Подсказка указывает допустимые категории намерений: "Support, Feedback, Complaint", "Order Tracking" и "Refund/Exchange".
• Подсказка включает несколько примеров (так называемый few-shot prompting), чтобы проиллюстрировать, как должен быть отформатирован вывод, что улучшает точность и согласованность.

Разделение ответа Claude на отдельные секции с XML-тегами позволяет использовать регулярные выражения для независимого извлечения обоснования и намерения из вывода. Это позволяет создавать целенаправленные следующие шаги в рабочем процессе маршрутизации тикетов, например, использовать только намерение для решения, какому человеку направить тикет.



Разверните вашу подсказку

Трудно понять, насколько хорошо работает ваша подсказка, не развернув ее в тестовой производственной среде и не проведя оценки.

Создайте структуру развертывания. Начните с определения сигнатуры метода для обертывания вызова Claude. Расширьте метод, который вы начали писать ранее, принимающий ticket_contents в качестве входных данных, так чтобы теперь он возвращал кортеж из reasoning и intent в качестве вывода. Если у вас есть существующая автоматизация с использованием традиционного машинного обучения, вам следует следовать этой сигнатуре метода.

import re

# Создаём экземпляр клиента Claude API
client = anthropic.Anthropic()

# Задаём модель по умолчанию
DEFAULT_MODEL = "claude-haiku-4-5-20251001"


def classify_support_request(ticket_contents):
    # Определяем подсказку для задачи классификации
    classification_prompt = f"""You will be acting as a customer support ticket classification system.
        ...
        ... The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """
    # Отправляем подсказку в API для классификации запроса в поддержку.
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # Используем библиотеку регулярных выражений Python для извлечения `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Аналогично извлекаем и `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    return reasoning, intent

Этот код:

• Создает экземпляр клиента, используя ваш ключ API.
• Определяет функцию classify_support_request, которая принимает строку ticket_contents.
• Отправляет ticket_contents в Claude для классификации, используя classification_prompt.
• Возвращает reasoning и intent модели, извлеченные из ответа.

Поскольку весь текст обоснования и намерения должен быть сгенерирован до парсинга, в примере устанавливается stream=False (значение по умолчанию).



Оцените вашу подсказку

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

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



Создайте функцию оценки

Пример оценки для этого руководства измеряет производительность Claude по трем ключевым метрикам:

• Точность
• Стоимость одной классификации

Вам может потребоваться оценить Claude по другим параметрам в зависимости от того, какие факторы важны для вас.

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

import re

# Создаём экземпляр клиента Claude API
client = anthropic.Anthropic()

# Задаём модель по умолчанию
DEFAULT_MODEL = "claude-haiku-4-5-20251001"


def classify_support_request(request, actual_intent):
    # Определяем подсказку для задачи классификации
    classification_prompt = f"""You will be acting as a customer support ticket classification system.
        ...
        ...The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # Get the usage statistics for the API call for how many input and output tokens were used.
    reasoning_and_intent = message.content[0].text

    # Используем библиотеку регулярных выражений Python, чтобы извлечь `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Аналогично извлекаем и `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    # Проверяем, верно ли предсказание модели.
    correct = actual_intent.strip() == intent.strip()

    # Возвращаем reasoning, intent, correct и usage.
    return reasoning, intent, correct, usage

Вот разбор внесенных изменений:

• Метод classify_support_request теперь принимает actual_intent из тестовых случаев и сравнивает его с классификацией намерения Claude, чтобы оценить, совпадают ли они.
• Метод извлекает статистику использования для вызова API, чтобы рассчитать стоимость на основе использованных входных и выходных токенов.



Запустите вашу оценку

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

• Точность: 95% (из 100 тестов)
• Стоимость одной классификации: снижение в среднем на 50% (по 100 тестам) по сравнению с текущим методом маршрутизации

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



Улучшите производительность

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



Используйте таксономическую иерархию для случаев с 20+ категориями намерений

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

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

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

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

• Минусы — увеличенная "latency" (задержка): Имейте в виду, что несколько классификаторов могут привести к увеличению задержки, и Anthropic рекомендует реализовывать этот подход с самой быстрой моделью, Haiku.



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

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

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

Этот подход, подробно описанный в рецепте классификации, показал улучшение производительности с 71% точности до 93% точности.



Специально учитывайте ожидаемые пограничные случаи

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



Интегрируйте Claude в ваш общий рабочий процесс поддержки

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

• На основе push: Система тикетов поддержки, которую вы используете (например, Zendesk), запускает ваш код, отправляя событие webhook в ваш сервис маршрутизации, который затем классифицирует намерение и маршрутизирует его.
  • Этот подход более масштабируем для веба, но требует от вас предоставления публичной конечной точки.
• На основе pull: Ваш код запрашивает последние тикеты по заданному расписанию и маршрутизирует их во время запроса.
  • Этот подход проще в реализации, но может делать ненужные вызовы к системе тикетов поддержки, когда частота запросов слишком высока, или может быть чрезмерно медленным, когда частота запросов слишком низка.

Для любого из этих подходов вам нужно обернуть ваш скрипт в сервис. Выбор подхода зависит от того, какие API предоставляет ваша система тикетов поддержки.