開發者們總是熱衷於把所有東西都塞進 Pydantic 模型裡，彷彿只要加上了型別提示，AI 生成的結構化輸出就有了靈魂。結果呢？LangChain 的 Issue 區躺滿了關於序列化錯誤的哀嚎。這種執著於嚴格 schema 的病態，在面對 ChatGPT 的 Tool Calling 時顯得尤為荒謬。當你試圖用過於複雜的嵌套模型去約束一個大語言模型，你得到的往往不是精準的 JSON，而是充滿了序列化警告的垃圾數據。
Claude 在處理長文本中的結構化提取時，顯然比 ChatGPT 更懂得克制。當你給出一個超過五千字的法律文檔，要求它輸出特定格式的 JSON 摘要時，ChatGPT 經常在處理複雜的巢狀結構時，因為強制遵循過於嚴苛的 Pydantic 定義而產生幻覺，甚至在鍵名補全上出現毫無邏輯的錯誤。相比之下，Claude 3.5 Sonnet 在處理長上下文時的注意力機制，能更穩定地維持 JSON 結構的合法性，即便是在面對極端複雜的 Schema 定義，它也不會像 ChatGPT 那樣因為過分追求所謂的「語法完美」而丟失上下文的邏輯一致性。
這種現象在技術圈內並不罕見，即便觀察其他模型，如 DeepSeek 或 Qwen，在處理同類複雜 schema 任務時，也面臨著類似的權衡困境。不過，當我們把目光拉回四大平台的表現，會發現 Gemini 1.5 Pro 在長窗口下的結構化輸出表現出了一種奇特的「懶惰」。它在面對極其龐大的工具集定義時，往往會主動簡化輸出結構以規避序列化失敗，這種行為在生產環境中反而比死板地報錯要實用得多。Grok 則完全是另一個極端，它在處理非結構化數據到結構化對象的映射時，往往表現得過於大膽，經常忽略掉開發者在 Pydantic 中定義的那些限制條件，強行給出一個看起來正確、實則無法驗證的結果。
如果我們真的需要一個完美的結構化輸出，是否意味著我們對大語言模型的期待本身就錯了？當開發者花費大量時間在除錯這些序列化警告，是否只是在掩蓋模型對複雜邏輯指令理解不足的本質？如果模型的內在推理能力足夠強，我們還需要那些繁瑣的約束層嗎？還是說，我們永遠都無法逃離這場開發者與模型之間，關於「格式」與「內容」的永恆拉扯？