JSONプロンプティングは大規模言語モデルに構造化された指示を与える手法として注目されてきたが、実際にはトークン数が大幅に増加し、必ずしも効率的ではないという問題がある。この動画では、JSONの代替としてトークン指向オブジェクト表記法「Tune」を検証する。TuneはJSONと比較して30〜60%のトークン削減を実現し、特に大量の配列データをLLMに渡す際に有効である。ベンチマークテストでは、Gemini 2.5 FlashやGPT-4o miniがデータ取得において優れた性能を示し、Tuneを使用することでトークンコストを削減しながら精度を維持できることが明らかになった。当初は懐疑的だった作者も、実際の検証を通じてTuneの実用性を認めるに至っている。
TuneとJSONプロンプティングの検証
JSONプロンプティングって聞いたことありますか。もしかしたらないかもしれませんね。これは多くの人が深く掘り下げている、ちょっと混沌としたテーマなんです。言語モデルは文章としての指示に従うのが必ずしも得意ではないけれど、JSONは構造として比較的一貫性があって簡潔だという考え方があります。
それで、モデルにやってもらいたいことをJSON形式にしたらどうなるでしょうか。そうすればモデルがより良く、より賢くなるんじゃないでしょうか。おそらくそうかもしれません。それについてはすぐに触れますが、まず違いがどのように見えるかを示したいと思います。
最初の例がこちらです。「応答を各日のサブヘッディング付きのマークダウンリストとしてフォーマットする」というものです。これがYAML形式で、こちらがJSON形式です。
でも、ここからが面白いところなんです。これをChatGPTのトークナイザーにコピペしてみます。引用符なしの段落バージョンは55トークンでした。トークンというのは、モデルがテキストの塊を分割して効果的に処理し、自動補完できるようにする単位のことです。
これをYAMLバージョンと比較すると、55トークンから88トークンに増えます。何ですって。増えてるじゃないですか。でもすごく簡潔に見えるのに。もっとひどくなりますよ、皆さん。JSONバージョンを試してみましょう。115トークンです。これが効果的だと思ってトークン数を2倍以上にしてしまったんです。
そしてこれがTuneが存在する理由なんです。TuneはToken-Oriented Object Notation、トークン指向オブジェクト表記法の略です。JSONに似ています。基本的に同じことをすることを意図していますが、違いはLLM入力に使用されることを目的としており、JSONの無損失なドロップイン代替品として設計されているという点です。
こちらにアイテムのリストが入ったJSONの例があります。そしてこちらが、Tuneが同じ情報をより少ないトークンで伝える方法です。ユーザーは2つ、なぜなら中に2つのものがあるからです。IDと名前とROがあって、すぐにこのリストが続きます。
ここでトークン化を比較してみましょう。JSON例は51トークン、Tune例は24トークンです。これは本当すぎて信じられないように思えますよね。おそらくそうでしょう。それについては今日のスポンサーからの簡単なメッセージの後にお話しします。
皆さんに正直に言わなければなりません。今、採用活動はかなり大変なんです。AI生成された履歴書の山がものすごくあって、良い候補者を見つけるのは本当に本当に難しいんです。今日のスポンサーであるG2Iを使わない限りはね。
スポンサーシップの範囲外でも、どれだけ多くの人をここに紹介したか言い表せません。確かに彼らはここで彼らが採用においてなぜ優れているかを伝えるために私にお金を払っていますが、実際に何度も推薦してきましたし、その結果には非常に感銘を受けています。
彼らの候補者は最初の面接から最初のPRのマージまで7日以内で進めることができます。そしてこれが十分な回数起こるのを見てきたので、自信を持って言えます。彼らは8,000人以上の本当に技術的なエンジニアのネットワークを持っています。大学を出たばかりのランダムな人々ではなく、パートタイム、フルタイム、アメリカ、ラテンアメリカなど、さまざまなオプションで働ける実際の業界経験を持つ人々です。
あらゆるタイプの経験、あらゆるレベルのAI使用、そしてコードへの深い理解について、本当に幅広い選択肢があります。彼らは単なる採用会社ではありません。ネットワークであり、面接プロセスを行うための素晴らしいツールセットであり、あなたのSlackに統合して、信じられないようなタイムラインで適切な人材を見つけることを確実にする本物のチームなんです。
彼らと仕事をするのは本当に素晴らしかったです。クリエイターとして彼らと仕事をするだけでも素晴らしい経験でした。彼らはReact Miamiも運営していて、ちなみに行けるなら本当に行くべきです。これまで参加した中で最も楽しい技術カンファレンスです。毎年わざわざ参加していますし、できる限りチーム全員を連れていきます。
優れたエンジニアを雇うのに何ヶ月も費やすのはやめて、代わりに素晴らしいエンジニアを数日で雇いましょう。今すぐsoyv.link/g2iでチェックしてください。
Tuneの仕組みと検証
さて、ここに来ました。また別のオブジェクト表記法です。YAMLでもなく、pickleでもなく、JSONでもなく、BSONでもなく、他の変なやつでもありません。まあ、ある種の変なやつではあるんですけどね。今やトークン指向オブジェクト表記法の世界に入っているわけです。
Tuneの元々の作成者はこちらのJohanさんで、こう発表しています。「JSONはLLMにとってトークンコストが高い、まさにMatt PcOがよく言及しているように。Tuneを紹介します。トークン指向オブジェクト表記法で、JSONより40〜60%少ないトークンで、読みやすく、トークナイザーを意識しています。コード内でJSONをラップするだけでトークンコストを半分に節約できます」
これが機能するというのは本当にクールなことです。試してみたいです。フォーマットトークン化プレイグラウンドを試してみてください。ここにプレイグラウンドがあって、何をするかによってトークン化がどう変わるかの既存の例を見ることができます。
もう一度言いますが、トークンはモデルが使用するテキストの塊で、どの塊が何につながるかを把握するためのものです。これらのモデルは入力を文字ごとに処理するわけではありません。これらの塊に分解して、パラメータが浮遊しているだけのクレイジーなニューラルネットワークの中でどこに行くかのマップを作成できるようにするんです。
持っているトークンのセットとその順序に基づいて、次に来る可能性が最も高いトークンを予測できます。整形されたJSONがある場合、77トークンはあまり良くありません。フラットにして空白をすべて削除すると、これらのタブはそれぞれトークンです。38トークンまで減ります。YAMLは50トークンで、Tuneは32トークンです。
公平に言うと、フラット化されたJSONからTuneへの圧縮はわずか4トークン程度です。ほとんど注目に値しませんが、自分のデータを持ち込めます。それをやってみましょう。ここから私のJSON例を持ってきましょう。ペースト。冗談でしょう。
これを作るのは難しくもないじゃないですか。私は間違っていました。AIは間違いです。バイブコーディングは馬鹿げています。このデモさえ完成できなかったなんて。何をすべきか分かっていますが、これは嫌ですね。
このプロジェクトは、オブジェクト表記法のさまざまな構文の実装とトークン数を簡単に比較できるようにすることを目的としています。JSONブロブを貼り付けられるようにして、それがどのようにトークン化されるかを表示し、整形されていないJSONバージョンと比較できるようにすべきです。
つまり、折りたたまれたJSON出力、YAML出力、そしてTune出力です。Tuneのドキュメントもここにリンクします。公式のトークナイザーパッケージと、YAMLとTuneの変換パッケージも使用します。どのパッケージを使用すべきか質問があれば、ハイライトしてください。できる限り答えます。
バックグラウンドでそれを進めている間に、実際に有用なことをやってみます。それまでは、既存の非均一な大規模複合データを使用します。ここでは371トークンです。JSONをフラット化すると199に減ります。YAMLは250で、Tuneは257です。非標準で非均一なデータ構造だと本当にダメになるみたいですね。
均一なネスト構造で均一なデータの場合、560トークンから、整形されたJSONからJSONへと318トークンになります。Tuneは401に減ります。YAMLは390です。何が起こっているんですか。なぜYAMLの方が圧縮率が良いんですか。世の中の半分のものは作り話じゃないかと思えてきます。マジで。
そもそもJSONプロンプティングをダメにしている私のお気に入りのことにまだ触れてもいません。JSONプロンプティングのベンチマークを探してGoogle検索したんですが、プロンプトをJSONで書き直せば出力が魔法のように良くなると思っている狂人たちのためのベンチマークです。
この検索結果がすごく面白いんです。2ヶ月前、「JSONプロンプティングが正確なAI応答のために爆発的に増加」。次に、1週間前のMediumの記事、「JSONプロンプティングは死んだ。なぜあなたの革命的なLLM技術が実際には15%の失敗率を隠しているのか」。次の投稿、「なぜ私はJSONプロンプティングに切り替えたのか、そしてなぜあなたもそうする必要があるかもしれないのか」。ああ、すごい。
「JSONプロンプティング、完璧なAI出力への究極のガイド」。この件に関する意見は少し分かれているかもしれませんね。ネスト構造が問題になるかもしれないと指摘する人もいます。それは妥当な指摘です。代わりに均一なプリミティブのトップル配列を試してみましょう。
すると796トークンから、整形されたJSONからJSONへと484トークンになります。いいですね。YAMLは612トークンで、Tuneは318トークンです。なるほど。ネストが深くなるとTuneは崩れるんですね。でも、ここのように1階層だけの場合、つまりこの巨大な配列にものが入っているだけの場合、Tuneは本当に優れているんです。
上部のここにある均一なオブジェクトの配列について彼らが言っていることが分かります。行ごとに複数のフィールドがあり、アイテム全体で同じ構造。理にかなっています。LLMに大量の配列データを渡す場合、これが機能する可能性があります。
CSVのようなコンパクトさを持ちながら、LMSがデータを確実に解析および検証するのに役立つ明示的な構造を追加します。Tuneを翻訳レイヤーとして考えてください。プログラム的にJSONを使用してから、LM入力用にTuneに変換します。
上部のこの図が本当に気に入っています。彼らはそれが何でないかを偽っていません。Tuneをすべてのもの、書くすべてのコードに使えとは言っていません。JSONを使って、彼らのエンコード関数を呼び出して代わりにTune出力を作成し、それをLLMに送ってトークンを30〜60%節約しろと言っているんです。
そして彼らのテストによると、取得精度が意味のある量、4%程度上昇するそうです。これは実際に理にかなっているかもしれません。ここまで少し厳しいことを言ってきましたが、実際にこれには価値があります。LLMに何百行もの馬鹿げたデータを渡したい場合、JSONを通じてそれをすべきではないでしょう。
これは以前やったことがあります。巨大なHTMLを貼り付けて疑わしい結果を得たこともあります。これはそのためのはるかに良い選択肢のようです。JSONプロンプティングにTuneを使うべきではありません。なぜならJSONプロンプティング自体をすべきではないからです。
JSONプロンプティングは愚かで、悪くて、醜くて、悲惨で、自分たちが私たちより賢いと思っていて、LMSをより良くするための賢いハックを見つけたと思っている人々がやる奇妙なことです。
これがすべて非決定論的であることが問題なんです。陰謀論者たちが大挙して、LMSをより賢くする方法について自分たちのクレイジーなことを考え出しているんです。これがより多くのより良い評価が必要な理由でもあります。だからこそ私はより良い評価に取り組んでいるんです。
チャットの誰かがもうコンバーターサイトを作っています。おやおや。さっきの私の馬鹿げた例を115トークンから81トークンに変換してみましょう。でもまた、これは本当にリスト型の例ではありません。これはJSONプロンプティングの下手な試みです。デモです。NFSD、この例をありがとう。本当に感謝します。
ベンチマークテストの結果
どうやら彼らは独自のベンチマークを持っているようです。ベンチマークは公平な比較を確保するために2つのトラックに整理されています。最初のものは混合構造トラックで、データセットにネストされた構造または半均一な構造があります。CSVがこれらの構造を適切に表現できない場合は除外されます。
そうですね。CSVは非常に非常にフラットですが、フラットのみのトラックもあります。CSVが表現できるデータセットです。理にかなっています。こちらが、単純なデータセットカタログに対する各フォーマットの全体的なパフォーマンスとトークンコストの比較です。
この数字が何なのか分かりません。ええ、この数字は彼らがこれら2つの値に対して行っている奇妙な計算だと思います。重要なのは精度と使用されたトークン数です。圧縮されたJSONは、この最初の例でわずかに多いトークンで約3%の精度低下を受けます。
YAMLは精度でさらに1〜2%低下し、トークンが大幅に増加します。彼らの標準的な整形済みJSONは、フラット化されておらず、すべてのタブが削除されていないものです。はるかに多くのトークンですが、確実な精度です。圧縮されたJSONが整形済みJSONよりも正確だというのは実際面白いですね。
トークンは奇妙なものです。LLMは本当に変なんです。そしてXMLはゴミです。LLMにXMLを使わないでください、お願いします。モデルごとに変わります。おやおや。Gemini 2.5 Flashが勝ち続けています。良いものを使っていたと思っていました。
しばらく疑っていて、それを証明する良いベンチマークがなかったんですが、2.5 Flashは巨大なデータの山の中からランダムなものを取り出すのが本当に得意なんです。ほら、証拠があります。でも今ではGPT-4o miniがさらに良いようです。
Geminiの最悪のケース、つまり標準的なJSON解析でも77%の精度評価を得たのに、数週間前にリリースされたばかりのHaiku 4.5が、Tuneを使った最良のケースでも60%に届かなかったというのは、私にとって本当に面白いです。
Claudeがあなたのコードを理解しない理由を知りたいなら、それはClaudeが最初の1,000トークンを超えるものを理解しないからです。だからT3チャットで10万トークンのクエリを送るのをやめてください。それは私たちにお金がかかりますし、良い答えも得られません。
Gemini 2.5 Flashは、このモデルが何ヶ月も更新されていないにもかかわらず、大規模なコンテキストではるかに優れています。そして4o miniはさらにそうです。4o miniは非常に過小評価されているモデルだと思います。見てください、Grok 2 fast非推論モデルは、何か合理的なことをするよう求めると、それができないんです。
これはおそらくここで最も重要な点です。GeminiとGPT-4o miniがデータ取得においてはるかに優れているということです。この差がこんなに大きいとは思ってもみませんでした。どうやら2.5 Flashは2ヶ月前に少しアップデートされたそうです。すみません、大きな発表はしませんでした。それでもクールな結果です。
より多くのネストされたデータ構造に入ると、ここでギャップが見えます。コンパクトなJSONはわずかに優れていて、かなり少ないトークンを使用しています。しかしXMLは再び役に立たず、Tuneが72,000トークンでやることに122,000トークンかかっています。
実はこれ、私はこれに賛成するようになってきました。実際にJSON配列をモデルに渡している場合、本当にこれを試してみるべきです。データをそのまま渡す代わりに、このエンコード呼び出しでラップするだけです。小さなパッケージです。
インストールして、データをこれでラップしてLLMに渡し、お金が節約できるか、そして賢くなるかを確認してください。実際にそうなるかもしれません。plan MDです。私はLLMが大好きです。彼らはCLIさえ持っています。
ローカルでbashスクリプトでデータをダンプしてTune形式にしたいだけなら、とても簡単です。実際、ちょっと試してみたいです。私の下手なJSONプロンプトの例を取ってきましょう。それを保存してTuneフォーマットCLI。理にかなっています。実際に本当にクールです。
彼らがシンプルなものを作ったのが気に入っています。これを書こうとしていたら、彼らがすでに私のために作ってくれていました。これは奇妙なほど良く考えられていて、実際に役立ちます。私はこれに予想よりもずっと早く、ずっと強く賛成するようになっていることに驚いています。
これに本物の価値が見えますし、いくつかのプロジェクトでやっているランダムなJSON関連のことで、これをある程度定期的に使っている自分が想像できます。これがこんなに役立つとは思っていませんでした。これは実際にかなり良いです。
バイブコーディングで解決策を作れるかどうか、そしてどうなるか見たかったんです。できるようです。かなりクレイジーです。1行もコードを書いていません。GPT-4oに計画を書くよう指示し、2つのエラーを貼り付けて、動作する実装を得ました。
最終的にここでTuneに賛成するようになったと思います。皆さんがどう思うか気になります。これは過大評価されていて価値がないのか、それとも実際にLLMと一緒に使うためのかなり便利な小さなツールなのか。皆さんの考えを聞かせてください。それでは次回まで、彼は始めます。
コメント