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

以下は、分類タスクに従来のML手法ではなく、ClaudeのようなLLMを使用すべき主な指標です：

​
LLMサポートワークフローの構築とデプロイ

​
現在のサポートアプローチを理解する

自動化に取り組む前に、既存のチケットシステムを理解することが重要です。まず、サポートチームが現在どのようにチケットルーティングを処理しているかを調査することから始めましょう。

以下のような質問を検討してください：

  • どのような基準でSLA/サービス提供が適用されるかを決定していますか？
  • チケットルーティングは、チケットがどのサポートレベルまたは製品スペシャリストに行くかを決定するために使用されていますか？
  • すでに自動化されたルールやワークフローはありますか？どのような場合に失敗しますか？
  • エッジケースや曖昧なチケットはどのように処理されていますか？
  • チームはどのようにチケットに優先順位をつけていますか？

人間がどのようにして特定のケースを処理しているかについて知れば知るほど、Claudeとともにタスクを行うことがより良くできるようになります。

​
ユーザー意図カテゴリを定義する

明確に定義されたユーザー意図カテゴリのリストは、Claudeによる正確なサポートチケット分類に不可欠です。Claudeがシステム内でチケットを効果的にルーティングする能力は、システムのカテゴリがどれだけ明確に定義されているかに直接比例します。

以下はユーザー意図カテゴリとサブカテゴリの例です。

意図に加えて、チケットのルーティングと優先順位付けは、緊急性、顧客タイプ、SLA、または言語などの他の要因によっても影響を受ける場合があります。自動ルーティングシステムを構築する際には、他のルーティング基準も考慮してください。

​
成功基準を確立する

サポートチームと協力して、測定可能なベンチマーク、しきい値、および目標を持つ明確な成功基準を定義してください。

以下は、サポートチケットルーティングにLLMを使用する際の標準的な基準とベンチマークです：

以下は、LLMが使用されているかどうかに関わらず有用な一般的な成功基準です：

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

モデルの選択は、コスト、精度、応答時間のトレードオフによって異なります。

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

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

チケットルーティングは分類タスクの一種です。Claudeはサポートチケットの内容を分析し、問題のタイプ、緊急性、必要な専門知識、またはその他の関連要因に基づいて、事前定義されたカテゴリに分類します。

チケット分類プロンプトを作成しましょう。初期プロンプトには、ユーザーリクエストの内容を含め、推論と意図の両方を返すようにします。

Anthropic 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>こんにちは！土曜日に高速光ファイバーインターネットを設置してもらいましたが、インストーラーのケビンさんは本当に素晴らしかったです！ポジティブなレビューをどこに送ればいいですか？ご協力ありがとうございます！</request>

        以下は、出力のフォーマット方法の例です（上記の例のリクエストに対して）：
        <reasoning>ユーザーはポジティブなフィードバックを残すための情報を求めています。</reasoning>
        <intent>サポート、フィードバック、苦情</intent>

        さらにいくつかの例を示します：
        <examples>
        <example 2>
        例2の入力：
        <request>先週末の父の葬儀中に私の家族に示してくださった思いやりに対して、個人的にお礼を申し上げたいと思います。スタッフの皆さんはこのプロセス全体を通じて非常に思いやりがあり、助けになりました。それは本当に私たちの肩の重荷を軽くしてくれました。訪問パンフレットは美しかったです。あなたが示してくれた親切さを決して忘れることはなく、進行がどれほどスムーズに進んだかに感謝しています。改めて感謝します。ヒル家を代表してアマランサ・ヒル。</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文字列を使用してプロンプトテンプレートを作成し、ticket_contentsを<request>タグ内に挿入できるようにしています。
  • Claudeに顧客の核心的な意図とニーズを慎重に分析するチケット内容を分類システムとしての明確に定義された役割を与えています。
  • Claudeに適切な出力フォーマットを指示し、この場合は<reasoning>タグ内に理由と分析を提供し、その後に<intent>タグ内に適切な分類ラベルを提供するよう指示しています。
  • 有効な意図カテゴリを指定しています：「サポート、フィードバック、苦情」、「注文追跡」、「返金/交換」。
  • 出力がどのようにフォーマットされるべきかを示すためにいくつかの例（いわゆるfew-shotプロンプティング）を含めており、これにより精度と一貫性が向上します。

Claudeに様々なXMLタグセクションに応答を分割させたい理由は、正規表現を使用して出力から理由と意図を別々に抽出できるようにするためです。これにより、チケットルーティングワークフローで次のステップを対象とすることができます。例えば、チケットをルーティングする人を決定するために意図のみを使用するなどです。

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

テスト生産環境にデプロイして評価を実行せずに、プロンプトがどれだけうまく機能するかを知ることは難しいです。

デプロイ構造を構築しましょう。まず、Claudeへの呼び出しをラップするメソッドシグネチャを定義します。すでに書き始めているメソッドを使用し、入力としてticket_contentsを取り、出力としてreasoningとintentのタプルを返します。従来のMLを使用した既存の自動化がある場合は、代わりにそのメソッドシグネチャに従ってください。

import anthropic
import re

# Anthropic 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に送信します。
  • レスポンスから抽出したreasoningとintentを返します。

生成全体の理由と意図のテキストを解析する前に待つ必要があるため、stream=False（デフォルト）を設定しています。

​
プロンプトを評価する

プロンプティングは、本番環境に対応するためにテストと最適化が必要なことがよくあります。ソリューションの準備状況を判断するには、先に確立した成功基準としきい値に基づいてパフォーマンスを評価します。

評価を実行するには、テストケースが必要です。このガイドの残りの部分では、すでにテストケースを開発していることを前提としています。

​
評価関数を構築する

このガイドの例の評価では、Claudeのパフォーマンスを3つの主要な指標に沿って測定します：

  • 精度
  • 分類あたりのコスト

あなたにとって重要な要素に応じて、他の軸でClaudeを評価する必要があるかもしれません。

これを評価するために、まず私たちが書いたスクリプトを修正し、予測された意図と実際の意図を比較して正確な予測の割合を計算する関数を追加する必要があります。また、コスト計算と時間測定機能も追加する必要があります。

import anthropic
import re

# Anthropic 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()

    # reasoning、intent、correct、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 ベースのチケットルーティングスクリプトがより大きなチケットルーティングシステムのアーキテクチャにどのように適合するかについて、いくつかの決定を行う必要があります。これには2つの方法があります：

  • プッシュベース： 使用しているサポートチケットシステム（例：Zendesk）が、ルーティングサービスにウェブフックイベントを送信することでコードをトリガーし、そのサービスが意図を分類してルーティングします。
    • このアプローチはウェブスケーラビリティが高いですが、パブリックエンドポイントを公開する必要があります。
  • プルベース： コードが特定のスケジュールに基づいて最新のチケットをプルし、プル時にそれらをルーティングします。
    • このアプローチは実装が容易ですが、プル頻度が高すぎると不必要なサポートチケットシステムへの呼び出しが発生したり、プル頻度が低すぎると過度に遅くなる可能性があります。

これらのアプローチのいずれについても、スクリプトをサービスにラップする必要があります。アプローチの選択は、サポートチケットシステムが提供するAPIによって異なります。

分類クックブック

より多くのサンプルコードと詳細な評価ガイダンスについては、分類クックブックをご覧ください。

Anthropic Console

Anthropic Consoleでワークフローの構築と評価を開始しましょう。