以下是一些關鍵指標,可協助您判斷是否應使用像 Claude 這樣的 LLM,而非傳統機器學習方法來執行分類任務:
在深入自動化之前,了解您現有的工單系統至關重要。首先調查您的支援團隊目前如何處理工單分派。
請考慮以下問題:
您對人類如何處理特定案例了解得越多,就越能與 Claude 協作完成任務。
明確定義的使用者意圖類別清單,對於使用 Claude 準確分類支援工單至關重要。Claude 在您系統中有效分派工單的能力,與您系統類別定義的完善程度成正比。
以下是一些使用者意圖類別和子類別的範例。
除了意圖之外,工單分派和優先排序也可能受到其他因素影響,例如緊急程度、客戶類型、SLA 或語言。在建立自動化分派系統時,請務必考慮其他分派標準。
與您的支援團隊合作,定義明確的成功標準,包含可衡量的基準、門檻和目標。
以下是使用 LLM 進行支援工單分派時的一些標準準則和基準:
以下是一些無論是否使用 LLM 都可能有用的常見成功標準:
模型的選擇取決於成本、準確度和回應時間之間的權衡。
許多客戶發現 claude-haiku-4-5-20251001 是工單分派的理想模型,因為它是 Claude 4 系列中最快速且最具成本效益的模型,同時仍能提供出色的結果。如果您的分類問題需要深入的專業知識或大量需要複雜推理的意圖類別,您可以選擇更大的 Sonnet 模型。
工單分派是一種分類任務。Claude 會分析支援工單的內容,並根據問題類型、緊急程度、所需專業知識或其他相關因素,將其分類到預定義的類別中。
讓我們來撰寫一個工單分類提示。我們的初始提示應包含使用者請求的內容,並回傳推理過程和意圖。
試試 Claude Console 上的提示產生器,讓 Claude 為您撰寫初稿。
以下是一個工單分派分類提示的範例:
def classify_support_request(ticket_contents):
# 定義分類任務的提示
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 的元組作為輸出。如果您已有使用傳統機器學習的自動化流程,則應遵循該方法簽章。
import re
# 建立 Claude API 用戶端的實例
client = anthropic.Anthropic()
# 設定預設模型
DEFAULT_MODEL = "claude-haiku-4-5-20251001"
def classify_support_request(ticket_contents):
# 定義分類任務的提示
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.
"""
# 將提示傳送至 API 以分類支援請求。
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
# 使用 Python 的正規表示式函式庫來擷取 `reasoning`。
reasoning_match = re.search(
r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
)
reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
# 同樣地,也擷取 `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 re
# 建立 Claude API 用戶端的實例
client = anthropic.Anthropic()
# 設定預設模型
DEFAULT_MODEL = "claude-haiku-4-5-20251001"
def classify_support_request(request, actual_intent):
# 定義分類任務的提示
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
# 使用 Python 的正規表示式函式庫來擷取 `reasoning`。
reasoning_match = re.search(
r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
)
reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
# 同樣地,也擷取 `intent`。
intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
intent = intent_match.group(1).strip() if intent_match else ""
# 檢查模型的預測是否正確。
correct = actual_intent.strip() == intent.strip()
# 回傳 reasoning、intent、correct 與 usage。
return reasoning, intent, correct, usage讓我們分解所做的修改:
actual_intent 加入 classify_support_request 方法中,並設定比較以評估 Claude 的意圖分類是否與我們的標準意圖分類相符。適當的評估需要明確的門檻和基準來判斷什麼是好的結果。上述腳本為我們提供了準確度、回應時間和每次分類成本的執行時數值,但我們仍需要明確建立的門檻。例如:
有了這些門檻,您就能以公正的實證方式,快速輕鬆地大規模判斷哪種方法最適合您,以及可能需要進行哪些變更以更符合您的需求。
在複雜的情境中,除了標準的提示工程技術和防護措施實作策略之外,考慮其他策略來提升效能可能會有所幫助。以下是一些常見情境:
隨著類別數量增加,所需的範例數量也會擴大,可能使提示變得難以管理。作為替代方案,您可以考慮使用混合分類器來實作階層式分類系統。
例如,您可能有一個頂層分類器,將工單大致分類為「技術問題」、「帳單問題」和「一般查詢」。然後,這些類別中的每一個都可以有自己的子分類器,以進一步細化分類。

優點 - 更細緻且更準確: 您可以為每個父路徑建立不同的提示,實現更具針對性和情境特定的分類。這可以提高準確度,並更細緻地處理客戶請求。
缺點 - 延遲增加: 請注意,多個分類器可能導致「latency」(延遲)增加,我們建議使用我們最快的模型 Haiku 來實作此方法。
儘管提供範例是提升效能最有效的方法,但如果支援請求變化很大,可能很難在單一提示中包含足夠的範例。
在這種情況下,您可以使用向量資料庫從範例資料集中進行相似度搜尋,並為給定查詢檢索最相關的範例。
這種方法在我們的分類範例中有詳細說明,已被證明可將效能從 71% 的準確度提升至 93%。
以下是 Claude 可能錯誤分類工單的一些情境(可能還有其他您特有的情況)。在這些情境中,請考慮在提示中提供明確的指示或範例,說明 Claude 應如何處理邊緣案例:
適當的整合需要您就基於 Claude 的工單分派腳本如何融入更大的工單分派系統架構做出一些決策。有兩種方式可以做到這一點:
無論採用哪種方法,您都需要將腳本封裝在一個服務中。方法的選擇取決於您的支援工單系統提供哪些 API。
Was this page helpful?