なぜ、ナレッジグラフは重要なのか？ベクトルDBとの違いなど
背景
しかし、どちらがより正確で、信頼性があり、説明可能な基盤をLLMに提供するか？
ナレッジグラフとベクターデータベースのどちらを選ぶべきかを決定する際に考慮すべき主要な要素は？
それらがわからないため、文献をあさってみた。
ナレッジグラフ .vs. ベクトルデータベースの違い
グラフデータベースでLLMを構築した方が、性能、正確性、ハルシネーション防止、等の面で優れている、という記事
以下、詳細
複雑な質問への回答
質問の複雑性が高いほど、ベクトルデータベースが迅速かつ効率的に結果を返すことが難しくなる。
例えば、ナレッジグラフとベクターデータベースの両方は、「私の会社のCEOは誰ですか？」という質問に簡単に答えを返すことができますが、ナレッジグラフは「過去12ヶ月で少なくとも2人のメンバーが投票を棄権した理事会はどれですか？」といった質問に対して、ベクターデータベースよりも速く答えを見つけ出します。
ベクターデータベースは、ベクター空間内の対象の中間で答えを見つける可能性が高く、特定の答えではありません。
ナレッジグラフは、関係によって接続されたグラフを走査することに基づいて、正確な情報を探して返します。
完全な回答の取得
ベクトルデータベースは、類似度スコアリングと事前に定義された結果の制限に依存しているため、回答を返す際に不完全または無関係な結果を提供する可能性が高い。
例えば、「John Smithによって書かれたすべての本をリストしてください」と質問すると、
ベクターデータベースは以下のいずれかを返します：
・タイトルの不完全なリスト（事前に定義された制限が低すぎる）、または
・John Smithと他の著者によるすべてのタイトル（事前に定義された制限が高すぎる）、または
・ 正確な答え（事前に定義された制限がちょうど良い）。
開発者はすべての可能なクエリに対する事前に定義された制限を知ることができないため、ベクターデータベースから正確な答えを得ることはほぼ不可能です。
ナレッジグラフのエンティティは関係によって直接接続されているため、各エンティティの関係の数は異なります。ナレッジグラフは正確な答えを取得して返し、それ以上のものはありません。この場合、ナレッジグラフのクエリは、John Smithによって書かれたすべての本を返し、それ以上のものはありません。
信頼性のある回答の取得
ベクターデータベースは、2つの事実的な情報をつなげて何か不正確なことを推測することがある。
例えば、「製品管理チームには誰がいますか？」と質問した場合、ベクターデータベースは、誰かが製品チームにいると誤って推測するかもしれない。それは、その人が製品チームによって作成された文書に頻繁にコメントアクセスを持っているめ、その名前が結果に返される可能性がある。
ナレッジグラフは、ノードと関係を使用して組織内の人々がどのように関連しているかを識別するため、製品チームにいる人々だけを返す。
LLMの幻覚 (Hallucination) を修正する
ナレッジグラフはデータの人間が読める表現を持っていますが、ベクターデータベースはブラックボックスしか提供しません。
例えば：製品チームのメンバーが誤って識別された場合、ベクターデータベースは誤情報を推測するために使用した事実を識別することができない。これは、それを元に戻すことやエラーの源を理解することができないことを意味する。一方で、ナレッジグラフのユーザーは、LLMが何かを誤って推測した場合、誤情報を見つけて修正するのは簡単。
ナレッジグラフは完全な透明性を持っている。それらは、データ内の誤情報を識別し、クエリの経路を遡り、それに対する修正を行うのを助ける。これにより、LLMの精度を向上させることができる。
一方で、ベクターデータベースはほとんどまたはまったく透明性がなく、特定の修正を行う能力もない。
なぜ、グラフデータベースがAI推論に向いているのか、ベクトルとテーブルデータとの論理的な比較
生成AIのデータを管理するデータベースとして、グラフデータベースを採用する事例が急速に増えている。
グラフデータベースはデータ間の関係性を重視したデータ表現手法で、人間の思考に近い技術としてその可能性に注目が集まっている。
なぜ、従来の方法だとまずいか？
ナレッジグラフの優れたメリット
明示的な意味論、抽象化、構造、アルゴリズムの組み合わせにより、接続を正確に表現でき、AIに推論のための構造的手がかりを提供できる。
https://scrapbox.io/files/658225c9419f6000230a9beb.png
上図のように、事実はノードとして、接続はエッジとしてモデル化される。
これにより、意味論、階層、抽象化がキャプチャされ、推論のための構造的手がかりが提供される。
ノードは実世界のエンティティや様々な抽象レベルの概念を忠実に表現できる。
ラベル付きの関係は、「is-a（〜である）」「part-of（一部である）」など、ノード間の事実的な知識をモデル化する。
オントロジーは階層型の型構造を提供する。ノードは親型の意味論を継承する。
グラフアルゴリズムは、PageRank Surface Insightsのような洞察に強い。
中心性 (Centrality)で重要なノードの識別を行なう。
パスファインディング (Path Finding)により、ノード間の最も効率的な経路を決定するプロセスを見出すことで多段階推論が可能になる。
グラフデータベースは、LLMの検索拡張世代（RAG）機能を強化する上でどのように役立つのか？
グラフ検索拡張生成（GRAG）を実現し、グラフを検索ツールとして、より深い方法でテキストとチャットすることができる。これはRAGの新しい改良版で、ベクトルDBをリトリーバーとして使い、文書とチャットする。 RAGがこれほど効率的なら、なぜまだ生成テキストの品質を改善する方法を探しているのでしょうか。簡単に言えば、RAGは良いですが、十分ではありません。
まず、取得したい文書のタイプやサイズに基づいて変わる多くのハイパーパラメータがあります。これらのパラメーターの組み合わせは、各ユースケースに適切に機能するわけではなく、正しい組み合わせを知る唯一の方法は実験を通じてです。これは文書のサイズやボリュームに応じて、知識ベースを形成するのに非常に時間がかかる傾向があります。
次に、RAGは一次元の質問に対してはうまく機能しますが、情報から推論を引き出し、そのような推論を使って質問に答えることには非効率です。また、多くの場合、RAGベースのモデルはマルチホップまたはマルチドキュメントクエリを処理できません。
例えば、個々の映画に関する情報（要約、キャスト、評価、公開日など）が含まれる複数の文書があるとします。RAGを使用し、「XYZ映画に出演した俳優は誰ですか？」と質問すると、モデルは簡単に答えることができます。
しかし、「Xが主演した映画はいくつありますか？」と質問した場合、正しい答えを得られない可能性があります。LLMは限られたコンテキストサイズを持っており、毎回全ての映画情報を渡しています。この場合、モデルは「X」が関与するいくつかの映画についての情報を受け取りますが、それには要約、キャスト、公開日などが含まれます。これは非常に非効率的です。なぜなら、この特定のユースケースではあらすじや公開日には関心がなく、キャストの詳細のみが必要だからです。
これらの問題の多くは、関連文書を取得する方法、類似性検索によって生じます。類似性検索は、関連するキーワードや/または意味的類似性を検索して関連情報を取得しようとします。ここでグラフデータベースが登場します。
ユースケースに必要な情報の種類を絞り込むことができれば、グラフ形式でグラフデータベースに格納できます。グラフデータベースは、関連しているかどうかにかかわらず、ノードの形であらゆる種類のデータを格納することができる柔軟性があります。これら個々のノードは、それぞれ独自の属性を持つことができます。Neo4j、OrientDB、ArangoDB、TigerGraphは、いくつかの人気のあるグラフデータベースプロバイダーです。私は個人的にNeo4jを使用しています。
まず最初に行うべきステップは、データをグラフ形式に変換することです。これにはいくつかの方法がありますが、最も効果的な方法は、LLMを使用してデータベースに保存したい関連する実体と関係を抽出することです。巧みなプロンプトを使用すれば、文書がシステムに取り込まれるたびに、すべての実体、その属性、および関係を一度に取得できます。
グラフが準備できたら、グラフからデータを抽出するための2つの方法があります：
1) 質問に基づいて関連するデータを取得できるサイファークエリを生成するためにLLMを使用する。
2) 知識グラフとのLLM統合を使用して、ノードを直接抽出する。
最初の方法は十分にシンプルで、グラフデータベースの構造をコンテキストとしてLLMに提供し、質問に答えるために必要な情報を取得するためのクエリを生成させます。その後、この情報を使用して最終的な回答を生成します。
この方法の欠点は、モデルがサイファークエリを生成する能力に完全に依存していることです。もしモデルが悪いクエリを生成した場合、パイプライン全体が失敗します。
2つ目の方法は、使用するグラフデータベースプロバイダーによって異なります。たとえばNeo4jは、最近のAPOC統合を使ってグラフで類似性検索を直接実行することができますが、現時点ではOpenAIとVertexAIのみをサポートしています。
まず、次のクエリを使用してAPOCエンドポイントを呼び出す必要があります：
CALL apoc.ml.openai.embedding($question, $apiKey) YIELD embedding
ここで、$questionはユーザーの質問用のプレースホルダーであり、$apiKeyはの場合OpenAI APIキー用のプレースホルダーです。類似性検索メトリックは、「gds.similarity.cosine(embedding, m.embedding)」をクエリのWITHセクションで使用することで定義できます。最後に、MATCH句を使用して、取得したいデータを選択します。
この方法は、質問に関連するノードと隣接ノードを取得し、その上で回答を生成するのに非常に効果的です。
グラフアプローチの明白な欠点は、正確性が大きくグラフの構造と生成されるクエリに依存していることです。必要なデータを効率的にグラフに追加できない場合、このパイプラインは完全に失敗します。
結論として、グラフデータベースはRAGパイプラインの精度を向上させ、マルチホップの質問のような複雑な問題を解決するのに役立つ可能性がありますが、データをグラフ形式で表現できる場合に限ります。物事が急速に変化している現在、これらの欠点を効率的に扱う方法がすぐに見つかるかもしれません。