エージェントと情報を共有する方法(OKFに似た実装)

ここ2週間ほど東京にいてあまり作業できませんでしたが、相変わらずLegionを作っています。

「ウェブリサーチ」というエージェントを作って、「お題」を元に深掘りしてレポートを書くようなことをさせるようになりました。

それはいいんですが、その「レポート」は返答にすると一過性になってしまうので、どこかに文書として置きたいなと思いました。現実にはそこはあまり指定しなくても、エージェントのワークスペースに自動的に作ってはいるんですが、もうちょっと見易い場所に作らせたいと思ってました。

そこで思いついたのは、

人間とAI共通の知識ベースのWikiを作る

ということです。

概要

特に何も難しいことではありません。

エージェントがWikiを操作できるようにして、Wikiの読み書きをさせます。もちろんWikiですから人間も読み書きできます。 AIが読み書きできるわけですから、人間がその内容を操作すると、AIも動作が変わります。

たとえば「マニュアル的知識」をWikiに書きます。

もちろん人間はその「マニュアル」に従うことを期待します。と言うか、そのためのマニュアルなわけです。エージェントもそれが読めます。そのマニュアルにあることであれば、それに従った動作をしてくれます。と言うか、そうなるような指示を与えておきます。

これをすると何が嬉しいかと言えば、「人間とエージェントの両方に意味のあるskills」が作れたりします。もちろん一般の知識ベースと言うかWikiとして使えます。

たとえば「コーディング規約」とか、人間もエージェントも遵守して欲しいですよね。そもそも、このWikiの運用自体も、人間もエージェントも遵守して欲しいですよね。

これはLLM-Wikiが発想の元にありますが、もうちょっと「協業」を意識しています。つまり、エージェントも主体の一つであって、人間と対等な扱いです。でもまぁ似たようなもんっちゃー似たようなもんです。客観的には「個人用」かどうかの違いくらいじゃないかと思います。

実現

just ideaだったので、とりあえずお手軽にWikiシステムは用意しないで、単にそういうディレクトリツリーを用意しました。将来作るWikiシステムは、そのディレクトリツリーを操作できればいいだけですから、何も問題は起きないでしょう。「Wikiらしい編集」とか「メタデータの自動メンテナンス」ができないだけで、構造的にはそのまま使えますからね。

そして、それぞれのフォルダにはindex.mdを用意して、

ここにはどんな情報があるか
個々の情報へのポインタ
その他説明

を書いておきます。こうしておけば、人間もエージェントも「ここにはこういったことを書くのだな」「このスペースの利用規約はこうなんだな」というようなことがわかります。

実際の情報は、とりあえずMarkdownで書くことにします。ディレクトリツリーに過ぎませんから、とりあえず普段エントリを見るためにはexplorerかdired的なものをそのまま使います。実際にはMarkdownのファイルを主に操作するので、VSCodeで… ってやることが多いですけど。

このディレクトリツリーをLegion(のバックエンドエージェント)から読み書きできるように環境設定しておきます。具体的には、sandboxの設定に追加します。

exec bwrap \
  --die-with-parent \
  --share-net \
  --unshare-pid \
  --unshare-ipc \
  --ro-bind /usr /usr \
  --ro-bind /bin /bin \
  --ro-bind /lib /lib \
  --dir /etc \
  --ro-bind /etc/resolv.conf /etc/resolv.conf \
  --ro-bind-try /etc/hosts /etc/hosts \
  --ro-bind-try /etc/nsswitch.conf /etc/nsswitch.conf \
  --ro-bind-try /etc/gai.conf /etc/gai.conf \
  --ro-bind-try /etc/services /etc/services \
  --ro-bind /etc/ssl /etc/ssl \
  --ro-bind ./src /src \
  --ro-bind ./node_modules /node_modules \
  --ro-bind ./.env /.env \
  --ro-bind ./config /config \
  --ro-bind ./roles /roles \
  --bind ./workers /workers \
  --bind ./workspace /workspace \
  --bind /home2/public/knowledge /knowledge \  ここです
  --bind ./logs /logs \
  --proc /proc \
  --dev /dev \
  --tmpfs /tmp \
  --chdir / \
  /usr/bin/node src/cli/index.js --debug llm --watch --persona ${PERSONA}

インデスク化(たとえばQMDを使うとか)やベクトルDB化は今のところはしていません。データが増えれば作るべきだと思いますが(一応用意はしてある)、index.mdがうまくメンテされていれば、特に何もしてなくてもいい感じに辿ってくれます。つまり、あえてRAG的なメカニズムを用意しなくても、file_readだけで使ってくれます。人間も活用するということを考えれば、ディレクトリ構造を優先した方が嬉しいですね。

エージェントには「内心」の部分があるのですが、そこはWikiには入れません。「内心」をデバッグ以外の目的で操作するのは、倫理的に許されない… と思っていると共に、そこは「内心」としてエージェントがメンテしているので、下手に人間が操作すると謎動作の元になるからです。

効果

効果は絶大です。

人間とエージェントが直接共働できますし、エージェントに「index.mdメンテしておいて」という指示も出せます。もちろんエージェントの作るレポートもそこに置かれますから、

人間の知識ベースに蓄積される
エージェントの知識ベースになる
各エージェント同士の情報共有の場となる
情報が有機的に結合する

というように、まぁ良いことずくめです。

情報はWikiに直接見に行くこともできますし、エージェントに聞くこともできます。もちろんエージェントとのチャットで、Wikiの内容について言及することもできます。

OKF

これでいい感じだなと喜んでいたらGoogleから、

Introducing the Open Knowledge Format

というエントリが出て来ました(私はこれを読む前に考えて実装してます)。

AI(ちゃっぴー)に

Googleがこんなこと言い出したな
https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/

と言ってみたら、

かなり雑に言うと、おごちゃんが今作っている ./knowledge/wiki の設計は、方向性としてOKFど真ん中です。

と言って、あれこれ類似点や問題点の指摘があったのですが

今の設計をOKFに寄せて変える必要はない。
今の設計がすでにOKF的なので、将来必要になった時だけ front matter を足せばいい。

ということで、「俺が先だ」とは言わないまでも、ほぼ同時期に同じようなものを考えていたことになります。

その上で、ちゃっぴーと会話していてOKFの問題点をいくつか発見しました。

OKFには情報の多重管理が少なからずある
タグは人類がメンテするものではない
全体に冗長

それぞれちょっとだけ余分に説明します。

OKFには情報の多重管理が少なからずある

これはおそらく可搬性とのトレードオフとなることだと思うのですが、たとえば「文書のフォーマット」を書くことになっていますが、そもそもそういったものは

見ればわかる

ものです。「肉眼」で見えなくても、file(1)やstat(2)でわかります。こういったものを特に意味もなく書かせるのは、単に間違いの元でしかありません。

同じようにタイムタンプ的なものも、人間がメンテするよりはstat(2)でやるべきでしょう。

タグは人類がメンテするものではない

OKFにはタグが指定できます。

タグは便利なものです。下手なベクトル化よりも期待通りの結果を返してくれます。人間もエージェントも理解しやすいです。

とは言え、人間にタグをいじらせると、

揺らぐ
記者のクセや習熟度の影響を受ける
そもそも適切なものを付与するのが難しい

というような問題があります。

ですから、一昔前ならしょうがないにしても、現代で人間が付与したりメンテナンスしたりするようなものではありません。使いものにならないゴミの山を作り始めることになりかねません。

全体に冗長

既に挙げたようなものの他にも「別にそれ個々のファイルが持たなくていいよね」的なものが少なからずあります。

これは多分にファイル単位でのハンドリングを意識したものだろうと思うのですが、そもそも「組織化されたエントリ群の個々のエントリをハンドリングする」ということは、あまり良いことと言えません。と言うのも、「知識」には「文脈」が存在しているので、知識の断片に過ぎない単体のファイルは、持ち運べても嬉しさが少なくなります。せっかくの有機結合が切れてしまいます。

というように、ちょっと考えれば「いらない」という結論になるような情報であっても、盛り込みがちな設計になっています。「先々」を意識してそうなっているのだろうというのは簡単にわかりますが、「やり過ぎ」感が強くて「そのうち面倒臭くなるぞ」という感じがします。

とか思うと、現段階でOKFに完全準拠とか、そういった方向性で考えるだとかいうことは、しなくてもいいなというのが個人的な結論です。あくまでもエッセンスだけ戴けば良いでしょう。