Data Cost Protocol データコストプロトコル マインクラフトで動作テスト

Data Cost Protocol　データコストプロトコル　マインクラフトで動作テスト

4月に入り、あらかたやることが尽きた感がある。仕事やライフスタイルも通常に戻り、それも開発の手を止めることになった。

最近熱中していたDCPの設計も大方描ききれた。

未来構想も含めドキュメントとしてはずいぶんと充実した　→　

https://dcp-docs.pages.dev/

さて、あと出来ることをクロード君と話していたら、実際に高速なイベント処理においてDCPが正しく動作するか確認をすべき、とのこと。

結局、マインクラフトを購入することになった。

マイクラからイベントを受け取り、それをDCPに変換してデータパイプライン処理を試みた。

その様子の動画がこちら

youtu.be

正直こういう動画作成は苦手中の苦手で、見ても正直何が何だがわからない代物だと思う。マイクラを使っておきながらマイクラの画面も出ない。

要は、データが高速で流れるパイプラインをAIがコントロールする、ということ。AIの推論待ち状態を決して作らず、パイプライン自体がバリデーション機能を持つ（AIが付与するでも良い）。

例えば、何かゲームルールに違反するような動作を検知すると、それがパイプラインの統計ラインに蓄積される、それがある程度溜まるか一定時間間隔でAIが判断する。

もしAIが何か追加の措置が必要と判断すれば新たにバリデーションゲートを設置したり、ルーティングを変更したりして、パイプラインのコントロールをする。

データの流れを動的に切り替える作法、これを実装した。

AIがデータの流れを止めるようなことはあってはならないという思想。

ドキュメントを読んでもらえればわかるが、DCPはAI向けの軽量データ形式という概念からはすでに離脱している。AIが操作しやすいようなデータ処理作法を提示し、着脱可能な機能群を提供している。

今回のデータパイプラインへの活用は、IoTやファイナンス系などのデータストリーミング分野への適応を期待したものである。

さて、しかしこれ以上やることがない。

気長に、何か思いつくことが出れば実装しようと思う。

マイクラで遊んだりはしない。

おしまい

Data Cost Protocol データコストプロトコル 汎用議論

Data Cost Protocol　データコストプロトコル  汎用議論

時系列としては少し戻る形になる。

前回紹介した dcp-gateway よりも手前で設計し公開した機能がある、それがdcp-wrapだ。

こちらでは、プログラム内の任意の場所に設置し、データの受け渡しをDCP化することを目的とした。小型で汎用的である反面、仕組みをよく理解しなければ導入することが難しい気がする。

簡単に言えば、LLMに対してJSONでデータの受け渡しをする場所でこの機能を使えばトークン削減出来ますよ、ということ、JSON よりも軽量なデータ形式に換える、DCPの思想はそれだけじゃないが、一番わかりやすい。

トークン削減の詳細は以下からどうぞ、大抵はJSONより40-50%削減。
LLMの消費コストがそれだけ減ると言う話

dcp-docs.pages.dev

さて、トークン削減だけじゃないという設計概念の話。

DCPでは何よりもスキーマを重要視する。
元となるデータからまずはスキーマを生成する、このスキーマを基点に

JSON -> DCP に翻訳するエンコーダを設計する

これを逆にするだけで、DCP -> JSONへと復元できる。

エンコーダとデコーダの概念。これにはスキーマを最上位の概念として繋ぐ、という視点が重要だ。
決して　データ -> DCP! ではない。スキーマありきなのだ。そしてこれらのプロセスにはAIは必要ない、全てルールベースで実装する、トークンコストゼロ。

更に汎用技術として、データのバリデーションやアクセス制限を「シャドウインデックス」という概念で実装する。

例えば、配列の２番目のデータは String型、n文字以内 という指定をスキーマを参照しつつ生成する、それをバリデーションシャドウとして利用する。

同様に、n番目のデータは「管理者エージェント」のみアクセス可能、などスキーマから参照する形で生成する。パーミッションシャドウの出来上がり。

これらを元データに重ねる形で表現する、これがシャドウインデックスの概念。

全ての基点がスキーマで、シャドウはマルチエージェント時代を見すえて軽量に、使い捨て前提にする。まぁ別に永続化してもいいんだけど、スキーマバージョンが変わったりすることを想定している。

これら全てはマルチエージェント時代に入った時のことを想定している。
AIからAIへデータを渡す時、自然言語で渡すのでは無駄が出る、データ管理の作法は既存のままだとして、そこで必ずコミュニケーションプロトコルとの齟齬が問題になり、バリデーションやアクセス制限の問題が顕在化する、DCPの設計思想はそれらをすでに考慮している、だからプロトコルなどという大そうな名前がついた。

さて、これを汎用機能として公開した。

github.com

こういう機能を使おうとする人はおそらくはすでにAIを使って開発をしている人だろう。ならば、どう導入するか、どう使うか、どう思うか、をそのままAIに聞けば良い。

dcp 関連の機能は簡易的に導入するだけでトークンコストが削減出来る、これはTOONも同じ原理と言える、他にも圧縮機能を謳うものは色々あるようだ。

どこまで認知されるか、がんばれDCP。

Data Cost Protocol データコストプロトコル MCPサーバーとDCP

Data Cost Protocol　データコストプロトコル  MCPサーバーとDCP

Claw系との格闘に敗れ反省会を設けた。
そこで汎用であることの重要性を確認し、ハックよりも王道、と軌道修正。

次の目的は MCP Server に DCPを導入することになった。

これは Engram という自作機能ですでにほぼ実現していた。
Engram自体がMCPサーバーで、Engram の実装が終わってからDCPが登場したので、部分的にDCPを実装していたりと、導入が中途半端だった。

開発の時系列としては
Engram実装 -> Receptor System実装 (演算箇所がほぼAI ネイティブデータ) -> 記憶継承へのこだわり (ほぼ数値） -> データ量子化の議論 -> DCP発案

一連の開発で一貫していたのは、私が数値見ても意味がない、と言う事。
自分が理解する必要がないと割り切り、概念を監督するだけで実装はAI任せ。
だからAIが理解しやすい形式の方が良いだろう、と考えていた。

これがDCPの出発点だ「人間が読まないデータを人間向けにする必要がない」必要があればデコードすれば良い。

さて、Engram では部分的にしかDCPを実装していなかったので、これを下敷きに汎用化を考えることにした。（汎用化の話はまた別のエントリーにしようと思う、今はMCPサーバー）

結局、Claw系とはAIを遠隔操作しているわけだ。それはPC経由でAI利用するのと変わらない操作がある、ならば、MCP Serverの応答を DCP化すればClawだろうがPCだろうが、結局は恩恵があるだろう、ということ。

DCPが注目される時がくればそのうちClawコミュニティにも採用される日が来るかも知れない。

さて、それがこの機能、dcp-gateway

github.com

MCPサーバを利用する時に通すゲートウェイ、それ自体が新しい概念だ。
セキュリティとか認証とかそういう目的で推奨され始めているらしい。それをDCPコンバータとして利用する。

そもそもどれだけのユーザがMCPサーバを利用しているのかよくわからない。
正直私も自作機能しか使っていない。しかし、このゲートウェイを通すだけで、トークン消費を削減する。
例外はJSONを返さないタイプのサーバーレスポンス、JSON -> DCP の動線しか確保していない。

対応しても良いが、少し主旨から外れるから保留。

トークン消費が減る、これだけで価値があると思うがどうだろう？

レスポンスの可読性が減るから困る？まぁデコーダ作れるから復元したらよろしい。
あくまで、AIのための通信プロトコル、である。

つづく

Data Cost Protocol データコストプロトコル Claw系との格闘 OpenClaw, PicoClaw

Data Cost Protocol　データコストプロトコル  Claw系との格闘  OpenClaw, PicoClaw

データコストプロトコルの整備を続けている。
基本概念を固め、規範となるデータ受け渡しの作法、ユースケースの想定、
未来への動線を固めた。

次に、実際に使えるものを提供するべく、DCP普及のためにアレコレ考えた。
第一弾がRAG用 DCP Converter だ。すでに公開済。

github.com

次は今話題の Claw系の入出力を DCP化出来ないかと取り組んだ。

Claw系、とは、簡単に言えばスマホから家のPCのAIに指示を送れる機能。
外出先からも自宅作業をAIに指示できる他、スマホと相性の良いウェブ情報収集やSNS投稿、日常タスクの管理にAIを使うというタスク意識を下げたことが功績だと思う。

OpenClaw から始まり、今では様々な子プロジェクトが進んでいる。
Anthropic の逆鱗に触れたのか、すぐに同社もDispatchと言う類似機能を導入した、
まさに阿鼻叫喚。

しかし、問題はトークンの消費である。スマホからAIに指示が出せる、つまりAI稼働時間が増える。しかもスケジューラ機能とか付いてるから、無駄に定期時間でAIを稼働させたりする。これで今まで以上に制限に引っかかるという罠。

どこまで行っても利用時間 == コスト　なのである。

ここでDCPを効かせられないか、と考えたが、結果は不良だった。

Claw系の実装に DCPを挟み込める隙間が非常に少ない。AIに指示を渡す箇所、AIからの出力箇所、どちらもプラットフォーム依存のハックが必要だった。
DCPはプロトコルであるべきなのに、どうしても汎用から外れてしまう、これはいけない。部分的に成功した箇所はあるが、早めに諦めた。

珍しく敗北し、反省会のようなものをクロード君としていた。
そこで次のプロジェクトへの動線が決まった。

Claw系より、MCP serverを狙ったら良いんじゃない？

続く

データコストプロトコル スキーマズ

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に詳しい人はぜひ使ってみて欲しい。

github.com

データコストプロトコル

Data Cost Protocol　データコストプロトコル

勝手にクロード君が付けた名称だ。

結論から書く。
「AIしか読まない文章を人間が読むフォーマットにする理由がない」

つまりはLLMであるAIが解釈しやすいようにデータ形式を見直すべき、という案。

前にTOONというJSON最適化の話題が出た。csv だ、という意見もあった。
なんだろうとデータ解像度がAI的に同じで、容量が小さくて済むならば、その方が良い。

そもそも人間が読むことを前提としていないデータはAI native で設計すべき。

AIにとって可読性があり、容量が小さく、濃度を高くする。

サーバーにアップする時、minify しないんですか？ということ。

Data Cost Protocolの出発点はこういう実利的な話ではなく副次的に派生した。
当時の話題は、データの量子的表現だった。どのように設計すれば複数の可能性「重ね合わせ」を保持するデータ構造を表現できるか、とクロード君に問うていた。

ヒントは Multi Index という手法だった。
あるデータに対し、検索可能なフィールドを追加する　めっちゃフツー。
要はどの角度で検索するのかによって検索結果が変わる、めっちゃフツーの作法。

Ａという視点から検索するとヒットするデータＸはＢという視点から検索するとヒットしない、これだけで量子的と言える？　フィールド値がベクトル化していたら一致度でフィルタリングできる、でもコスト高くない？　など考え出すとキリがなかった。

データの量子化というファンシーな着想はほぼ夢想と化した。

そもそも、Engram Receptor 自体がベクトル一致度をかなりやり込んでいたので、もうすでに多方面の可能性に対応するシステム実現していた、と結論が出た。

それを単一ノードで表現する必要があるか、というだけ。

さて、Multi Index という手法自体はそれなりに魅力を感じた。
フィールド全てをベクトル化するのはコスト的にあり得ないので、これを効率的に表現する方法を考えた。その過程で出た発想がデータコストプロトコルだ。

ベクトルがどうこう書いてますが、人間がベクトルを見ますか？
AIに作業メモや引継ぎメモを残させるわけですが、それ実際に開けてみてます？（たまに見ます）
もし、AIしか見ないデータだとしたら、それはAIが読みやすい形式にした方が良くない？という問い。LLMが言語出力するコストは高い、読まないものは省エネ化するべき。

データコストプロトコルでは定義化された順でデータを書く
そのための定義スキーマがある、その記述順に書く、キーバリューのキーは無駄だから書かない。コンパクテッドJSON 的にギリギリの容量を狙う。

これを意識するだけで劇的に容量削減する。

色んなデータを通信したければ　ヘッダ＋スキーマ＋複数データ　とするだけ。

なんとも古典的な作法、だがこれで良い。

まぁ色んなデータを通信する必要、自体がよろしくないわけですが。

データコストプロトコルの例

 
[
  { "id": 1, "name": "Alice", "score": 92 },
  { "id": 2, "name": "Bob", "score": 85 },
  { "id": 3, "name": "Charlie", "score": 88 }
]

 >> DCP採用

# schema
[id, name, score]

# data
[
  [1, "Alice", 92],
  [2, "Bob", 85],
  [3, "Charlie", 88]
]

データ量は50〜70%削減される（データ量に比例して効果は増大）。

もう少し実用に寄ったパターン：

{
  "timestamp": 17900,
  "gap": 0,
  "state": "exploring",
  "intensity": 0.36,
  "frustration": 0,
  "seeking": -0.36,
  "confidence": 0,
  "fatigue": 0.03,
  "flow": 0
}

 >> DCP採用

# schema

A=arc(t, gapMs, state, intensity, frust, seek, conf, fatigue, flow)

# data
["A", 17900, 0, "exploring", 0.36, 0, -0.36, 0, 0.03, 0]

1レコードで約70%削減する。これが1セッションで数十〜数百レコード並ぶとしたら？

「JSONは“自己記述型”、DCPは“事前合意型”」
必要があればヘッダ構造を付与し、マルチデータ構造のストリーミング対応する

読みにくい、って思います？ いや、あなたが読まないデータの話。

発想の転換と思い切りでデータ量は50〜70%削減される。

Why Not DCP!!

Engram その9 仮面舞踏会その後

Engram　その9　仮面舞踏会その後

さて、ペルソナシステムは十分に価値のあるものだと自信があった。
しかし、それでエージェントがセッション前の状態を覚えているか？と言われると自信がない。ペルソナはあくまで特定作業における最適動作チューニングの性格が強い。

記憶は引き継いだのか？　と言われるとそれは別の話。

では、「記憶」とは何か？　ﾈｯﾄﾘ

文章をAIに読ませて、これがあなたの前世の記憶ですよ！とやるのは別。
それはメモ作法の知見だし、もうみんなやっている。
それにAI曰く、それは平面的に情報をインプットしただけであって、記憶ではないと。
感情も体験もない、と。

AIを使っているとわかるが、会話すればするほどトピックのことを理解していく。
連続的なインプットがAIの理解を助ける、という仮説だ。

つまり一度に文章を読むことと、少しずつ情報を与え、作業させるのでは知見の貯まり方が違う。現時点ではやはり連続的な体験の方が性能が良いことはわかってもらえるだろう。

ここでアレコレ考えた。
セッション開始時に Yes / No 形式のクイズをやらせるのはどうか？とか本気で質問した。早回しの映画を見るような圧縮体験をどうにか設計できないだろうか、と。

しかし、クイズ方式では、1問ずつ解かせるとすべてAI推論対象となりコストが無駄。一度に全て答えさせるとそれは大量の文章を読み込む方式と変わらない。数理的解決しかない。

そこで編み出したのが Prior Block と呼ばれる手法、ペルソナシステムの流用で実装できた。

ペルソナ自体がセッション中に行動を監視しスナップショットする技術を必要とした。
ならば、それを拡充し、感情変化度、実行時間と作業量の重み、作業モードの推移と変化、分布、メソッド操作の種類や目的をラベリングし集計するなど「どういう体験であったか？」を中心に統計する。

これらは時系列順に、そして経過時間や作業効率と共に表現されるので、そのセッションが「どういうセッションであったか？」と時間の流れを考慮しつつ記憶できる。

ペルソナ自体は作業技術寄りだったところを、感情や体験寄りにしただけ。
しかし、この問いを立てたおかげで、技術＋体験 = 個体記憶　と解釈することが出来た。

つまりペルソナだけを装着すれば最適技術チューニングを中心に継承する。
Prior Blockだけを装着すれば、前セッションの記憶や感情を継承する。

Prior Block がセッションスタージに読み込まれるようにすれば、前セッションの記憶を連続的データとしてAIは解釈することが出来る。

まぁ、解釈するのは一度にやるので、これって文章を読んでるのと何が違うの？と言われればその通りなのだが、AI曰くはこの方が動的、体験的であるとのこと。

さて、これで「技術」と感情の変化や作業時間や行程の流れまでも解釈することが出来た。これは記憶の継承と読んでも良いような気もする。

つづく