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

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

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

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

Прежде чем погружаться в автоматизацию, крайне важно понять вашу существующую систему заявок. Начните с исследования того, как ваша команда поддержки в настоящее время обрабатывает маршрутизацию заявок. Рассмотрите такие вопросы, как:
  • Какие критерии используются для определения того, какое SLA/предложение услуг применяется?
  • Используется ли маршрутизация заявок для определения того, к какому уровню поддержки или специалисту по продукту направляется заявка?
  • Есть ли уже какие-либо автоматизированные правила или рабочие процессы? В каких случаях они терпят неудачу?
  • Как обрабатываются крайние случаи или неоднозначные заявки?
  • Как команда расставляет приоритеты заявок?
Чем больше вы знаете о том, как люди обрабатывают определенные случаи, тем лучше вы сможете работать с Claude для выполнения задачи.

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

Хорошо определенный список категорий намерений пользователей имеет решающее значение для точной классификации заявок поддержки с помощью Claude. Способность Claude эффективно направлять заявки в вашей системе прямо пропорциональна тому, насколько хорошо определены категории вашей системы. Вот некоторые примеры категорий намерений пользователей и подкатегорий.
  • Проблема с оборудованием
  • Ошибка программного обеспечения
  • Проблема совместимости
  • Проблема производительности
  • Сброс пароля
  • Проблемы доступа к аккаунту
  • Запросы по биллингу
  • Изменения подписки
  • Запросы о функциях
  • Вопросы совместимости продукта
  • Информация о ценах
  • Запросы о доступности
  • Вопросы “как сделать”
  • Помощь в использовании функций
  • Советы по лучшим практикам
  • Руководство по устранению неполадок
  • Отчеты об ошибках
  • Запросы функций
  • Общая обратная связь или предложения
  • Жалобы
  • Запросы о статусе заказа
  • Информация о доставке
  • Возвраты и обмены
  • Изменения заказа
  • Помощь в установке
  • Запросы на обновление
  • Планирование обслуживания
  • Отмена услуги
  • Запросы о конфиденциальности данных
  • Отчеты о подозрительной активности
  • Помощь с функциями безопасности
  • Вопросы регулятивного соответствия
  • Запросы об условиях обслуживания
  • Запросы правовой документации
  • Критические сбои системы
  • Срочные проблемы безопасности
  • Проблемы, чувствительные ко времени
  • Запросы на обучение продукту
  • Запросы документации
  • Информация о вебинарах или семинарах
  • Помощь в интеграции
  • Вопросы использования API
  • Запросы совместимости с третьими сторонами
В дополнение к намерению, маршрутизация и приоритизация заявок также могут зависеть от других факторов, таких как срочность, тип клиента, SLA или язык. Обязательно учитывайте другие критерии маршрутизации при создании вашей автоматизированной системы маршрутизации.

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

Работайте с вашей командой поддержки, чтобы определить четкие критерии успеха с измеримыми показателями, пороговыми значениями и целями. Вот некоторые стандартные критерии и показатели при использовании LLM для маршрутизации заявок поддержки:
Эта метрика оценивает, насколько последовательно Claude классифицирует похожие заявки со временем. Это имеет решающее значение для поддержания надежности маршрутизации. Измеряйте это, периодически тестируя модель с набором стандартизированных входных данных и стремясь к уровню согласованности 95% или выше.
Это измеряет, как быстро Claude может адаптироваться к новым категориям или изменяющимся шаблонам заявок. Тестируйте это, вводя новые типы заявок и измеряя время, необходимое модели для достижения удовлетворительной точности (например, >90%) на этих новых категориях. Стремитесь к адаптации в течение 50-100 образцов заявок.
Это оценивает способность Claude точно направлять заявки на нескольких языках. Измеряйте точность маршрутизации на разных языках, стремясь к снижению точности не более чем на 5-10% для неосновных языков.
Это оценивает производительность Claude на необычных или сложных заявках. Создайте тестовый набор крайних случаев и измерьте точность маршрутизации, стремясь к точности не менее 80% на этих сложных входных данных.
Это измеряет справедливость Claude в маршрутизации по различным демографическим группам клиентов. Регулярно проводите аудит решений маршрутизации на предмет потенциальных предвзятостей, стремясь к согласованной точности маршрутизации (в пределах 2-3%) по всем группам клиентов.
В ситуациях, когда минимизация количества токенов имеет решающее значение, этот критерий оценивает, насколько хорошо Claude работает с минимальным контекстом. Измеряйте точность маршрутизации с различным количеством предоставленного контекста, стремясь к точности 90%+ только с заголовком заявки и кратким описанием.
Это оценивает качество и релевантность объяснений Claude для его решений маршрутизации. Человеческие оценщики могут оценивать объяснения по шкале (например, 1-5), с целью достижения средней оценки 4 или выше.
Вот некоторые общие критерии успеха, которые могут быть полезны независимо от того, используется ли LLM:
Точность маршрутизации измеряет, как часто заявки правильно назначаются соответствующей команде или лицу с первой попытки. Это обычно измеряется как процент правильно направленных заявок от общего количества заявок. Отраслевые показатели часто стремятся к точности 90-95%, хотя это может варьироваться в зависимости от сложности структуры поддержки.
Эта метрика отслеживает, как быстро заявки назначаются после подачи. Более быстрое время назначения обычно приводит к более быстрому разрешению и улучшенному удовлетворению клиентов. Лучшие в классе системы часто достигают среднего времени назначения менее 5 минут, при этом многие стремятся к почти мгновенной маршрутизации (что возможно с реализациями LLM).
Частота перенаправления указывает, как часто заявки нужно переназначать после первоначальной маршрутизации. Более низкая частота предполагает более точную первоначальную маршрутизацию. Стремитесь к частоте перенаправления ниже 10%, при этом лучшие системы достигают частоты 5% или менее.
Это измеряет процент заявок, разрешенных во время первого взаимодействия с клиентом. Более высокие частоты указывают на эффективную маршрутизацию и хорошо подготовленные команды поддержки. Отраслевые показатели обычно варьируются от 70-75%, при этом лучшие исполнители достигают частоты 80% или выше.
Среднее время обработки измеряет, сколько времени требуется для разрешения заявки от начала до конца. Эффективная маршрутизация может значительно сократить это время. Показатели широко варьируются по отраслям и сложности, но многие организации стремятся держать среднее время обработки менее 24 часов для некритических проблем.
Часто измеряемые через опросы после взаимодействия, эти оценки отражают общее удовлетворение клиентов процессом поддержки. Эффективная маршрутизация способствует более высокому удовлетворению. Стремитесь к оценкам CSAT 90% или выше, при этом лучшие исполнители часто достигают уровня удовлетворенности 95%+.
Это измеряет, как часто заявки нужно эскалировать на более высокие уровни поддержки. Более низкие частоты эскалации часто указывают на более точную первоначальную маршрутизацию. Стремитесь к частоте эскалации ниже 20%, при этом лучшие в классе системы достигают частоты 10% или менее.
Эта метрика рассматривает, сколько заявок агенты могут эффективно обрабатывать после внедрения решения маршрутизации. Улучшенная маршрутизация должна увеличить производительность. Измеряйте это, отслеживая заявки, разрешенные на агента в день или час, стремясь к улучшению на 10-20% после внедрения новой системы маршрутизации.
Это измеряет процент потенциальных заявок, разрешенных через опции самообслуживания до входа в систему маршрутизации. Более высокие частоты указывают на эффективную предварительную сортировку маршрутизации. Стремитесь к частоте отклонения 20-30%, при этом лучшие исполнители достигают частоты 40% или выше.
Эта метрика рассчитывает среднюю стоимость разрешения каждой заявки поддержки. Эффективная маршрутизация должна помочь снизить эту стоимость со временем. Хотя показатели широко варьируются, многие организации стремятся снизить стоимость на заявку на 10-15% после внедрения улучшенной системы маршрутизации.

Выберите правильную модель Claude

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

Создайте сильный промпт

Маршрутизация заявок - это тип задачи классификации. Claude анализирует содержимое заявки поддержки и классифицирует ее в предопределенные категории на основе типа проблемы, срочности, требуемой экспертизы или других соответствующих факторов. Давайте напишем промпт классификации заявок. Наш первоначальный промпт должен содержать содержимое пользовательского запроса и возвращать как рассуждение, так и намерение.
Попробуйте генератор промптов в консоли Claude, чтобы Claude написал первый черновик для вас.
Вот пример промпта классификации маршрутизации заявок:
def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    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.
        """
Давайте разберем ключевые компоненты этого промпта:
  • Мы используем f-строки Python для создания шаблона промпта, позволяя вставлять 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 anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    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.
        """
    # Send the prompt to the API to classify the support request.
    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

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `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
Этот код:
  • Импортирует библиотеку Anthropic и создает экземпляр клиента, используя ваш API-ключ.
  • Определяет функцию classify_support_request, которая принимает строку ticket_contents.
  • Отправляет ticket_contents в Claude для классификации, используя classification_prompt
  • Возвращает reasoning и intent модели, извлеченные из ответа.
Поскольку нам нужно дождаться генерации всего текста рассуждения и намерения перед парсингом, мы устанавливаем stream=False (по умолчанию).

Оцените ваш промпт

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

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

Наш пример оценки для этого руководства измеряет производительность Claude по трем ключевым метрикам:
  • Точность
  • Стоимость на классификацию
Вам может потребоваться оценить Claude по другим осям в зависимости от того, какие факторы важны для вас. Для оценки этого мы сначала должны изменить скрипт, который мы написали, и добавить функцию для сравнения предсказанного намерения с фактическим намерением и вычисления процента правильных предсказаний. Мы также должны добавить функциональность расчета стоимости и измерения времени.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(request, actual_intent):
    # Define the prompt for the classification task
    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

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

      # Check if the model's prediction is correct.
    correct = actual_intent.strip() == intent.strip()

    # Return the reasoning, intent, correct, and usage.
    return reasoning, intent, correct, usage
Давайте разберем изменения, которые мы внесли:
  • Мы добавили actual_intent из наших тестовых случаев в метод classify_support_request и настроили сравнение для оценки того, соответствует ли классификация намерения Claude нашей золотой классификации намерения.
  • Мы извлекли статистику использования для API-вызова для расчета стоимости на основе использованных входных и выходных токенов

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

Правильная оценка требует четких пороговых значений и показателей для определения того, что является хорошим результатом. Скрипт выше даст нам значения времени выполнения для точности, времени отклика и стоимости на классификацию, но нам все еще нужны четко установленные пороговые значения. Например:
  • Точность: 95% (из 100 тестов)
  • Стоимость на классификацию: 50% снижение в среднем (по 100 тестам) от текущего метода маршрутизации
Наличие этих пороговых значений позволяет вам быстро и легко определить в масштабе и с беспристрастным эмпиризмом, какой метод лучше всего подходит для вас и какие изменения могут потребоваться для лучшего соответствия вашим требованиям.

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

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

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

По мере роста количества классов также расширяется количество требуемых примеров, потенциально делая промпт громоздким. В качестве альтернативы вы можете рассмотреть реализацию иерархической системы классификации, используя смесь классификаторов.
  1. Организуйте ваши намерения в структуру таксономического дерева.
  2. Создайте серию классификаторов на каждом уровне дерева, обеспечивая каскадный подход маршрутизации.
Например, у вас может быть классификатор верхнего уровня, который широко категоризирует заявки на “Технические проблемы”, “Вопросы биллинга” и “Общие запросы”. Каждая из этих категорий может затем иметь свой собственный подклассификатор для дальнейшего уточнения классификации.
  • Плюсы - большая нюансировка и точность: Вы можете создать разные промпты для каждого родительского пути, позволяя более целевую и контекстно-специфическую классификацию. Это может привести к улучшенной точности и более нюансированной обработке запросов клиентов.
  • Минусы - увеличенная задержка: Имейте в виду, что множественные классификаторы могут привести к увеличенной задержке, и мы рекомендуем реализовать этот подход с нашей самой быстрой моделью, Haiku.

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

Несмотря на то, что предоставление примеров является наиболее эффективным способом улучшения производительности, если запросы поддержки сильно варьируются, может быть трудно включить достаточно примеров в один промпт. В этом сценарии вы могли бы использовать векторную базу данных для поиска по сходству из набора данных примеров и извлечения наиболее релевантных примеров для данного запроса. Этот подход, подробно описанный в нашем рецепте классификации, показал улучшение производительности с 71% точности до 93% точности.

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

Вот некоторые сценарии, где Claude может неправильно классифицировать заявки (могут быть другие, уникальные для вашей ситуации). В этих сценариях рассмотрите предоставление явных инструкций или примеров в промпте того, как Claude должен обрабатывать крайний случай:
Клиенты часто выражают потребности косвенно. Например, “Я жду свою посылку уже более двух недель” может быть косвенным запросом статуса заказа.
  • Решение: Предоставьте Claude некоторые реальные примеры клиентов таких запросов, вместе с тем, каково основное намерение. Вы можете получить еще лучшие результаты, если включите обоснование классификации для особенно нюансированных намерений заявок, чтобы Claude мог лучше обобщить логику на другие заявки.
Когда клиенты выражают неудовлетворенность, Claude может приоритизировать обращение к эмоции над решением основной проблемы.
  • Решение: Предоставьте Claude указания о том, когда приоритизировать настроение клиента или нет. Это может быть что-то простое, как “Игнорируйте все эмоции клиентов. Сосредоточьтесь только на анализе намерения запроса клиента и какую информацию клиент может запрашивать.”
Когда клиенты представляют множественные проблемы в одном взаимодействии, Claude может испытывать трудности с идентификацией основной проблемы.
  • Решение: Уточните приоритизацию намерений, чтобы Claude мог лучше ранжировать извлеченные намерения и идентифицировать основную проблему.

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

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