定義是否使用 Claude 進行工單路由
以下是一些關鍵指標,表明您應該使用像 Claude 這樣的 LLM 而不是傳統 ML 方法來處理分類任務:您可用的標記訓練資料有限
您可用的標記訓練資料有限
傳統 ML 流程需要大量標記資料集。Claude 的預訓練模型只需幾十個標記範例就能有效分類工單,大幅減少資料準備時間和成本。
您的分類類別可能會隨時間變化或演進
您的分類類別可能會隨時間變化或演進
一旦建立了傳統 ML 方法,改變它是一項費力且資料密集的工作。另一方面,隨著您的產品或客戶需求演變,Claude 可以輕鬆適應類別定義的變化或新類別,無需大量重新標記訓練資料。
您需要處理複雜的非結構化文本輸入
您需要處理複雜的非結構化文本輸入
傳統 ML 模型通常難以處理非結構化資料,需要大量特徵工程。Claude 的先進語言理解能力允許基於內容和上下文進行準確分類,而不是依賴嚴格的本體結構。
您的分類規則基於語義理解
您的分類規則基於語義理解
傳統 ML 方法通常依賴詞袋模型或簡單模式匹配。當類別由條件而非範例定義時,Claude 在理解和應用底層規則方面表現出色。
您需要分類決策的可解釋推理
您需要分類決策的可解釋推理
許多傳統 ML 模型對其決策過程提供很少洞察。Claude 可以為其分類決策提供人類可讀的解釋,建立對自動化系統的信任,並在需要時促進輕鬆適應。
您希望更有效地處理邊緣案例和模糊工單
您希望更有效地處理邊緣案例和模糊工單
傳統 ML 系統通常難以處理異常值和模糊輸入,經常錯誤分類它們或預設為通用類別。Claude 的自然語言處理能力使其能夠更好地解釋支援工單中的上下文和細微差別,可能減少需要人工干預的錯誤路由或未分類工單數量。
您需要多語言支援而無需維護單獨的模型
您需要多語言支援而無需維護單獨的模型
傳統 ML 方法通常需要為每種支援的語言建立單獨的模型或大量翻譯流程。Claude 的多語言能力使其能夠分類各種語言的工單,無需單獨的模型或大量翻譯流程,簡化對全球客戶群的支援。
建立和部署您的 LLM 支援工作流程
了解您目前的支援方法
在深入自動化之前,了解您現有的工單系統至關重要。首先調查您的支援團隊目前如何處理工單路由。 考慮以下問題:- 使用什麼標準來決定應用什麼 SLA/服務提供?
- 工單路由是否用於決定工單分配給哪一層支援或產品專家?
- 是否已有任何自動化規則或工作流程?在什麼情況下它們會失敗?
- 如何處理邊緣案例或模糊工單?
- 團隊如何優先處理工單?
定義用戶意圖類別
明確定義的用戶意圖類別清單對於使用 Claude 進行準確的支援工單分類至關重要。Claude 在您系統內有效路由工單的能力與您系統類別的明確定義程度成正比。 以下是一些用戶意圖類別和子類別的範例。技術問題
技術問題
- 硬體問題
- 軟體錯誤
- 相容性問題
- 效能問題
帳戶管理
帳戶管理
- 密碼重設
- 帳戶存取問題
- 帳單查詢
- 訂閱變更
產品資訊
產品資訊
- 功能查詢
- 產品相容性問題
- 價格資訊
- 可用性查詢
用戶指導
用戶指導
- 操作問題
- 功能使用協助
- 最佳實務建議
- 故障排除指導
回饋
回饋
- 錯誤報告
- 功能請求
- 一般回饋或建議
- 投訴
訂單相關
訂單相關
- 訂單狀態查詢
- 運送資訊
- 退貨和換貨
- 訂單修改
服務請求
服務請求
- 安裝協助
- 升級請求
- 維護排程
- 服務取消
安全問題
安全問題
- 資料隱私查詢
- 可疑活動報告
- 安全功能協助
合規和法律
合規和法律
- 法規合規問題
- 服務條款查詢
- 法律文件請求
緊急支援
緊急支援
- 關鍵系統故障
- 緊急安全問題
- 時間敏感問題
培訓和教育
培訓和教育
- 產品培訓請求
- 文件查詢
- 網路研討會或工作坊資訊
整合和 API
整合和 API
- 整合協助
- API 使用問題
- 第三方相容性查詢
建立成功標準
與您的支援團隊合作定義明確的成功標準,包括可衡量的基準、閾值和目標。 以下是使用 LLM 進行支援工單路由時的一些標準標準和基準:分類一致性
分類一致性
此指標評估 Claude 隨時間對類似工單分類的一致性。這對於維護路由可靠性至關重要。通過定期使用一組標準化輸入測試模型來衡量,目標是達到 95% 或更高的一致性率。
適應速度
適應速度
這衡量 Claude 適應新類別或變化的工單模式的速度。通過引入新的工單類型並測量模型在這些新類別上達到滿意準確度(例如 >90%)所需的時間來測試。目標是在 50-100 個樣本工單內適應。
多語言處理
多語言處理
這評估 Claude 準確路由多種語言工單的能力。測量不同語言的路由準確度,目標是非主要語言的準確度下降不超過 5-10%。
邊緣案例處理
邊緣案例處理
這評估 Claude 在異常或複雜工單上的表現。創建邊緣案例測試集並測量路由準確度,目標是在這些具有挑戰性的輸入上至少達到 80% 的準確度。
偏見緩解
偏見緩解
這衡量 Claude 在不同客戶人口統計中路由的公平性。定期審核路由決策的潛在偏見,目標是在所有客戶群體中保持一致的路由準確度(在 2-3% 內)。
提示效率
提示效率
在最小化令牌數量至關重要的情況下,此標準評估 Claude 在最少上下文下的表現。測量提供不同數量上下文時的路由準確度,目標是僅使用工單標題和簡短描述就達到 90%+ 的準確度。
可解釋性分數
可解釋性分數
這評估 Claude 對其路由決策解釋的品質和相關性。人類評分員可以按比例(例如 1-5)對解釋進行評分,目標是達到 4 或更高的平均分數。
路由準確度
路由準確度
路由準確度衡量工單在第一次嘗試時正確分配給適當團隊或個人的頻率。這通常以正確路由工單佔總工單的百分比來衡量。行業基準通常目標是 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 為您編寫初稿。
- 我們使用 Python f-strings 創建提示模板,允許將
ticket_contents插入到<request>標籤中。 - 我們給 Claude 一個明確定義的角色,作為仔細分析工單內容以確定客戶核心意圖和需求的分類系統。
- 我們指導 Claude 正確的輸出格式,在這種情況下,在
<reasoning>標籤內提供其推理和分析,然後在<intent>標籤內提供適當的分類標籤。 - 我們指定有效的意圖類別:“支援、回饋、投訴”、“訂單追蹤”和”退款/換貨”。
- 我們包含一些範例(即少樣本提示)來說明輸出應該如何格式化,這提高了準確性和一致性。
部署您的提示
在沒有在測試生產環境中部署並運行評估的情況下,很難知道您的提示效果如何。 讓我們建立部署結構。首先定義包裝我們對 Claude 調用的方法簽名。我們將採用我們已經開始編寫的方法,該方法以ticket_contents 作為輸入,現在返回 reasoning 和 intent 的元組作為輸出。如果您有使用傳統 ML 的現有自動化,您將希望遵循該方法簽名。
- 匯入 Anthropic 庫並使用您的 API 金鑰創建客戶端實例。
- 定義一個接受
ticket_contents字串的classify_support_request函數。 - 使用
classification_prompt將ticket_contents發送給 Claude 進行分類 - 返回從回應中提取的模型的
reasoning和intent。
stream=False(預設值)。
評估您的提示
提示通常需要測試和優化才能準備好投入生產。要確定您解決方案的準備情況,請根據您之前建立的成功標準和閾值評估效能。 要運行您的評估,您需要測試案例來運行它。本指南的其餘部分假設您已經開發了您的測試案例。建立評估函數
我們這個指南的範例評估沿著三個關鍵指標衡量 Claude 的效能:- 準確度
- 每次分類成本
- 我們將測試案例中的
actual_intent添加到classify_support_request方法中,並設置比較以評估 Claude 的意圖分類是否與我們的黃金意圖分類匹配。 - 我們提取 API 調用的使用統計資料,以根據使用的輸入和輸出令牌計算成本
運行您的評估
適當的評估需要明確的閾值和基準來確定什麼是好結果。上述腳本將為我們提供準確度、回應時間和每次分類成本的運行時值,但我們仍然需要明確建立的閾值。例如:- 準確度: 95%(100 次測試中)
- 每次分類成本: 平均比目前路由方法減少 50%(100 次測試中)
改善效能
在複雜場景中,除了標準提示工程技術和護欄實施策略之外,考慮額外策略來改善效能可能會有幫助。以下是一些常見場景:對於 20+ 意圖類別的案例使用分類階層
隨著類別數量的增長,所需範例的數量也會擴展,可能使提示變得笨重。作為替代方案,您可以考慮使用分類器混合實施階層分類系統。- 將您的意圖組織成分類樹結構。
- 在樹的每個層級創建一系列分類器,實現級聯路由方法。

- 優點 - 更大的細微差別和準確度: 您可以為每個父路徑創建不同的提示,允許更有針對性和特定上下文的分類。這可以導致改善的準確度和更細緻的客戶請求處理。
- 缺點 - 增加延遲: 請注意,多個分類器可能導致增加的延遲,我們建議使用我們最快的模型 Haiku 實施此方法。
使用向量資料庫和相似性搜索檢索來處理高度可變的工單
儘管提供範例是改善效能的最有效方法,但如果支援請求高度可變,很難在單個提示中包含足夠的範例。 在這種情況下,您可以使用向量資料庫從範例資料集中進行相似性搜索,並檢索給定查詢最相關的範例。 這種方法在我們的分類食譜中有詳細概述,已被證明可以將效能從 71% 準確度提高到 93% 準確度。專門考慮預期的邊緣案例
以下是 Claude 可能錯誤分類工單的一些場景(可能還有其他對您情況獨特的場景)。在這些場景中,考慮在提示中提供明確的指示或範例,說明 Claude 應該如何處理邊緣案例:客戶提出隱含請求
客戶提出隱含請求
客戶經常間接表達需求。例如,“我已經等我的包裹超過兩週了”可能是對訂單狀態的間接請求。
- 解決方案: 為 Claude 提供一些這類請求的真實客戶範例,以及底層意圖是什麼。如果您為特別細緻的工單意圖包含分類理由,您可以獲得更好的結果,這樣 Claude 可以更好地將邏輯推廣到其他工單。
Claude 優先考慮情緒而非意圖
Claude 優先考慮情緒而非意圖
當客戶表達不滿時,Claude 可能優先處理情緒而非解決底層問題。
- 解決方案: 為 Claude 提供何時優先考慮客戶情緒或不優先考慮的指示。可以簡單如”忽略所有客戶情緒。只專注於分析客戶請求的意圖以及客戶可能要求的資訊。”
多個問題導致問題優先級混亂
多個問題導致問題優先級混亂
當客戶在單次互動中提出多個問題時,Claude 可能難以識別主要關注點。
- 解決方案: 澄清意圖的優先級,以便 Claude 可以更好地排序提取的意圖並識別主要關注點。
將 Claude 整合到您更大的支援工作流程中
適當的整合需要您就基於 Claude 的工單路由腳本如何適應您更大的工單路由系統架構做出一些決定。您可以通過兩種方式做到這一點:- 推送式: 您使用的支援工單系統(例如 Zendesk)通過向您的路由服務發送 webhook 事件來觸發您的程式碼,然後分類意圖並路由它。
- 這種方法更具網路可擴展性,但需要您公開一個公共端點。
- 拉取式: 您的程式碼根據給定的排程拉取最新工單,並在拉取時路由它們。
- 這種方法更容易實施,但當拉取頻率過高時可能對支援工單系統進行不必要的調用,或當拉取頻率過低時可能過於緩慢。