Knowledge Graph
読み: ナレッジ・グラフ
ナレッジグラフとは知識の構造化
現実世界のヒトやモノおよびコトをエンティティとして捉えそれらの複雑な関係性をネットワーク状に結びつけるデータ構造。AIに人間のような文脈理解と論理的推論を可能にさせる基盤技術。
かんたんに言うと
点と点を線で結ぶ星座表のようなものである。単なる星の羅列ではなくどの星とどの星が繋がって何の形を成しているのかをシステムに教え込む。
Knowledge Graphがエンティティと関係性で構築する知識ネットワークの全体像
従来のリレーショナルデータベースは行と列の表形式でデータを管理する。だが現実世界のデータはそんなに綺麗に収まらない。
そこで登場するのが知識グラフである。
顧客や商品といった実体をノードとし誰が何を買ったかという関係性をエッジとして表現する。表の結合を繰り返すSQLの苦行から解放されデータ同士の繋がりそのものを直接クエリできる。
ただこれを構築するのは口で言うほど簡単ではない。データの正規化とは全く異なる頭の使い方を要求されるからである。
現場を動かすグラフデータベースの実力と代表的プロダクト
Googleの検索結果の右側に出てくる情報パネルを見たことがあるだろう。あれが知識グラフの最も身近な例である。
では企業内ではどう使われているのか。
例えば法務部門。数万件の契約書から特定の条項変更がどの取引先に影響するかを瞬時に特定する。あるいは物流部門でサプライチェーンのを可視化する。ここで活躍するのがNeo4jやAmazon Neptuneといったグラフデータベース製品である。セマンティックウェブの文脈ならOntotext GraphDBも選択肢に入る。
どれを選ぶべきか。用途によってクエリ言語もCypherかSPARQLかで分かれるためインフラ担当の好みだけで決めるのは危険である。
LLMの弱点を補うRAGへの応用とオントロジー設計の泥沼
最近はLLMのハルシネーション対策としてRAGのバックエンドに知識グラフを据える構成いわゆるGraphRAGがもてはやされている。ベクトル検索だけでは拾いきれない複雑な文脈を補完できるのは確かに懸かっている。
だがここで現場は深い沼にハマる。
オントロジー設計。社内の用語定義や概念の階層構造をどう設計するか。営業と経理で同じ言葉でも意味が違うことはザラにある。これを統一してグラフ化する作業は技術というより社内政治に近い。
どこまで厳密に設計すべきか実務では常に判断が分かれる。完璧を求めれば永遠にリリースできない。
複雑なデータ構造に立ち向かうための投資判断
自社のデータが単なるマスタの羅列ならわざわざグラフデータベースを入れる必要はない。
製造業の部品構成表のように階層が深く関係性が複雑に絡み合うデータ構造を扱う場合に初めて真価を発揮する。PoCを回すならまずは既存のRDBでクエリのパフォーマンスが限界に達している領域を狙うべきである。
ROIをどう算定するかは悩ましい。検索精度の向上を金額換算するのは至難の業だからである。
流行りだからと飛びつく前に自社のデータが本当にグラフ構造を求めているのか。泥臭いデータクレンジングの覚悟はあるのか。そこを問うてからでも遅くはない。
当社の見解
当社はAI長期記憶システムを自社開発・運用している。開発のきっかけは、AIと経営戦略の壁打ちで出した結論がセッション切れで消えたことで絶望を感じた。1日かけて議論してきたことを振り返り、では事業計画書に落とし込むように指示を出したところ、「そのような記録はありません」と言われたことで、強烈な危機感を覚えこれは何としても解決しなければならない問題だと感じた。記憶がないAIは毎朝記憶喪失になる新入社員と同じだ。記憶があるAIは、前提条件を理解した上で本題に入れる。短いプロンプトで済むようになり、「前に言ったように実行して」と曖昧で短いプロンプトでも業務を遂行してくれる。同じことを繰り返し伝える回数も減り、開発業務でも同じミスを繰り返しにくくなり、人間の手戻りが減り、ストレスも減る。AIで本当に業務の質を上げるならば、記憶はマストである。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。