はじめに
今回は、NoLLMの第2弾となります！。
まずは、はじめに断っておきたいのですが、
NoLLMは、決して、既存のLLMを排除するものではありません。
むしろ、LLMとNoLLMは適材適所で上手に住み分けられる関係になると考えています。
早速ですが、ぜひ、お付き合いください！。
本題
まず、LLM単体でのサービス運用では、ReplitやCursorのような事故が今後も起こると予想します。
ですので、それを防ぐためにも、NoLLMをここで提案したい訳です。
私の考えでは、今後、LLMは、ユーザー意図の抽出・返答メッセージの生成と、
コーディングの三つに役割が絞られていくと考えています。
LLMを直接に実行環境と接続すると、先の例の通り、また同様の事故が起こりかねないからです。
したがって、私の考えるアーキテクチャでは、
「DROP TABLE」「DELETE *」「rm -rf」「system()」「exec()」などの危険操作は、DSLの文法上、そもそも組み込まないのです。
つまり、実行環境へのアクセスはNoLLMに担当させて、それ以外はLLMに担当させるという全体設計になります。
さらに、前回の考察からいくらかの追加・変更点があります。
リレーショナルデータベースには、各属性次元を処理する関数コードをASTないしDSL形式で登録しておきます。
これに対して、グラフデータベースには、リレーショナル側に登録されている各関数へのIDを登録しておきます。
より具体的には、「[ウマ] → (模様の変化) → [シマウマ]」というエンティティとノードがあるとすると、
「[ウマ] → (模様の変化: 関数ID) → [シマウマ]」といった具合に、属性変化を表現・実装します。
※もちろん、この関数は、安全サンドボックス内で実行され、メモリー・ファイル・ネットワークへのアクセスは制限されます。
※そして、その関数コードの実行が安全だと確認されたら、本番環境に対してステージを変更して実行されるというイメージです。
※ちなみに、事前の許可のないリソースアクセスに関しては、その関数の実行前に、実行が拒否されるものとします。
ここで、LLMは、ユーザーからのフンワリとした指示の下で、具体的な関数コードを生成して、
それをNoLLMが検証して、安全性が確認されたものだけをリレーショナルベースに登録するという流れになります。
まとめ
●LLM単体では、重大事故を根本的に回避できない。
●NoLLMと組み合わせることで、重大事故を防ぎつつ、
AIシステム全体の持続的な学習・適応が可能になる。
おわりに
いかがでしたでしょうか？。
これは、アイデア段階での提案なので、実装や実証はまだですが、
年内には、自分の手で、このアーキテクチャのPoCをしようと考えています。
また懲りずに記事を書いていきたいと思います！。
それではまた～。