工單路由
本指南說明如何利用 Claude 的進階自然語言理解能力,根據客戶意圖、緊急程度、優先順序、客戶資料等因素大規模分類客戶支援工單。
判斷是否使用 Claude 進行工單路由
以下是一些關鍵指標,可幫助您判斷是否應該使用像 Claude 這樣的 LLM 而非傳統機器學習方法來進行分類任務:
建立和部署您的 LLM 支援工作流程
了解您當前的支援方法
在開始自動化之前,了解您現有的工單系統至關重要。首先調查您的支援團隊目前如何處理工單路由。
考慮以下問題:
- 使用什麼標準來確定應用哪種 SLA/服務?
- 工單路由是否用於確定工單應該分配給哪個支援層級或產品專家?
- 是否已有任何自動化規則或工作流程? 在什麼情況下它們會失效?
- 如何處理邊緣案例或模糊工單?
- 團隊如何確定工單優先順序?
您越了解人類如何處理某些案例,就越能更好地與 Claude 合作完成任務。
定義用戶意圖類別
一個定義明確的用戶意圖類別列表對於使用 Claude 準確分類支援工單至關重要。Claude 在您系統中路由工單的能力與您系統類別的定義程度直接相關。
以下是一些用戶意圖類別和子類別的示例。
除了意圖外,工單路由和優先順序也可能受到其他因素的影響,如緊急程度、客戶類型、SLA 或語言。在建立自動化路由系統時,請務必考慮其他路由標準。
建立成功標準
與您的支援團隊合作,定義明確的成功標準,包括可衡量的基準、閾值和目標。
以下是使用 LLM 進行支援工單路由時的一些標準標準和基準:
以下是一些常見的成功標準,無論是否使用 LLM 都可能有用:
選擇合適的 Claude 模型
模型的選擇取決於成本、準確度和響應時間之間的權衡。
許多客戶發現 claude-3-haiku-20240307
是工單路由的理想模型,因為它是 Claude 3 系列中最快速和最具成本效益的模型,同時仍能提供出色的結果。如果您的分類問題需要深入的專業知識或大量的意圖類別複雜推理,您可能會選擇更大的 Sonnet 模型。
建立強大的提示
工單路由是一種分類任務。Claude 分析支援工單的內容,並根據問題類型、緊急程度、所需專業知識或其他相關因素將其分類到預定義的類別中。
讓我們編寫一個工單分類提示。我們的初始提示應包含用戶請求的內容,並返回推理和意圖。
嘗試使用 Anthropic Console 上的提示生成器,讓 Claude 為您撰寫初稿。
以下是一個工單路由分類提示示例:
讓我們分解這個提示的關鍵組成部分:
- 我們使用 Python f-strings 創建提示模板,允許將
ticket_contents
插入到<request>
標籤中。 - 我們給 Claude 一個明確定義的角色,作為一個仔細分析工單內容以確定客戶核心意圖和需求的分類系統。
- 我們指導 Claude 關於正確的輸出格式,在本例中是在
<reasoning>
標籤內提供其推理和分析,然後在<intent>
標籤內提供適當的分類標籤。 - 我們指定有效的意圖類別:“支援、反饋、投訴”、“訂單追蹤”和”退款/換貨”。
- 我們包含了一些示例(又稱少量提示)來說明輸出應該如何格式化,這可以提高準確性和一致性。
我們希望讓 Claude 將其回應分成各種 XML 標籤部分的原因是,這樣我們可以使用正則表達式從輸出中分別提取推理和意圖。這允許我們在工單路由工作流程中創建有針對性的後續步驟,例如僅使用意圖來決定將工單路由給誰。
部署您的提示
如果不在測試生產環境中部署並運行評估,很難知道您的提示效果如何。
讓我們建立部署結構。首先定義包裝我們對 Claude 調用的方法簽名。我們將繼續編寫已經開始的方法,它以 ticket_contents
作為輸入,現在返回 reasoning
和 intent
的元組作為輸出。如果您有使用傳統機器學習的現有自動化,您會想要遵循該方法簽名。
此代碼:
- 導入 Anthropic 庫並使用您的 API 密鑰創建客戶端實例。
- 定義一個接受
ticket_contents
字符串的classify_support_request
函數。 - 使用
classification_prompt
將ticket_contents
發送給 Claude 進行分類 - 返回從響應中提取的模型的
reasoning
和intent
。
由於我們需要等待生成整個推理和意圖文本才能解析,我們設置 stream=False
(默認值)。
評估您的提示
提示通常需要測試和優化才能準備好用於生產。要確定您的解決方案是否準備就緒,請根據您之前建立的成功標準和閾值評估性能。
要運行您的評估,您需要測試案例來運行它。本指南的其餘部分假設您已經開發了您的測試案例。
建立評估函數
本指南的示例評估沿著三個關鍵指標衡量 Claude 的表現:
- 準確度
- 每次分類的成本
根據對您重要的因素,您可能需要在其他方面評估 Claude。
要評估這一點,我們首先必須修改我們編寫的腳本,添加一個函數來比較預測的意圖與實際意圖並計算正確預測的百分比。我們還必須添加成本計算和時間測量功能。
讓我們分解我們做出的編輯:
- 我們將
actual_intent
從我們的測試案例添加到classify_support_request
方法中,並設置了比較來評估 Claude 的意圖分類是否與我們的黃金意圖分類相匹配。 - 我們提取了 API 調用的使用統計,以根據使用的輸入和輸出令牌計算成本
運行您的評估
適當的評估需要明確的閾值和基準來確定什麼是好的結果。上面的腳本將給我們準確度、響應時間和每次分類成本的運行時值,但我們仍然需要明確建立的閾值。例如:
- 準確度: 95%(100 次測試中)
- 每次分類成本: 與當前路由方法相比平均減少 50%(在 100 次測試中)
有了這些閾值,您就可以快速且輕鬆地以大規模和公正的經驗主義方式判斷哪種方法最適合您,以及可能需要做出哪些改變以更好地滿足您的要求。
提高性能
在複雜的場景中,除了標準的提示工程技術和護欄實施策略之外,考慮其他策略來提高性能可能會有幫助。以下是一些常見場景:
對於 20+ 意圖類別的案例使用分類層次結構
隨著類別數量的增長,所需的示例數量也會擴大,可能使提示變得難以處理。作為替代方案,您可以考慮實施分層分類系統,使用分類器組合。
- 將您的意圖組織成分類樹結構。
- 在樹的每個層級創建一系列分類器,實現級聯路由方法。
例如,您可能有一個頂層分類器,將工單大致分類為”技術問題”、“帳單問題”和”一般查詢”。然後這些類別中的每一個都可以有自己的子分類器來進一步細化分類。
-
優點 - 更大的細微差別和準確度: 您可以為每個父路徑創建不同的提示,允許更有針對性和特定上下文的分類。這可以導致改進的準確度和更細微的客戶請求處理。
-
缺點 - 增加延遲: 請注意,多個分類器可能導致延遲增加,我們建議使用我們最快的模型 Haiku 來實施這種方法。
使用向量數據庫和相似度搜索檢索來處理高度可變的工單
儘管提供示例是提高性能最有效的方式,但如果支援請求高度可變,在單個提示中包含足夠的示例可能很困難。
在這種情況下,您可以使用向量數據庫對示例數據集進行相似度搜索,並檢索與給定查詢最相關的示例。
這種方法在我們的分類配方中有詳細說明,已被證明可以將準確度從 71% 提高到 93%。
專門處理預期的邊緣案例
以下是一些 Claude 可能錯誤分類工單的場景(可能還有其他特定於您情況的場景)。在這些場景中,考慮在提示中提供明確的指示或示例,說明 Claude 應該如何處理邊緣案例:
將 Claude 整合到您的更大支援工作流程中
適當的整合需要您就基於 Claude 的工單路由腳本如何適應您更大的工單路由系統架構做出一些決定。有兩種方法可以做到這一點:
- 推送式: 您使用的支援工單系統(例如 Zendesk)通過向您的路由服務發送 webhook 事件來觸發您的代碼,然後對意圖進行分類並路由。
- 這種方法更具網路可擴展性,但需要您公開一個公共端點。
- 拉取式: 您的代碼根據給定的時間表拉取最新工單並在拉取時路由它們。
- 這種方法更容易實施,但當拉取頻率太高時可能會對支援工單系統進行不必要的調用,或者當拉取頻率太低時可能會過於緩慢。
對於這兩種方法中的任何一種,您都需要將您的腳本包裝在一個服務中。方法的選擇取決於您的支援工單系統提供什麼 API。