- Token-Oriented Object Notation
- LLMへの入力時にトークン使用量を削減するために設計された直列化フォーマット
- JSONデータを損失なく表現しながら、トークン効率と可読性を同時に確保
- 均一なオブジェクト配列に最適化された構造で、繰り返し現れるキーを削除し、30〜60%のトークン削減効果を提供
- YAMLのインデントベース構造とCSVの表形式を組み合わせたハイブリッドフォーマット
- ネスト構造が深い、または不均一なデータではJSONのほうが効率的
- 明示的な構造情報を含み、LLMがデータを安定して解析・検証可能
- 配列長（
[N]）とフィールド定義（{id,name,role}）を明示し、構造認識を向上
- 簡潔な文法により不要な括弧、引用符、句読点を取り除いた最小構文設計
- インデントベースの階層表現、CSV類似の行単位データストリームをサポート
- CLIツールを通じてJSON ↔ TOON間の双方向変換をサポート
- 自動フォーマット検出、区切り文字（
,, \t, |）指定、トークン削減統計の出力などのオプションを提供
- API構成
encode()でJSONを直列化し、decode()で逆直列化を実行- オプションでインデント、区切り文字、長さマーカー（
#）を指定可能
- ベンチマーク結果では、JSON比で平均21〜60%のトークン削減、LLMクエリ精度73.9%を達成
- CSVよりわずかに大きいが、構造的な検証機能によりLLMの信頼性を向上
- 形式ルール
- 文字列は必要な場合にのみ引用し、区切り文字を含む場合は自動的に引用処理
- 数値・ブール値・日付などはLLMフレンドリーな形に変換
- さまざまな言語実装を提供
- 公式: Python, Rust（開発中）
- コミュニティ: Go, Java, Swift, C++, .NET, Ruby など
3件のコメント
function callingを使っているので、一度テストしてみようと思います。いくつかの例を見ると、空白を削除した場合はJSON形式のほうがずっとトークン数を減らせるようです……。まだよく分かりませんが、本当に使ってみる価値のある形式なのか気になります。
モデル別の精度比較
ベンチマーク結果だけを信じるなら、精度を落とさずに token 使用量が減るので、使わない理由はなさそうですね