JSON から TOON への変換

LLM で TOON を使用する方法

LLM
迅速なエンジニアリング

大きな JSON 配列を ChatGPT または Claude に貼り付けたことがある場合は、コンテキスト ウィンドウが閉じてしまう苦痛を感じたことがあるでしょう。JSON は Web API にとっては素晴らしいものですが、Large Language Model (LLM) にとっては信じられないほど無駄です。 "id":、"name":、および "timestamp": などのフィールド名をレコードごとに繰り返すのは、単に冗長であるだけではありません。 リアルマネーと貴重なコンテキストスペースを必要とするトークンを焼き尽くします。

ここで TOON (Table Object Notation) が威力を発揮します。 これは単なるデータ形式ではありません。 これは、LLM インタラクションを最適化するための戦略です。 JSON の構文を取り除き、明示的な構造ヘッダーを追加することで、TOON を使用すると、より多くのデータをモデルに渡し、その代わりにより信頼性の高い構造化された出力を取得できるようになります。

TOONのトークンエコノミクス

なぜフォーマットをわざわざ切り替える必要があるのでしょうか? 計算は簡単です。 オブジェクトの標準的な JSON 配列では、行ごとにスキーマが繰り返されます。 50 人のユーザーのリストがある場合、フィールド名の料金を 50 回支払うことになります。

TOON は、ヘッダー内でスキーマを 1 回宣言することで、この冗長性を排除します。 データは、緻密で合理的な形式で続きます。 実際には、これにより通常、フォーマットされた JSON と比較して均一配列のトークン使用量が 30 ～ 60% 削減されます。 大規模なコンテキスト ウィンドウや大量の API 呼び出しを処理する場合、その効率はそのまま請求額の削減と待ち時間の短縮につながります。

データの送信: 「伝えるな、見せる」ルール

データ分析に LLM が必要な場合、迅速な戦略が重要です。 初心者はデータ形式を説明する長い文章を書くことがよくあります。 TOON を使用すると、その必要はありません。

LLM はパターン マッチング エンジンです。 彼らは、TOON が YAML と CSV のハイブリッドのように見えるため、直感的に理解できます。これは、トレーニング中に何十億回も見たフォーマットです。

データを送信するには、フェンスで囲まれたコード ブロックでデータをラップするだけです。 これに「トゥーン」というラベルを付けることもできますが、モデルの構文ハイライトが正式にサポートしていなくても、モデルは構造をすぐに理解します。

入力例

スキーマを説明する代わりに、ブロックを指定するだけです。

ヘッダー users[3]{id,name,role,lastLogin} は、エンティティ タイプ、数 (3 行)、およびフィールドの順序など、モデルが知る必要があるすべてをモデルに伝えます。 インデントは階層を処理します。 この「自己文書化」の性質により、プロンプトは構文解析命令ではなく実際のロジック タスクに集中できるようになります。

``md ユーザーのアクティビティログは次のとおりです。 データは TOON 形式 (2 スペースのインデント、明示的なヘッダー) です。

ユーザー[3]{ID、名前、役割、最終ログイン}: 1、アリス、管理者、2025-01-15T10:30:00Z 2、ボブ、ユーザー、2025-01-14T15:22:00Z 3、チャーリー、ユーザー、2025-01-13T09:45:00Z

タスク: ログを分析し、過去 24 時間以内にログインしていないユーザーを特定します。 「」

信頼性の高い出力の生成

LLM でデータを読み取るのは簡単です。 有効な構造化データを_生成_するのは難しい部分です。 モデルは幻覚を見せたり、JSON を切り詰めたり、右中括弧を忘れたりするのが大好きです。

TOON は、ヘッダー構文、特に [N] カウントを通じて安全層を追加します。 モデルに TOON を出力するよう依頼すると、データを生成する前に構造にコミットするようモデルに依頼することになります。

生成のプロンプト

最良の結果を得るには、期待するヘッダー形式を指定し、行を埋めるようにモデルに指示します。

モデルに [N] の計算を依頼することで、モデルが出力サイズを計画する必要がある「思考の連鎖」プロセスを強制します。 この一見小さな制約により、モデルがリストの途中で切断される可能性が大幅に減少します。

``md タスク: ロール「user」を持つアクティブなユーザーのリストを返します。 形式: TOON を使用します。 生成する行数と正確に一致するようにヘッダーの [N] 値を設定します。

期待される形式: ユーザー[N]{id,name,role,lastLogin}: 「」

Strict モードでの検証

LLM から応答を受け取った場合、それをただ信頼する必要はありません。 ここで、TOON ライブラリの厳密モードが運用アプリケーションにとって強力になります。

TypeScript ライブラリを使用している場合、厳密モードでデコードすると、生成された行がヘッダー数と一致するかどうかが検証されます。

これにより、アプリケーションの下流で不正なデータを検出するのではなく、「遅延」モデルの出力やネットワークの切り捨てをプログラムで即座に捕捉できるようになります。

 import { decode } から '@toon-format/toon';

 {を試してください
 // モデルに [5] と表示されていても 4 行がある場合、エラーがスローされます。 
const data = decode(modelOutput, { strict: true });
 console.log('有効なデータを受信しました:', data);
 } キャッチ (エラー) {
 console.error('モデルの幻覚または切り捨てが検出されました:', error.message);
 }
 「」

高度な最適化: タブのトリック

最適化に夢中になっている場合 (LLM の世界では、おそらくそうすべきでしょう)、区切り文字を賢く選択することで、さらに効率を高めることができます。

カンマは標準ですが、多くのトークナイザー語彙ではタブ (\t) が単一のトークンとして表されることがよくあります。 さらに、タブがナチュラル テキスト フィールド内に表示されることはほとんどないため、エスケープ文字 (文字列を引用符で囲むなど) の必要性が減ります。

データをモデルに送信する前に、タブを使用してデータをエンコードできます。

プロンプトでモデルに次のように通知することを忘れないでください: 「データはタブで区切られた TOON.」 これにより、モデルの解析と生成が非常に簡単になる超コンパクトな表現が作成されます。

 const toonPrompt = encode(data, { 区切り文字: '\t' });
 「」

完全なワークフローの例

実際のシナリオ、つまりシステム ログのフィルタリングを見てみましょう。 生のログをモデルに送信し、構造化されたエラーのリストを取得したいと考えています。

プロンプト:

モデルの出力:

``md TOON 形式のシステム ログ (タブ区切り):

イベント[4]{ID、レベル、メッセージ、タイムスタンプ}: 1、エラー、接続タイムアウト、2025-01-15T10:00:00Z 2、警告、遅いクエリ、2025-01-15T10:05:00Z 3、情報、ユーザー ログイン、2025-01-15T10:10:00Z 4、エラー、データベース エラー025-01-15T10:15:00Z

タスク: レベル「エラー」を持つすべてのイベントを抽出します。 更新されたヘッダー数を持つ有効な TOON として結果を返します。 「」

結果：

「トゥーン」 イベント[2]{ID、レベル、メッセージ、タイムスタンプ}: 1、エラー、接続タイムアウト、2025-01-15T10:00:00Z 4、エラー、データベース エラー、2025-01-15T10:15:00Z 「」

モデルはリストを正しくフィルタリングし、重要なことに、ヘッダーを「events[2]」に更新しました。 この応答をデコードすると、アプリケーション ロジックに使用できるクリーンでタイプ セーフな配列が得られます。

＃＃ まとめ

TOON は、人間の読みやすさと機械の効率の間のギャップを埋めます。 LLM のコスト制約を尊重しながら、堅牢なソフトウェア開発に必要な構造を提供します。

  1. 規模を小さくしてください: 例では 2 ～ 5 行を使用します。 モデルは一般化されます。
  1. 明示的であること: モデルがスキーマを認識できるように、ヘッダーを明確に定義します。
  1. 厳密に検証します: 形式のメタデータを使用して生成エラーを検出します。

プロンプト ペイロードを JSON から移行することで、トークンを節約するだけでなく、より信頼性の高い AI パイプラインを構築できます。