JSON から TOON への変換

トゥーンとは何ですか？

トゥーン
JSON
最適化

私たちは皆、そこに行ったことがある。 大規模言語モデル (LLM) 用のプロンプトを設計していて、構造化データを渡す必要があります。 JSON に手を伸ばします。 結局のところ、それは業界標準です。 しかし、コンテキスト ウィンドウが無限の中括弧、繰り返されるキー、単純な整数を囲む引用符でいっぱいになるのを見ると、「もっと良い方法はないものか?_」と疑問に思うようになります。

YAML は可読性を提供しますが、あいまいさの問題があります。 CSV は高密度ですが、階層がありません。

トゥーンと入力してください。

TOON は、開発者にとって新風のように感じられるデータシリアル化形式であり、AI モデルの母国語です。 人間の読みやすさと機械の効率の間のギャップを埋めます。 今日は、TOON が高効率のデータ交換に急速に人気を集めている理由を理解するために、TOON の構文と仕組みを深く掘り下げてみましょう。

哲学: JSON セマンティクス、YAML 美学

TOON はその中核として、JSON とまったく同じデータ モデルを共有します。 JSON (プリミティブ (文字列、数値、ブール値、null)、オブジェクト、配列) で表現できれば、TOON で表現できます。 ただし、プレゼンテーションは根本的に異なります。

TOON は中括弧を廃止します。 YAML と同様に、インデントを使用して階層を表します。 シンプルなオブジェクトはすっきりしていて親しみやすいように見えます。

ただし、YAML とは異なり、TOON は型について厳密です。 「no」が「false」を意味するのか、それとも文字列「no」を意味するのかを推測することはできません。 TOON では、文字列に特殊文字が含まれている場合、数字に似ている場合、または空である場合など、絶対に必要な場合にのみ文字列に引用符が必要です。 「message: Hello World」と入力すると、文字列が表示されます。 「count: 42」と入力すると、数値が表示されます。

 ID:123
 名前：エイダ
 アクティブ: true
 「」

配列の力: 長さとテーブル

TOON がパックから真に分離しているのは、配列の処理です。 これは、トークン最適化の「キラー機能」です。

TOON のすべての配列は、items[3] のように、その長さを括弧内で明示的に宣言します。 これは人間にとっては冗長に思えるかもしれませんが、LLM にとっては超大国です。 これにより、モデルは構造を即座に検証し、切り捨てを検出できます。 ストリームが 2 つのアイテムの後で切断されたが、ヘッダーでは 3 つのアイテムが約束されていた場合、パーサーは何か問題が発生したことを認識します。

TOON は、配列を処理する 3 つの方法を効果的に提供し、最も効率的な方法を自動的に選択します。

  1. インライン プリミティブ: 数値または文字列の単純なリストの場合、TOON はコンパクトに保ちます。 タグ[3]: 管理者、運用、開発
  1. 標準リスト: 混合型の場合、YAML に似たハイフンでつながれたリスト構文が使用されます。
  1. 表形式オブジェクト: これはゲームチェンジャーです。

同じキーを共有するオブジェクトの配列がある場合 (データベース レコードの非常に一般的なパターン)、TOON は 表形式 にピボットします。 単一行ごとにキーを繰り返す代わりに、ヘッダー内でキーを 1 回宣言します。

上の例では、users[2]{id,name,role}: は 2 つの行があることを示し、スキーマを定義します。 データは CSV のような構造で続きます。 これにより、ユーザーごとに "id":、"name":、および "role": を繰り返すことによる膨大なトークンのオーバーヘッドがなくなります。

 ユーザー[2]{ID,名前,役割}:
 1、アリス管理者、管理者
 2、ボブ・スミス、ユーザー
 「」

デリミタとトークンの効率

上記の例ではカンマが使用されていることに気づくかもしれません。 TOON は実際に、カンマ (デフォルト)、タブ、パイプ (|) の 3 つの区切り文字をサポートしています。

なぜこれが重要なのでしょうか? トークン化。

多くの LLM トークナイザーでは、引用符に続くカンマが複数のトークンに分割される場合があります。 ただし、タブ文字は多くの場合、非常にきれいにトークン化されます。 TOON を使用すると、配列ヘッダー レベルで区切り文字を切り替えることができます。 タブ区切り文字を使用すると、多くの場合、スペースを含む文字列を引用符で囲む必要さえなくなり、データがさらに圧縮されます。

この形式は「衝突」を処理できるほど賢いものです。 データにアクティブな区切り文字が含まれている場合、TOON はその特定の値を単純に引用します。

 商品[2]{SKU、名前、数量}:
 A1、ウィジェット名、2
 B2、ガジェット名、1
 「」

キーの折りたたみ: 曲線を平坦化する

TOON の効率性への重点を強調するもう 1 つの機能は キー フォールディングです。 深くネストされたオブジェクトは通常、水平方向のスペースとトークンを消費するインデントの「階段」を生じます。

中間オブジェクトに兄弟がない深い階層がある場合、TOON はそれらをドット表記パスに折りたたむことができます。

書く代わりに:

次のように書くことができます:

 データ:
 メタデータ:
 アイテム[2]: a、b
 「」

この機能は仕様 v1.5 以降で利用可能であり、行数とインデント トークンを大幅に削減します。 重要なのは、これは完全に元に戻すことができるということです。 パス拡張を有効にしてデータをデコードすると、深いオブジェクト階層が完全に再構築されます。

 データ.メタデータ.アイテム[2]: a,b
 「」

厳格さと安全性

TOON はその簡潔な外観とは裏腹に、データに疎いわけではありません。 引用符とエスケープに関する一連の厳格なルールに従っています。

通常、文字列は引用符で囲まれないため、読みやすくなります。 ただし、TOON では、データの整合性を確保するために、エッジケースに対しては引用を強制します。 文字列が数値のように見える場合 (例: "05" や "1e-6")、数値として解析されないように引用符で囲まれます。 文字列が「true」や「null」などの予約語である場合、引用符で囲まれます。

さらに、TOON は数値を正規化します。 標準的な 10 進数形式を出力します。科学表記法や出力の末尾のゼロはなく、一貫性が確保されます。 BigInt も安全に処理します。 数値が安全な整数の範囲を超える場合、転送中の精度の低下を防ぐために、数値は文字列としてシリアル化されます。

ルートフォーム

私たちのほとんどはルート オブジェクトを使用して作業しますが、TOON は柔軟です。 ドキュメントはキーと値のペアで始まる必要はありません。 ルート配列 (すぐに [N]: で始まる) または単一のルート プリミティブもサポートします。 JSON とのこの同等性は、相手側にパーサーがある限り、現在 JSON が使用されているほぼすべてのパイプラインに TOON を交換できることを意味します。

最終的な考え

TOONは単なる「別のフォーマット」ではありません。 これは、データが決定論的なコードと同じくらい確率モデルによっても消費される時代に特化したツールです。 JSON の厳格なデータ モデルと CSV の密度および YAML の読みやすさを組み合わせることで、タイプ セーフを犠牲にすることなく、コンテキスト ウィンドウの最適化という特定の問題を解決します。

エージェントを構築している場合、モデルを微調整している場合、または単に右中括弧を延々とスクロールするのにうんざりしている場合は、TOON を試してみてください。