當(dāng)要求大語(yǔ)言模型（LLM）輸出結(jié)構(gòu)化數(shù)據(jù)時(shí)，所采用的格式會(huì)對(duì)結(jié)果產(chǎn)生比較大的影響。本文對(duì)比了六種不同的格式，評(píng)估考察了它們的處理速度、tokens 消耗以及各自的限制。

1.簡(jiǎn)要說(shuō)明

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

需要注意的是，沒(méi)有一種格式能在所有情況下都表現(xiàn)最佳，以下是一個(gè)決策指南：

圖片

（如果你好奇為何沒(méi)有提及 XML，那是因?yàn)槲矣袀€(gè)個(gè)人目標(biāo)：50 年不碰 XML —— 只剩下 4 年就能達(dá)成了?。?/span>

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

2.token 使用情況

探究 JSON 之外的其他選項(xiàng)，主要目的是為了減少所需的 tokens 數(shù)量，這樣做可以降低運(yùn)營(yíng)成本并縮短響應(yīng)時(shí)間。

為了對(duì)這些格式進(jìn)行有效比較，我們將基于它們表示特定數(shù)據(jù)集所需的 token 數(shù)量來(lái)進(jìn)行評(píng)估。

2.1 比較框架

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

image.png

我將要求 LLM 將這段普通文本轉(zhuǎn)換成結(jié)構(gòu)化數(shù)據(jù)，其中每個(gè)國(guó)家都是一條記錄，每條記錄包含國(guó)家名稱、領(lǐng)導(dǎo)人姓名、領(lǐng)導(dǎo)人出生日期、領(lǐng)導(dǎo)人性別、人口數(shù)量和領(lǐng)土面積等鍵/值對(duì)。

我將針對(duì)每種結(jié)構(gòu)化輸出格式執(zhí)行這一操作，并檢查六種格式的輸出結(jié)果是否相同。

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

image.png

LLM（本次測(cè)試使用的是 gpt-4o-mini）能夠以不同格式準(zhǔn)確返回相同的數(shù)據(jù)。當(dāng)然，如果數(shù)據(jù)更復(fù)雜，或者使用的 LLM 不夠強(qiáng)大，結(jié)果可能就不會(huì)這么精確了。

2.2 比較結(jié)果

下表展示了使用不同格式表示數(shù)據(jù)所需的 tokens 數(shù)量。

image.png

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

當(dāng)然，這些結(jié)果僅針對(duì)我們的示例數(shù)據(jù)。展示本圖表的目的并非要讓你認(rèn)為 JSON 在所有情況下都會(huì)大量消耗 tokens，而是讓你相信值得用其他格式測(cè)試自己的數(shù)據(jù)。

接下來(lái)，我們來(lái)看看這些格式的響應(yīng)時(shí)間。

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

將數(shù)據(jù)結(jié)構(gòu)化輸出的響應(yīng)時(shí)間還是蠻重要的，所以趕緊測(cè)試吧。

3.局限性與考慮因素

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

3.1 TSV

在表示表格數(shù)據(jù)時(shí)，TSV 和 CSV 格式頗為相似，區(qū)別在于 TSV 使用制表符分隔每一行的數(shù)據(jù)，而 CSV 則采用逗號(hào)。如果數(shù)據(jù)中本身就包含逗號(hào)或制表符，那么這些值就需要用雙引號(hào)括起來(lái)，這時(shí)兩種格式的 tokens 使用差異才會(huì)顯現(xiàn)。

由于制表符在數(shù)據(jù)中出現(xiàn)的頻率低于逗號(hào)，因此 TSV 在大多數(shù)情況下使用的分隔符數(shù)量會(huì)少于 CSV。

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

如果數(shù)據(jù)中不含換行符，TSV 可以輕松地逐行解析。因此，若想從 LLM 流式傳輸響應(yīng)數(shù)據(jù)并實(shí)時(shí)處理每一行數(shù)據(jù)，TSV（以及 CSV）都是不錯(cuò)的選擇。雖然 TOML、YAML 和 JSON 也能實(shí)現(xiàn)類似功能，但處理起來(lái)會(huì)更加繁瑣。另外，本文尚未測(cè)試的 NDJSON 也是一個(gè)值得考慮的選項(xiàng)。

3.2 CSV

如前文所述，CSV 格式的挑戰(zhàn)在于逗號(hào)在數(shù)據(jù)中較為常見(jiàn)，這可能會(huì)導(dǎo)致兩種情況：要么是需要更多的 tokens 來(lái)處理這些逗號(hào)，要么是 LLM 在處理時(shí)未能正確進(jìn)行轉(zhuǎn)義，從而產(chǎn)生錯(cuò)誤的數(shù)據(jù)。因此，如果你的數(shù)據(jù)可能包含逗號(hào)，最好避免使用 CSV，或者設(shè)計(jì)一個(gè)詳盡的提示詞，并實(shí)施有效的評(píng)估流程，以便準(zhǔn)確衡量其可靠性。

對(duì)于 TSV 和 CSV 兩種格式，你需要用那些可能包含特殊字符（如逗號(hào)、制表符、換行符和雙引號(hào)）的數(shù)據(jù)來(lái)測(cè)試你的系統(tǒng)配置。這樣，你才能確保系統(tǒng)能夠正確處理這些特殊情況。

3.3 Columnar JSON

Columnar JSON 并不是一個(gè)常見(jiàn)的技術(shù)術(shù)語(yǔ)；我之所以將它納入這次比較，是因?yàn)槲液芎闷嫠?tokens 使用效率如何。

可能有些人還不清楚 Columnar JSON 是什么樣的，下面就是前文提到的國(guó)家數(shù)據(jù)所對(duì)應(yīng)的 Columnar JSON 格式：

image.png

在所有格式中，Columnar JSON 的直觀性最差。但是，由于其結(jié)構(gòu)特點(diǎn)，每個(gè)字段名只會(huì)出現(xiàn)一次，而不是每條記錄都重復(fù)，這樣就能節(jié)省 tokens。

我注意到，有時(shí) LLM 能夠理解“Columnar JSON”的含義，但有時(shí)候需要一些額外的提示詞，例如：“應(yīng)以列名作為鍵名，對(duì)應(yīng)的列內(nèi)容以列表的形式組織呈現(xiàn)”。

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

image.png

與 CSV 和 TSV 不同，columnar JSON 支持嵌套的數(shù)據(jù)結(jié)構(gòu)，因此它非常適合表示那些某些字段具有復(fù)雜結(jié)構(gòu)的記錄列表。

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

3.4 YAML

YAML 能夠返回一個(gè) top-level list（譯者注：指在結(jié)構(gòu)化數(shù)據(jù)格式中，最外層直接定義為列表結(jié)構(gòu)而非對(duì)象。），但我注意到，某些 LLM 更傾向于生成一個(gè) top-level object。因此，在給出提示詞時(shí)，我們需要明確指出，以確保 LLM 按照統(tǒng)一的格式返回?cái)?shù)據(jù)。

我還遇到了一個(gè)問(wèn)題，即 LLM 在返回字符串值時(shí)，格式可能會(huì)不一致。在某些情況下，這可能無(wú)關(guān)緊要，但 YAML 有五種不同的方式來(lái)表示字符串，而其中只有一種能夠正確解析轉(zhuǎn)義序列（例如\t, \u03B1）。因此，如果你的數(shù)據(jù)中包含轉(zhuǎn)義序列，那么最好明確要求 LLM 使用雙引號(hào)來(lái)定義字符串。

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

為了解析 YAML，你需要安裝一個(gè)第三方庫(kù)。我個(gè)人使用的是pyyaml，這是一個(gè)無(wú)依賴的庫(kù)。

3.5 TOML

TOML 是在此場(chǎng)景中唯一不支持 top-level list 的格式，因?yàn)樗脑O(shè)計(jì)初衷是作為一種配置文件格式。因此，若想用 TOML 來(lái)表示記錄列表，就必須將這些記錄包含在一個(gè) top-level object 內(nèi)，并告訴 LLM 你想在這個(gè)對(duì)象中調(diào)用什么鍵。

TOML 在使用上通常會(huì)比 YAML 需要更多的 token，因?yàn)?TOML 要求所有的字符串值都必須用引號(hào)括起來(lái)。

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

TOML 的普及度不及 YAML，你可能會(huì)擔(dān)心 LLM 在處理 TOML 格式時(shí)是否會(huì)遇到難題。但在我所使用的頂級(jí) LLM 中，并沒(méi)有發(fā)現(xiàn)明顯的格式處理問(wèn)題。我認(rèn)為，TOML 相較于 YAML 的簡(jiǎn)潔性在一定程度上彌補(bǔ)了這一普及度差距。而且，YAML 有多種方式可以表達(dá)相同的數(shù)據(jù)，這可能會(huì)降低 LLM 的確定性，使得兩種格式的可靠性相差無(wú)幾。

根據(jù)我的個(gè)人經(jīng)驗(yàn)，TOML 和 YAML 都可能出現(xiàn)錯(cuò)誤，但這些錯(cuò)誤通常可以通過(guò)更精確的提示詞來(lái)解決。

關(guān)于 YAML 中的字符串和轉(zhuǎn)義序列的問(wèn)題，TOML 也同樣存在。

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

3.6 JSON

關(guān)于 JSON，其實(shí)沒(méi)什么特別需要強(qiáng)調(diào)的。它之所以能成為默認(rèn)格式，是因?yàn)樗猛緩V泛、易于解析，而且出錯(cuò)率低。只是它包含了大量的引號(hào)、逗號(hào)、冒號(hào)和換行符，這些都增加了 token 的數(shù)量，這一點(diǎn)稍顯遺憾。

值得注意的是，如果你想要使用 LLM 服務(wù)商提供的“結(jié)構(gòu)化數(shù)據(jù)模式”，或者使用像 Guardrails^[3]、Outlines^[4] 這樣的結(jié)構(gòu)化工具，JSON 往往是唯一的選擇。但我認(rèn)為這種情況會(huì)隨著時(shí)間的推移而有所改變。隨著越來(lái)越多的基于 LLM 的應(yīng)用投入實(shí)際使用，開(kāi)發(fā)者會(huì)開(kāi)始關(guān)注如何減少 token 使用等優(yōu)化措施，LLM 服務(wù)商也會(huì)通過(guò)支持更多結(jié)構(gòu)化數(shù)據(jù)格式來(lái)滿足這一需求。

理想的情況是，LLM 服務(wù)商能夠調(diào)整模型，使其能夠可靠地處理多種格式的數(shù)據(jù)，并在結(jié)構(gòu)化數(shù)據(jù)模式中提供這些格式作為可選項(xiàng)。

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

這一點(diǎn)對(duì)于使用某些特殊功能或軟件包的人來(lái)說(shuō)尤為重要，這些功能或軟件包可能會(huì)基于一年或更久之前的假設(shè)或證據(jù)來(lái)強(qiáng)制輸出結(jié)構(gòu)化數(shù)據(jù)。你可能并不需要這些功能或軟件包，它們可能會(huì)迫使你使用 JSON，而實(shí)際上你可以選擇更經(jīng)濟(jì)、更快捷的格式。

4.實(shí)際應(yīng)用

在理論層面這些格式各有優(yōu)勢(shì)，但假設(shè)你已經(jīng)有了一套使用 JSON 的結(jié)構(gòu)化數(shù)據(jù)處理系統(tǒng)，并且運(yùn)行得很順暢。你知道 TSV 格式也能適用于你的數(shù)據(jù)，那么是否有必要進(jìn)行格式轉(zhuǎn)換呢？

如果你關(guān)注的是速度——因?yàn)槿藗冃枰却?LLM 生成 token，那么你需要評(píng)估等待時(shí)間的價(jià)值，這部分在這里不展開(kāi)討論。

但如果你只是在后臺(tái)運(yùn)行一個(gè)進(jìn)程，這個(gè)問(wèn)題就簡(jiǎn)單多了。舉例來(lái)說(shuō)，我們可以設(shè)定以下假設(shè)條件：

• 你的時(shí)間成本是每天 1000 美元
• 將現(xiàn)有系統(tǒng)從 JSON 轉(zhuǎn)換為 TSV 需要半天時(shí)間
• 輸出 token 的費(fèi)用是每百萬(wàn) 0.60 美元
• 使用 TSV 可以減少 50% 的 token 使用量
• 你希望一年內(nèi)收回投資

我們可以用一個(gè)小 Python 腳本來(lái)計(jì)算這些數(shù)值：

image.png

根據(jù)計(jì)算，如果你現(xiàn)在每天生成大約 4,566,210 個(gè) JSON token，一年后就能實(shí)現(xiàn)收支平衡。

當(dāng)然，你應(yīng)該根據(jù)自己的實(shí)際情況來(lái)調(diào)整這些數(shù)值，但以下基準(zhǔn)數(shù)據(jù)可供你參考。如果你每天只生成幾千個(gè)結(jié)構(gòu)化數(shù)據(jù)的 token（并且不介意速度），那么盲目調(diào)整數(shù)據(jù)格式的性價(jià)比極低。但如果你每天需要處理數(shù)千萬(wàn)個(gè) token，那么探索其他格式絕對(duì)是一個(gè)劃算的決定。

5.總結(jié)

選擇默認(rèn)的 JSON 格式確實(shí)很有吸引力，因?yàn)樗`活、穩(wěn)定且解析起來(lái)簡(jiǎn)單。但相對(duì)而言，它的處理速度較慢，成本也更高。因此，不妨考慮一下其他數(shù)據(jù)格式，做一些測(cè)試，挑選出既能控制成本又能保證穩(wěn)定性和速度的最佳選項(xiàng)。