AIエージェントの知識表現と推論に なぜグラフが使われるのか - 記号的AIの復権とニューラルAIとの統合

Transcript

1. AIエージェントの知識表現と推論に なぜグラフが使われるのか 記号的AIの復権とニューラルAIとの統合 大西 洋平 MLOps・LLMOps・AgentOps 勉強会 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会
2. 1｜本発表の概要 本発表の概要 何を発表するの か？ 古典的AIの時代からある知識グラフ／オントロジーが再び注目される背景と、AI エージェントで活用するための判断軸を整理する なぜ発表するの か？ 知識グラフやオントロジの概要を理解している人が オントロジや知識グラフに対 する過度な期待と関連技術との混同を避けられるようにするため 何を持ち帰って ほしいか？ 知識グラフ・オントロジは万能でも必須でもない。自社の課題に必要か、人間が どこまで設計すべきかを判断する視点 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 2
3. 2｜Databricks / Snowflake が発表したもの 2026年、Databricks / Snowflake がオントロジ自動構築を発表した Snowflake Databricks オントロジ構築 Cortex Sense Genie Ontology（OntoRank） オントロジのデータソース （データカタログ） Horizon Unity Catalog エージェント CoWork / CoCo など Genie One など カタログのメタデータや利用履歴からデータの意味や定義を裁定し、エージェントへ 注入 ≠ 人手で全社オントロジーを先に書く ≠ Text-to-SQL 丸投げ 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 3
4. 3｜オントロジーと知識グラフとは何か 知識グラフとオントロジーとは何か？ 用語 何か グラフ 点と線で関係を表す 構造一般（道路網も SNS も） 知識グラフ 業務の実体と、意味のある関係を載せた 実態 オントロジ 許される概念・関係の型・制約 (設計図・物差し） 例: 「部品 —使われる→ 製品」は許可。 「サプライヤー —使われる→ 製品」は型としておかしい、と止められるのが物差し 側。 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 4
5. 4｜例: SPDM の簡易オントロジ 例: SPDM の簡易オントロジ（製造業） SPDM = Simulation Process and Data Management 設計工程における数値シミュレーションの流れ・条件・結果を一つの枠でつなぐ管理 材料／荷重 条件 具体化する 要求・設 計・試験な どの仕様書 根拠となる 解析要件／ 解析条件 規定する 解析ケース 対象とする ⼊⼒する モデルを持 製品／部品 つ CADモデル 起動する シミュレー ション ソルバー 使う 出⼒する 属する 結果 ⽣成する メッシュ ⼊⼒する 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 5
6. 5｜グラフは既存システムを置き換えない グラフはデータ統合のための足場である - 既存システムを置き換えない 置き場（SoR／基盤） 何を置くか（例:SPDM） ワークフロー管理システム 解析ケースの進行、承認、タスク状態 CAD (Computer-Aided Design)／ PDM (Product Data Management) CAD モデル本体、版管理 CAE (Computer-Aided Engineering) ジョブ定義、ソルバー設定、実行ログ オブジェクトストレージ メッシュ／結果ファイル（大容量バイナリ） 文書管理 or ベクトル 要求・設計・試験などの 仕様書本文（意味検索） グラフ 上記の ID と関係だけ（部品 ケース 実行 結果 仕様） 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 ↔ ↔ ↔ ↔ 6
7. 6｜RAG の地図 — いつグラフが候補になるか RAG／知識取得の地図（得意／苦手） グラフが何かを置き換えると言うより、これら全てを適材適所で総動員する 手法 得意 苦手になりやすい ベクトル 似た文書・仕様書の意味検 索 厳密な論理関係の多段追跡 RDB / SQL・セマンティック層 集計・定型の正確な数値 アドホックな多ホップ Agentic Search （リンク巡回） ゆるい文書網の探索 大規模構造化・厳格な ID 連鎖 知識グラフ 関係の連鎖・経路の説明 構築・保守コスト（必須ではない） 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 7
8. 7｜物理グラフDBである必要はあるか — 必須ではない 常に物理グラフDBである必要はない — 規模や複雑さによる やり方 向くとき（ざっくり） 設定ファイル 関係が少なく、人が読んでメンテできる RDB＋SQL 結合パスが既知・定型で足りる 仮想グラフ (Spark, PostgreSQL など） グラフ的に見たいが専用DBなしで済ませたい 物理グラフDB 関係が大規模・複雑で、多段探索を高速に回したい 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 8
9. 8｜なぜ知識表現と推論にグラフを使うのか — 古典からの蓄積を使える なぜ知識表現と推論にグラフを使うのか — 古典からの蓄積を使える 1. 知識表現・推論の蓄積 — 古典的 AI／セマンティック Web の資産に乗れる 古典哲学:「存在・概念・関係」で世界を整理する発想（オントロジーの語源） 古典的 AI（1970s〜）: 意味ネットワーク／フレーム。概念をノード、関係をエッジ で表現 2000年代: セマンティック Web。RDF（三つ組）・OWL（より厳密な意味・制約） 2. グラフアルゴリズムが便利 — 探索・重要度・クラスタを定石で使える 最短経路、PageRank、コミュニティ検出、類似検索など SQL 手書きより格段に楽 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 9
10. 9｜なぜ過去10年ほど聞かなかったか — セマンティック Web の挫折 なぜ最近までオントロジ・知識グラフが話題にならなかったか 2000年代、オントロジー最大のアプリ＝セマンティック Web が普及せず、 オントロ ジーへの失望が生まれたから セマンティック Webの目標 - 世の中の知識を 数学的・論理的に厳密に書きさえすれ ば、機械が推論する 全ての知識を人力で厳密に書き続けるには、労力が足りない 厳密推論は重い。当時のコンピュータでは実務規模で回せないことが多かった 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 10
11. 10｜Google 知識グラフの成功（2010年代） Google 知識グラフは成功した（2010年代〜） 概念のグラフ構造を自動構築する。検索キーワード に関連する概念を芋づる式に引っ張り、より深い文 脈の検索結果を出せる 人力で全集を書くのではなく、統計・機械処理・分 散でスケールした 厳密定義の書き続けではなく、機械側が主力（キュ レーションは最小） 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 11
12. 11｜なぜ今また着目されるか — 記号 × ニューラル なぜ今また着目されているか 古典的 AI 時代の 記号的 AI の弱点を、 ニューラル AI（LLM） が補えるようになった LLMで知識の獲得・構築がスムーズになる 構築した知識構造で推論の妥当性を検証（グラウンディング） 記号的 AI ニューラル AI（LLM） 例 ルール、RDF/OWL、KG上の決定論的クエリ LLM たとえ コンクリート（硬い） スポンジ／粘土（柔らかい） 強み 厳密・正確・再現しやすい 柔軟・それっぽく使える 弱み 融通が効かない／管理コストが高い 厳密性に欠ける／間違う 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 12
13. 12｜獲得・構築・保守に、またボトルネック 形を変えて残る、知識獲得ボトルネック LLM を使う と知識の獲得と構築が楽になる。しかし、LLMは 間違えるかもしれない。 LLMの間違いを考慮して、人手のレビューや清書を入れると、労力がかかる 人間のエキスパートが厳密にオントロジを書く と、正しさは上がるが、スケールしな い どちらもプロセスが重く、セマンティック Web と同じ問題に陥る 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 13
14. 13｜PF 再訪 — Google と同じ構成が、いまも続く 2010年代と同じ問題構造を解こうとしている Google 知識グラフ（2010年代） Snowflake / Databricks オントロジ（2026） 材料 Web のリンク・利用など カタログ上のクエリ・BI・メタデータ やり 方 統計・機械処理・分散で半自動 利用統計で定義を裁定し注入 狙い 人が全集を書かずにスケール 獲得ボトルネックを迂回し、AI が推論できる状態を作 る 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 14
15. 14｜まだ始まったばかり — 人間のモデリングは続く されど人間がオントロジーをモデリングする時代は続く 2026年、特定ベンダーが PF依存でオントロジー自動構築を提案し、世間に広がりつ つあるが、全員が恩恵を受けるわけではない（他製品は未対応） Googleが アルゴリズムで知識グラフを自動構築 したが、それでも人間のキュレーショ ンは残った いま残る／残りそうな人間の仕事: 1. モデリングする領域は残る（型・線引き・競争領域の正しさ） 2. 自動化されている領域でも、すべてが自動になるとは限らない 3. 人間が機械に ヒントを与えて自動化をスムーズにする仕事も残るかもしれない 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 15
16. 15｜現代のデータエンジニアリングの道具としてのオントロジー （再解釈）現代のデータエンジニアリングの道具としてのオントロジー （スキーマ・制約）・・・オントロジー＝グラフのスキーマと制約がこうあるべきという定義 自動生成 モデル 入力データのバリデーション・LLMがクエリを生成する際のヒントに使う グラフ へ投入 非同期 グラフが壊れていないことを検証 YAML ↓ Pydantic ──▶ ↓ DB ↓ Cypher/SHACL ──▶ オントロジはデータ・グラフ基盤の維持管理を楽にするデータエンジニアリングの道 具にもなる 詳細・コードは GitHub／Zenn 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 16
17. 16｜まとめ — 持ち帰り まとめ 1. 知識グラフ＋オントロジーは知識構造と推論に有効な分野がある — だが獲得・構築・ 保守にボトルネック（LLM支援でも残る） 2. PFでの自動オントロジ構築はまだ始まったばかり — ベンダーPF依存の自動も進むが、 人間のモデリング／ヒント出しは続く 3. 置き換えない／DEの道具 — グラフは既存や他RAGを消さない。オントロジーはスキー マ・制約・検証に使う 大西 洋平 / MLOps・LLMOps・AgentOps 勉強会 17