告別「昂貴」的 JSON：TOON 在 LLM 架構中的實務與權衡

從 XML 到 JSON，再到以大模型為核心的互動層，序列化格式一直在「人類可讀」與「模型／執行期成本」之間取捨。TOON（Token-Oriented Object Notation）與 JSON 的比較討論很多；本文從工程與架構角度，聚焦三件事：Token 是否真省、跨模型與巢狀場景是否穩、以及解析與閘道成本是否可接受。

說明：下文百分比、延遲與 token 數為典型樣本的示意量級，用於說明權衡維度；請以自有資料與 tokenizer 復測後再做容量規劃。

核心摘要

TOON 透過減少 JSON 冗餘分隔符，並採用「表頭 + 資料列」的緊湊版面，在同質、列表型資料上常能明顯縮短上下文。它較適合作為 LLM 輸入側的表示層，而非取代對外 REST API 或持久化儲存中的 JSON。

---

一、容易被忽略的「資訊增量」

深層巢狀與注意力預算

JSON 每層 {}、"、: 都會進入 tokenizer 與上下文視窗。對深度巢狀（如複雜抽取結果、AST 片段）而言，這些符號構成結構化雜訊：佔用 token，也可能增加模型對齊括號與欄位的負擔。

TOON 在「可表頭化」的重複結構上，把欄位名從每列重複中抽離，因此在深而同質的列表場景裡，壓縮收益更明顯；若每層結構都不同，表頭／schema 宣告本身會吃掉收益。

跨 tokenizer 的收益差異

同一字節序列在不同模型 tokenizer 下的 token 數並不相同。實務上常見：

• • 詞表較大的模型：對短標點、重複子字串往往更省；TOON 對短符號的收益可能被放大。

• • 長上下文模型：對重複欄位與表格對齊較敏感；表頭清楚的 TOON 有時有利於欄位對齊（仍需以你的任務集驗證）。

結論：沒有放諸四海皆準的節省比例；要以目標模型與目標資料分布為準。

---

二、技術權衡矩陣（JSON / YAML / TOON）

---

三、三個不可忽視的問題

1. 深層異質巢狀時，TOON 優勢會收斂

結論：若是 AST、動態 schema、欄位頻繁變化的物件列表，JSON 的「囉嗦」未必是首要矛盾，遷移 TOON 的 ROI 要重新算。

2. 模型之間對 TOON 的穩健性差異大

部署建議：開源／本地模型若對「表頭 + 列」對齊不穩定，優先 JSON；在閉源旗艦模型且成本壓力極大時，再評估 TOON，並固定 schema 與 few-shot 範例。

3. 解析與轉換的 CPU 成本

JSON 解析器經多年 SIMD、串流與零拷貝最佳化；TOON 若仍在直譯型遞迴下降 + 大量字串拼接階段，更容易成為閘道瓶頸。高頻線上路徑要嘛快取轉換結果，要嘛把轉換挪到離線或批次。

---

四、範例：電商訂單列表的 Token 對比

JSON（示意約 180 tokens）

{
  "order_id": "992831",
  "items": [
    {"sku": "A12-B", "price": 99.0, "qty": 1},
    {"sku": "C34-D", "price": 45.5, "qty": 2},
    {"sku": "E56-F", "price": 12.0, "qty": 5}
  ],
  "customer": "John Doe"
}

TOON（示意約 52 tokens）

order_id: 992831
items[3]{sku, price, qty}:
  A12-B, 99.0, 1
  C34-D, 45.5, 2
  E56-F, 12.0, 5
customer: John Doe

解讀：同質 items 陣列是 TOON 的舒適區；瀏覽器端無法原生解析 TOON 時，通常在閘道或 BFF 做 JSON ↔ TOON，並注意快取與錯誤回退。

---

五、FAQ

Q1：TOON 會更容易幻覺嗎？

A：在表頭明確、列對齊、schema 穩定時，欄位級表現可與 JSON 接近；極簡無表頭模式只建議用於強約定場景。

Q2：效能開銷主要在哪？

A：主要在轉換與解析實作；大 payload 建議在快取層做 TOON 化，或對靜態知識庫離線轉換。

Q3：多型物件列表怎麼辦？

A：欄位不一致時 TOON 的壓縮率會迅速下降，此時應回退 JSON 或拆分為多張「同 schema 表」。

---

六、何時選 JSON，何時考慮 TOON

• • 優先 JSON：對外標準 API、強 schema 校驗、深異質巢狀、團隊測試投入有限、或主力為本地開源模型。

• • 評估 TOON：LLM 帳單與上下文視窗是硬約束、資料以同質列表／寬表為主、且已在目標模型上完成準確率迴歸。

---

七、與工具鏈結合

在 CI/CD 或資料準備階段對靜態資料集做 JSON → 緊湊表示的轉換，可在 playground 中快速對照 tokenizer 計數；無論採用何種中間格式，線上仍建議保留 JSON 作為事實來源（source of truth），TOON 作為面向模型的衍生視圖。

---

相關工具

• • JSON ⇄ TOON 線上轉換

• • JSON 美化器

• • JSON 驗證器

• • JSON 壓縮

結語：TOON 不是要取代 JSON，而是對 LLM 上下文這一層做有針對性的瘦身。掌握「面向 token 的表示」與全鏈路成本，比追逐單一節省比例更重要。