Data Cost Protocol データコストプロトコル 汎用議論
時系列としては少し戻る形になる。
前回紹介した dcp-gateway よりも手前で設計し公開した機能がある、それがdcp-wrapだ。
こちらでは、プログラム内の任意の場所に設置し、データの受け渡しをDCP化することを目的とした。小型で汎用的である反面、仕組みをよく理解しなければ導入することが難しい気がする。
簡単に言えば、LLMに対してJSONでデータの受け渡しをする場所でこの機能を使えばトークン削減出来ますよ、ということ、JSON よりも軽量なデータ形式に換える、DCPの思想はそれだけじゃないが、一番わかりやすい。
トークン削減の詳細は以下からどうぞ、大抵はJSONより40-50%削減。
LLMの消費コストがそれだけ減ると言う話
さて、トークン削減だけじゃないという設計概念の話。
DCPでは何よりもスキーマを重要視する。
元となるデータからまずはスキーマを生成する、このスキーマを基点に
JSON -> DCP に翻訳するエンコーダを設計する
これを逆にするだけで、DCP -> JSONへと復元できる。
エンコーダとデコーダの概念。これにはスキーマを最上位の概念として繋ぐ、という視点が重要だ。
決して データ -> DCP! ではない。スキーマありきなのだ。そしてこれらのプロセスにはAIは必要ない、全てルールベースで実装する、トークンコストゼロ。
更に汎用技術として、データのバリデーションやアクセス制限を「シャドウインデックス」という概念で実装する。
例えば、配列の２番目のデータは String型、n文字以内 という指定をスキーマを参照しつつ生成する、それをバリデーションシャドウとして利用する。
同様に、n番目のデータは「管理者エージェント」のみアクセス可能、などスキーマから参照する形で生成する。パーミッションシャドウの出来上がり。
これらを元データに重ねる形で表現する、これがシャドウインデックスの概念。
全ての基点がスキーマで、シャドウはマルチエージェント時代を見すえて軽量に、使い捨て前提にする。まぁ別に永続化してもいいんだけど、スキーマバージョンが変わったりすることを想定している。
これら全てはマルチエージェント時代に入った時のことを想定している。
AIからAIへデータを渡す時、自然言語で渡すのでは無駄が出る、データ管理の作法は既存のままだとして、そこで必ずコミュニケーションプロトコルとの齟齬が問題になり、バリデーションやアクセス制限の問題が顕在化する、DCPの設計思想はそれらをすでに考慮している、だからプロトコルなどという大そうな名前がついた。
さて、これを汎用機能として公開した。
こういう機能を使おうとする人はおそらくはすでにAIを使って開発をしている人だろう。ならば、どう導入するか、どう使うか、どう思うか、をそのままAIに聞けば良い。
dcp 関連の機能は簡易的に導入するだけでトークンコストが削減出来る、これはTOONも同じ原理と言える、他にも圧縮機能を謳うものは色々あるようだ。
どこまで認知されるか、がんばれDCP。
