チケットルーティングにClaudeを使用するかどうかを決定する

分類タスクに従来のMLアプローチではなく、Claudeのような大規模言語モデルを使用すべき主要な指標をいくつか示します:
従来のMLプロセスには大量のラベル付きデータセットが必要です。Claudeの事前トレーニング済みモデルは、わずか数十のラベル付き例でチケットを効果的に分類でき、データ準備時間とコストを大幅に削減できます。
従来のMLアプローチが確立されると、それを変更することは労力とデータ集約的な作業になります。一方、製品や顧客のニーズが進化するにつれて、Claudeはクラス定義の変更や新しいクラスに、トレーニングデータの大規模な再ラベル付けなしに簡単に適応できます。
従来のMLモデルは非構造化データに苦労することが多く、広範囲な特徴エンジニアリングが必要です。Claudeの高度な言語理解により、厳密な存在論的構造に依存するのではなく、内容と文脈に基づいた正確な分類が可能になります。
従来のMLアプローチは、しばしばbag-of-wordsモデルや単純なパターンマッチングに依存しています。Claudeは、クラスが例ではなく条件によって定義される場合に、基礎となるルールを理解し適用することに優れています。
多くの従来のMLモデルは、その意思決定プロセスについてほとんど洞察を提供しません。Claudeは分類決定に対して人間が読める説明を提供でき、自動化システムへの信頼を構築し、必要に応じて簡単な適応を促進します。
従来のMLシステムは外れ値や曖昧な入力に苦労することが多く、しばしばそれらを誤分類したり、包括的なカテゴリにデフォルト設定したりします。Claudeの自然言語処理機能により、サポートチケットの文脈とニュアンスをより良く解釈でき、手動介入が必要な誤ルーティングや未分類チケットの数を潜在的に削減できます。
従来のMLアプローチは通常、サポートされる各言語に対して別々のモデルまたは広範囲な翻訳プロセスが必要です。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時間未満に保つことを目指しています。
多くの場合、やり取り後の調査で測定され、これらのスコアはサポートプロセス全体に対する顧客の総合的な満足度を反映します。効果的なルーティングはより高い満足度に貢献します。90%以上のCSATスコアを目指し、トップパフォーマーは多くの場合95%以上の満足率を達成しています。
これは、チケットがより高いサポート層にエスカレーションされる頻度を測定します。低いエスカレーション率は多くの場合、より正確な初期ルーティングを示します。20%未満のエスカレーション率を目指し、最高クラスのシステムは10%以下の率を達成しています。
この指標は、ルーティングソリューション実装後にエージェントがどれだけ多くのチケットを効果的に処理できるかを見ます。改善されたルーティングは生産性を向上させるはずです。エージェント1人当たり1日または1時間当たりの解決チケット数を追跡することで測定し、新しいルーティングシステム実装後10-20%の改善を目指します。
これは、ルーティングシステムに入る前にセルフサービスオプションで解決される潜在的チケットの割合を測定します。高い率は効果的なルーティング前トリアージを示します。20-30%の転換率を目指し、トップパフォーマーは40%以上の率を達成しています。
この指標は、各サポートチケットを解決するための平均コストを計算します。効率的なルーティングは時間の経過とともにこのコストを削減するのに役立つはずです。ベンチマークは大きく異なりますが、多くの組織は改善されたルーティングシステム実装後にチケット当たりのコストを10-15%削減することを目指しています。

適切なClaudeモデルを選択する

モデルの選択は、コスト、精度、応答時間の間のトレードオフによって決まります。 多くの顧客は、claude-3-5-haiku-20241022がチケットルーティングに理想的なモデルであることを発見しています。これはClaude 3ファミリーで最も高速で費用対効果の高いモデルでありながら、優れた結果を提供するためです。分類問題が深い専門知識や大量の意図カテゴリの複雑な推論を必要とする場合は、より大きなSonnetモデルを選択することもできます。

強力なプロンプトを構築する

チケットルーティングは分類タスクの一種です。Claudeはサポートチケットの内容を分析し、問題タイプ、緊急度、必要な専門知識、またはその他の関連要因に基づいて事前定義されたカテゴリに分類します。 チケット分類プロンプトを書いてみましょう。初期プロンプトには、ユーザーリクエストの内容を含み、推論と意図の両方を返すべきです。
Claude Consoleプロンプトジェネレーターを試して、Claudeに最初のドラフトを書いてもらいましょう。
以下は、チケットルーティング分類プロンプトの例です:
def classify_support_request(ticket_contents):
    # 分類タスクのプロンプトを定義
    classification_prompt = f"""あなたはカスタマーサポートチケット分類システムとして動作します。あなたのタスクは、カスタマーサポートリクエストを分析し、各リクエストに対して適切な分類意図を推論とともに出力することです。

        以下が分類する必要があるカスタマーサポートリクエストです:

        <request>{ticket_contents}</request>

        上記のリクエストを注意深く分析して、顧客の核となる意図とニーズを決定してください。顧客が何を求めているか、何について懸念しているかを考慮してください。

        まず、このリクエストをどのように分類するかについての推論と分析を<reasoning>タグ内に書いてください。

        次に、リクエストに対する適切な分類ラベルを<intent>タグ内に出力してください。有効な意図は以下の通りです:
        <intents>
        <intent>サポート、フィードバック、苦情</intent>
        <intent>注文追跡</intent>
        <intent>返金・交換</intent>
        </intents>

        リクエストには1つの適用可能な意図のみがあります。リクエストに最も適用可能な意図のみを含めてください。

        例として、以下のリクエストを考えてください:
        <request>こんにちは!土曜日に高速光ファイバーインターネットを設置してもらい、設置担当者のKevinさんは本当に素晴らしかったです!どこに肯定的なレビューを送ることができますか?ご協力ありがとうございます!</request>

        以下は、出力がどのようにフォーマットされるべきかの例です(上記の例のリクエストに対して):
        <reasoning>ユーザーは肯定的なフィードバックを残すための情報を求めています。</reasoning>
        <intent>サポート、フィードバック、苦情</intent>

        以下はさらなる例です:
        <examples>
        <example 2>
        例2の入力:
        <request>この週末の父の葬儀の際に、私の家族に示してくださった思いやりについて、個人的にお礼を申し上げたく筆を取りました。スタッフの皆様は、このプロセス全体を通じてとても思いやりがあり親切で、本当に私たちの肩の荷を下ろしてくれました。弔問のパンフレットは美しかったです。皆様が示してくださった親切さを決して忘れることはなく、式典がいかにスムーズに進行したかについて、とても感謝しています。改めて、Hill家を代表してAmarantha Hillより、ありがとうございました。</request>

        例2の出力:
        <reasoning>ユーザーは自分の体験について肯定的なレビューを残しています。</reasoning>
        <intent>サポート、フィードバック、苦情</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        例9の入力:
        <request>あなたのウェブサイトは画面全体をブロックする広告ポップアップを送り続けています。苦情を言うための電話番号を見つけるのに20分もかかりました。これらすべてのポップアップで、どうやって自分のアカウント情報にアクセスできるでしょうか?あなたのウェブサイトが壊れているので、私のアカウントにアクセスしてもらえますか?ファイルにある住所を知る必要があります。</request>

        例9の出力:
        <reasoning>ユーザーはウェブアカウント情報へのアクセスのヘルプを要求しています。</reasoning>
        <intent>サポート、フィードバック、苦情</intent>
        </example 9>

        分類推論を実際の意図出力の前に常に含めることを忘れないでください。推論は<reasoning>タグで囲み、意図は<intent>タグで囲んでください。推論と意図のみを返してください。
        """
このプロンプトの主要コンポーネントを分解してみましょう:
  • Python f-stringsを使用してプロンプトテンプレートを作成し、ticket_contents<request>タグに挿入できるようにしています。
  • Claudeに、チケット内容を注意深く分析して顧客の核となる意図とニーズを決定する分類システムとしての明確に定義された役割を与えています。
  • 適切な出力フォーマットについてClaudeに指示し、この場合は<reasoning>タグ内に推論と分析を提供し、続いて<intent>タグ内に適切な分類ラベルを提供するよう指示しています。
  • 有効な意図カテゴリを指定しています:「サポート、フィードバック、苦情」、「注文追跡」、「返金・交換」。
  • 出力がどのようにフォーマットされるべきかを説明するためにいくつかの例(いわゆるfew-shotプロンプティング)を含めており、これにより精度と一貫性が向上します。
Claudeの応答を様々なXMLタグセクションに分割したい理由は、正規表現を使用して出力から推論と意図を別々に抽出できるようにするためです。これにより、チケットルーティングワークフローで対象を絞った次のステップを作成できます。例えば、意図のみを使用してチケットをどの人にルーティングするかを決定することができます。

プロンプトをデプロイする

テスト本番環境でプロンプトをデプロイし、評価を実行することなしに、プロンプトがどれだけうまく機能するかを知ることは困難です。 デプロイ構造を構築しましょう。Claudeへの呼び出しをラップするメソッドシグネチャを定義することから始めます。すでに書き始めたメソッドを取り、ticket_contentsを入力とし、出力としてreasoningintentのタプルを返すようにします。従来のMLを使用した既存の自動化がある場合は、代わりにそのメソッドシグネチャに従う必要があります。
import anthropic
import re

# Claude APIクライアントのインスタンスを作成
client = anthropic.Anthropic()

# デフォルトモデルを設定
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(ticket_contents):
    # 分類タスクのプロンプトを定義
    classification_prompt = f"""あなたはカスタマーサポートチケット分類システムとして動作します。
        ...
        ... 推論は<reasoning>タグで囲み、意図は<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
このコードは:
  • AnthropicライブラリをインポートしAPIキーを使用してクライアントインスタンスを作成します。
  • ticket_contents文字列を受け取るclassify_support_request関数を定義します。
  • classification_promptを使用して分類のためにticket_contentsをClaudeに送信します
  • 応答から抽出されたモデルのreasoningintentを返します。
推論と意図のテキスト全体が生成されてから解析する必要があるため、stream=False(デフォルト)に設定します。

プロンプトを評価する

プロンプティングは本番環境に対応するために、多くの場合テストと最適化が必要です。ソリューションの準備状況を判断するために、先ほど確立した成功基準と閾値に基づいてパフォーマンスを評価します。 評価を実行するには、実行するテストケースが必要です。このガイドの残りの部分では、すでにテストケースを開発していることを前提としています。

評価関数を構築する

このガイドの例の評価では、3つの主要な指標に沿ってClaudeのパフォーマンスを測定します:
  • 精度
  • 分類あたりのコスト
あなたにとって重要な要因に応じて、他の軸でClaudeを評価する必要があるかもしれません。 これを評価するために、まず書いたスクリプトを変更し、予測された意図と実際の意図を比較して正しい予測の割合を計算する関数を追加する必要があります。また、コスト計算と時間測定機能も追加する必要があります。
import anthropic
import re

# Claude APIクライアントのインスタンスを作成
client = anthropic.Anthropic()

# デフォルトモデルを設定
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(request, actual_intent):
    # 分類タスクのプロンプトを定義
    classification_prompt = f"""あなたはカスタマーサポートチケット分類システムとして動作します。
        ...
        ...推論は<reasoning>タグで囲み、意図は<intent>タグで囲んでください。推論と意図のみを返してください。
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # 入力と出力トークンがどれだけ使用されたかのAPI呼び出しの使用統計を取得
    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()

    # 推論、意図、正解、使用量を返す
    return reasoning, intent, correct, usage
行った編集を分解してみましょう:
  • テストケースからactual_intentclassify_support_requestメソッドに追加し、Claudeの意図分類が私たちのゴールデン意図分類と一致するかどうかを評価するための比較を設定しました。
  • 使用された入力と出力トークンに基づいてコストを計算するために、API呼び出しの使用統計を抽出しました

評価を実行する

適切な評価には、何が良い結果かを判断するための明確な閾値とベンチマークが必要です。上記のスクリプトは精度、応答時間、分類あたりのコストのランタイム値を提供しますが、明確に確立された閾値が必要です。例えば:
  • 精度: 95%(100テスト中)
  • 分類あたりのコスト: 現在のルーティング方法から平均50%削減(100テスト全体で)
これらの閾値を持つことで、大規模かつ公平な経験主義で、どの方法が最適で、要件により適合するためにどのような変更が必要かもしれないかを迅速かつ簡単に判断できます。

パフォーマンスを向上させる

複雑なシナリオでは、標準的なプロンプトエンジニアリング技術ガードレール実装戦略を超えて、パフォーマンスを向上させるための追加戦略を検討することが有用な場合があります。以下は一般的なシナリオです:

20以上の意図カテゴリがある場合は分類階層を使用する

クラス数が増加するにつれて、必要な例の数も拡大し、プロンプトが扱いにくくなる可能性があります。代替として、分類器の混合を使用した階層分類システムの実装を検討できます。
  1. 意図を分類学的ツリー構造で整理します。
  2. ツリーのすべてのレベルで一連の分類器を作成し、カスケードルーティングアプローチを可能にします。
例えば、チケットを「技術的問題」、「請求に関する質問」、「一般的な問い合わせ」に大まかに分類するトップレベル分類器を持つことができます。これらの各カテゴリは、分類をさらに絞り込むための独自のサブ分類器を持つことができます。
  • 長所 - より大きなニュアンスと精度: 各親パスに対して異なるプロンプトを作成でき、より対象を絞った文脈固有の分類が可能になります。これにより精度が向上し、顧客リクエストのより細かい処理が可能になります。
  • 短所 - 遅延の増加: 複数の分類器は遅延の増加につながる可能性があることに注意してください。最速のモデルであるHaikuでこのアプローチを実装することをお勧めします。

高度に可変なチケットを処理するためにベクトルデータベースと類似性検索取得を使用する

例を提供することがパフォーマンスを向上させる最も効果的な方法であるにもかかわらず、サポートリクエストが高度に可変である場合、単一のプロンプトに十分な例を含めることが困難な場合があります。 このシナリオでは、ベクトルデータベースを使用して例のデータセットから類似性検索を行い、特定のクエリに最も関連する例を取得することができます。 分類レシピで詳しく説明されているこのアプローチは、パフォーマンスを71%の精度から93%の精度に向上させることが示されています。

予想されるエッジケースを具体的に考慮する

Claudeがチケットを誤分類する可能性があるシナリオをいくつか示します(あなたの状況に固有の他のものもあるかもしれません)。これらのシナリオでは、Claudeがエッジケースをどのように処理すべきかについて、プロンプトで明示的な指示や例を提供することを検討してください:
顧客はしばしば間接的にニーズを表現します。例えば、「パッケージを2週間以上待っています」は注文状況の間接的なリクエストかもしれません。
  • 解決策: Claudeにこの種のリクエストの実際の顧客例と、基礎となる意図が何であるかを提供してください。特に微妙なチケット意図について分類根拠を含めると、Claudeが他のチケットにロジックをより良く一般化できるため、さらに良い結果を得ることができます。
顧客が不満を表現する際、Claudeは基礎となる問題を解決することよりも感情に対処することを優先する場合があります。
  • 解決策: 顧客の感情を優先するかどうかについてClaudeに指示を提供してください。「すべての顧客の感情を無視してください。顧客のリクエストの意図と顧客が求めている可能性のある情報の分析にのみ焦点を当ててください。」のような簡単なものでも構いません。
顧客が単一のやり取りで複数の問題を提示する場合、Claudeは主要な懸念を特定するのに困難を感じる場合があります。
  • 解決策: Claudeが抽出された意図をより良くランク付けし、主要な懸念を特定できるように、意図の優先順位付けを明確にしてください。

Claudeをより大きなサポートワークフローに統合する

適切な統合には、Claudeベースのチケットルーティングスクリプトがより大きなチケットルーティングシステムのアーキテクチャにどのように適合するかについていくつかの決定を行う必要があります。これを行う方法は2つあります:
  • プッシュベース: 使用しているサポートチケットシステム(例:Zendesk)がWebhookイベントをルーティングサービスに送信することでコードをトリガーし、その後意図を分類してルーティングします。
    • このアプローチはよりWebスケーラブルですが、パブリックエンドポイントを公開する必要があります。
  • プルベース: コードが指定されたスケジュールに基づいて最新のチケットをプルし、プル時にルーティングします。
    • このアプローチは実装が簡単ですが、プル頻度が高すぎる場合はサポートチケットシステムへの不要な呼び出しを行う可能性があり、プル頻度が低すぎる場合は過度に遅くなる可能性があります。
これらのアプローチのいずれについても、スクリプトをサービスでラップする必要があります。アプローチの選択は、サポートチケットシステムが提供するAPIによって決まります。