模型輸出不符合所需格式

問題
1

image
image1216×1542 40.1 KB

在使用 gamma 4 模型的 llm chain 中使用輸出解析器時，每次都會遇到這個問題

2

@Mukul_Rai 那個錯誤表示解析器無法將模型的文本驗證為與你的 schema 相符的 JSON，較小的模型經常在這上面出問題，它們會把 JSON 包裹在散文或 markdown 中，或者丟掉欄位。有兩個修復方法，最簡單的是用 Auto-fixing Output Parser 包裝它，它會執行第二次 LLM 傳遞來修復輸出，然後再進行解析。比較可靠的方法是切換到在結構化輸出上表現穩定的模型（gemini flash、gpt-4o-mini、claude haiku），較弱的模型就是無法保持 schema。還有就是加強提示詞，說明只返回有效的 JSON，不要有 markdown 或額外文字。

3

@Mukul_Rai
這是預期的情況，gemma 4 schema 不符合 Open AI 格式。如果你自行託管，你可能仍然可以通過 LiteLLM 代理它

4

這個錯誤來自結構化/輸出解析器對模型回應進行嚴格的模式檢查——而回應不匹配（通常是額外的文字、markdown ```json 圍欄或格式略微不正確的 JSON）。根節點中的「出錯時變更」提示只是阻止執行失敗；它並不能修復實際輸出，所以我會將其視為最後手段，而不是修復方案。

這裡的真實驅動因素幾乎肯定是模型。如果「gamma 4」是本地運行的 Google Gemma，較小的開源模型在嚴格結構化輸出和函數調用方面相比 GPT-4o / Claude 明顯較弱——它們往往會將 JSON 包裹在代碼圍欄中或添加說明文字，這每次都會破壞解析器。以下是一些能夠修復此問題的方法，按影響程度排列：

  1. 將其包裝在自動修復輸出解析器中。n8n 有一個解析器，當第一次解析失敗時，它會自動將錯誤輸出加上錯誤信息反饋給模型，並要求其更正格式。單靠這一點就能修復大多數較弱模型的情況——以最少的努力獲得最大的效果。

  2. 優化提示詞。明確告訴模型：「僅返回與模式匹配的有效 JSON——沒有 markdown、沒有代碼圍欄、沒有說明。」小模型喜歡添加代碼圍欄和文字說明；明確說明這一點可以消除大多數失敗。

  3. 將結構化步驟的溫度降至 0-0.2。較高的溫度會增加格式偏差。

  4. 簡化模式。深層嵌套的物件及許多必需欄位在小模型上的失敗率遠高於簡單結構。將其扁平化、保持必需欄位最少，並為每個欄位添加簡短描述，使模型清楚了解要生成的內容。

  5. 如果精確度很重要且可行的話，對解析步驟使用在 JSON / 工具調用方面更強大的模型——即使是另一個本地模型如 qwen2.5-instruct 也能比 Gemma 更好地處理結構化輸出，而 API 模型（小型 GPT-4o-mini 或 Claude Haiku）可以達到接近 100% 的合規率。

我在運行本地模型進行結構化提取時遇到過完全相同的情況——自動修復解析器加上明確的「僅限 JSON、無圍欄」指令通常能將其從每次失敗轉變為可靠的性能。從這裡開始，看看能達到什麼效果。

5

上面的解析器/自動修復建議是正確的。我也會將此視為監控問題，而不僅僅是提示問題。

在生產環境中，有時會返回錯誤格式的 AI 步驟不應被允許繼續運行，就像工作流已成功完成一樣。我會在模型步驟之後立即放置一個驗證閘門：

  1. 檢查回應是否為有效的 JSON。
  2. 檢查所有必需欄位是否存在。
  3. 檢查欄位是否非空且在預期範圍內。
  4. 將無效輸出路由到重試、自動修復或人工審查。
  5. 使用執行 ID 和輸入類型記錄驗證結果。

關鍵區別在於技術成功與業務成功。工作流可以以綠色狀態完成，但輸出卻無法使用。對於客戶工作流，我希望這些驗證失敗能成為可見的問題，否則客戶只有在壞數據進入 CRM、電子郵件、試算表或報告時才會注意到。

6

上面的解析器/自動修復建議是對的。我也會把這視為一個監控問題，而不只是提示問題。

在生產環境中，有時返回錯誤結構的 AI 步驟不應該被允許繼續，好像工作流程成功了一樣。我會在模型步驟之後立即放置一個驗證閘門：

  1. 檢查回應是否為有效的 JSON。
  2. 檢查所有必需欄位是否存在。
  3. 檢查欄位是否非空且在預期範圍內。
  4. 將無效輸出路由到重試、自動修復或人工審查。
  5. 使用執行 ID 和輸入類型記錄驗證結果。

關鍵的區別是技術成功與業務成功。工作流程可能完成並顯示成功，但輸出卻無法使用。對於用戶端工作流程，我希望那些驗證失敗能夠變成可見的問題，否則用戶端只會在壞資料到達 CRM、電子郵件、試算表或報告時才發現。