「ナレッジグラフを必要とする理由と、それを構築する方法」

Reasons for needing a knowledge graph and how to build one

関係データベースからグラフデータベースへの移行ガイド

要約: 知識グラフは、イベント、人物、リソース、ドキュメントをグラフデータベースで高度な分析のために組織化します。この記事では、知識グラフの目的を説明し、関係データモデルをグラフモデルに変換し、データをグラフデータベースにロードし、いくつかのサンプルグラフクエリを作成する基本を紹介します。

なぜ知識グラフが必要なのか？

関係データベースはリストを作成するのには適していますが、多様なエンティティのネットワークを管理するのには向いていません。関係データベースを使用して以下のタスクを実行したことはありますか？

• 数十人、場所、手順と相互作用するヘルスケアのケアエピソードを分析する
• ベンダー、顧客、取引タイプが関与する金融詐欺のパターンを見つける
• サプライチェーンの依存関係と相互接続された要素を最適化する

これらはすべて、イベント、人物、リソースのネットワークの例であり、関係データベースを使用しているSQLアナリストにとって非常に困難なものです。ネットワークのサイズが増えるにつれて、関係データベースは指数関数的に遅くなりますが、グラフデータベースは比較的直線的な関係を持ちます。もし活動や物事のネットワーク、またはウェブを管理しているのであれば、グラフデータベースが適切な選択肢です。将来的には、企業のデータグループが、1つのビジネス機能に対して分離された分析に関係データベースを採用し、複雑でネットワーク化されたプロセスに対して知識グラフを採用することが予想されます。

グラフデータベースをベースにした知識グラフは、多様なプロセスとエンティティのネットワークを処理するために構築されています。知識グラフでは、人物、イベント、場所、リソース、ドキュメントなどを表すノードがあります。ノード間のリンクを表す関係（エッジ）もあります。関係は、データベース内で名前と方向を持って物理的に格納されます。すべてのグラフデータベースが知識グラフであるわけではありません。知識グラフとして認識されるためには、ノードと関係の名前には明確なビジネス名が反映され、複数のビジネス機能をまたがる異なるセットのノードが含まれるデザインである必要があります。つまり、相互作用するビジネスのすべての部分からシームレスなウェブを作成し、データをそれらが表すプロセスに密接に結び付けるためにビジネスセマンティクスを使用します。これは、将来の生成的LLMモデルの基盤となることができます。

• Pythonコード生成のためのLlama-2 7Bモデルのファインチューニング
• 現実世界における数学：テスト、シミュレーション、その他
• 「企業がデータにアプローチする方法を変えるジェネラティブAIの5つの方法（そして変えない方法）」

知識グラフでさまざまなデータを示すために、サプライチェーンのロジスティクスの単純な例を見てみましょう。ビジネスプロセスは次のようにモデル化されるかもしれません：

このモデルは、顧客の返品、請求書、原材料、製造プロセス、従業員、さらには顧客レビューなど、ビジネスプロセスの関連部分を含めるように拡張することができます。事前に定義されたスキーマはないため、モデルは任意の方向や深さで拡張することができます。

関係モデルから次元モデルへからグラフモデルへ

さて、典型的な関係データベースモデルをグラフモデルに変換するプロセスを、電子商取引ベンダーのシナリオを使って説明しましょう。このベンダーは、ウェブサイトでのデジタルマーケティングキャンペーンを展開し、注文を受けて商品を顧客に出荷しています。関係モデルは次のようになります：

これをデータウェアハウスで使用するための次元モデルに変換すると、モデルは次のようになります：

注：ファクトテーブルはイベントに焦点を当てており、ディメンションテーブルはビジネスエンティティの属性をすべて1つのテーブルに組み合わせたものです。このイベント中心の設計は、クエリ時間を短縮しますが、他の問題を引き起こします。各イベントは異なるファクトテーブルであり、関連するイベントからの接続を見ることが困難です。複数のファクトテーブル間に関係が分割されている場合、製品のようなディメンションエンティティと他のディメンションのエンティティとの共有するイベントのすべての関係を理解する簡単な方法はありません。ディメンションモデルは1つのイベントに焦点を当てますが、異なるイベント間の接続を不明瞭にします。

グラフモデルは、エンティティ間の相互関連性を表示する問題を解決します。プロセスを次のようにモデリングします：

最初に見ると、このグラフモデルは次元モデルよりも関係モデルに似ていますが、データウェアハウスと同じ分析目的に使用することができます。各関係は名前が付けられ、方向を持ちます。そして、関係はイベントとイベント、人と人、ドキュメントとイベントなどのノード間に作成することができます。 グラフクエリでは、SQLでは不可能な方法でグラフをトラバースすることもできます。

たとえば、特定のキーイベントに関連するノードを収集し、発生パターンを研究することができます。階層構造は保持され、各レベルは個別に参照することができますが、非正規化されたディメンションテーブルではできません。最も重要なことは、グラフは厳密なスキーマ制約のセットに従わずに、ビジネスの任意のイベントやエンティティをモデル化するための柔軟性があります。グラフはビジネスの意味モデルに合わせて設計されています。

データの抽出、変換、ロード（ETL）

では、サンプルのリレーショナルデータベーステーブルを見て、データをグラフデータベースに抽出、変換、ロードするためのサンプルスクリプトを作成しましょう。この記事では、最も人気のある商用グラフデータベースであるNeo4jが使用するCypher言語を使用します。ただし、グラフクエリ言語（GQL）の他のバリエーションにも同じ概念が適用されます。以下のサンプルのProductテーブルを使用します：

以下のクエリを使用することで、過去24時間に更新された新しい製品を取得できます：

SELECT product_id,  product_name,  cost_usd,  product_statusFROM ProductWHERE last_updated_date > current_date -1;

これらの結果をPythonのPandasデータフレーム「df」に取得し、グラフデータベースへの接続を開いた後、次のスクリプトを使用してデータフレームをグラフにマージします

UNWIND $df as rowMERGE INTO (p:Product {product_id: row.product_id})SET p.product_name = row.product_name,  p.cost_usd = row.cost_usd,  p.product_status= row.product_status,  p.last_updated_date = datetime();

最初の行では、「df」というパラメータを参照しています。これはPandasからのデータフレームです。ノードタイプ「Product」にマージします。これはエイリアス「P」で参照されます。その後、「product_id」セクションはノード内の一意の識別子にバインドするために使用されます。その後、MergeステートメントはSQLのマージに似ています。

上記のようなマージステートメントを使用してノードを作成した後、リレーションシップを作成します。リレーションシップは、同じスクリプト内またはポストプロセッシングスクリプトで次のようなマージコマンドを使用して作成できます：

MATCH (p:Product), (o:Order)WHERE p.product_id = o.order_idMERGE (o)-[:CONTAINS]->(p);

Matchステートメントは、Oracleでの古いジョインの使用と似ており、Matchの後に2つのノードタイプが宣言され、その後、JoinがWhere句で行われます。

グラフモデル上のクエリ

グラフを構築し、クエリを実行したいとします。以下のようなクエリを使用して、アリゾナからの注文がドライブされたAd Groupを確認できます。

MATCH (ag:広告グループ)<-[:所属]-(a:広告)-[:運営]-(o:オーダー)<-[:注文]-(c:顧客)WHERE c.state = 'AZ'RETURN ag.group_name,  COUNT(o) as order_count

このクエリは、アリゾナ州の状態でフィルタリングされた広告グループ名と注文数を返します。CypherではSQLと異なり、Group By句は必要ありません。このクエリから、以下のサンプル出力を受け取ることができます。

この例は、注文の事実テーブルを使用して類似のクエリをリレーショナルデータベースやデータウェアハウスで簡単に作成できるため、些細なものに見えるかもしれません。しかし、より複雑なクエリを考えてみましょう。キャンペーンの開始から帰属可能な配信が受け取られるまでの時間を表示したいとします。データウェアハウスでは、このクエリは事実テーブルをクロス参照するため、かなりのリソースを必要とします。リレーショナルデータベースでは、このクエリには長い連結が含まれます。グラフデータベースでは、クエリは次のようになります。

MATCH (cp:キャンペーン)<-[:所属]-(ag:広告グループ)<-[:所属]-(a:広告)MATCH (a)-[:運営]-(o:オーダー)<-[:達成]-(d:配信)RETURN cp.campaign_name,  cp.start_date as campaign_launch_date,  MAX(d.receive_date) as last_delivery_date

私は1つのサンプルクエリパスを使用しましたが、ユーザーが異なるビジネスの質問に答えるために取ることができるさまざまなパスがあります。クエリでは、キャンペーンから配信までのパスが、オーダーと配信の関係を介して行われることに注意してください。また、読みやすさのために、パスを2つの部分に分割し、2行目からAdのエイリアスで開始しました。クエリの出力は以下のようになります。

結論

リレーショナルモデルからグラフモデルへの電子商取引のプロセスを変換するためのいくつかのサンプル手順を見てきましたが、この1つの記事ではすべての設計原則をカバーすることはできません。おそらく、グラフデータベースはリレーショナルデータベースと同じレベルの技術的なスキルを要すること、移行が大きなハードルではないことがわかったでしょう。

最大の課題は、従来のリレーショナルモデリング技術から離れ、セマンティックまたはビジネスモデリングの観点で考えるように脳を再教育することです。グラフ技術に潜在的な応用があると思われる場合は、概念実証プロジェクトで試してみてください。知識グラフを使用した分析の可能性は、2次元テーブルではできない範囲に及びます！

すべての画像は著者によるものです

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!