コンテキストウィンドウの最適化：AIエージェントのためのトークン効率の高いID

エージェント型AIの時代において、コンテキストウィンドウはシステム内で最も貴重なリソースです。ボイラープレート、メタデータ、またはシステム識別子によって消費されるすべてのトークンは、実際の推論やタスク実行から奪われるトークンです。最も見落とされがちなトークン浪費の原因の一つは、どこにでもあるUniversally Unique Identifier (UUID)です。UUIDはデータベースの整合性においてはゴールドスタンダードですが、大規模言語モデル (LLM) に渡される際には著しく非効率的です。

id-agent は、データベースではなくコンテキストウィンドウのために特別に設計された新しいライブラリです。ランダムな16進数文字列を、厳選された単語ベースのIDに置き換えることで、トークンオーバーヘッドを削減し、特定のエンティティを参照する際のLLMの信頼性を向上させることを目指しています。

LLMコンテキストにおけるUUIDの問題点

従来のUUID v4識別子（例：89b842d9-6df9-4cf4-8db0-9dc3aed3cfd7）は、機械用であり、GPT-4oのような現代のLLMで使用されるBPE (Byte Pair Encoding) トークナイザー用ではありません。

トークナイザーは自然言語で学習されているため、ランダムな英数字文字列に苦戦します。単一のUUIDは、トークナイザーが文字列を小さく予測不可能な断片に分割しなければならないため、23トークン以上を消費することがあります。これにより、主に2つの問題が発生します。

  1. トークン増大: 何十ものIDがやり取りされる複雑なエージェント型ワークフローでは、累積的なトークンコストが増加し、レイテンシとコストが増大します。
  2. ハルシネーション: LLMは、自然な単語よりもランダムな16進数文字列を「ハルシネーション（幻覚）」したり、打ち間違えたりする傾向があります。エージェントが特定のIDを参照するように求められた際、UUIDに意味的な構造がないため、モデルが文字や数字を誤って入力し、参照の整合性を損なうことが容易になります。

id-agent の仕組み

id-agent は、4,096個の厳選された英語単語のワードリストを使用することで、この問題を解決します。このリスト内の各単語は、o200k_base トークナイザーにおいて、正確に1つのBPEトークンであることを確認されています。

エントロピーと衝突の数学

122ビットのUUIDから単語ベースのシステムに移行することで、セキュリティが低下したり衝突リスクが増加したりすることを懸念するかもしれません。しかし、ほとんどの実用的なアプリケーションにおいては、数学的にそうではないことが示唆されています。各単語は4,096単語のプール ($2^{12}$) から選ばれ、つまり各単語は12ビットのエントロピーを追加します。

単語数 エントロピー 衝突確率 (100万アイテムの場合) 50% 衝突しきい値
3 36 bits $7.3 imes 10^{-2}$ ~309K items
5 60 bits $4.3 imes 10^{-7}$ ~1.3B items
8 (デフォルト) 96 bits $6.3 imes 10^{-18}$ ~331T items
10 120 bits $9.4 imes 10^{-26}$ ~2.7 quintillion items

デフォルトの8単語構成では、100万個のIDの中で衝突が発生する確率は、およそ158京分の1であり、ほとんどのSaaSアプリケーションにおいて事実上ゼロです。

主要な機能と実装

このライブラリは、既存のシステムにこれらのIDを統合するために、完全なデータベース移行を必要とせずに、いくつかのユーティリティを提供します。

1. ランダムおよび決定論的な生成

開発者は、idAgent() を使用してランダムなIDを生成したり、idAgent.from() を使用してHMAC-SHA256を介して決定論的なID（同じ入力から常に同じIDが生成されるもの）を生成したりできます。

2. エイリアス・マップ

レガシーシステムにとっておそらく最も強力な機能は、createAliasMap です。これにより、開発者はデータベースにUUIDを保持しつつ、テキストをLLMに送信する前に、それらを短く、単語ベースのエイリアスにマッピングすることができます。

const aliases = createAliasMap({ words: 3 });
aliases.set('8cdda07b-85d2-459c-8a2a-83c8f9245dbe'); // => "storm-delta-stone"

const shortened = aliases.replace(text, { pattern: uuidRegex });
// The LLM sees "storm-delta-stone", saving ~18 tokens per ID.

LLMが応答を返すと、restore メソッドによって、データがバックエンドに到達する前にエイリアスを元のUUIDsに書き戻します。

コミュニティの視点とトレードオフ

技術的な効率性は明らかですが、Hacker News コミュニティは、単語ベースのIDの使用に関して、いくつかの重要な検討事項を提起しました。

意味的な干渉のリスク: 一部のユーザーは、これらのIDが実際の単語であるため、ランダムな文字列よりもLLMの注意機構（attention mechanism）に異なる影響を与える可能性があると指摘しました。あるユーザーは次のように述べています。

"Tokens that represent real words will probably influence the attention in a different way than random numbers."

必要性の疑問: 批判的な意見として、IDがクライアント側で生成される場合、トークンコストはゼロであると主張されました。しかし、これは、エージェントがマルチターン会話を通じて反復的に行われる際、プロンプトや応答の中にIDが存在することによるコストを履歴-として無視しています。

プロンプト・インジェクション: 単語ベースのIDが、もし偶然にも一貫性のあるフレーズを形成した場合、指示として誤解されたり、プロンプント・インジェクションに寄与したりする理論的な懸念があります。ただし、ワードリストの厳選された性質が、これを軽減することを意図しています。

結論

id-agent は、識別子の考え方における転換を表しています。従来のソフトウェアでは、ストレージと一意性のために最適化します。エージェント型AIの時代においては、トークナイザーのために最適化しなければなりません。コンテキストウィンドウを制約されたリソースとして扱うことで、id-agent は、コストを削減し、AIエージェントの信頼性を向上させる実用的な方法を提供します。

Sources