使用微調本地模型構建可靠的 AI 代理：完整指南

每個自動化平台現在都有「AI 代理」。每個工作流程構建器、每個 CRM、每個內部工具。幾乎所有工具的工作方式都相同：將用戶消息發送給 GPT-4，解析結構化響應，執行工具，返回結果。

它起作用。直到不起作用為止。

在每天 100 次代理互動時，偶爾的失敗很煩人。在 10,000 次時，這是可靠性危機。在 100,000 次時，您每月花費 $3,000–$9,000 在 API 調用上，但仍然面臨 3–5% 的失敗率，這在您的工作流程中級聯傳播。

有更好的方法。在您的特定代理任務上微調一個小模型。它在本地運行，在基礎設施之後每次查詢零成本，並且在您的代理實際執行的狹窄任務集上比 GPT-4 更可靠。

本指南涵蓋完整架構：為什麼它有效、何時無效、成本是多少以及如何構建它。

為什麼前沿模型對代理任務來說過於強大

看看 AI 代理在典型互動中實際做了什麼：

1. 分類意圖 -- 哪個工具（5–50 個選項中）匹配用戶消息？
2. 提取參數 -- 從自然語言中提取結構化資料（JSON）
3. 生成響應 -- 將工具的輸出格式化為人類可讀的回覆

步驟 1 是分類。步驟 2 是結構化提取。步驟 3 是模板化生成。這些都不需要 1.8 萬億參數模型的完整推理能力。它們需要在窄域上的精確度——正是微調小模型擅長的地方。

GPT-4 在新穎推理、多領域綜合和開放式創意任務上非常出色。您的將支援工單路由到 12 個類別之一並提取客戶 ID 的代理不需要這些。

基準測試實際顯示了什麼

微調模型在除廣度之外的每個指標上都勝出。它們在您的工具、您的 schema、您的邊緣案例上進行了訓練。GPT-4 是從一般知識中猜測的。94.2% 的工具選擇精確度聽起來不錯，直到您意識到這意味著每 17 次互動中有 1 次路由到錯誤的工具。

可靠性差距：95% vs 98%

精確度提高 3 個百分點聽起來微不足道。實際上不是。

在 95% 可靠性（典型的 GPT-4 工具調用）下，每 1,000 次互動中有 50 次失敗。在代理工作流程中，代理每次互動進行 3 次工具調用時，完全成功的互動概率降至 0.95 的 3 次方 = 85.7%。

在 98% 可靠性（您的 schema 上的微調模型）下，每 1,000 次互動中有 20 次失敗。同樣的 3 步工作流程成功率為 0.98 的 3 次方 = 94.1%。

這是「大多數時候有效」和「可靠到可以無人監督運行」之間的差距。

為什麼微調模型在您的工具上更可靠

• 沒有幻覺的函數名稱。 模型在訓練期間只見過您的實際工具名稱。它不能在真實名稱是 query_db 時發明 search_database。
• Schema 鎖定的參數。 它在您的確切參數類型的數千個示例上進行了訓練。user_id 始終是整數，因為這是每個訓練示例顯示的。
• 校準的信心。 當模型不確定時，它以特定領域的方式不確定，您可以檢測和處理，而不是以通用模型失敗的不可預測方式。
• 沒有不必要的調用。 它在正確操作是「無工具」的示例上進行了訓練——所以它實際上學會了何時直接響應。

架構：雙模型代理

最可靠的本地代理架構使用兩個微調模型，而不是一個：

用戶消息
    |
    v
[微調路由模型 - 1B–3B 參數]
    |
    |--> 需要工具？ --> 提取工具名稱 + 參數（JSON）
    |                         |
    |                         v
    |                    [工具執行層]
    |                         |
    |                         v
    |                    [微調響應模型 - 7B–8B 參數]
    |                         |
    |                         v
    |                    格式化響應給用戶
    |
    |--> 不需要工具？ --> 從路由模型直接響應

為什麼要兩個模型？

**路由模型（1B–3B 參數）**處理分類和參數提取。它很小，速度很快（15–30ms 延遲），且非常精確，因為它只做一件事：決定調用哪個工具並生成參數。在您的工具 schema 上微調的 Llama 3.2 1B 或 Qwen 2.5 1.5B 就足夠了。

**響應模型（7B–8B 參數）**獲取工具的原始輸出並生成自然語言響應。這需要更多容量，因為響應生成確實比分類更困難。Llama 3.3 8B 或 Qwen 2.5 7B 可以很好地處理這個問題。

為什麼不用一個模型？

您可以使用單個模型執行兩個任務。但分割它們可以給您：

• 更快的路由。 1B 模型在 15ms 內運行。您不用等待 8B 參數來分類意圖。
• 獨立擴展。 如果路由精確度降低，只重新訓練路由器。響應品質問題？只重新訓練響應模型。
• 更低的記憶體佔用。 路由模型可以在 CPU 上運行。只有響應模型需要 GPU。
• 更好的故障隔離。 如果響應模型產生幻覺，工具調用仍然是正確的——您可以重試響應生成而不重新執行工具。

成本比較：雲端 vs 本地代理

以下是每個人都問的數學問題。我們將比較 GPT-4o（代理最常見的選擇）與自托管微調設置。

每次互動成本

規模化月度成本

盈虧平衡點在每月 1,000 到 5,000 次互動之間，具體取決於您的基礎設施成本和平均 token 使用量。低於此水平，API 更便宜。高於此水平，本地推理勝出——差距呈指數級擴大。

在每月 100 萬次互動時，您正在比較 $30K–$90K 的 API 成本與 $200–$500 的專用 GPU 伺服器。這不是最佳化。這是不同的商業模式。

代理模型的微調管道

構建可靠的代理模型不是單次微調運行。這是一個管道。

步驟 1：收集工具調用日誌

如果您已在運行基於雲端的代理，您已經有了訓練資料。導出：

• 用戶消息（輸入）
• 進行的工具調用（工具名稱 + 參數）
• 工具調用是否成功或失敗
• 對用戶的最終響應

每個工具需要 500–2,000 個示例以獲得良好的覆蓋。如果您有 10 個工具，那就是 5,000–20,000 個總示例。對於具有複雜參數提取（日期、嵌套對象、條件字段）的工具，目標是更高端。

步驟 2：格式化為訓練資料

將您的日誌轉換為您的基礎模型期望的聊天完成格式：

{
  "messages": [
    {
      "role": "system",
      "content": "您是一個工具調用代理。可用工具：[schema]"
    },
    {
      "role": "user",
      "content": "檢查客戶 4521 的訂單狀態"
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "function": {
          "name": "get_order_status",
          "arguments": "{\"customer_id\": 4521}"
        }
      }]
    }
  ]
}

關鍵：包含負面示例——不應調用工具的消息。沒有這些，模型學習到始終調用工具。

步驟 3：使用 LoRA 微調

完整微調 7B 模型需要 40 GB 以上的 VRAM 和幾個小時的訓練。LoRA（低秩適應）以一小部分計算獲得 95% 以上的品質：

• 路由模型（1B–3B）： 在單個 GPU 上 10–20 分鐘，LoRA rank 16–32
• 響應模型（7B–8B）： 在單個 GPU 上 30–60 分鐘，LoRA rank 32–64
• 所需 VRAM 總計： 8–16 GB（適合消費者 RTX 4090 或雲端 A10G）

步驟 4：嚴格評估

不要在沒有評估的情況下發布模型。在保留集（您資料的 20%）上測試並測量：

• 工具選擇精確度： 它是否選擇了正確的工具？
• 參數精確匹配： 所有參數的類型和值是否正確？
• JSON 有效性率： 每個輸出是否都是有效的、可解析的 JSON？
• 假陽性率： 它在不應該的時候多久調用工具？
• 延遲 P95： 最壞情況的響應時間是多少？

您的目標：97% 以上的工具選擇，96% 以上的參數匹配，99% 以上的 JSON 有效性，低於 2% 的假陽性率。

步驟 5：部署和監控

在推理伺服器（vLLM、llama.cpp、Ollama）後面部署模型，並將您的代理流量路由到它。從影子部署開始：並行運行雲端模型和本地模型，比較結果，只有在您有信心時才提供本地模型的響應。

五種與本地模型配合良好的代理模式

並非每個代理架構都需要 GPT-4。以下是微調本地模型是正確選擇的五種模式。

模式 1：單工具路由器

做什麼： 將用戶消息路由到固定集合中的一個工具。

示例： 將工單分類到不同類別並路由到正確部門的支援代理。

為什麼本地模型有效： 純分類。在您的特定工單類別上微調的 1B 模型以 99% 以上的精確度處理這個問題，延遲低於 20ms。

模型大小： 1B–3B 參數

模式 2：多工具協調器

做什麼： 從多個工具中選擇並按順序鏈接它們來完成任務。

示例： 「在下週二下午 2 點與 Sarah 預約會議」——需要日曆查詢、可用性檢查、事件創建。

為什麼本地模型有效： 每個步驟仍然是分類 + 參數提取。協調邏輯在您的代碼中，而不是在模型中。模型只是選擇下一個工具。

模型大小： 3B–8B 參數（多步驟規劃需要更多容量）

模式 3：對話代理

做什麼： 處理多輪對話，在需要時調用工具，在不需要時直接響應。

示例： 一個可以檢查系統狀態、重置密碼和創建工單的內部 IT 服務台機器人——或者只是從其訓練資料中回答常見問題。

為什麼本地模型有效： 對話上下文保留在您的領域內。模型不需要世界知識——它需要您公司的具體程序和工具 schema。

模型大小： 7B–8B 參數

模式 4：工作流程自動化代理

做什麼： 位於自動化管道（n8n、Make.com、自定義）內部，在分支點做出決策。

示例： 傳入發票到達。代理對其分類（費用類型），提取關鍵字段（金額、供應商、日期），決定審批路由（500 美元以下自動審批，以上需要經理審核）。

為什麼本地模型有效： 完全結構化。每個輸入和輸出都遵循已知格式。在您實際發票的 1,000 個示例上進行微調可以產生近乎完美的提取。

模型大小： 1B–3B 參數

模式 5：資料提取代理

做什麼： 從非結構化文字——電子郵件、文件、聊天消息——中提取結構化資料。

示例： 從銷售電子郵件中提取交易詳情：公司名稱、交易規模、階段、下一步行動、截止日期。

為什麼本地模型有效： 提取是典型的微調任務。您的模型學習您的特定字段名稱、您的資料格式、您的邊緣案例。不需要提示工程。

模型大小： 3B–7B 參數

何時仍然需要前沿模型

微調本地模型不是萬能的。誠實面對它們的不足之處。

跨領域的新穎推理

如果代理需要從多個不相關領域綜合信息——「將我們 Q3 的法律費用與行業基準進行比較並建議成本最佳化策略」——這需要 7B 模型沒有的廣博知識。

模糊的多領域意圖

當用戶消息可以映射到完全不同領域的工具，且上下文不足以在沒有世界知識的情況下消除歧義時，前沿模型更廣泛的訓練有幫助。

開放式生成

如果代理的主要輸出是長格式的創意或分析寫作（不是結構化工具調用），微調小模型與前沿模型相比會遇到困難。

混合方法

實際答案通常是混合。對可預測、結構化和特定領域的 80–90% 互動使用微調本地模型。將剩餘的 10–20% 通過 API 路由到前沿模型。

這讓您在大部分流量上獲得本地推理的成本節省和可靠性，同時以 GPT-4 作為需要的任務的備用。您的月度 API 費用下降 80–90%，您的平均可靠性提高，因為微調模型更好地處理結構化工作。

用戶消息
    |
    v
[微調路由模型]
    |
    |--> 高信心（超過 0.92）--> 本地工具執行 + 本地響應
    |
    |--> 低信心（低於 0.92）--> 路由到 GPT-4o API --> 雲端執行

信心閾值是可調的。從 0.85 開始，監控備用率，隨著微調模型在更多訓練資料中改進而提高它。

將所有東西放在一起：現實的時間線

以下是第一次部署微調代理的團隊的端到端流程。

瓶頸是資料收集，而不是微調。如果您已經有來自現有代理的乾淨工具調用日誌，您可以將此時間線縮短一半。

延伸閱讀

• 工具調用的微調：用小模型構建可靠的 AI 代理 -- 工具調用微調流程、訓練資料格式和評估指標的深度解析
• 微調本地模型能否替代 GPT-4 進行工具調用？ -- 在真實工具調用任務上比較微調 Llama 和 Qwen 模型與 GPT-4 的頭對頭基準測試
• 邊緣上的 AI 代理：針對離線和氣隙部署的微調模型 -- 如何在沒有互聯網依賴的邊緣硬體上部署代理模型