エンタープライズナレッジグラフ

データベースにはデータが保存されます。ナレッジグラフはデータを意味のあるものにします。

もっと正確に言うと、エンタープライズナレッジグラフは、既存のデータプラットフォーム（Databricks、Snowflake、SAP、Microsoft Fabric、その他のシステム）の上に置かれるセマンティックオーバーレイで、データドメイン間の接続を明示的でクエリ可能で、AI対応にします。データを移動したりコピーしたりせずに。

これが主な違いです。リレーショナルデータベースでは、エンティティ間の関係は暗黙的で、外部キーとJOIN操作に埋もれています。異なるドメインの5つのテーブルをつなぐには、開発者、作業日数、あらかじめ決められた質問が必要です。ナレッジグラフでは、人間関係は第一級です。明確に定義され、意味的に意味があり、ミリ秒単位で移動できます。

その結果、クロスドメインの回答が必要になるたびに、データチームにカスタムクエリの作成を依頼する代わりに、接続されているどのドメインでも、アドホックでリアルタイムであらゆる質問をすることができます。

これがナレッジグラフをAIの基礎にしている理由です。データプラットフォームは、データがどこにあるかを教えてくれます。LLMは言語の処理方法を教えてくれます。ナレッジグラフは、データの意味とつながりを教えてくれます。その第3層がなければ、AIエージェントは検索できますが、推論することはできません。

GraphRagはナレッジグラフを使用して、LLMが情報を取得する方法を改善しています。ベクター検索に加えて、構造、関係、エンティティ解決が追加されています。似たような文書を見つけるだけでなく、「誰が誰とつながっているのか」などの関係的な質問に答えたり、事実データに基づいてAIが応答したりして、幻覚を減らすことができます。
それは有意義な一歩でした。しかし、それはGenAI向けに設計されていました—取得して応答してください。エージェントAIは違います。エージェントは質問に答えるだけでなく、複数のステップにわたって計画、推論、行動し、多くのドメインにわたるワークフローごとに数十から数百のクエリを発行します。

そこでGraphRagは壁にぶつかります：

-エージェントは、グラフでは答えられないクロスドメインの質問をします。そのドメインが含まれていなかったからです
-エージェントが大量のクエリを発行すると、グラフが大きく崩れます
-複数のエージェントが、アーキテクチャが構築されなかったリソースをめぐって争っています
-グラフにはメタデータレベルの埋め込みが含まれていますが、エージェントが確実に行動するために必要なビジネスコンテキスト全体ではありません

問題はコンセプトではありません。天井です。1つのチームと1つのユースケース向けに構築されたポイント・ソリューション・グラフは、エージェントで構成される企業のコンテクストレイヤーにはなり得ません。そのためには、根本的に異なるものが必要です。それは、機関レベルのエンタープライズ規模のContext Graphです。幅に上限がなく、エージェントの流れを保つのに十分な速さでクエリパフォーマンスを実現できるものです。

なぜなら、AIエージェントは質問に答えるだけではないからです。彼らは計画を立て、理由を立て、行動します。そして、それを確実に行うためには、1つのシステムだけでなく、企業全体にまたがるコンテキストが必要です。

ほとんどの組織は、関連文書を取得してLLMに提供し、回答を生成するRetrieval-Augmented Generation（RAG）からAIの旅を始めました。RAGは文書Q&Aにはうまく機能します。しかし、必要なときにはすぐに機能しなくなります。

• 構造化データ — RAGは「シフトごとの生産利回りはいくらですか？」と答えられません。データベースから。
• 関係 — RAGには、「このサプライヤーがこの製品にコンポーネントを提供し、それがこの顧客に出荷される」という概念はありません。
• マルチホップ推論 —「サプライヤーXが遅れた場合、どの顧客が危険にさらされるのか」などの質問似たようなテキストを取得するのではなく、複数の事実をつなぎ合わせる必要があります。

チャットボットからエージェントAI（質問に答えるだけでなく行動を起こすエージェント）に移行すると、リスクは高まります。影響を受ける顧客を誤認し、誤った通知を送信するエージェントは、単に間違った答えを出すだけではありません。間違ったアクションを取ります。

ナレッジグラフは、エージェントに根拠のある構造化されたクロスドメインコンテキストを提供することでこれを解決します。すべての回答はソースデータまでさかのぼり、すべての関係は明確で、ビジネスが関心を持つすべてのドメインは単一のセマンティックレイヤーでつながっています。

経済的な議論もあります。AIの価格設定が消費ベースのモデルに移行するにつれて、知識グラフなしで業務を行うエージェントは、クロスドメインの回答をブルートフォースして10〜20倍のトークンを消費します。企業規模（1日に数百件のエージェントからの問い合わせ）では、そのコスト差は重要です。ナレッジグラフは、よりスマートなアーキテクチャだけではありません。それは一番安いものです。

ナレッジグラフは、Databricks、Snowflake、SAP、または既存のデータプラットフォームに取って代わるものではありません。セマンティックレイヤーとして一番上にあります：

• データはそのまま残ります。記録はSAP、Teamcenter、Snowflake、S3など、現在保存されている場所ならどこにでも残ります。
• グラフはセマンティックオーバーレイを作成します。つまり、ソースシステムからデータを取り込んだり仮想化したりして、オントロジーに従ってデータを接続します。
• 消費者は、AIエージェント、SPARQLクエリ、REST APIs、BIツールなどのグラフをクエリし、さまざまな分野にわたる回答を得ます。
• 段階的です。1つの価値の高いユースケースでは、2つまたは3つのデータドメインから始めましょう。そこから拡大してください。ボイル・ザ・オーシャンは必要ありません。

重要なメンタルモデルの変化：顧客はしばしば、ナレッジグラフはデータの移行または置き換えを意味すると想定しています。そうではありません。RMGSは、すでに持っているもの、つまりそれらのプラットフォームをエージェントAIに役立つものにしているセマンティック結合組織と連携します。彼らのDatabricksへの投資はなくなりません。それがグラフの上にある基盤になります。

ナレッジグラフは幅広い業界で使用されています。データが複数のシステムにまたがってサイロ化されていて、クロスドメインの質問には迅速で信頼できる回答が必要な場合に適しています。

製造会社や工業企業は、これらを使ってPLM、ERP、MES、サプライチェーンのデータをつなげて、「このサプライヤーの品質問題の影響を受ける出荷製品はどれですか？」などの質問に答えます。— 単一のシステムだけでは答えられないことです。製薬会社やライフサイエンス企業は、製造、品質、規制システム（GSKはライブプロダクションのリファレンスです）にわたる4つ以上の階層レベルにわたるバッチ系図や規制コンプライアンス、資料の追跡に大いに依存しています。金融サービス企業は、カウンターパーティリスク、詐欺検出、ESGリスク分析にこれらを使用しています。1つの本番環境では、数百億のエンティティがリアルタイムで処理されます。医療機関は、まったく別のシステムに保存されている臨床業務、医療機器追跡、創薬データを結び付けて、患者の経過と臨床結果を全体的に把握します。また、ハイテク企業やフィールドサービス企業は、構造化された知識グラフと構造化されていないサービス文書を組み合わせることで、複雑な製品構成の質問に答えることができるAIアシスタントを強化するためにそれらを使用しています。

共通点は業界ではなく、ドメイン間のデータの複雑さです。顧客が、1つのシステムでは答えられない質問をしている場合、その顧客は候補者です。

いいえ。あなたのデータはそのまま残ります。

これは、現代のエンタープライズナレッジグラフの仕組みを理解する上で最も重要なことの1つです。記録はSAP、Teamcenter、Snowflake、S3など、現在保存されている場所ならどこにでも残ります。ナレッジグラフは、既存のシステムから読み込んで、データプラットフォーム上の計算されたセマンティックビューを作成します。コピーではありません。新しいサイロではありません。これは、データ間の接続を明確にするライブでクエリ可能なレイヤーです。

SQLビューとマテリアライズドテーブルのようなものだと考えてください。ナレッジグラフはビューです。それを構築するためのロジックはすべて永続化され、バージョン管理されていますが、データ自体は既存のシステムから流れます。ソースプラットフォームは、信頼できる情報源であり続けます。

これが重要な理由は3つあります。

• Governance。データが管理環境から離れることはありません。それをサードパーティのプラットフォームに渡さないと、リネージやアクセスポリシーを制御できなくなります。
• 重複はありません。別のコピーを個別に管理、同期、管理する必要はありません。
• 段階的な採用。最初のユースケースで重要なデータソースを接続します。最初にデータレイクにすべてを含める必要はありません。ナレッジグラフは、JDBC、APIs、ファイルベースの取り込みを介してソースシステムに直接接続します。

簡単に言うと、ナレッジグラフはデータの移動を求めません。すでに存在している場所であなたのデータに出会います。

これは、エンタープライズグラフプロジェクトで最もよくある間違いであり、修正するのが最も費用がかかる間違いです。



パターンは予測可能です。チームは特定のユースケースに合わせて、開発者が使いやすいグラフデータベース（Neo4j、Amazon Neptuneなど）を選びます。パイロットは成功します。コンセプトは実証済みです。それから、企業はもっと多くを求めます。



ユースケース2には別のデータモデルが必要です。ユースケース3には、接続されたことのないシステムからのデータが必要です。ユースケース5では、クロスドメインインテリジェンスのない、複数の切り離されたグラフがあり、最初と同じサイロの問題がグラフレイヤー内で再現されています。



最終的にエンタープライズ規模が必要になったとき、建築の限界に気づきます。

• データ量だけでなく、クエリの複雑さ。グラフデータベースには数十億のノードを格納できます。彼らが苦労しているのは、何十億もの複雑なマルチホップ分析クエリ、つまりAIエージェントが生成する正確なクエリプロファイルを実行することです。そこで建築が決定的です。
• 大規模な ETL。カスタムETLパイプラインを介してグラフデータベースにデータを読み込むことは、ポイントソリューションに適しています。企業規模では、建物の価値よりもパイプラインを管理するエンジニアの方が多くなり、スキーマを変更するたびに何かが壊れます。
• オントロジーの限界。対象分野の専門家によって構築された単一ドメインのオントロジーは、1つのチームで機能します。企業全体で10ドメインまで拡張することはできません。

この壁にぶつかる代償は、技術的なことだけではありません。グラフ、パイプライン、アプリケーションの再構築にかかる移行コストです。拡張できないプラットフォームを実証するのに2〜3年かかりました。それは機会費用です。一方、最初に正しいアーキテクチャ上の決定を下した競合他社は、すでに企業全体でエージェントを運用しています。



パイロットのために選んだプラットフォームが、企業の天井になります。正しい質問は、「このツールは私の最初のユースケースに対応できますか？」ではありません。— それは「このプラットフォームを私のエンタープライズナレッジグラフの基礎にすることはできますか？」