從 n8n 工作流程到微調模型：機構的逐步行動手冊

你的 n8n 工作流程正在為你的客戶運行。它們為分類、摘要、生成或分析任務呼叫 OpenAI 或 Anthropic API。工作流程有效，但 API 費用侵蝕了你的利潤，質量也不一致。

以下是將那些現有 n8n 工作流程轉化為微調管道的行動手冊——使用你已經在生成的互動資料來訓練一個更便宜、更快、更準確的定制模型。

管道概覽

n8n 工作流程（現有）→ 資料收集 → 清理 → 微調 → 本地部署 → n8n 工作流程（更新）

你從 n8n 開始和結束。中間步驟將你客戶的使用資料轉化為替換 API 呼叫的定制模型。

第一步：通過 n8n 收集客戶互動資料

你現有的 n8n 工作流程已經包含了你需要的訓練資料——每個 API 呼叫都包含一個輸入（指令）和一個輸出（模型的回應）。你只需要捕獲它。

添加資料收集分支

對於每個呼叫 AI API 的工作流程，添加一個記錄互動的平行分支：

1. 在 HTTP 請求節點（API 呼叫）之後，添加一個提取以下內容的 Set 節點：

   • 發送到 API 的輸入提示/消息
   • 從 API 接收的回應
   • 時間戳記
   • 客戶識別符
   • 任務類型（分類、摘要等）

2. 將此路由到存儲記錄的 Google Sheets、Airtable 或 PostgreSQL 節點。

對於已經在生產中的工作流程，你可以添加此日誌記錄分支而不中斷現有流程——n8n 的分支模型讓你可以添加平行路徑。

要捕獲什麼

{
  "instruction": "摘要這個客戶支持票券：[票券文字]",
  "response": "客戶正在請求退款訂單 #12345，原因是 2026-01-15 收到有缺陷的產品...",
  "task_type": "ticket_summarisation",
  "client_id": "client_acme",
  "timestamp": "2026-02-10T14:30:00Z",
  "model_used": "gpt-4o",
  "was_accepted": true
}

was_accepted 字段是可選的但有價值——如果客戶的團隊審閱 AI 輸出並有時拒絕它們，追蹤這個有助於過濾高質量訓練資料。

容量目標

現在就開始收集，即使你還有幾週才會微調。更多資料產生更好的模型。

第二步：清理和格式化資料集

原始互動日誌在微調之前需要清理。建立一個 n8n 工作流程來完成這個，或手動完成——選擇取決於容量。

自動清理（n8n 工作流程）

創建一個資料清理工作流程：

1. 從你的資料存儲讀取（Google Sheets、PostgreSQL 等）
2. 過濾掉被拒絕的回應（其中 was_accepted 為 false）
3. 刪除重複項（相同指令帶有相同回應）
4. 標準化格式（一致的換行符、修剪空白）
5. 驗證結構（指令和回應字段非空，長度合理）
6. 導出為 JSONL（每行一個 JSON 對象）

手動審閱

對於第一次微調運行，手動審閱一個樣本（100-200 個範例）：

• 指令清晰且能代表任務嗎？
• 回應高質量嗎？（你會希望模型產生這個嗎？）
• 是否有需要刪除的敏感資料？（PII、API 密鑰、內部引用）
• 是否有應該從訓練中排除的邊緣案例？

輸出格式

最終的 JSONL 文件應該看起來像：

{"instruction": "將這封電子郵件分類為：billing, technical, general, 或 spam。\n\n電子郵件：更新後我無法登錄我的帳戶...", "response": "technical"}
{"instruction": "為週報摘要這個支持票券：\n\n票券：客戶報告...", "response": "客戶在 v2.3 更新後遇到登錄失敗。解決方案：清除瀏覽器緩存並重置會話令牌。解決時間：15 分鐘。"}

第三步：在 Ertas Studio 中微調

準備好清理後的 JSONL 文件後：

1. 在 Ertas Studio 中為此客戶和任務創建一個專案
2. 上傳 JSONL 文件 — Studio 驗證格式並顯示資料統計
3. 選擇基礎模型 — Llama 3.1 8B 用於大多數機構任務，Mistral 7B 作為替代
4. 配置訓練：
   • LoRA rank：16（默認，適用於大多數任務）
   • 訓練輪次：3
   • 學習率：2e-4
5. 開始訓練 — 2,000 個範例在 8B 模型上通常需要 30-60 分鐘
6. 評估 — 使用 Studio 的並排比較對樣本輸入測試微調模型

質量檢查

部署之前，用模型從未見過的 20-30 個範例測試：

• 微調模型匹配或超過 API 模型的質量嗎？
• 輸出格式一致嗎？
• 它正確處理邊緣案例嗎？

如果質量不夠，常見的修復：

• 添加更多訓練資料（尤其是質量弱的案例）
• 將 LoRA rank 從 16 增加到 32
• 再加一個訓練輪次
• 提高資料質量（刪除有噪音的範例）

第四步：本地部署模型

從 Ertas Studio 以 GGUF 格式（用於 Ollama）或 SafeTensors（用於 vLLM）導出你的微調模型。

使用 Ollama 部署

# 創建 Modelfile
echo 'FROM llama3.1:8b
ADAPTER /path/to/your-adapter.gguf' > Modelfile

# 註冊模型
ollama create client-acme-summariser -f Modelfile

# 測試它
ollama run client-acme-summariser "摘要這個票券：..."

Ollama 在 http://localhost:11434/v1/chat/completions 公開一個 OpenAI 兼容 API。

使用 vLLM 部署

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B \
  --enable-lora \
  --lora-modules client-acme=/path/to/adapter \
  --host 0.0.0.0 --port 8000

vLLM 在 http://your-server:8000/v1/chat/completions 公開一個 OpenAI 兼容 API。

第五步：將 n8n 連接到你的本地模型

這是回報所在。更新你現有的 n8n 工作流程，指向你的本地模型而不是雲端 API。

選項 A：更改 API URL

如果你使用 n8n 的 HTTP 請求節點呼叫 OpenAI：

1. 將 URL 從 https://api.openai.com/v1/chat/completions 更改為 http://localhost:11434/v1/chat/completions（Ollama）或 http://your-server:8000/v1/chat/completions（vLLM）
2. 將模型參數從 gpt-4o 更新為你的模型名稱
3. 刪除或更新 API 密鑰（Ollama 不需要）

就是這樣。請求/回應格式是相同的。你的工作流程邏輯、錯誤處理和輸出處理保持不變。

選項 B：使用帶有自定義基礎 URL 的 n8n OpenAI 憑證

1. 在 n8n 中，創建一個新的 OpenAI 憑證
2. 設置基礎 URL 到你的本地端點
3. 設置 API 密鑰為任意字符串（例如，"local"）
4. 在你現有的 OpenAI 節點中使用此憑證
5. 將模型名稱更改為你的微調模型

這種方法除了更新憑證之外不需要工作流程更改——每個使用憑證的節點會自動切換到本地推理。

測試切換

切換生產工作流程之前：

1. 克隆工作流程 — 創建一個使用本地模型的副本
2. 平行運行兩個 24-48 小時
3. 比較輸出 — 本地模型的結果相等或更好嗎？
4. 監控延遲 — 對於大多數工作負載，本地推理應該更快
5. 切換 — 更新生產工作流程使用本地端點

第六步：迭代和改進

微調不是一次性事件。模型通過反饋改進：

持續資料收集

在你更新的工作流程中保持資料收集分支活躍。現在它捕獲：

• 與你的微調模型的互動（不是 API）
• 客戶反饋（接受/拒絕）
• 模型表現不佳的邊緣案例

定期重新訓練

每 4-8 週（或當質量問題出現時）：

1. 從你的日誌記錄管道導出新的互動資料
2. 為模型困難的案例添加糾正範例
3. 與原始訓練資料合並
4. 在 Ertas Studio 中重新訓練
5. 對上一個模型版本進行評估
6. 如果有改進就部署

追蹤隨時間的改進

記錄模型版本和對應的質量指標。經過 3-4 個訓練週期，你會看到可測量的改進，因為模型從真實世界的使用模式中學習。

業務影響

對於大多數機構，切換在 1-3 個月內收回成本。更重要的是，它將服務從「我們將你的工作流程連接到 ChatGPT」轉化為「我們構建在你的資料上訓練的定制 AI 模型」——一個明顯更高價值的主張。

延伸閱讀

• n8n + 本地 LLMs：構建符合 HIPAA 的自動化工作流程 — 醫療保健特定的 n8n + 本地 LLM 工作流程
• 法律客戶的 AI 機構技術堆疊 — 為服務律師事務所的機構提供的完整架構