Knowledge Navigation Layer

Repository ExplorerとPivot Reasoning Engineには、Knowledge Navigation Layerというものが入ります。

ClaudeやCodexなどが使うエージェントファイルと似たものに、Navigation Policyを書いて、それを読んだKnowledge Navigationがアプリケーションコードを呼び出す仕組みです。

最近、よく目にするPalantirという会社がありますが、この会社はAIそのものを作っているというよりは、AIを動かす環境を含めたアプリケーションを顧客に合わせて仕立てる会社と言った方が実態に近いでしょう。

Palantirによって有名になったOntologyという考え方は「世界はこう見える」というモデルをアプリケーションに焼き込むものです。
目的は意思決定を速くすること。
販売戦略をどんなタイミングで実行に移すか、いつ敵のどこを攻撃すべきか、みたいなことを速くしたい。

Knowledge NavigationのPolicyには、このOntologyを載せることができるので、Knowledge Navigation Layerを持ったアプリケーションは、Palantirが作っているようなものに似せられる。

ただ、ZIKUUの場合は、販売戦略や戦争には関心がないので、それをやらない。
できてもやらない。

もっとも一人で開発しているので、企業や軍専用の意思決定支援システムの実装をするほどのマンパワーはありません。

だから、小さなコンポーネントを、抽象を保ったまま、つまり柔軟性を維持したまま、開発して、用途ごとに部品を入れ替えるという構造にしています。

Knowledge Navigation Layerはいくつかのクラスから構成されます。

この2枚のスクリーンショットは、Repository Explorerと Pivot Reasonin Engineのプロジェクトを開いた様子で、どちらにも同じnavigationというパッケージが入っています。これがKnowledge Navigation Layerの実体。

Repository Explorerは収束型、Pivot Reasoning Engineは発散型のPolicyを入れます。

収束型は、答えが出れば終了。

この2枚のスクリーンショットは、Repository Explorerを実際に動かした様子です。

質問に対して、調査対象の候補を見つけ、調査計画を立て、調査を実施して根拠を見つけたら、それを回答の根拠として積み上げ、一通り根拠候補が集まったら、回答を作成する。
「一通り根拠候補が集まった」で収束するというものです。
つまり問いを閉じるのが目的。

対して、発散型は、Pivot Serviceの複数の観測面を眺めて、傾向、関連、偏りを検出して、仮説を積み上げてまとめます。

その上で、

「これが答えです」
ではなく
「これはこう見える」けど「こういう見方も可能かもしれない」
と返す。

つまり、問いを返すことが目的で、問いを閉じない。
人間は問い続ける存在としてAIに向き合います。

Repository Explorerに関しては、最終的に200万行ほどになるソースコードを対象にすることになるし、Pivot Reasoning Engineに関しては、日々蓄積されるニュース記事、活動記録、会話、小説や教科書、論文といった膨大な資料が対象です。

これらは人間の認知能力を遥かに超えた情報空間を構成するから、人間が把握して理解するのは不可能です。それを補助するための道案内や示唆をするのが、Knowledge Navigationというわけです。