LangGraph 代理的微調模型：在你的代理堆疊中替換 GPT-4

LangGraph 是 2026 年構建有狀態 AI 代理的主流框架。它讓你對代理狀態有明確控制、支援循環和條件分支，並處理更簡單框架無法應對的複雜性。如果你在用 Python 構建生產代理，你可能正在使用 LangGraph 或受其嚴重啟發的東西。

每個 LangGraph 教程的預設模式：ChatOpenAI(model="gpt-4o") 作為推理引擎。每個需要思考、路由、摘要或生成的節點都呼叫 GPT-4。每次呼叫都要花錢。

一個典型的帶有 5 個節點的 LangGraph 代理——路由器、研究員、分析師、回應者、審查員——每次任務執行進行 5-15 次 LLM 呼叫。以 GPT-4o 定價，每次執行花費 $0.05-$0.30。每天運行 1,000 個任務，你每天花費 $50-$300，即每月 $1,500-$9,000。僅推論費用。

這些 LLM 呼叫中的大多數不需要 GPT-4。它們需要一個了解你的特定工具、你的特定路由邏輯和你的特定輸出格式的模型。這就是微調給你的。

分解每個代理節點實際做什麼

LangGraph 代理是節點圖，每個節點執行特定功能。讓我們分類每種節點類型從 LLM 實際需要什麼：

路由器節點（分類）

路由器查看傳入的請求並決定代理應該走哪條路徑。「這是一個帳單問題、技術支援問題還是銷售詢問？」這是一個有固定類別集的分類任務。

GPT-4 在定義明確的類別上的分類準確率：約 95-98%。在相同類別上的微調 8B 模型準確率：約 96-99%。微調模型通常更準確，因為它只在你的類別上訓練，不會幻覺不存在的類別。

工具選擇節點（結構化輸出）

代理決定呼叫哪個工具並生成參數。「呼叫帶 {"query": "refund policy", "category": "billing"} 的 search_knowledge_base。」這是結構化輸出生成——模型需要輸出符合特定 schema 的有效 JSON。

微調模型在這裡表現出色。它們學習你確切的工具名稱、你確切的參數 schema 和你確切的呼叫慣例。不再有幻覺的函數名稱或錯誤的參數類型。詳細分析請見我們的 Fine-Tuning for Tool Calling。

回應生成節點（特定領域文字）

代理根據收集的上下文生成最終回應給用戶。這需要領域知識、適當的語氣和準確的資訊合成。

對於特定領域回應（法律、醫療、金融、客戶支援），在你認可回應語料庫上訓練的微調模型產生比帶系統提示的 GPT-4 更一致的輸出。它不偏移、不幻覺你未認可的免責聲明語言、不在回應之間隨機改變語氣。

狀態摘要節點（壓縮）

在長時間運行的代理中，你會定期摘要對話狀態以適應上下文限制。「以下是最後 20 條訊息。摘要關鍵事實。」這是一個壓縮任務。

在你特定狀態格式上訓練的微調摘要模型產生保留下游節點實際需要欄位的摘要，而不是可能丟失關鍵細節的通用摘要。

複雜推理節點（多步驟邏輯）

「給定這三個資料點，確定客戶是否有資格獲得高級計劃，如果有，計算折扣。」涉及新穎事實組合的多步驟推理。

這是前沿模型仍然值得的地方。複雜的多步驟推理處理新問題是 GPT-4 和 Claude 一致優於微調小模型的一個領域。你無法通過微調達到通用智慧——你只能針對模型見過的模式進行微調。

混合架構

實用的架構不是「用微調模型替換一切」——而是「替換可以微調的一切，為無法替換的保留雲端 API」。

用戶輸入
    │
    ▼
[路由器節點] ← 微調 8B（分類）
    │
    ├── 路徑 A：簡單查詢
    │   └── [回應節點] ← 微調 8B（領域回應）
    │
    ├── 路徑 B：需要工具的查詢
    │   ├── [工具選擇] ← 微調 8B（結構化輸出）
    │   ├── [工具執行] ← 無需 LLM
    │   └── [回應節點] ← 微調 8B（領域回應）
    │
    └── 路徑 C：複雜推理
        └── [分析節點] ← GPT-4o（多步驟推理）
            └── [回應節點] ← 微調 8B（格式化輸出）

在這個架構中，80-90% 的請求遵循路徑 A 或 B——完全由微調模型處理。只有真正複雜的 10-20% 路由到 GPT-4。你的 API 帳單降低 80-90%。

從代理追蹤中獲取訓練資料

LangGraph 讓訓練資料收集變得直接，因為每次執行都產生完整的追蹤記錄——每個節點的輸入和輸出、每個決策、每個工具呼叫。這些追蹤記錄就是你的訓練資料集。

收集追蹤記錄

啟用 LangSmith 追蹤或在每個節點構建自訂記錄：

from langchain_core.tracers import LangChainTracer

# 每次執行都自動記錄
tracer = LangChainTracer(project_name="agent-training-data")
agent.invoke(input, config={"callbacks": [tracer]})

在 GPT-4 上運行你的代理 2-4 週後，你將擁有數千個追蹤的執行記錄。每個追蹤包含每個節點的確切輸入-輸出配對——現成的訓練資料。

過濾和格式化

並非所有追蹤記錄都是好的訓練資料。過濾以下條件：

• 成功執行——代理在沒有錯誤的情況下達成目標
• 乾淨的工具呼叫——沒有因參數格式錯誤而重試
• 正向用戶回饋——如果你收集回饋，對這些追蹤記錄給予更高權重

將每個節點的輸入-輸出配對格式化為訓練範例：

{
  "messages": [
    {"role": "system", "content": "You are a routing agent. Classify the user's request into one of: billing, technical, sales, general."},
    {"role": "user", "content": "I was charged twice for my subscription last month"},
    {"role": "assistant", "content": "billing"}
  ]
}

對工具呼叫節點：

{
  "messages": [
    {"role": "system", "content": "Select the appropriate tool and parameters for the user's request. Available tools: search_kb, create_ticket, get_account_info."},
    {"role": "user", "content": "Look up the refund policy for annual plans"},
    {"role": "assistant", "content": "{\"tool\": \"search_kb\", \"params\": {\"query\": \"refund policy annual plans\", \"category\": \"billing\"}}"}
  ]
}

訓練分離的 LoRA 適配器

為了最大效率，為每種節點類型訓練分離的 LoRA 適配器：

• 路由器適配器： 在路由決策上訓練（小資料集，快速訓練）
• 工具呼叫適配器： 在工具選擇和參數生成上訓練
• 回應適配器： 在特定領域回應生成上訓練
• 摘要適配器： 在狀態壓縮上訓練

每個適配器 50-200MB。你可以按節點熱切換它們，或將最常用的合併到基礎模型中，並按需載入其他的。

每種節點類型 500-1,000 個範例是合理的起點。路由器節點需要較少範例（對 5-10 個類別，200-300 個通常足夠）。回應生成受益於更多（多樣化輸出品質需要 800-1,500 個）。

使用 Ollama 的直接替換

之所以能以最少代碼更改實現這一點：Ollama 暴露了與 OpenAI 兼容的 API。LangGraph 使用 LangChain 的聊天模型介面。將 GPT-4 換成本地模型是一行更改。

之前：

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o", temperature=0)

之後：

from langchain_ollama import ChatOllama
llm = ChatOllama(model="fine-tuned-router", temperature=0)

對混合架構，為不同節點分配不同模型：

router_llm = ChatOllama(model="fine-tuned-router")
tool_llm = ChatOllama(model="fine-tuned-tools")
response_llm = ChatOllama(model="fine-tuned-responder")
reasoning_llm = ChatOpenAI(model="gpt-4o")  # 雲端備用

你的 LangGraph 圖中的每個節點獲得最適合其任務的模型。圖的編排是相同的——只有 LLM 後端改變。

成本影響

讓我們計算一個每天處理 1,000 個任務的客戶支援代理，平均每個任務 8 次 LLM 呼叫：

全部 GPT-4o

• 8,000 次呼叫/天 × 約 2,000 tokens 平均 × ($2.50 + $10)/2M tokens
• 大約每天 $50-$100 → 每月 $1,500-$3,000

混合（80% 本地，20% GPT-4o）

• 6,400 次/天本地呼叫：$0
• 1,600 次/天 GPT-4o 呼叫：每天 $10-$20
• 本地模型的雲端 GPU：每月 $150-$300
• 每月 $450-$900（降低 70%）

全部本地（真正新穎案例使用雲端備用）

• 7,800 次/天本地呼叫：$0
• 200 次/天 GPT-4o 備用：約每天 $2.50
• 雲端 GPU：每月 $150-$300
• 每月 $225-$375（降低 85-90%）

從 100% 雲端到混合的過渡大約需要 3 週：1 週收集追蹤記錄，1 週訓練適配器，1 週測試和部署。從混合到大多數本地是漸進的——隨著從剩餘雲端呼叫收集更多訓練資料，你擴大微調模型的覆蓋範圍。

評估：確保微調代理有效

在生產中部署微調節點之前，進行適當的評估：

1. 保留 20% 的追蹤記錄作為測試資料。 不要在其上訓練。
2. 在測試輸入上運行微調模型，並將輸出與 GPT-4 輸出進行比較。 對路由節點，測量準確率。對工具呼叫節點，測量 schema 合規性和參數準確率。對回應節點，測量語義相似度和事實準確率。
3. 在歷史任務上用微調節點運行完整代理圖。 比較端到端成功率。
4. 影子部署。 在實時流量上同時運行 GPT-4 代理和微調代理，但只提供 GPT-4 回應。記錄微調回應以供比較。當微調代理在 95% 以上的任務上匹配 GPT-4 時，切換過去。

目標指標：

• 路由器準確率：97% 以上（大多數團隊達到 98-99%）
• 工具呼叫 schema 合規性：99% 以上
• 回應品質（人工評分）：在 5 分制上與 GPT-4 相差 0.2 分以內
• 端到端任務成功率：在 GPT-4 代理的 2-3% 以內

何時保留在 GPT-4 上

某些 LangGraph 代理確實需要在整個過程中使用前沿模型：

• 處理真正開放式任務的代理，輸入類型不可預測
• 跨數十個領域運作的代理，你無法構建特定領域的訓練資料
• 早期開發的原型代理，你仍在探索任務結構
• 尾部分佈準確率至關重要的代理（醫療診斷、法律分析），你需要每個案例都使用最強的模型

對大多數生產 LangGraph 代理——客戶支援、資料處理、內容生成、工作流程自動化——以微調本地模型為核心的混合方式以更低的成本提供更好的一致性。

---

延伸閱讀

• Multi-Step AI Agents with Local Models — 如何架構完全在本地推論上運行的多步驟代理工作流程。
• Fine-Tuning for Tool Calling: How to Build Reliable AI Agents with Small Models — 深入探討訓練模型進行結構化工具呼叫輸出。
• Replace GPT-4 with a Local Tool-Calling Model — 在你的代理堆疊中用本地推論替換雲端 API 的逐步指南。