你是否曾經對 LLM 的 API 成本感到擔憂?如果傳遞給提示的大量數據,令標記數量激增,那麼成本和響應速度都會受到影響。
造成這一問題的原因之一就是 JSON。因為 JSON 是為了讓人類閱讀而設計,所以符號和重複的內容非常多,對 LLM 來說變成了冗餘的格式。
因此,「TOON(Token-Oriented Object Notation)」應運而生。這是一種專為 LLM 優化的數據格式,據說與 JSON 相比可以減少 30% 至 60% 的標記數。
本文將具體說明 TOON 的優點以及如何使用,並附上實例進行說明。
讓我們看個具體例子。商品數據使用 JSON 描述為:
{
"products": [
{
"id": 301,
"name": "Mouse",
"price": 29.99
},
{
"id": 302,
"name": "Keyboard",
"price": 89.00
},
{
"id": 303,
"name": "Hub",
"price": 45.50
}
]
}
問題顯而易見。"id":、"name":、"price": 這些鍵名按照商品數量重複出現。
如果有100個商品,僅這些鍵名就會被發送300次。這就是標記的浪費。
TOON 則消除了這些重複。在最開始只宣告一次字段名,後面只列出值。
同樣的數據用 TOON 表達為:
products{id,name,price}:
301,Mouse,29.99
302,Keyboard,89.00
303,Hub,45.50
就這麼簡單。
發生了什麼:
"id":、"name":、"price":)只宣告一次{} 的重複" 的使用結果,使用約少了 40% 的標記來表達相同的信息。
讓我們再看一個更簡單的例子。
JSON:
{
"users": [
{
"id": 1,
"name": "Alice",
"role": "admin"
},
{
"id": 2,
"name": "Bob",
"role": "user"
}
]
}
TOON:
users{id,name,role}:
1,Alice,admin
2,Bob,user
一目了然,TOON 的格式更加簡潔且易讀。
LLM 的 API 是根據標記數量進行收費的。TOON 通過刪除 JSON 的冗餘符號,能夠以 30% 至 60% 更少的標記傳送相同的信息。
實際測試案例:
使用 GPT-4o 時:
如果每天向 LLM 傳送 100 萬標記的數據,僅僅改用 TOON 就可以每月節省 75 到 150 美元的成本。對於大規模系統,年節省額可達數十萬至數百萬。
隨著標記數的減少,LLM 的處理時間也會縮短。特別是對於 RAG 或代理等大量使用上下文窗口的應用,響應時間的改善會變得顯著。
更重要的是,可以更有效地利用有限的上下文窗口。假如上下文窗口為 128K 標記,使用 JSON 只能傳遞約 200 條搜尋結果,但使用 TOON 則可以傳遞約 350 條。這樣能夠使用更多的信息,提高 LLM 的回答精度。
通過以更乾淨的形狀向 LLM 提供結構化數據,推理質量隨之上升。JSON 的冗餘符號和重複內容對 LLM 來說有時候會形成「噪音」。TOON 將這些噪音降到最低,明確展示數據的本質結構。這樣一來,LLM 更容易正確理解數據之間的關係。
特別是在 RAG 系統中搜索精度的提升得到了報告。當以 TOON 格式將搜尋結果傳入 LLM 時,準確提取相關信息的概率會增加。表格形式的數據中,字段名與值的關係更加明確,因此 LLM 誤解的可能性也降低。
實際效果:
TOON 特別在數據庫查詢結果、RAG 搜尋結果、CSV 等表格數據、日誌數據和時序數據等「同一字段重複」的數據結構中展現了強大的效果。
TOON 一個重要的特徵是,它能與 JSON 完全互轉。TOON 表達的數據都可以退回到 JSON,反之亦然。這意味著無需放棄現有的 JSON 資產,可以根據需求隨意轉換 TOON 和 JSON。
TOON ⇔ JSON 轉換過程中不會有信息的丟失,數值和字符串等類型信息也會得到保持。甚至複雜的嵌套結構也可以進行雙向轉換。由於這種兼容性,API 可以使用 JSON,內部處理則僅使用 TOON。
循序漸進的導入也是它的一大優勢。無需一次性全部切換,而是可以從效果顯著的部分逐步轉向 TOON。
JSON 的轉換步驟繁多,而 TOON 則可以從一開始就有效率地處理。這是個簡單的圖示,但此差異直接影響延遲和成本。
TOON 在多種語言中提供官方 SDK:
@toon-format/toonpython-toonNIZZOLA.TOON.NET基本流程如下:
import { stringify, parse } from '@toon-format/toon';
// 準備 JSON 數據
const data = {
users: [
{ id: 1, name: 'Alice', role: 'admin' },
{ id: 2, name: 'Bob', role: 'user' }
]
};
// 轉換為 TOON
const toonString = stringify(data);
// 傳送給 LLM
const prompt = `請從以下用戶數據中提取管理者:\n${toonString};`;
// 根據 LLM 回應的 TOON 進行還原
const result = parse(llmResponse);
推薦的導入方法:
僅將 LLM 的輸入輸出改為 TOON
逐步擴展
一定要進行 A/B 測試
判斷標準很簡單。如果你向 LLM 傳遞大量的表格數據,且 LLM API 的成本超過每月數萬元,則值得一試。當 RAG 系統的搜尋結果有幾十到幾百條數據時,或者當直接分析數據庫的查詢結果時,或在處理日誌和時序數據時,這類「同一字段重複」的結構 TOON 將最大化其效果。
如果你在上下文窗口的限制上遇到困擾,TOON 更是一個出色的選擇。即使是相同的窗口大小,也能容納更多的資訊。
另一方面,TOON 不是萬能的。
1. 對複雜嵌套結構較弱
TOON 最適合於表格數據。對於深度嵌套的數據或結構不均勻的數據則不太適用。例如,像公司組織圖那樣部門→團隊→成員的深度嵌套結構,使用 JSON 或 YAML 更為方便。
2. LLM 對 TOON 的熟悉度不足
LLM 訓練時接觸了大量的 JSON,但對 TOON 了解甚少。因此在簡單數據提取任務中 TOON 可能會佔優勢,但是在複雜推理任務中可能 JSON 更精確。獨立基準測試中報告 TOON 在深度嵌套的數據上精度不及 JSON 或 YAML 的結果。
3. 尚未標準化
TOON 是較新的技術,尚未形成行業標準。雖然主要語言的 SDK 都在增長,但與 Protobuf 或 JSON 的成熟度相比,仍不夠強大。
4. 如果需要謹慎
在醫療或金融等高精度優先的領域應該謹慎。如果 LLM API 的使用量較小,或者將其整合既有系統的成本較高,則可能不會得到相應的收益。
小規模開始。先在小規模測試中比較 JSON 和 TOON。在標記減少率和精度上進行實測,只有在有效的部分進行 TOON 化。然後逐步擴大範圍。現有的 API 和數據庫保留 JSON,僅將 LLM 接口改為 TOON 的方法最為現實。
TOON 不是 JSON 的替代品,而是專為 LLM 優化的數據傳送格式。
TOON 解決的問題是 LLM API 的標記數和成本、上下文窗口的限制、響應時間的改善等實務問題。當面對大量表格數據(例如 RAG 的搜尋結果、數據庫結果、日誌等)時,效果尤為顯著。
不過對於深度嵌套結構、複雜推理任務,以及高精度所需的情境則不適合。LLM 較熟悉 JSON,但對 TOON 的認識仍然有限。
這並不意味著 JSON 的時代已經結束。TOON 作為用於 LLM 接口的優化工具,將與 JSON 共同存在。導入應該從小規模開始,測量效果後再進行擴展。這是降低風險並最大化收益的明智之舉。