AI利用には、依然として解決困難な課題がある。
生成AIと呼ばれるものは、文字や単語の続きを推論するシステムのこと。もっともらしい続きの言葉を紡ぐ装置だ。
あなたは、自分の金銭的な取引、契約、医療行為、裁判をサイコロを振って決めるか？
生成AIがやっていることは、統計的にそれらしい言葉を出力する、つまりサイコロを振っている。
AIへの熱狂の裏にある真実だ。
これは特性なので、仕方のないことだ。
新しい仕組みを考えるか、そういうものだとして使うしかない。
低性能なAIは、露骨にいい加減な文章を出力する。
これは平和だ。
すぐに気づいて対処できるから。
高性能なAIが、99%の確率で正しい回答をしたとする。
机上で遊んでいるうちは、妄想文章を書いているうちは、それでも問題ないが、実際の取引、契約、医療、裁判に接続すると、そういうわけにはいかない。
1%の蓄積がいずれ大きな問題を引き起こす。
実際に、保険会社の中には、AIの生成物よる被害は補償しないと謳うケースが出ている。
要するに誰が責任を取るか、責任を取るためにどうやって検証するか、という当然のことが抜けている。
これは倫理や道徳の問題というよりも、工学的な問題として対処するのが先決だ。
AI業界は、膨大な借金をして開発資金に投資をしていて、止めるに止められない状況にある。
使う側も、金儲けに目がくらんで、面倒くさいことには手を出さない。
ZIKUUのシステムの重要な部分、CPS、PRE、Repository Explorer、AI塾長には、Observablity APIを入れようと思っている。
もともとZIKUUのソフトウェア群は、それぞれに責務を明確に分けて、問題の所在を発見しやすい設計になっているが、それだけで不十分だ。
ここでいうObservabilityは、CPU使用率、ログ、メトリクスのような通常の運用監視ではない。
対象は、
- 何を入力として受け取ったか
- 何を観察したか
- 何を候補として扱ったか
- 何を選択したか
- 何を捨てたか
- 何を根拠としたか
- どのような処理経路を通ったか
- 最終的に何を出力したか
という、知的処理そのものの観測可能性である。
重要な判断を行うコンポーネントは、その入力・観察・選択・根拠・出力を外部から追跡可能でなければならない。
Observability APIは、内部DBや内部実装をそのまま公開するものではない。
各コンポーネント内部の情報を、評価・検証・説明に使える安定した形式へ投影する。
この境界を持つことで、内部実装が変更されても、観測側を可能な限り安定させる。
CPS Observability
CPSでは、入力データがどのように文脈束へ変換されたかを観察可能にする。
主な観測対象は以下。
- セグメント境界が妥当か
- 重要情報が欠落していないか
- 元文にない情報が混入していないか
- 重複抽出していないか
- provenanceが保持されているか
- Recipe変更前後で何が変わったか
Repository Explorer Observability
Repository Explorerでは、最終回答だけでなく、調査経路を観察対象とする。
- 正しいリポジトリを選べたか
- 必要なファイルを見つけられたか
- 無関係な探索が多すぎないか
- 根拠が実際のコードに存在するか
- WikiやZDLを見るべき場面で参照したか
- 同じ調査を不要に繰り返していないか
などを評価する。
PRE Observability
PREでは、
- どのDetectorが発火したか
- 何を根拠に発火したか
- 何を発火させなかったか
- どのContextを選んだか
AI塾長 Observability
AI塾長では、単純なPrompt / Responseではなく、
- 必要なツールを使ったか
- 不要なツールを使っていないか
- 必要な文脈だけ取得したか
- 既知情報を再質問していないか
- 原因確認中に修正提案していないか
- 根拠のない回答をしていないか
などを見る。
ここまでは「AIとはそういうものだ」を受容した対策だ。
これらはZIKUUの知的処理のObservabilityであって、LLM自体のObservabilityではない。
「AIはこうあるべきだ」は、LLM自体のアーキテクチャーも含めて、独自開発する必要があるかもしれない。
案としては、
マイクロカーネル方式で知識専門家を動的に抜き差しできる構造のLLM
だ。
カーネル部には、専門家ルーターと観察・遡及ができる機能を持たせる。
専門家を抜き差しできることで、必要なものだけ、必要な場所で動かせる。
ほとんどOS開発のようになる。
これについては、じっくり考えようと思う。
