當要求大語言模型（LLM）輸出結構化數據時，所采用的格式會對結果產生比較大的影響。本文對比了六種不同的格式，評估考察了它們的處理速度、tokens 消耗以及各自的限制。

1.簡要說明

JSON 雖然是多數人的首選，但它對 tokens 的消耗極大。處理相同數據時，它可能需要其他格式兩倍的 tokens。

需要注意的是，沒有一種格式能在所有情況下都表現最佳，以下是一個決策指南：

圖片

（如果你好奇為何沒有提及 XML，那是因為我有個個人目標：50 年不碰 XML —— 只剩下 4 年就能達成了！）

我將在下文中詳細解釋這些格式選擇，并探討每種格式的局限性。但在此之前，先讓我們對比一下它們的 token 使用情況和速度。

2.token 使用情況

探究 JSON 之外的其他選項，主要目的是為了減少所需的 tokens 數量，這樣做可以降低運營成本并縮短響應時間。

為了對這些格式進行有效比較，我們將基于它們表示特定數據集所需的 token 數量來進行評估。

2.1 比較框架

本次比較我將使用一段文本作為輸入，該文本包含了關于歐盟每個國家的一段信息。

image.png

我將要求 LLM 將這段普通文本轉換成結構化數據，其中每個國家都是一條記錄，每條記錄包含國家名稱、領導人姓名、領導人出生日期、領導人性別、人口數量和領土面積等鍵/值對。

我將針對每種結構化輸出格式執行這一操作，并檢查六種格式的輸出結果是否相同。

感興趣的朋友，可以在這個 gist^[1] 中查看完整的代碼。對于不太感興趣的朋友，這里展示了我如何為每種格式定義 name、可選的 hint 以及 parser（這里將所有數據解析成 Pandas DataFrame）：

image.png

LLM（本次測試使用的是 gpt-4o-mini）能夠以不同格式準確返回相同的數據。當然，如果數據更復雜，或者使用的 LLM 不夠強大，結果可能就不會這么精確了。

2.2 比較結果

下表展示了使用不同格式表示數據所需的 tokens 數量。

image.png

JSON 所需的 tokens 數量是 TSV 的兩倍。這個差異不容小覷。設想一下，如果你在某個 API 的價格頁面上看到，選擇 JSON 格式的數據需要支付 1 美元，而 TSV 格式只需 0.5 美元，YAML 格式則是 0.8 美元。

當然，這些結果僅針對我們的示例數據。展示本圖表的目的并非要讓你認為 JSON 在所有情況下都會大量消耗 tokens，而是讓你相信值得用其他格式測試自己的數據。

接下來，我們來看看這些格式的響應時間。

盡管 JSON “只”需要兩倍于 TSV 的 tokens ，但其響應時間通常比 TSV 慢四倍。我原本以為 token 數量與響應時間之間的關系是近似線性的 —— 接近O(n)，因此如此夸張的響應時間出乎我的意料，我建議我們可以將這種現象的時間復雜度設為O(my)。

將數據結構化輸出的響應時間還是蠻重要的，所以趕緊測試吧。

3.局限性與考慮因素

如果這些格式都同樣可靠和靈活，那么結論就會很簡單：使用 TSV。但事實并非如此，所以讓我們對每一種格式進行更深入的了解。

3.1 TSV

在表示表格數據時，TSV 和 CSV 格式頗為相似，區別在于 TSV 使用制表符分隔每一行的數據，而 CSV 則采用逗號。如果數據中本身就包含逗號或制表符，那么這些值就需要用雙引號括起來，這時兩種格式的 tokens 使用差異才會顯現。

由于制表符在數據中出現的頻率低于逗號，因此 TSV 在大多數情況下使用的分隔符數量會少于 CSV。

在解析數據時，TSV 與 CSV 相比 JSON，在純 Python 環境下解析起來略顯復雜。雖然可以利用 Python 內置的 csv 模塊進行解析，但使用 Pandas 庫會更加便捷。在其他編程語言中，解析這兩種格式要么需要編寫更多代碼，要么得依賴第三方庫。

如果數據中不含換行符，TSV 可以輕松地逐行解析。因此，若想從 LLM 流式傳輸響應數據并實時處理每一行數據，TSV（以及 CSV）都是不錯的選擇。雖然 TOML、YAML 和 JSON 也能實現類似功能，但處理起來會更加繁瑣。另外，本文尚未測試的 NDJSON 也是一個值得考慮的選項。

3.2 CSV

如前文所述，CSV 格式的挑戰在于逗號在數據中較為常見，這可能會導致兩種情況：要么是需要更多的 tokens 來處理這些逗號，要么是 LLM 在處理時未能正確進行轉義，從而產生錯誤的數據。因此，如果你的數據可能包含逗號，最好避免使用 CSV，或者設計一個詳盡的提示詞，并實施有效的評估流程，以便準確衡量其可靠性。

對于 TSV 和 CSV 兩種格式，你需要用那些可能包含特殊字符（如逗號、制表符、換行符和雙引號）的數據來測試你的系統配置。這樣，你才能確保系統能夠正確處理這些特殊情況。

3.3 Columnar JSON

Columnar JSON 并不是一個常見的技術術語；我之所以將它納入這次比較，是因為我很好奇它的 tokens 使用效率如何。

可能有些人還不清楚 Columnar JSON 是什么樣的，下面就是前文提到的國家數據所對應的 Columnar JSON 格式：

image.png

在所有格式中，Columnar JSON 的直觀性最差。但是，由于其結構特點，每個字段名只會出現一次，而不是每條記錄都重復，這樣就能節省 tokens。

我注意到，有時 LLM 能夠理解“Columnar JSON”的含義，但有時候需要一些額外的提示詞，例如：“應以列名作為鍵名，對應的列內容以列表的形式組織呈現”。

要解析 columnar JSON，你可以這樣將其傳遞給 Pandas 處理：

image.png

與 CSV 和 TSV 不同，columnar JSON 支持嵌套的數據結構，因此它非常適合表示那些某些字段具有復雜結構的記錄列表。

這三種格式——TSV、CSV、columnar JSON——僅適用于表示表格數據，即以記錄列表為核心的結構。它們都不適合用來表示像配置文件這樣的單一 top-level object（譯者注：指在結構化數據格式（如 JSON/YAML/TOML）中，最外層定義的單一根對象，通常作為整個數據結構的入口點。）。而接下來的三種格式（YAML、TOML、JSON）則更為靈活多變。

3.4 YAML

YAML 能夠返回一個 top-level list（譯者注：指在結構化數據格式中，最外層直接定義為列表結構而非對象。），但我注意到，某些 LLM 更傾向于生成一個 top-level object。因此，在給出提示詞時，我們需要明確指出，以確保 LLM 按照統一的格式返回數據。

我還遇到了一個問題，即 LLM 在返回字符串值時，格式可能會不一致。在某些情況下，這可能無關緊要，但 YAML 有五種不同的方式來表示字符串，而其中只有一種能夠正確解析轉義序列（例如\t, \u03B1）。因此，如果你的數據中包含轉義序列，那么最好明確要求 LLM 使用雙引號來定義字符串。

YAML 相較于 JSON，存在更多的“陷阱”和注意事項。建議你深入了解這些潛在的問題，而不是盲目地期待 LLM 能夠自動正確地格式化 YAML。

為了解析 YAML，你需要安裝一個第三方庫。我個人使用的是pyyaml，這是一個無依賴的庫。

3.5 TOML

TOML 是在此場景中唯一不支持 top-level list 的格式，因為它的設計初衷是作為一種配置文件格式。因此，若想用 TOML 來表示記錄列表，就必須將這些記錄包含在一個 top-level object 內，并告訴 LLM 你想在這個對象中調用什么鍵。

TOML 在使用上通常會比 YAML 需要更多的 token，因為 TOML 要求所有的字符串值都必須用引號括起來。

在解析方面，如果你的 Python 版本是 3.11 或以上，那么內置的 TOML 解析器^[2]就可以直接使用。如果不是，那就需要安裝 tomlkit 或類似的庫來處理。

TOML 的普及度不及 YAML，你可能會擔心 LLM 在處理 TOML 格式時是否會遇到難題。但在我所使用的頂級 LLM 中，并沒有發現明顯的格式處理問題。我認為，TOML 相較于 YAML 的簡潔性在一定程度上彌補了這一普及度差距。而且，YAML 有多種方式可以表達相同的數據，這可能會降低 LLM 的確定性，使得兩種格式的可靠性相差無幾。

根據我的個人經驗，TOML 和 YAML 都可能出現錯誤，但這些錯誤通常可以通過更精確的提示詞來解決。

關于 YAML 中的字符串和轉義序列的問題，TOML 也同樣存在。

總體而言，TOML 和 YAML 非常相似，TOML 需要更多的 token，不支持 top-level lists，但對于使用 Python 3.11 或以上版本的用戶來說，不需要額外的解析庫。

3.6 JSON

關于 JSON，其實沒什么特別需要強調的。它之所以能成為默認格式，是因為它用途廣泛、易于解析，而且出錯率低。只是它包含了大量的引號、逗號、冒號和換行符，這些都增加了 token 的數量，這一點稍顯遺憾。

值得注意的是，如果你想要使用 LLM 服務商提供的“結構化數據模式”，或者使用像 Guardrails^[3]、Outlines^[4] 這樣的結構化工具，JSON 往往是唯一的選擇。但我認為這種情況會隨著時間的推移而有所改變。隨著越來越多的基于 LLM 的應用投入實際使用，開發者會開始關注如何減少 token 使用等優化措施，LLM 服務商也會通過支持更多結構化數據格式來滿足這一需求。

理想的情況是，LLM 服務商能夠調整模型，使其能夠可靠地處理多種格式的數據，并在結構化數據模式中提供這些格式作為可選項。

這里有一個注意事項：對于有關 LLM 在輸出特定格式時的可靠性方面的舊建議，我們應該保持謹慎。正如 OpenAI 在 2024 年 8 月的一篇博客文章中所提到的^[5]，GPT-4 的早期版本在處理復雜的 JSON 測試時的正確率僅為 35%，而較新版本的 GPT-4 正確率則高達 85%。這在 GPT-4 系列中是一個巨大的飛躍。

這一點對于使用某些特殊功能或軟件包的人來說尤為重要，這些功能或軟件包可能會基于一年或更久之前的假設或證據來強制輸出結構化數據。你可能并不需要這些功能或軟件包，它們可能會迫使你使用 JSON，而實際上你可以選擇更經濟、更快捷的格式。

4.實際應用

在理論層面這些格式各有優勢，但假設你已經有了一套使用 JSON 的結構化數據處理系統，并且運行得很順暢。你知道 TSV 格式也能適用于你的數據，那么是否有必要進行格式轉換呢？

如果你關注的是速度——因為人們需要等待 LLM 生成 token，那么你需要評估等待時間的價值，這部分在這里不展開討論。

但如果你只是在后臺運行一個進程，這個問題就簡單多了。舉例來說，我們可以設定以下假設條件：

• 你的時間成本是每天 1000 美元
• 將現有系統從 JSON 轉換為 TSV 需要半天時間
• 輸出 token 的費用是每百萬 0.60 美元
• 使用 TSV 可以減少 50% 的 token 使用量
• 你希望一年內收回投資

我們可以用一個小 Python 腳本來計算這些數值：

image.png

根據計算，如果你現在每天生成大約 4,566,210 個 JSON token，一年后就能實現收支平衡。

當然，你應該根據自己的實際情況來調整這些數值，但以下基準數據可供你參考。如果你每天只生成幾千個結構化數據的 token（并且不介意速度），那么盲目調整數據格式的性價比極低。但如果你每天需要處理數千萬個 token，那么探索其他格式絕對是一個劃算的決定。

5.總結

選擇默認的 JSON 格式確實很有吸引力，因為它靈活、穩定且解析起來簡單。但相對而言，它的處理速度較慢，成本也更高。因此，不妨考慮一下其他數據格式，做一些測試，挑選出既能控制成本又能保證穩定性和速度的最佳選項。