Data Cost Protocol データコストプロトコル スキーマズ
「AIしか読まない文章を人間が読むフォーマットにする理由がない」
そういうフォーマットを考えた話。
こういう風に記述する
# schema
[id, name, score]
# data
[
[1, "Alice", 92],
[2, "Bob", 85],
[3, "Charlie", 88]
]
AIは一度スキーマを与えられるとデータの位置でキチンと把握してくれる。
むしろJSON式に何度も同じキーが繰り返される方がノイズとして処理の邪魔をするとのこと。人間にはわかり辛い記法はAIにとってはそうではない。
ま、そう言うんだからそれで良い。DCPの記法を使うととにかくデータサイズが減る。
さて、ここに来てSchema スキーマと呼ばれる規範が非常に重要であることがわかる。
これがなければデータの順番が何を表しているのかがわからないからだ。
↓これ
# schema
[id, name, score]
クロード君のような優秀なAIならば一度確認すればその後何件パースしようとスキーマを正確に覚えていてくれる（らしい）
別の形のデータを渡したいって？ ならば別のスキーマを作りなさい
# schema
[id_cities, cityName, country, population]
DCPの理想の利用法では、同じ形のデータを連打するケースを想定している、この種類のシステムには相性抜群で、効果は極めて大きい。
もしコロコロと違うデータ形式が流れるようなら スキーマ＋データ のパケットとして送信することになる、あんまりおすすめしないが。
そういうことのないようなシステムラインを検討すべき。
どの道、DCPならスキーマがいっぱい増えるじゃないかって？まぁそうなる。
我々が知っている古典的スキーマというのは非常に地味な存在である。
一度作成したらドシッと構え、めったに変更しないアンタッチャブル、まさに規範なのである。
しかし DCP においてはスキーマはよりアクティブな存在にならざるを得ない。
そして、スキーマ＋データ のコンビネーションが入り乱れるのは中々に鈍重だ。スキーマ自体が結構な文字量を含む可能性がある。
ならばどうするか？
答えは簡単、スキーマを別ファイルに一覧定義してIDで管理する。
エージェントは扱うデータのスキーマ定義をまず見るが、その後はSchemaIdでしか表示されない。つまり
schemaId: a21,
# data
[
[1, "Alice", 92],
[2, "Bob", 85],
[3, "Charlie", 88]
]
こう簡略化される
もしAIがスキーマ定義をまた参照したければ当然IDから検索をかけて閲覧する。
スキーマ定義をリストしたテーブルが一元管理され、データ処理ラインもコンパクトに。
これすべて、AIのトークンコストに直結する。
AIが見る文字数が少なければコストダウンする。出力する言葉が少なければコストダウンする。そして、AIは一般的JSONよりも DCP 記法を好む。試しに聞いてごらんなさい。
仮に軽量AIがスキーマID＋DCPの略式を解釈できないようなら段階的に対応すればよい。軽量AIには定期的にスキーマデータを処理ラインにはさむ、など。
このあたりは開発しながら今後テストしていくと思う。
さて、試しにRAGの処理ラインに入れられるような機能を作った。
RAG の出口ではLLMにデータベースからのデータが成型されたものが渡され、AIが解釈しユーザに渡すことになる。ここに DCP変換器を取り付ける
RAG --> データ成型機能達 --> DCP Formatter --> AI --> 人間
DCPは正直RAGとは相性が悪い。なぜなら、RAGの基本は文書（文字）の保存であり、それらはDCPが触るものではない、つまり文書度が高ければ高いほどDCPの活躍の場面が減る。それでも活躍できる部分がある、それはメタデータである。
RAGから取り出したデータには必ずメタデータが付いている。
それをDCP記法に変換する、やってみるとメタデータ部分の削減率は 40 -- 60% にもなった、凄い。
文書部分がメインだから全体では 10 -- 15%程度の削減率に落ち着きそうだが、それでもこれを付けるだけでトークンコストが減る。パフォーマンスは変わらないどころか、清潔なデータに変わるので、むしろAIの調子が良くなるかも知れない。
正直RAGというのはスフィアプロジェクトに取ってライバルのような存在のいけすかん奴だ。それでもDCPの使い道を考えた時に知名度のあるRAGに適応したらどうなるか、とヒントをくれて実装にまで及んだ、感謝せねばなるまい。
以上、公開してあるからRAGに詳しい人はぜひ使ってみて欲しい。
