KnowHowを使ったナレッジグラフでRAGを強化する
Retrieval Augmented Generation(RAG)は、MilvusやZilliz Cloud(フルマネージドMilvus)のようなベクトルデータベースを通じて、LLMに追加の知識と長期記憶を提供する一般的なテクニックである。基本的なRAGは多くのLLMの頭痛の種に対処できるが、カスタマイズや検索結果のより大きな制御など、より高度な要求がある場合には不十分である。
先日のUnstructured Data Meetupでは、WhyHowの共同設立者であるChris Recが、パフォーマンスと精度を向上させるためにナレッジグラフ(KG)をどのようにRAGパイプラインに組み込んでいるかを共有した。このブログでは、ナレッジ・グラフの概要、RAGの概要、ナレッジ・グラフをRAGシステムに統合してパフォーマンスを向上させる方法など、彼の講演のポイントを紹介する。
このトピックについてもっと知りたい方は、YouTubeで講演全体をご覧になることをお勧めします。
.RAGの概要と課題
RAGは、検索ベースの人工知能システムと生成ベースの人工知能システムの両方の長所を利用した手法である。通常のRAGは、Milvusのようなベクトルデータベース、埋め込みモデル、大規模言語モデル(LLM)から構成される。
RAGシステムは、まず埋め込みモデルを用いて文書をベクトル埋め込みに変換し、ベクトルデータベースに格納する。次に、このベクトルデータベースから関連するクエリ情報を検索し、検索結果をLLMに提供する。最後に、LLMは検索された情報をコンテキストとして利用し、より正確な出力を生成する。
RAGワークフロー](https://assets.zilliz.com/RAG_chatbot_2f1ff9ec07.png)
図1：RAGの仕組み
バニラのRAGは、より最新で正確な結果を生成することに優れているが、それでもいくつかの制限がある。
第一に、LLMは質問の特定の文脈や領域を完全に理解するのに苦労する可能性があり、不正確な回答や無関係な回答を導く可能性がある。例えば、「車両定員」という用語は、自動車が収容できる乗客の数を指すこともあれば、道路に収まる自動車の数を指すこともあり、曖昧さが生じる。
**例えば、"ロンドンに行きたい "というようなロケーションベースの問い合わせに対応するのと、"仕事でストレスが溜まっているので休暇を取りたい "というような、より抽象的なウェルネス関連の問い合わせに対応するのとでは、大きく異なる。
**例えば、海岸から1マイル離れた「ビーチハウス」と、砂浜に直接建っている「ビーチフロントハウス」を区別するのは難しい。
第4に、回答の完全性も懸念されます。 特に、少なくとも1,000万ドルを投資し、特別なデータアクセス権を持っているファンドの全リミテッド・パートナ ー（LP）をリストアップするような複雑な質問の場合、包括的な質問に対して全ての関連情報を検索することは 困難です。
**最後に、マルチホップクエリでは、複数の情報を正確に組み合わせる必要があるため、さらに複雑さが増します。このアプローチでは、クエリをいくつかのサブクエリに分解し、それぞれに特定の条件を付けて、最終的なレスポンスが正確で完全なものになるようにする必要があります。
プロンプトの改善、高度なチャンキング戦略、より良い埋め込みモデル、リランキングなどのソリューションは、RAGに関連する課題の多くに対処することができますが、WhyHowはRAGパイプラインにナレッジグラフを組み込むことで、異なるアプローチを取ります。
ナレッジグラフ（KG）とは？
ナレッジグラフ（KG）とは、データを格納するだけでなく、類似または非類似のデータをそれらの関係に基づいてリンクするデータ構造の一種です。このアプローチにより、関連する情報や関連する情報を提供できるようにリンクされたもの（データの種類は問わない）のコレクションを持つことができる。
ナレッジグラフは、ノード、エッジ、およびプロパティで構成されます。
図2-知識グラフの構成要素](https://assets.zilliz.com/Fig_2_Building_Blocks_of_a_Knowledge_Graph_3a3c13c822.png)
図2：知識グラフの構成要素
**ノード
グラフ内のエンティティまたはオブジェクトを表します。
これらのエンティティのストア値は、どのようなタイプのデータでもよい。
**エッジ
エンティティ間の関係を表します。
接続されたノード間の関係の性質に関する情報を保持する。
プロパティ： 個々のエンティティに関連付けられた特性または特徴。
従来の表形式のデータベースとは異なり、ナレッジグラフはグラフ構造を使用して関係を柔軟に表現し、意味的な理解に重点を置いている。このアプローチにより、複雑なクエリーを可能にし、特定の情報の抽出を容易にする。
ナレッジグラフをRAGシステムに統合するメリット
知識グラフをRAGパイプラインに組み込むことで、システムの検索能力と回答品質を大幅に向上させ、優れたパフォーマンス、正確性、追跡可能性、完全性を実現することができます。以下は、ナレッジグラフベースのRAGシステムの主な利点です：
文脈理解の強化
ナレッジグラフは、RAGシステムがエンティティ間の複雑な関係を把握することを可能にする、情報の豊富で相互接続された表現を提供します。この深い文脈理解は、よりニュアンスのある適切な対応につながります。
正確性と事実の一貫性の向上
ナレッジグラフの構造化された性質は、生成されたコンテンツ全体の事実の一貫性を維持するのに役立ちます。グラフ内の検証された情報に回答を固定することで、従来の言語モデルにありがちなエラーや幻覚を減らすことができます。
マルチホップ推論機能
知識グラフは、RAGシステムが論理的な経路を通じて異なる情報の断片を接続し、マルチホップ推論を実行することを可能にする。この機能により、より洗練されたクエリ応答と推論生成が可能になる。
効率的な情報検索
グラフ構造は、複雑なクエリであっても、迅速かつ正確な情報検索を容易にします。この効率性は、応答時間の短縮と、より関連性の高いコンテンツの生成につながる。さらに、ナレッジグラフベースのRAGシステムは、MilvusやZilliz Cloudのようなベクトルデータベースが提供するベクトル検索とキーワード検索とグラフトラバーサルを組み合わせたハイブリッド検索アプローチを可能にする。
より具体的に言えば、このハイブリッド・アプローチは以下を可能にする：
グラフ・トラバーサルによる正確なエンティティと関係のマッチング
ベクトル埋め込み](https://zilliz.com/glossary/vector-embeddings)を用いた意味的類似性マッチング
テキストが多いコンテンツに対する従来のキーワードベース検索
この多面的な検索戦略は、様々なデータタイプや構造にわたって最も関連性の高い情報を見つけるシステムの能力を強化し、より包括的で正確な回答につながる。
透明で追跡可能な出力
ナレッジグラフを使用することで、応答生成に使用された情報の明確な証明性を提供することができます。このトレーサビリティはユーザーの信頼を高め、事実確認や検証を容易にします。
クロスドメイン知識合成
多様な領域を単一のグラフ構造で表現することで、ナレッジグラフベースのRAGシステムは、異なる分野にまたがる情報をより容易に合成することができ、より包括的で学際的な洞察につながる。
曖昧さの取り扱いの改善
知識グラフの関係構造は、実体や概念の曖昧さを解消し、用語や名称が複数の意味や参照を持つ可能性のある状況での混乱を軽減するのに役立つ。
これらの利点を活用することで、知識グラフで強化されたRAGアプリケーションは、ユーザーのクエリに対して、より正確で、文脈に関連した、包括的な応答を提供することができます。
WhyHowとは？ナレッジグラフでRAGをどのように強化するのか？
WhyHowは、複雑なデータ検索をサポートするナレッジグラフを構築・管理するためのプラットフォームです。包括的なナレッジグラフの構築は困難で時間がかかる。WhyHowは、小さなKGを作成し、特定のドメインに対して満足のいくKGが現れるまで何度もそれを繰り返すことで、この問題を解決します。このアプローチは、KGが複雑であるため、高度にドメインに特化し、よりシンプルで作業しやすくするのに役立ちます。
WhyHowはまた、複雑なRAGを実行するために非構造化データを整理し、文脈化し、確実に取得するためのビルディングブロックを開発者に提供します。ベクターデータベースを利用した既存のRAGパイプラインにWhyHowを統合することで、より優れた構造、一貫性、制御を備えたRAGシステムを構築することができます。下図は、ナレッジグラフで強化されたRAGがどのように機能するかを示しています。
図3-RAGとWhyHowの統合](https://assets.zilliz.com/Fig_3_Integration_of_RAG_with_Why_How_b893400b28.png)
図3：RAGとWhyHowの統合
WhyHowをRAGワークフローに組み込むことで、ベクトルデータベースが提供する知識グラフとベクトル検索機能の両方の長所を活用し、グラフとベクトルのハイブリッドアプローチを取ることができます。
WhyHowでナレッジグラフを強化したRAGを構築する方法についてのより詳細なガイドについては、Zilliz主催のUnstructured Data MeetupでChrisが共有したライブデモを見ることをお勧めします。
WhyHowとZilliz Cloudを使ってRAG内の検索ワークフローをよりコントロールする
RAGアプリケーションをよりパフォーマンスとトレーサビリティの高いものにすることに加えて、多くの開発者はRAGが何を取得するかをよりコントロールできるようになることを望んでいます。なぜなら、RAGアプリケーションは、ユーザが不適切なフレーズのクエリを送信した場合や、ユーザがコンテキストに関連するがセマンティックに異なるデータをレスポンスに含める必要がある場合に、正しいデータチャンクを一貫して取得できないことがあるからです。
このような問題に対処するため、WhyHowはZilliz Cloudとの統合によりルールベースの検索パッケージを構築しています。このPythonパッケージにより、開発者は高度なフィルタリング機能を備えたより正確な検索ワークフローを構築することができ、RAGパイプライン内の検索ワークフローをより制御できるようになります。このパッケージは、テキスト生成のためのOpenAIと、ストレージと効率的なベクトル類似検索とメタデータフィルタリングのためのZilliz Cloudと統合されています。
ルールベースの検索ソリューションは、これらのタスクを実行する：
1.**チャンク埋め込みを保存するためのMilvusコレクションを作成する。
2.分割、 チャンキング、埋め込み: LangChainのPyPDFLoaderとRecursiveCharacterTextSplitterを使って、アップロードされたドキュメントの分割、チャンキング、埋め込みを自動的に行い、OpenAIのtext-embedding-3-smallモデルをサポートします。
3.データ挿入：埋め込みとメタデータをMilvusまたはZilliz Cloudにアップロードします。
4.自動フィルタリング: ユーザ定義のルールに基づいてメタデータフィルタを構築し、ベクターストアに対するクエリを絞り込みます。
ワークフローは以下の通り：
WhyHowとZilliz Cloudの連携方法](https://assets.zilliz.com/How_Why_How_and_Zilliz_Cloud_work_together_8510ecf053.png)
図4：ルールベース検索ソリューションのワークフロー
ソースデータは、OpenAIの埋め込みモデルを用いてベクトル埋め込みデータに変換され、Zilliz Cloudに取り込まれる。ユーザーからのクエリが行われると、そのクエリもベクトル埋め込みデータに変換され、Zilliz Cloudに送られ、最も関連性の高い結果を検索する。WhyHowはベクトル検索にルールを設定し、フィルタを追加する。検索された結果は、元のユーザークエリとともにLLMに送られ、LLMはより正確な結果を生成してユーザに送信する。
結論
LLMは、様々な問題に対する答えを見つける上で、我々の負担を本当に軽減してくれた。LLMは提供されたクエリを理解するのに十分賢いのだが、幻覚を見ているようなものであり、リソースの制約から最新の状態に保つのは難しい。したがって、検索拡張世代（RAG）技術は、クエリにコンテキストを提供することによって、LLMに力を与える。しかし、RAGシステムにも、議論したように限界がある。
WhyHowはこれらの限界を明らかにし、解決策はRAGパイプラインにナレッジグラフを組み込むことにあると強調した。ナレッジグラフでRAGを強化することで、RAGシステムはより関連性の高い文脈に沿った情報を取得し、幻覚が少なく精度の高い、より確定的な回答を生成することができます。
このトピックをより深く知りたい方は、YouTubeのクリスのプレゼンテーションをご覧ください。
その他のリソース
RAGとは何か ](https://zilliz.com/learn/Retrieval-Augmented-Generation)
RAGパイプラインのパフォーマンスを高める方法](https://zilliz.com/learn/how-to-enhance-the-performance-of-your-rag-pipeline)
リランカーによるRAGの最適化：その役割とトレードオフ](https://zilliz.com/learn/optimize-rag-with-rerankers-the-role-and-tradeoffs)
フルRAG：ハイパーパーソナライゼーションのための最新アーキテクチャ](https://zilliz.com/blog/full-rag-modern-architecture-for-hyperpersonalization)
LangServe、LangGraph、MilvusによるインテリジェントなRAGアプリケーションの構築](https://zilliz.com/blog/build-intelligent-rag-with-langserve-langgraph-and-milvus)
セルフデプロイされたMilvusとSnowparkコンテナサービスによるRAGの構築](https://zilliz.com/blog/build-rag-with-self-deployed-milvus-vector-database-and-snowpark-container-service)
高効率なRAGパイプラインを構築するためのDSPyとMilvusとの統合](https://zilliz.com/blog/exploring-dspy-and-its-integration-with-milvus-vector-database-for-RAG)
Haziqa SajidDigital Storytelling for Data, AI, B2B & SaaS
読み続けて
Why AI Databases Don't Need SQL
Whether you like it or not, here's the truth: SQL is destined for decline in the era of AI.
Stop Waiting, Start Building: Voice Assistant With Milvus and Llama 3.2
We'll learn to build a Voice Assistant, a specialized Agentic RAG system designed for voice interactions, with Milvus, Llama 3.2, and other GenAI tools.
How to Select the Most Appropriate CU Type and Size for Your Business?
Explore Zilliz Cloud’s three CU options and learn how to choose the most suitable one for your business