以下是一些關鍵指標,表明您應該使用 Claude 等 LLM,而不是傳統 ML 方法進行分類任務:
在深入自動化之前,了解您現有的工單系統至關重要。首先調查您的支援團隊目前如何處理工單路由。
考慮以下問題:
您對人類如何處理某些情況的了解越多,您就越能夠與 Claude 合作完成任務。
明確定義的用戶意圖類別列表對於使用 Claude 進行準確的支援工單分類至關重要。Claude 在您系統內有效路由工單的能力與您系統類別的定義程度成正比。
以下是一些用戶意圖類別和子類別的示例。
除了意圖外,工單路由和優先級可能還受到其他因素的影響,例如緊急程度、客戶類型、SLA 或語言。在構建自動化路由系統時,請務必考慮其他路由標準。
與您的支援團隊合作定義明確的成功標準,包括可測量的基準、閾值和目標。
以下是使用 LLM 進行支援工單路由時的一些標準標準和基準:
以下是一些常見的成功標準,無論是否使用 LLM 都可能有用:
模型的選擇取決於成本、準確度和響應時間之間的權衡。
許多客戶發現 claude-haiku-4-5-20251001 是工單路由的理想模型,因為它是 Claude 4 系列中最快且最具成本效益的模型,同時仍能提供優異的結果。如果您的分類問題需要深入的主題專業知識或大量的意圖類別複雜推理,您可以選擇更大的 Sonnet 模型。
工單路由是一種分類任務。Claude 分析支援工單的內容,並根據問題類型、緊急程度、所需專業知識或其他相關因素將其分類為預定義的類別。
讓我們編寫一個工單分類提示。我們的初始提示應包含用戶請求的內容,並返回推理和意圖。
在 Claude 控制台上嘗試提示生成器,讓 Claude 為您編寫初稿。
以下是一個工單路由分類提示的示例:
def classify_support_request(ticket_contents):
# Define the prompt for the classification task
classification_prompt = f"""You will be acting as a customer support ticket classification system. Your task is to analyze customer support requests and output the appropriate classification intent for each request, along with your reasoning.
Here is the customer support request you need to classify:
<request>{ticket_contents}</request>
Please carefully analyze the above request to determine the customer's core intent and needs. Consider what the customer is asking for has concerns about.
First, write out your reasoning and analysis of how to classify this request inside <reasoning> tags.
Then, output the appropriate classification label for the request inside a <intent> tag. The valid intents are:
<intents>
<intent>Support, Feedback, Complaint</intent>
<intent>Order Tracking</intent>
<intent>Refund/Exchange</intent>
</intents>
A request may have ONLY ONE applicable intent. Only include the intent that is most applicable to the request.
As an example, consider the following request:
<request>Hello! I had high-speed fiber internet installed on Saturday and my installer, Kevin, was absolutely fantastic! Where can I send my positive review? Thanks for your help!</request>
Here is an example of how your output should be formatted (for the above example request):
<reasoning>The user seeks information in order to leave positive feedback.</reasoning>
<intent>Support, Feedback, Complaint</intent>
Here are a few more examples:
<examples>
<example 2>
Example 2 Input:
<request>I wanted to write and personally thank you for the compassion you showed towards my family during my father's funeral this past weekend. Your staff was so considerate and helpful throughout this whole process; it really took a load off our shoulders. The visitation brochures were beautiful. We'll never forget the kindness you showed us and we are so appreciative of how smoothly the proceedings went. Thank you, again, Amarantha Hill on behalf of the Hill Family.</request>
Example 2 Output:
<reasoning>User leaves a positive review of their experience.</reasoning>
<intent>Support, Feedback, Complaint</intent>
</example 2>
<example 3>
...
</example 8>
<example 9>
Example 9 Input:
<request>Your website keeps sending ad-popups that block the entire screen. It took me twenty minutes just to finally find the phone number to call and complain. How can I possibly access my account information with all of these popups? Can you access my account for me, since your website is broken? I need to know what the address is on file.</request>
Example 9 Output:
<reasoning>The user requests help accessing their web account information.</reasoning>
<intent>Support, Feedback, Complaint</intent>
</example 9>
Remember to always include your classification reasoning before your actual intent output. The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""讓我們分解此提示的關鍵組件:
ticket_contents 插入到 <request> 標籤中。<reasoning> 標籤內提供其推理和分析,然後在 <intent> 標籤內提供適當的分類標籤。我們希望 Claude 將其響應分成各種 XML 標籤部分的原因是,我們可以使用正則表達式從輸出中分別提取推理和意圖。這允許我們在工單路由工作流中創建有針對性的後續步驟,例如僅使用意圖來決定將工單路由給誰。
在不在測試生產環境中部署提示並運行評估的情況下,很難知道您的提示效果如何。
讓我們構建部署結構。首先定義方法簽名以包裝我們對 Claude 的調用。我們將採用已經開始編寫的方法,該方法以 ticket_contents 作為輸入,現在返回 reasoning 和 intent 的元組作為輸出。如果您有使用傳統 ML 的現有自動化,您應該改為遵循該方法簽名。
import anthropic
import re
# Create an instance of the Claude API client
client = anthropic.Anthropic()
# Set the default model
DEFAULT_MODEL="claude-haiku-4-5-20251001"
def classify_support_request(ticket_contents):
# Define the prompt for the classification task
classification_prompt = f"""You will be acting as a customer support ticket classification system.
...
... The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the 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此代碼:
classify_support_request 函數,該函數接受 ticket_contents 字符串。classification_prompt 將 ticket_contents 發送給 Claude 進行分類reasoning 和 intent。由於我們需要等待整個推理和意圖文本生成後才能解析,我們設置 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-haiku-4-5-20251001"
def classify_support_request(request, actual_intent):
# Define the prompt for the classification task
classification_prompt = f"""You will be acting as a customer support ticket classification system.
...
...The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the 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 的意圖分類是否與我們的黃金意圖分類相匹配。適當的評估需要明確的閾值和基準來確定什麼是好的結果。上面的腳本將為我們提供準確度、響應時間和每次分類成本的運行時值,但我們仍然需要明確建立的閾值。例如:
有了這些閾值,您可以快速輕鬆地大規模判斷,並以公正的經驗主義判斷,什麼方法最適合您,以及可能需要做什麼改變以更好地適應您的要求。
在複雜的場景中,除了標準提示工程技術和護欄實現策略之外,考慮其他策略來改進效能可能會有幫助。以下是一些常見場景:
隨著類別數量的增加,所需示例的數量也會增加,可能使提示變得笨重。作為替代方案,您可以考慮使用分類器混合實現分層分類系統。
例如,您可能有一個頂級分類器,將工單廣泛分類為"技術問題"、"計費問題"和"一般查詢"。這些類別中的每一個都可以有自己的子分類器來進一步細化分類。

優點 - 更大的細微差別和準確度: 您可以為每個父路徑創建不同的提示,允許更有針對性和上下文特定的分類。這可以導致改進的準確度和對客戶請求的更細緻的處理。
缺點 - 增加的延遲: 請注意,多個分類器可能導致延遲增加,我們建議使用我們最快的模型 Haiku 實現此方法。
儘管提供示例是改進效能的最有效方式,但如果支援請求高度可變,很難在單個提示中包含足夠的示例。
在這種情況下,您可以使用向量數據庫從示例數據集進行相似性搜索,並為給定查詢檢索最相關的示例。
這種方法在我們的分類配方中詳細概述,已被證明可以將效能從 71% 準確度提高到 93% 準確度。
以下是 Claude 可能誤分類工單的一些場景(可能還有其他對您的情況獨特的場景)。在這些場景中,考慮在提示中提供明確的指示或示例,說明 Claude 應如何處理邊界情況:
適當的集成需要您做出一些決策,關於您基於 Claude 的工單路由腳本如何適應您更大的工單路由系統的架構。有兩種方式可以做到這一點:
對於這兩種方法中的任何一種,您都需要將腳本包裝在服務中。方法的選擇取決於您的支援工單系統提供的 API。