定義是否使用 Claude 進行工單路由

以下是一些關鍵指標,表明您應該使用像 Claude 這樣的 LLM 而不是傳統 ML 方法來處理分類任務:
傳統 ML 流程需要大量標記資料集。Claude 的預訓練模型只需幾十個標記範例就能有效分類工單,大幅減少資料準備時間和成本。
一旦建立了傳統 ML 方法,改變它是一項費力且資料密集的工作。另一方面,隨著您的產品或客戶需求演變,Claude 可以輕鬆適應類別定義的變化或新類別,無需大量重新標記訓練資料。
傳統 ML 模型通常難以處理非結構化資料,需要大量特徵工程。Claude 的先進語言理解能力允許基於內容和上下文進行準確分類,而不是依賴嚴格的本體結構。
傳統 ML 方法通常依賴詞袋模型或簡單模式匹配。當類別由條件而非範例定義時,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 小時以下。
通常通過互動後調查來衡量,這些分數反映客戶對支援流程的整體滿意度。有效的路由有助於提高滿意度。目標是 CSAT 分數達到 90% 或更高,頂級表現者通常達到 95%+ 的滿意度率。
這衡量工單需要升級到更高層支援的頻率。較低的升級率通常表示更準確的初始路由。努力將升級率保持在 20% 以下,頂級系統達到 10% 或更低的率。
此指標查看代理在實施路由解決方案後能夠有效處理多少工單。改進的路由應該提高生產力。通過追蹤每個代理每天或每小時解決的工單來衡量,目標是在實施新路由系統後提高 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):
    # Define the prompt for the classification task
    classification_prompt = f"""您將作為客戶支援工單分類系統。您的任務是分析客戶支援請求,並為每個請求輸出適當的分類意圖以及您的推理。

        以下是您需要分類的客戶支援請求:

        <request>{ticket_contents}</request>

        請仔細分析上述請求以確定客戶的核心意圖和需求。考慮客戶要求什麼或對什麼有擔憂。

        首先,在 <reasoning> 標籤內寫出您對如何分類此請求的推理和分析。

        然後,在 <intent> 標籤內輸出請求的適當分類標籤。有效的意圖是:
        <intents>
        <intent>支援、回饋、投訴</intent>
        <intent>訂單追蹤</intent>
        <intent>退款/換貨</intent>
        </intents>

        一個請求只能有一個適用的意圖。只包含最適用於請求的意圖。

        例如,考慮以下請求:
        <request>您好!我在星期六安裝了高速光纖網路,我的安裝人員 Kevin 非常棒!我可以在哪裡發送我的正面評價?謝謝您的幫助!</request>

        以下是您的輸出應該如何格式化的範例(針對上述範例請求):
        <reasoning>用戶尋求資訊以便留下正面回饋。</reasoning>
        <intent>支援、回饋、投訴</intent>

        以下是更多範例:
        <examples>
        <example 2>
        範例 2 輸入:
        <request>我想寫信親自感謝您在上週末我父親葬禮期間對我家人表現出的同情心。您的員工在整個過程中如此體貼和樂於助人;這真的減輕了我們肩上的負擔。瞻仰手冊很漂亮。我們永遠不會忘記您對我們的善意,我們非常感謝儀式進行得如此順利。再次感謝,Amarantha Hill 代表 Hill 家族。</request>

        範例 2 輸出:
        <reasoning>用戶對他們的體驗留下正面評價。</reasoning>
        <intent>支援、回饋、投訴</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        範例 9 輸入:
        <request>您的網站不斷發送阻擋整個螢幕的廣告彈窗。我花了二十分鐘才終於找到電話號碼來撥打和投訴。在所有這些彈窗的情況下,我怎麼可能存取我的帳戶資訊?您能為我存取我的帳戶嗎,因為您的網站壞了?我需要知道檔案中的地址是什麼。</request>

        範例 9 輸出:
        <reasoning>用戶請求幫助存取他們的網路帳戶資訊。</reasoning>
        <intent>支援、回饋、投訴</intent>
        </example 9>

        記住始終在實際意圖輸出之前包含您的分類推理。推理應該包含在 <reasoning> 標籤中,意圖包含在 <intent> 標籤中。只返回推理和意圖。
        """
讓我們分解這個提示的關鍵組件:
  • 我們使用 Python f-strings 創建提示模板,允許將 ticket_contents 插入到 <request> 標籤中。
  • 我們給 Claude 一個明確定義的角色,作為仔細分析工單內容以確定客戶核心意圖和需求的分類系統。
  • 我們指導 Claude 正確的輸出格式,在這種情況下,在 <reasoning> 標籤內提供其推理和分析,然後在 <intent> 標籤內提供適當的分類標籤。
  • 我們指定有效的意圖類別:“支援、回饋、投訴”、“訂單追蹤”和”退款/換貨”。
  • 我們包含一些範例(即少樣本提示)來說明輸出應該如何格式化,這提高了準確性和一致性。
我們希望 Claude 將其回應分成各種 XML 標籤部分的原因是,我們可以使用正則表達式從輸出中分別提取推理和意圖。這使我們能夠在工單路由工作流程中創建有針對性的下一步,例如僅使用意圖來決定將工單路由給哪個人。

部署您的提示

在沒有在測試生產環境中部署並運行評估的情況下,很難知道您的提示效果如何。 讓我們建立部署結構。首先定義包裝我們對 Claude 調用的方法簽名。我們將採用我們已經開始編寫的方法,該方法以 ticket_contents 作為輸入,現在返回 reasoningintent 的元組作為輸出。如果您有使用傳統 ML 的現有自動化,您將希望遵循該方法簽名。
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"""您將作為客戶支援工單分類系統。
        ...
        ... 推理應該包含在 <reasoning> 標籤中,意圖包含在 <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 金鑰創建客戶端實例。
  • 定義一個接受 ticket_contents 字串的 classify_support_request 函數。
  • 使用 classification_promptticket_contents 發送給 Claude 進行分類
  • 返回從回應中提取的模型的 reasoningintent
由於我們需要等待整個推理和意圖文本生成完成後才能解析,我們設置 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"""您將作為客戶支援工單分類系統。
        ...
        ...推理應該包含在 <reasoning> 標籤中,意圖包含在 <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 的工單路由腳本如何適應您更大的工單路由系統架構做出一些決定。您可以通過兩種方式做到這一點:
  • 推送式: 您使用的支援工單系統(例如 Zendesk)通過向您的路由服務發送 webhook 事件來觸發您的程式碼,然後分類意圖並路由它。
    • 這種方法更具網路可擴展性,但需要您公開一個公共端點。
  • 拉取式: 您的程式碼根據給定的排程拉取最新工單,並在拉取時路由它們。
    • 這種方法更容易實施,但當拉取頻率過高時可能對支援工單系統進行不必要的調用,或當拉取頻率過低時可能過於緩慢。
對於這兩種方法,您都需要將您的腳本包裝在服務中。方法的選擇取決於您的支援工單系統提供什麼 API。