工單路由
本指南介紹如何利用Claude的進階自然語言理解能力,根據客戶意圖、緊急程度、優先順序、客戶資料等大規模分類客戶支援工單。
確定是否使用Claude進行工單路由
以下是一些關鍵指標,表明您應該使用像Claude這樣的LLM而非傳統機器學習方法進行分類任務:
構建和部署您的LLM支援工作流程
了解您當前的支援方法
在深入自動化之前,了解您現有的工單系統至關重要。首先調查您的支援團隊目前如何處理工單路由。
考慮以下問題:
- 使用什麼標準來確定應用哪種SLA/服務?
- 工單路由是否用於確定工單分配給哪一級支援或產品專家?
- 是否已經有任何自動化規則或工作流程?在哪些情況下它們會失敗?
- 如何處理邊緣案例或模糊工單?
- 團隊如何對工單進行優先排序?
您對人類如何處理某些案例了解得越多,您就能越好地與Claude合作完成任務。
定義用戶意圖類別
一個定義良好的用戶意圖類別列表對於使用Claude進行準確的支援工單分類至關重要。Claude在您系統中有效路由工單的能力與您系統類別定義的好壞成正比。
以下是一些用戶意圖類別和子類別的示例。
除了意圖外,工單路由和優先順序也可能受到其他因素的影響,如緊急程度、客戶類型、SLA或語言。在構建自動化路由系統時,請確保考慮其他路由標準。
建立成功標準
與您的支援團隊合作,定義明確的成功標準,包括可衡量的基準、閾值和目標。
以下是使用LLM進行支援工單路由時的一些標準標準和基準:
以下是一些常見的成功標準,無論是否使用LLM都可能有用:
選擇合適的Claude模型
模型的選擇取決於成本、準確性和響應時間之間的權衡。
許多客戶發現claude-3-5-haiku-20241022
是工單路由的理想模型,因為它是Claude 3系列中最快速和最具成本效益的模型,同時仍然提供出色的結果。如果您的分類問題需要深入的專業知識或大量的意圖類別複雜推理,您可能會選擇更大的Sonnet模型。
構建強大的提示
工單路由是一種分類任務。Claude分析支援工單的內容,並根據問題類型、緊急程度、所需專業知識或其他相關因素將其分類為預定義的類別。
讓我們編寫一個工單分類提示。我們的初始提示應包含用戶請求的內容,並返回推理和意圖。
嘗試在Anthropic Console上使用提示生成器,讓Claude為您撰寫初稿。
以下是一個工單路由分類提示示例:
讓我們分解這個提示的關鍵組成部分:
- 我們使用Python f-strings創建提示模板,允許將
ticket_contents
插入到<request>
標籤中。 - 我們給Claude一個明確定義的角色,作為一個分類系統,仔細分析工單內容以確定客戶的核心意圖和需求。
- 我們指導Claude關於正確的輸出格式,在這種情況下,在
<reasoning>
標籤內提供其推理和分析,然後在<intent>
標籤內提供適當的分類標籤。 - 我們指定有效的意圖類別:“Support, Feedback, Complaint”、“Order Tracking”和”Refund/Exchange”。
- 我們包含了一些示例(即少量示例提示)來說明輸出應該如何格式化,這提高了準確性和一致性。
我們希望Claude將其回應分成各種XML標籤部分的原因是,這樣我們可以使用正則表達式從輸出中分別提取推理和意圖。這使我們能夠在工單路由工作流程中創建有針對性的下一步,例如僅使用意圖來決定將工單路由給哪個人。
部署您的提示
如果不在測試生產環境中部署並運行評估,很難知道您的提示效果如何。
讓我們構建部署結構。首先定義包裝我們對Claude的調用的方法簽名。我們將繼續編寫已經開始的方法,該方法以ticket_contents
作為輸入,並現在返回reasoning
和intent
的元組作為輸出。如果您有使用傳統ML的現有自動化,您將需要遵循該方法簽名。
此代碼:
- 導入Anthropic庫並使用您的API密鑰創建客戶端實例。
- 定義一個
classify_support_request
函數,該函數接受ticket_contents
字符串。 - 使用
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。