SaaS 客戶支援自動化的微調 AI

你的支援團隊每天處理 500 張工單。六個月前你部署了一個基於 RAG 的 AI 聊天機器人。它自動解決 34% 的傳入工單。其餘 66% 仍然落在人工代理的桌面上。

這個 34% 的數字並不罕見。這大概是大多數團隊在檢索增強生成上看到的結果：機器人找到相關文件、拼湊答案，大約三分之一的時間是正確的。對其餘的，回應要麼太通用、錯過了上下文，要麼完全錯誤——所以工單升級。

微調改變了這個計算。在你實際已解決對話上訓練的模型——你的產品術語、你的升級規則、你的邊緣案例——將自動解決率推升至 87%。這不是理論上的上限。這是特定領域微調模型在支援分類和回應生成任務上一貫達到的數字。

以下是如何達到那裡。

為何通用模型在客戶支援上失敗

在談到微調之前，值得準確了解基於 RAG 的支援機器人在哪裡失敗。失敗模式是具體且可預測的。

它們不了解你的產品語言

你的 SaaS 有自己的詞彙。「工作區」在 Notion vs Slack vs 你的產品中有不同的含義。「席位」可能表示用戶授權，或者在你的領域中可能表示完全不同的東西。通用模型猜測。微調模型知道。

客戶寫道：「我無法在我的團隊計劃中添加更多席位。」通用模型檢索有關團隊管理的文件，並給出通用的演示說明。微調模型知道「席位」在你的產品中表示活躍授權，團隊計劃上限為 10，客戶可能需要升級到商業版——並相應地回應。

它們無法遵循你的升級規則

每個支援組織都有升級邏輯。超過 500 美元的帳單爭議交給高級代理。與安全相關的工單獲得優先路由。企業客戶獲得不同的 SLA。RAG 機器人不編碼這種邏輯——它們檢索文件並希望答案包含正確的流程。

微調模型從資料中學習你的升級模式。它們見過數百個帳單爭議被路由到帳單團隊、安全報告被標記為緊急、企業客戶獲得特定回應模板的範例。

它們給出通用回應

關於 AI 支援機器人最常見的抱怨：「它聽起來像在讀 FAQ。」那是因為它字面上就是這樣。RAG 檢索類似 FAQ 的內容並轉述。回應缺乏具體性，錯過了用戶的實際情況，感覺不夠個人化。

微調模型生成的回應符合你最優秀人工代理的語氣、具體性和結構——因為它們是在這些代理的實際回應上訓練的。

從你的支援平台中擷取訓練資料

你已經有了訓練資料。它就在你的 Intercom、Zendesk、Freshdesk 或 Help Scout 實例中。問題是如何擷取和格式化它。

從 Intercom

Intercom 的 Export API 給你帶有對話部分的對話物件。每次對話有初始用戶訊息、代理回覆和解決狀態。以下是你想擷取的：

對每次已解決的對話：
  - 用戶的初始訊息 → 輸入
  - 代理的解決訊息 → 目標輸出
  - 分配的標籤/類別 → 意圖標籤
  - 解決時間 → 品質信號（越快 = 代理越好）

使用 Intercom API 拉取帶有 state: closed 的對話，並過濾代理（而非機器人）解決的對話。以以下格式匯出為 JSONL：

{"messages": [
  {"role": "user", "content": "I upgraded to Pro but my storage limit still shows 5GB"},
  {"role": "assistant", "content": "I can see your account was upgraded to Pro on Feb 12. The storage limit update can take up to 15 minutes to propagate. I've manually triggered a sync on your account — please log out and back in, and you should see your 50GB limit reflected. Let me know if it doesn't update within the next few minutes."}
]}

從 Zendesk

Zendesk 的增量工單匯出端點是你的好幫手。拉取 status: solved 或 status: closed 的工單。擷取初始工單描述和代理的解決回覆。Zendesk 標籤直接映射到意圖標籤。

# 拉取過去 90 天的已解決工單
curl "https://yourcompany.zendesk.com/api/v2/incremental/tickets.json?start_time=1732000000" \
  -H "Authorization: Bearer $ZENDESK_TOKEN" | \
  jq '.tickets[] | select(.status == "solved")'

「好的」訓練資料是什麼樣的

並非每張已解決的工單都是好的訓練資料。過濾：

• 確認解決：客戶積極回覆或工單標記為滿意
• 單輪解決：代理一次回覆就解決了（這些是最清晰的信號）
• 一致的代理：從滿意度分數最高的 3-5 名代理中拉取
• 多樣化意圖：涵蓋你的 20-30 個工單類別，而不只是最常見的一個

丟棄：

• 需要多次來回交流的工單（嘈雜的信號）
• 在沒有真正答案的情況下通過關閉解決的工單
• 代理粘貼宏但沒有任何定制的對話
• 無法匿名化的包含個人身份資訊的對話

一個好的起始資料集是跨你的 20 個意圖類別的 500-1,000 個對話配對。每個類別大約 25-50 個範例。

支援機器人管道

微調後的支援機器人不是單個模型。它是一個三階段管道，每個階段處理不同的任務。

階段 1：意圖分類

每張傳入工單都被分類到意圖類別。這決定接下來發生什麼。

模型： 微調分類器（1B-3B 參數模型已足夠） 訓練資料： 跨你意圖分類法的 200 個以上已標記範例 輸出： 意圖標籤 + 置信度分數

輸入：「我的一月份訂閱被重複收費了」
輸出：{ intent: "billing_duplicate_charge", confidence: 0.94 }

這個分類器在 50ms 以內運行，處理路由邏輯。對已知意圖高置信度？自動回應。低置信度或敏感類別？路由到人工。

階段 2：回應生成

對自動回應適當的意圖，微調後的回應模型生成回覆。

模型： 微調 7B-8B 模型（Llama 3.1 8B 或 Qwen 2.5 7B 效果很好） 訓練資料： 500 個以上已解決的對話配對 輸出： 帶有特定產品詳細資訊的代理品質回應

這是 RAG 和微調之間品質差異最明顯的地方。微調模型不只是檢索資訊——它以你支援團隊的聲音生成回應，帶有正確的詳細程度，正確地使用你的產品術語。

階段 3：升級評分

每個自動生成的回應在發送之前都獲得升級分數。這是一個單獨的微調模型（或回應模型上的分類頭），預測回應是否真的會解決問題。

模型： 微調分類器 訓練資料： 300 個以上標記為「已解決」vs「需要升級」的回應範例 輸出： 置信度分數（0-1）

如果升級分數低於你的閾值（通常 0.75-0.85），工單路由到人工代理，附上 AI 生成的草稿。代理可以使用、編輯或丟棄它。

基準測試：RAG 聊天機器人 vs 微調模型

以下是實際數字。這些指標來自處理每天 300-800 張工單的 B2B SaaS 產品的支援自動化部署。

自動解決率從 34% 跳至 87% 是頭條數字。但誤報率可以說更重要——糟糕的自動回應比沒有自動回應更差。微調模型將誤報從 18% 削減到 3.1%，因為它們學習了何時有足夠信心回應，何時升級。

要微調什麼（以及需要多少資料）

你不為所有事情微調單個模型。你微調三個專門的模型，每個有不同的資料需求。

1. 意圖分類模型

目的： 將傳入工單分類到你的意圖分類法 所需資料： 200 個以上已標記範例（每個意圖類別 10 個以上） 基礎模型： Qwen 2.5 1.5B 或 Llama 3.2 1B（小型模型擅長分類） 訓練時間： 在單個 GPU 上約 15 分鐘

意圖分類器是最容易訓練的，且提供最高的即時 ROI。即使你不自動回應任何事情，準確的意圖分類單獨就能改善路由並減少代理處理時間。

2. 回應生成模型

目的： 為可自動解決的工單生成代理品質的回應 所需資料： 500 個以上已解決的對話配對 基礎模型： Llama 3.1 8B 或 Qwen 2.5 7B（需要足夠的能力進行細緻的生成） 訓練時間： 在單個 GPU 上約 45 分鐘

這是最難做對的模型，因為回應品質是主觀的。從你評分最高的代理的已解決對話開始。微調、在保留的測試集上評估、迭代。

3. 升級評分模型

目的： 預測自動生成的回應是否真的會解決問題 所需資料： 300 個以上標記為「成功解決」vs「需要人工跟進」的範例 基礎模型： Qwen 2.5 1.5B（分類任務，小型模型有效） 訓練時間： 在單個 GPU 上約 15 分鐘

這個模型是你的安全網。它防止糟糕的自動回應到達客戶。根據你對誤報的容忍度調整置信度閾值。

成本比較：Intercom Fin vs 微調模型

讓我們談談錢。Intercom Fin 每次解決收費 $0.99。這個定價聽起來合理，直到你按規模計算。

場景：每天 500 張工單

微調模型以低 98% 的成本解決多 74% 的工單。而且成本不隨數量擴展——如果你每天從 500 張增加到 5,000 張工單，Intercom Fin 從每年 $89K 增至 $890K。你的自託管模型保持在大約每月 $150-300。

構建管道：逐步說明

以下是具體的實施路徑，從零到生產支援自動化。

第 1-2 週：資料擷取和準備

1. 從你的支援平台匯出 90 天的已解決對話
2. 過濾帶有正向客戶評分的單輪解決
3. 按你的意圖分類法分類（20-30 個類別）
4. 格式化為 JSONL 訓練文件（分類、生成、升級的單獨文件）
5. 按 80/10/10 分割為訓練/驗證/測試

第 3 週：微調

1. 在已標記工單上微調意圖分類器（Qwen 2.5 1.5B，約 15 分鐘）
2. 在對話配對上微調回應生成器（Llama 3.1 8B，約 45 分鐘）
3. 在解決結果資料上微調升級評分器（Qwen 2.5 1.5B，約 15 分鐘）
4. 在保留的測試集上評估所有三個模型

第 4 週：整合和測試

1. 構建分類 → 生成 → 評分管道
2. 連接到你的支援平台 API（Intercom、Zendesk 等）
3. 以影子模式運行：模型生成回應但不發送
4. 讓代理對 5 天的 AI 回應評分——測量對比實際情況的準確率

第 5 週：逐步推出

1. 僅對最高置信度工單啟用自動回應（0.95 以上閾值）
2. 每日監控誤報率
3. 隨著準確率被確認，每週將閾值降低 0.05
4. 目標在 4-6 週內達到 0.80-0.85 的穩定閾值

持續：每月重新訓練

1. 從代理更正和升級中收集新的訓練範例
2. 附加到訓練集
3. 每月重新訓練所有三個模型
4. 在升至生產環境之前，對比之前的模型版本進行評估

---

延伸閱讀

• Fine-Tune a Support Bot for Your Lovable App — 為獨立應用程式構建微調支援機器人的逐步指南
• Fine-Tuned vs. RAG: Which Approach Wins for Client Projects? — 生產使用案例中檢索增強生成 vs 微調的深度比較
• Adding AI Features to Your SaaS Without an ML Team — 產品團隊如何使用微調而非 ML 雇用來部署 AI 功能