グラフ型データベースのAIエージェント、運用して分かった難しさ
グラフ型データベースをAIエージェントの知識基盤として使うと、単純な文書検索よりできることがかなり増えます。
「この情報はどこから来たのか」「これを変えたら何に影響するのか」「前の決定と今の決定はどう違うのか」みたいなことを、文章の近さだけではなく、情報同士の関係をたどって探せるからです。
ただ、実際に長く使ってみると、作るところより運用の方がかなり大変でした。情報は古くなるし、業務を理解するほどデータの構造も変わるし、関係を増やしすぎると今度はAIの検索精度が落ちます。
この辺は、実際にやるまであまり見えてなかったところです。
まず、情報は普通に古くなる
一番分かりやすいのがナレッジのドリフトです。
会社の情報って固定されていません。顧客の状況も変わるし、社内ルールも変わるし、仕様も変わります。開発の文脈なら、要件もユーザーストーリーもずっと増えるし、途中で普通に変わります。
ここで困るのが、元の情報を更新しても、そこから作った情報まで勝手に新しくなるわけではないことです。
資料を直した。でも、その資料から以前作った要件や仕様は古いまま。検索側から見ると、どちらも普通に存在しています。
だから、元情報が変わった時に、そこから派生した情報まで再確認できるようにしておかないといけません。
どこから来た情報かを残しておかないと更新できない
変更を下流へ伝えるには、その情報が何から作られたのかを追える必要があります。
途中の取り込み処理で出典を落とすと、その時点では問題なく使えても、後から更新できなくなります。
なので、内容だけではなく、どの情報源から来たのか、いつ作られたのか、どの判断を根拠にしたのかまで残しておく必要があります。
AIが自動で関係を作る場合も同じです。人が明示的につないだのか、AIが推論してつないだのか、どのくらい確からしいのかが分からないと、後から関係を見直せません。
フローの情報と、今の正解は分けた方がいい
運用していてかなり大事だったのが、流れてくる情報と、現在の正しい状態を分けることです。
会議、チャット、コメント、検討中の資料みたいなものはフローの情報です。重要ではあるんですけど、そこに書いてあることがそのまま現在の仕様とは限りません。
一方で、現在の要件、現在の仕様、現在有効な契約、現在採用しているルールみたいなものはストックの情報です。
AIに「今どうなってる？」と聞いた時は、基本的にこっちを見せたいです。「なんでこうなったの？」を知りたい時に、会議や変更履歴まで戻ってたどればいい。
この二つを混ぜると、会議中に出ただけの案と、正式に決まった仕様が同じ強さで検索候補に入ってきます。
何を正本にするかは最初に決めておいた方がいい
もう一つ大事なのが、同じ事実を複数箇所で編集できる状態にしないことです。
顧客情報は顧客管理、契約は契約情報、現在の要件は要件管理、コードはリポジトリ、みたいに、何をどこで正とするかを決めておいた方がいいです。
グラフ側に全部コピーして、そこも編集可能にすると更新経路が増えます。最初は同じ値でも、片方だけ更新されてズレることがあります。
グラフ側は、それぞれの正本をつないで、「この要件はこの議事録から出た」「この仕様はこの要件に対応している」みたいな関係を持つ方が扱いやすいです。
オントロジーは、終盤まで完全には決まらない
値が変わるだけならまだ分かりやすいんですけど、実際にはデータの構造そのものも変わります。
業務を深く理解する前に、「何が存在して、何と何がどう関係するか」を最初から完全に決めるのはかなり難しいです。
最初は一つの概念で十分だと思っていたのに、ヒアリングを続けると二つに分ける必要が出たり、新しい関係が必要になったりします。逆に、最初に作った関係がいらなくなることもあります。
グラフ型データベースは後からノードや関係を追加しやすいので、この変化には強いです。でも、スキーマレスだから設計しなくていいわけではありません。
むしろ変えやすい分、オントロジーの変更をちゃんと管理しないと後から効いてきます。
構造を変えたら、既存データも移行する
オントロジーを変更したら、既存データも新しい構造へ移します。
対象データを洗い出して、新しいノードや関係を作る。既存データを埋め戻す。古い関係を削除する。読み取り側も新しい構造へ切り替える。必要なら検索用の索引や意味検索用のデータも作り直します。
結局、普通のデータベースと同じで、構造変更には移行処理が必要です。
最初から完璧なオントロジーを作ろうとするより、最初は崩したくない最小限だけ決めて、業務理解が深まるたびに直していく方が現実的だと思っています。
要件が増えるとエッジも増える。でも、増やしすぎると精度が落ちる
運用を続ければ、情報はどんどん増えます。当然、それをつなぐエッジも増えます。
必要な関係が足りなければ、影響分析もできないし、AIが必要な文脈までたどれません。
ただ、関係を増やせば増やすほど良くなるわけでもないです。
ある情報について周辺を探した時、関係の種類や本数が多すぎると、直接必要な情報だけではなく、少し関係があるだけの情報まで大量に検索候補へ入ってきます。
その結果、AIへ渡す文脈の中で、本当に重要な情報の割合が下がります。
現実を細かく表現できるグラフと、AIが検索しやすいグラフは、必ずしも同じではないです。
なので、何をつなぐかだけじゃなく、どの質問でどの関係をたどるのかまで考えないといけません。
エッジを一つ増やすだけでも、意外と影響範囲が広い
新しい関係を追加する作業自体は簡単です。
でも、その関係を追加したら、検索でたどるのか、影響分析に含めるのか、削除時にどう扱うのか、孤立したデータとして検知するのか、変更伝播に使うのか、といった横断処理も見直す必要があります。
関係の意味を変えるなら、既存データの移行も必要です。
グラフのモデルは柔軟なんですけど、その変更に検索、削除、完全性チェック、変更検知、評価まで追随させないと、別の場所で不整合が出ます。
更新基盤そのものの保守も結構重い
情報源を増やすと、取り込み処理も増えます。
追加、更新、削除、権限変更、重複排除、再実行、失敗時のリトライまで考える必要があります。
さらに、グラフ本体とは別にベクトル検索や意味検索用の索引を持っている場合は、片方だけ更新されることもあります。
グラフには新しい情報があるのに検索側にはない。逆に検索側には古い情報が残っている。こういうズレも普通に起きます。
なので、更新処理を作ったら終わりではなくて、その更新処理がちゃんと動いているかを監視したり、データ同士の件数や状態を突き合わせたりする仕組みまで必要になります。
精度が落ちても、AIエージェントは普通に動く
この手のシステムでかなり厄介なのが、壊れても明確なエラーにならないことです。
古い情報が少し混ざる。余計なエッジが増える。同じ対象が重複する。構造変更後に検索経路が一つ抜ける。
それでもAIエージェントは普通に回答します。
回答品質が少しずつ落ちても、人間が数件確認しただけでは気づきにくいです。
だから、評価の仕組みも最初から運用基盤の一部として持っておいた方がいいです。
構造を変えるたびに、同じ質問で再評価する
代表的な質問と、その質問で見つけてほしい情報、期待する回答をあらかじめ用意しておきます。
関係を追加した時、オントロジーを変えた時、検索方法を変えた時、新しい情報源を追加した時に、同じ質問群を再実行します。
- 必要な情報を検索できたか
- 余計な情報を取りすぎていないか
- 回答と参照元が一致しているか
- 期待した関係をたどっているか
- 応答時間が悪化していないか
- 処理量や費用が増えすぎていないか
特に見たいのは変更前より悪くなっていないかです。
エッジを追加したら余計な情報を取るようになった、構造を変えたら特定の質問だけ必要な情報へ到達しなくなった、みたいな劣化を継続的に拾えるようにします。
AIで開発するなら、タスク管理も同じ流れで追わないと厳しい
これはKG一般の運用とは少し別で、開発で使っていて感じることです。
AIでコードを書く速度が上がると、要件整理、ユーザーストーリーへの反映、仕様変更の影響確認、その先のタスク更新が人手のままだと、そこが詰まります。
ヒアリングで新しい条件が分かる。要件を更新する。ユーザーストーリーが変わる。仕様が変わる。タスクが変わる。実装する。顧客に見せる。また新しい条件が分かる。
自分たちは開発のタスク管理には、PM on Railsを使っています。要件、ユーザーストーリー、シナリオ、タスクまで同じ流れで追えるようにしています。
AIで実装が速くなるほど、ここを別々に管理して人が同期するのはかなりきついです。少なくとも自分たちは、もうそのやり方には戻れないなと思っています。
結局、作るより運用の方が難しい
グラフ型データベースをAIエージェントの知識基盤として使うと、できることはかなり増えます。
ただ、要件は変わるし、情報は古くなるし、オントロジーも変わるし、エッジも増えます。更新基盤も保守しないといけないし、精度が落ちても普通に返事は返ってきます。
作る時はどうやって知識を増やすかを考えるんですけど、運用が始まると、何を正しい情報として守るか、どう更新するか、どの関係を残すか、精度が落ちた時にどう気づくかの方が大事になってきます。