在 2026 年，在 n8n 中從本機 LLM 取得可靠結構化 JSON 輸出的最新方法是什麼？
我在 n8n 中使用本機模型（透過 Ollama），需要一致的 JSON 輸出，用於路由和 SQL 生成等用途。
2026 年人們目前使用的最佳實踐是什麼？
人們是否仍在依賴：
- 結構化輸出解析器 + JSON Schema
- 提示詞工程
- 程式碼節點來清理輸出
還是有更新、更可靠的方法？
1個讚
我不會將這視為單層問題。
對於路由或 SQL 相關的工作流程，我會將 JSON 視為介面契約：
- 用結構描述和一個微小的有效範例提示模型
- 解析輸出
- 驗證必需的鍵、類型、列舉和空值
- 通過將驗證錯誤提供給模型來修復一次
- 如果再次失敗，停止或轉向審查，而不是猜測
對於 SQL 特別是，我會避免讓模型生成直接執行的原始 SQL。更安全的模式是讓模型輸出結構化意圖、過濾器、來自允許清單的表格/欄位選擇，然後將其映射到你控制的查詢範本。
所以可靠的部分不只是「模型能發出 JSON 嗎？」而是「當 JSON 缺失、格式不正確、有效但錯誤，或不安全時會發生什麼？」
1個讚
好問題——我用 Ollama + n8n 反覆試驗過這個問題。以下是 2026 年真正可靠的做法：
**1. 使用 Ollama 原生的 `format: json` 參數（最可靠的層級）**
設定 Ollama Chat Model 節點時，在額外欄位 / 模型參數中新增 `format: json`。這會強制 Ollama 將其 token 採樣限制在有效的 JSON token 上——這不是提示工程，而是在模型層級強制執行的。`llama3`、`mistral` 和 `qwen2.5` 等模型都能很好地支持這一點。僅此一項就能消除約 80% 的格式錯誤輸出。
**2. 搭配 n8n 的 Structured Output Parser**
結合 Ollama 的 format:json + Structured Output Parser（搭配 JSON Schema）。該 schema 告訴模型你預期的欄位；parser 則驗證並提取它們。如果你在做路由，schema 可能簡單如 `{ “route”: { “type”: “string”, “enum”: [“billing”, “support”, “sales”] } }`。
**3. Code 節點作為安全網**
在 parser 之後新增一個 Code 節點，執行以下程式碼：
```js
const out = $input.first().json;
if (!out.route || ![‘billing’,‘support’,‘sales’].includes(out.route)) {
throw new Error('Invalid route: ’ + JSON.stringify(out));
}
return [{ json: out }];
```
這樣可以守護下游節點，確保你永遠不會無聲地路由到錯誤的地方。
**4. 針對 SQL 意圖**
不要要求模型輸出 SQL。改為要求它輸出結構化意圖：`{ “table”: “orders”, “filters”: [{“field”: “status”, “op”: “eq”, “value”: “pending”}], “limit”: 10 }`。然後你的 Code 節點將其對應到參數化查詢。這比自由形式的 SQL 安全得多，也更可靠。
**5. 必要時的單次修復迴圈**
對於複雜 schema，如果模型偶爾仍然失敗，可連接一個 IF 節點來檢查解析錯誤 → 將錯誤訊息附加到提示並重新傳送給 Ollama。一次重試就能捕捉大多數失敗的情況。如果失敗兩次，就路由到備用方案 / 人工審查，而不是猜測。
format:json + schema + Code 驗證的組合是我在類似生產環境的工作流程中使用的。不需要任何付費節點就能運作。
1個讚
歡迎 @osman1！
值得添加到堆疊中的一個東西：n8n 有一個「Auto-fixing Output Parser」節點，它包裝了 Structured Output Parser。如果模型返回格式不正確的 JSON，它會自動將錯誤發送回 LLM 進行單次自修復嘗試 - 不需要手動 IF/retry 邏輯。對於 Ollama 具體來說，也要在 Ollama Chat Model 節點的主體選項中傳遞 format: "json"，以在模型層級約束令牌採樣，然後讓 Auto-fixing Parser 在頂部強制執行你的模式。這種兩層設置（模型層級格式約束 + 解析器層級修復）是我用過的本地模型中最可靠的方法。
1個讚