GraphRAGの説明：知識グラフによるRAGの強化
RAGの紹介と課題
検索拡張生成(RAG)は、大規模言語モデル(LLM)の出力を拡張するために、外部のデータソースを接続する技術である。この技法は、LLMがプライベートデータやドメイン固有のデータにアクセスし、幻覚の問題に対処するのに最適である。したがって、RAGは、AIチャットボットや推薦システムのような多くのGenAIアプリケーションを強化するために広く使用されている。
ベースラインRAGは通常、ベクトルデータベースとLLMを統合しており、ベクトルデータベースはユーザクエリ用のコンテキスト情報を格納・検索し、LLMは検索されたコンテキストに基づいて回答を生成する。このアプローチは多くの場合うまく機能するが、マルチホップ推論や、異なる情報の断片を接続する必要がある質問に答えるような複雑なタスクでは苦労する。
例えば、次の質問を考えてみよう：「簒奪者アレクタスを倒した男の息子に与えられた名前は？
ベースラインRAGは、この質問に答えるために、一般的に次のようなステップを踏みます：
1.1.その人物を特定する：誰がアレクタスを倒したかを特定する。
2.**この人物の家族、特にその息子についての情報を調べなさい。
3.**息子の名前を特定する。
ベースラインRAGは意味的類似性に基づいてテキストを検索するため、特定の詳細がデータセットに明示的に記載されていないような複雑なクエリには直接答えられない。この制限により、必要な情報を正確に見つけることが難しくなり、頻繁なクエリに対してQ&Aのペアを手動で作成するような、高価で非現実的な解決策が必要になることが多い。
このような課題に対処するために、Microsoft ResearchはGraphRAGを発表した。これは、知識グラフを用いてRAGの検索と生成を補強する全く新しい手法である。以下のセクションでは、GraphRAGがどのように機能するのか、またMilvusvectorデータベースでどのように実行するのかを説明する。
GraphRAGとは何か？
意味的に類似したテキストを検索するためにベクトルデータベースを使用するベースラインRAGとは異なり、GraphRAGは知識グラフ（KG）を組み込むことによってRAGを強化する。ナレッジグラフは、関連または無関係なデータをそれらの関係に基づいて保存し、リンクするデータ構造である。
GraphRAGパイプラインは通常、インデックス作成とクエリの2つの基本プロセスで構成される。
GraphRAGパイプライン](https://assets.zilliz.com/The_Graph_RAG_Pipeline_0ecc08b69f.png)
GraphRAGパイプライン (画像出典:_ GraphRAG論文_)
インデックス作成
インデックス作成プロセスには4つの重要なステップがある：
1.テキスト単位の分割：入力コーパス全体を複数のテキスト単位（テキストチャンク）に分割する。これらのチャンクは分析可能な最小単位であり、段落、センテンス、その他の論理単位となる。長い文書を小さなチャンクに分割することで、入力データのより詳細な情報を抽出し、保存することができる。
2.エンティティ、関係、主張の抽出：GraphRAGはLLMを使って、各テキスト単位から、全てのエンティティ（人名、地名、組織名など）、それらの間の関係、テキスト中に表現されている主要な主張を特定し、抽出する。この抽出された情報を用いて初期知識グラフを構築する。
3.階層的クラスタリング：GraphRAGはLeiden手法を用いて初期知識グラフの階層的クラスタリングを行う。Leidenは、グラフ内のコミュニティ構造を効果的に発見できるコミュニティ検出アルゴリズムである。各クラスタ内のエンティティは、より詳細な分析のために異なるコミュニティに割り当てられる。
注：*コミュニティとは、グラフ内のノードのグループで、互いに密に接続されているが、ネットワーク内の他の密なグループとは疎に接続されているノードのグループである。
4.コミュニティ・サマリーの生成：GraphRAGはボトムアップアプローチで各コミュニティとそのメンバーの要約を生成する。これらの要約には、コミュニティ内の主なエンティティ、それらの関係、主要な主張が含まれる。このステップはデータセット全体の概要を示し、その後のクエリに有用な文脈情報を提供する。
図1-GPT-4ターボを使ってLLMが生成した知識グラフ](https://assets.zilliz.com/Figure_1_An_LLM_generated_knowledge_graph_built_using_GPT_4_Turbo_c51f682535.png)
図1: GPT-4ターボを使ってLLMが生成した知識グラフ.
(画像出典:_ Microsoft Research)。
クエリ
GraphRAGは異なるクエリに合わせた2つの異なるクエリワークフローを持っている。
グローバル検索](https://microsoft.github.io/graphrag/query/global_search/)は、コミュニティ要約を活用することで、データコーパス全体に関連する全体的な質問を推論する。
ローカル検索](https://microsoft.github.io/graphrag/query/local_search/) 特定のエンティティについて、その近傍や関連する概念まで広げて推論する。
このグローバル検索ワークフローには以下のフェーズが含まれる。
図2-グローバル検索データフロー](https://assets.zilliz.com/Figure_2_Global_search_dataflow_a3ffba1eda.png)
図2：グローバル検索のデータフロー（画像ソース：_ Microsoft Research）
1.ユーザーのクエリと会話履歴：システムはユーザーのクエリと会話履歴を初期入力として受け取る。
2.コミュニティ・レポート・バッチ：コミュニティ・レポート・バッチ**：LLMによって生成された、コミュニティ階層の指定されたレベルのノードコミュニティレポートをコンテキストデータとして使用します。これらのコミュニティレポートはシャッフルされ、複数のバッチに分割される（シャッフルされたコミュニティレポートバッチ1、バッチ2...バッチN）。
3.RIR (Rated Intermediate Responses)：コミュニティレポートの各バッチは、さらにあらかじめ定義されたサイズのテキストチャンクに分割されます。各テキストチャンクは中間応答を生成するために使用される。回答には、ポイントと呼ばれる情報断片のリストが含まれる。各ポイントには、その重要性を示す数値スコアが設定されている。これらの生成された中間レスポンスは、評価された中間レスポンス（評価された中間レスポンス1、レスポンス2...レスポンスN）です。
4.**ランク付けとフィルタリングシステムはこれらの中間回答をランク付けし、フィルタリングして、最も重要なポイントを選択します。選択された重要なポイントは、集計中間回答を形成します。
5.最終回答：集約された中間回答は、最終回答を生成するためのコンテキストとして使用されます。
ユーザーが特定のエンティティ（人名、地名、組織名など）について質問する場合は、ローカル検索ワークフローを使用することをお勧めします。このプロセスには以下のステップが含まれます：
図3-ローカル検索データフロー](https://assets.zilliz.com/Figure_3_Local_search_dataflow_60b507814a.png)
図3：ローカル検索データフロー（画像ソース：_ Microsoft Research）
1.**ユーザークエリまず、システムはユーザーのクエリを受け取る。クエリは単純な質問であったり、より複雑なクエリであったりする。
2.類似エンティティ検索：システムは知識グラフから、ユーザー入力に意味的に関連するエンティティのセットを特定する。これらのエンティティは、知識グラフへのエントリポイントとして機能する。このステップでは、Milvusのようなベクトルデータベースを使用してテキスト類似検索を行う。
3.エンティティ-テキストユニットのマッピング：抽出されたテキスト単位は、元のテキスト情報を取り除き、対応するエンティティにマッピングされる。
4.エンティティ-関係抽出：このステップでは、エンティティとそれに対応する関係に関する特定の情報を抽出する。
5.エンティティ-共変量マッピング（Entity-Covariate Mapping）：このステップでは、エンティティの共変量（統計データまたは他の関連属性を含む場合がある）を マッピングする。
6.エンティティ-コミュニティ・レポートのマッピング：コミュニティ・レポートが検索結果に統合され、グローバル情報が組み込まれる。
7.会話履歴の利用：提供された場合、システムはユーザーの意図と文脈をよりよく理解するために会話履歴を使用します。
8.**レスポンスの生成最後に、システムは、前のステップで生成されたフィルタリングされ、ソートされたデータに基づいて、ユーザーのクエリを構築し、応答します。
ベースラインRAGとGraphRAGの出力品質比較
GraphRAGの有効性を示すために、その作成者は発表ブログでベースラインRAGとGraphRAGの出力品質を比較している。ここでは簡単な例を挙げて説明する。
使用データセット
GraphRAGの作成者は、実験にViolent Incident Information from News Articles (VIINA)データセットを使用した。
注：* このデータセットにはデリケートなトピックが含まれている。このデータセットが選ばれたのは、その複雑さと、異なる意見や部分的な情報の存在だけが理由である。このデータセットは、LLMの基本モデルのトレーニングに含まれないほど最近のものであり、厄介な実世界のテストケースである。
実験の概要
ベースラインRAGもグラフRAGも同じ質問をされ、答えを構成するためにデータセット全体の情報を集約する必要がある。
**Q: データセットのトップ5のテーマは何ですか？
答えは下の画像に示されている。ベースラインRAGの結果は、ベクトル検索が無関係なテキストを検索したため、戦争テーマとは無関係であり、不正確な評価につながった。対照的に、GraphRAGは明確で適切な回答を提供し、主要なテーマとその詳細を特定した。結果はデータセットに沿ったもので、出典資料への言及もあった。
図4-複雑な要約問題に対するBaselineRAGとGraphRAGの比較](https://assets.zilliz.com/Figure_4_Baseline_RAG_vs_Graph_RAG_in_answering_complex_summarization_questions_b0870b2881.png)
図4: 複雑な要約の質問に答える際のBaselineRAGとGraphRAGの比較 Figure 4: BaselineRAG vs. GraphRAG in answering complex summarization questions
論文"[From Local to Global: A Graph RAG Approach to Query-Focused Summarization.]"(https://arxiv.org/pdf/2404.16130)における更なる実験は、GraphRAGがマルチホップ推論と複雑な情報の要約を大幅に改善することを示している。この研究は、GraphRAGが包括性と多様性の両方でベースラインRAGを上回ることを示している：
包括性:**答えが質問の全ての側面をカバーする程度。
多様性：***回答が提供する視点や洞察の多様性と豊かさ。
これらの実験の詳細については、グラフラグのオリジナル論文を読むことをお勧めします。
MilvusベクトルデータベースによるGraphRAGの実装方法
GraphRAGは知識グラフでRAGアプリケーションを強化し、関連するエンティティを検索するためにベクトルデータベースに依存する。本節では、Milvusベクトルデータベースを用いたGraphRAGの実装方法、GraphRAGインデックスの作成方法、クエリ方法を示す。
前提条件
このブログのコードを実行する前に、以下の依存関係がインストールされていることを確認してください：
pip install --upgrade pymilvus
pip install git+https://github.com/zc277584121/graphrag.git
注：* Milvusのストレージ機能は、執筆時点ではまだ公式マージが保留されているため、フォークしたリポジトリからGraphRAGをインストールしました。
インデックス作成ワークフローから始めよう。
データの準備
Project Gutenberg](https://www.gutenberg.org/)から約1000行の小さなテキストファイルをダウンロードし、GraphRAGのインデックス作成に使用する。
このデータセットはレオナルド・ダ・ヴィンチの物語に関するものである。GraphRAGを使って、ダ・ヴィンチに関連する全ての関係のグラフインデックスを構築し、Milvusベクトルデータベースを使って、質問に答えるための関連知識を検索する。
インポート nest_asyncio
nest_asyncio.apply()
インポート os
インポート urllib.request
index_root = os.path.join(os.getcwd(), 'graphrag_index')
os.makedirs(os.path.join(index_root, 'input'), exist_ok=True)
url = "https://www.gutenberg.org/cache/epub/7785/pg7785.txt"
file_path = os.path.join(index_root, 'input', 'davinci.txt')
urllib.request.urlretrieve(url, file_path)
with open(file_path, 'r+', encoding='utf-8') as file：
以降の行はこの例には関係ないので、 # テキストファイルの最初の934行を使います。
# もしapiキーのコストを節約したいのであれば, テキストファイルをより小さいサイズに切り詰めることができます.
lines = file.readlines()
file.seek(0)
file.writelines(lines[:934]) # もしapiキーのコストを節約したいのであれば, この数値を小さくします.
file.truncate()
ワークスペースを初期化する
それでは、GraphRAGを使ってテキストファイルのインデックスを作成してみよう。ワークスペースを初期化するために、まずgraphrag.index --initコマンドを実行する。
python -m graphrag.index --init --root ./graphrag_index
env`ファイルと設定を構成する
インデックスのルートディレクトリに .env ファイルがあります。これを使うには、OpenAIのAPIキーを .env ファイルに追加します。
重要な注意事項:_ __
この例ではOpenAIモデルを使用します。_APIキー __を用意してください。
GraphRAGのインデックス作成は、テキストコーパス全体をLLMで処理するため、コストがかかります。このデモを実行するには数ドルかかるかもしれない。お金を節約するには、テキスト・ファイルをより小さいサイズに切り詰めることを検討してください_。
インデックス作成パイプラインの実行
インデックス作成処理には時間がかかります。完了すると、./graphrag_index/output/<timestamp>/artifactsに、一連のparquetファイルを含む新しいフォルダができます。
python -m graphrag.index --root ./graphrag_index
Milvusベクトルデータベースでクエリを実行する
クエリの段階では、GraphRAG local searchのためのエンティティ記述埋め込みを格納するためにMilvusを使用する。この方法は知識グラフの構造化データと入力文書の非構造化データを結合し、LLMコンテキストを関連するエンティティ情報で強化することで、より正確な回答を得ることができる。
インポート os
import pandas as pd
インポート tiktoken
from graphrag.query.context_builder.entity_extraction import EntityVectorStoreKey
from graphrag.query.indexer_adapters import (
# read_indexer_covariates、
read_indexer_entities、
read_indexer_relationships、
read_indexer_reports、
read_indexer_text_units、
)
from graphrag.query.input.loaders.dfs import (
store_entity_semantic_embeddings、
)
from graphrag.query.llm.oai.chat_openai import ChatOpenAI
from graphrag.query.llm.oai.embedding import OpenAIEmbedding
from graphrag.query.llm.oai.typing import OpenaiApiType
from graphrag.query.question_gen.local_gen import LocalQuestionGen
from graphrag.query.structured_search.local_search.mixed_context import (
LocalSearchMixedContext、
)
from graphrag.query.structured_search.local_search.search import LocalSearch
from graphrag.vector_stores import MilvusVectorStore
output_dir = os.path.join(index_root, "output")
subdirs = [os.path.join(output_dir, d) for d in os.listdir(output_dir)].
latest_subdir = max(subdirs, key=os.path.getmtime) # 最新の出力ディレクトリを取得する
INPUT_DIR = os.path.join(latest_subdir, "artifacts")
COMMUNITY_REPORT_TABLE = "create_final_community_reports"
ENTITY_TABLE = "create_final_nodes"
ENTITY_EMBEDDING_TABLE = "create_final_entities"
RELATIONSHIP_TABLE = "create_final_relationships" リレーションシップを作成する。
COVARIATE_TABLE = "create_final_covariates" (共変量テーブルの作成)
TEXT_UNIT_TABLE = "create_final_text_units" テキスト単位を作成する。
コミュニティレベル = 2
インデックス作成プロセスからデータをロードする
インデックス作成プロセスでは、いくつかのパーケットファイルが生成されます。それらをメモリにロードし、エンティティ記述情報をMilvusベクトルデータベースに格納する。
エンティティの読み込み
# コミュニティと度数のデータを取得するためにノードテーブルを読み込む。
entity_df = pd.read_parquet(f"{INPUT_DIR}/{ENTITY_TABLE}.parquet")
entity_embedding_df = pd.read_parquet(f"{INPUT_DIR}/{ENTITY_EMBEDDING_TABLE}.parquet")
entities = read_indexer_entities(entity_df, entity_embedding_df, COMMUNITY_LEVEL)
description_embedding_store = MilvusVectorStore(
collection_name="entity_description_embeddings"、
)
# description_embedding_store.connect(uri="http://localhost:19530") # Milvusのドッカーサービスの場合
description_embedding_store.connect(uri="./milvus.db") # Milvus Lite用
entity_description_embeddings = store_entity_semantic_embeddings(
エンティティ=エンティティ, vectorstore=description_embedding_store
)
print(f "Entity count：{len(entity_df)}")。
entity_df.head()
エンティティ数：651
図5：エンティティのスクリーンショット](https://assets.zilliz.com/figure_5_a70dd5e79a.png)
図5：エンティティのスクリーンショット
関係を読む
relationship_df = pd.read_parquet(f"{INPUT_DIR}/{RELATIONSHIP_TABLE}.parquet")
relationships = read_indexer_relationships(relationship_df)
print(f "関係数：関係数：{len(relation_df)}")
relationship_df.head()
関係数：290
図6- 関係のスクリーンショット](https://assets.zilliz.com/Figure_6_a_screenshot_of_relationships_2093cb60fe.png)
図6：人間関係のスクリーンショット
コミュニティ・レポートを読む
report_df = pd.read_parquet(f"{INPUT_DIR}/{COMMUNITY_REPORT_TABLE}.parquet")
reports = read_indexer_reports(report_df, entity_df, COMMUNITY_LEVEL)
print(f "レポートレコード：{len(report_df)}")。
report_df.head()
レポートレコード：45
図7-レポート記録のスクリーンショット](https://assets.zilliz.com/Figure_7_a_screenshot_of_report_records_33d30dbbf2.png)
図7：レポート記録のスクリーンショット
テキストを読む
text_unit_df = pd.read_parquet(f"{INPUT_DIR}/{TEXT_UNIT_TABLE}.parquet")
text_units = read_indexer_text_units(text_unit_df)
print(f "テキストユニットのレコード：{len(text_unit_df)}")。
text_unit_df.head()
テキストユニットのレコード：51
図8-テキストユニット記録のスクリーンショット](https://assets.zilliz.com/Figure_8_a_screenshot_of_text_unit_records_259dc6146c.png)
図8：テキスト単位記録のスクリーンショット_()
ローカル検索エンジンの作成
ローカル検索エンジンに必要なデータが揃った。次に、これらのデータとLLM、埋め込みモデルを使って LocalSearch インスタンスを作成します。
ローカル検索エンジンに必要なデータを用意しました。これで、それらとLLMと埋め込みモデルを使って LocalSearch インスタンスを構築できる。
api_key = os.environ["OPENAI_API_KEY"] # OpenAIのAPIキー
llm_model = "gpt-4o" # または gpt-4-turbo-preview
埋め込みモデル = "text-embedding-3-small"
llm = ChatOpenAI(
api_key=api_key、
model=llm_model、
api_type=OpenaiApiType.OpenAI、
max_retries=20、
)
token_encoder = tiktoken.get_encoding("cl100k_base")
text_embedder = OpenAIEmbedding(
api_key=api_key、
api_base=None、
api_type=OpenaiApiType.OpenAI、
model=embedding_model、
deployment_name=embedding_model、
max_retries=20、
)
context_builder = LocalSearchMixedContext(
community_reports=reports、
text_units=text_units、
entities=entities、
relationships=relationships、
covariates=None, #covariates,#todo
entity_text_embeddings=description_embedding_store、
embedding_vectorstore_key=EntityVectorStoreKey.ID,#vectorstoreがidとしてエンティティタイトルを使用する場合、EntityVectorStoreKey.TITLEに設定します。
text_embedder=text_embedder、
token_encoder=token_encoder、
)
local_context_params = {
"text_unit_prop"：0.5,
"community_prop"：0.1,
"conversation_history_max_turns"：5,
「conversation_history_user_turns_only"：真、
「top_k_mapped_entities"：10,
「top_k_relationships"：10,
「include_entity_rank"：真、
"include_relationship_weight"：真：真、
"include_community_rank"：真：偽、
"return_candidate_context"：False、
"embedding_vectorstore_key"：EntityVectorStoreKey.ID、 # ベクトルストアがエンティティのタイトルをIDとして使用する場合は、EntityVectorStoreKey.TITLEに設定します。
"max_tokens"：12_000, # モデルのトークン制限に応じて変更してください（8k制限のモデルを使用している場合、5000に設定するのが良いでしょう）。
}
llm_params = {
"max_tokens"：2_000, # トークンの上限に応じて変更する(上限が8kのモデルを使用している場合、1000=1500に設定するのが良いでしょう)
"temperature"：0.0,
}
search_engine = LocalSearch(
llm=llm、
context_builder=context_builder、
token_encoder=token_encoder、
llm_params=llm_params、
context_builder_params=local_context_params、
response_type="複数段落", # レスポンスのタイプとフォーマットを記述する自由形式のテキスト。
)
クエリを作成する。
result = await search_engine.asearch("Tell me about Leonardo Da Vinci")
print(result.response)
# レオナルド・ダ・ヴィンチ
レオナルド・ダ・ヴィンチは1452年、フィレンツェ近郊の町ヴィンチに生まれ、イタリア・ルネサンス期における最も多才な天才の一人として広く知られている。彼のフルネームはレオナルド・ディ・セル・ピエロ・ダントニオ・ディ・セル・ピエロ・ディ・セル・グイド・ダ・ヴィンチであり、田舎の公証人であったセル・ピエロの長男であった[Data: Entities (0)]。レオナルドの貢献は芸術、科学、工学、哲学など様々な分野に及び、キリスト教時代における最も普遍的な天才の称号を得た［Data: Entities (8)］。
## 生い立ちと訓練
レオナルドはその才能を父に見込まれ、有名な画家であり彫刻家であったアンドレア・デル・ヴェロッキオのもとへ彼のデッサンのいくつかを持ち込んだ。レオナルドの才能に感銘を受けたヴェロッキオは、1469年から1470年頃に彼を工房に受け入れた。ここでレオナルドは、ボッティチェッリやロレンツォ・ディ・クレディなど、他の著名な芸術家たちと知り合った［Data: Sources (6, 7)］。1472年、レオナルドはフィレンツェの画家組合に入会し、プロとしてのキャリアをスタートさせた［Data: Sources (7)］。
## 芸術的傑作
レオナルドはおそらく、"モナ・リザ "や "最後の晩餐 "といった象徴的な絵画で最もよく知られている。微妙な表情と詳細な背景で有名な "モナ・リザ "はルーブル美術館に所蔵されており、世界で最も有名な芸術作品の1つである［Data: Relationships (0, 45)］。「最後の晩餐》は、イエスが弟子の一人に裏切りを告げる瞬間を描いたフレスコ画で、ミラノのサンタ・マリア・デッレ・グラツィエの食堂にある［データ：情報源（2）］。その他の代表作には、1489年から1490年頃に着手した『岩窟の聖母』や『絵画論』などがある［データ：関係資料（7、12）］。
## 科学と工学への貢献
レオナルドの天才的な才能は、芸術だけでなく、様々な科学や工学の分野にも及んだ。解剖学、光学、水力学において重要な観察を行い、彼のノートには多くの近代的発明を先取りしたスケッチやアイデアが詰まっている。例えば、彼はコペルニクスの地球運動説やラマルクの動物分類を先取りしていた［Data: Relationships (38, 39)］。光と影の法則に関する彼の研究と、キアロスクーロの習得は、芸術と科学の両方に多大な影響を与えた［データ：情報源（45）］。
## パトロンと仕事上の関係
レオナルドのキャリアはパトロンから大きな影響を受けた。ミラノ公ルドヴィーコ・スフォルツァは、宮廷画家および一般工芸家としてレオナルドを雇い、様々な作品を依頼し、1499年には葡萄畑まで贈った［データ：関係（9、19、84）］。晩年、レオナルドは国王フランシスコ1世の庇護のもとフランスに移り住み、フランシスコ1世はレオナルドに莫大な収入を与え、高く評価した［Data: Relationships (114, 37)］。レオナルドは晩年をアンボワーズ近郊のクルー邸で過ごし、王の訪問を頻繁に受け、親友で助手のフランチェスコ・メルツィに支えられた［Data: Relationships (28, 122)］。
## 遺産と影響力
レオナルド・ダ・ヴィンチの影響力は、その生涯をはるかに超えた。彼はミラノに絵画学校を創設し、彼の技法と教えは、ジョヴァンニ・アンブロージョ・ダ・プレディスやフランチェスコ・メルツィなどの弟子や信奉者たちによって受け継がれた［データ：関係（6、15、28）］。彼の作品は称賛され研究され続け、ルネサンス期における最も偉大な巨匠の一人としての遺産を確固たるものにしている。芸術と科学を融合させたレオナルドの能力は、両分野に忘れがたい足跡を残し、数え切れない世代の芸術家や科学者にインスピレーションを与えた［Data: Entities (148, 86); Relationships (27, 12)］。
まとめると、レオナルド・ダ・ヴィンチの芸術、科学、工学への比類なき貢献は、彼の革新的な思考と同時代の人々や後世への深い影響と相まって、人類の偉業史に燦然と輝く人物となった。彼の遺産は称賛と研究を刺激し続け、彼の天才が時代を超えて通用することを強調している。
GraphRAGの結果は具体的で、引用されたデータソースが明記されている。
質問生成
GraphRAGは過去のクエリに基づいて質問を生成することもでき、チャットボットのダイアログでおすすめの質問を作成するのに便利です。この方法では、ナレッジグラフの構造化データと入力ドキュメントの非構造化データを組み合わせて、特定のエンティティに関連する質問候補を生成する。
question_generator = LocalQuestionGen(
llm=llm、
context_builder=context_builder、
token_encoder=token_encoder、
llm_params=llm_params、
context_builder_params=local_context_params、
)
question_history = [
「レオナルド・ダ・ヴィンチについて教えてください、
「レオナルドの初期の作品
]
歴史に基づいた質問を生成する。
candidate_questions = await question_generator.agenerate(
question_history=question_history, context_data=None, question_count=5
)
候補_質問.応答
[レオナルド・ダ・ヴィンチの初期の作品にはどのようなものがありますか？
"-レオナルド・ダ・ヴィンチとアンドレア・デル・ヴェロッキオとの関係は、彼の初期の作品にどのような影響を与えたか？"、
'-レオナルド・ダ・ヴィンチはミラノ時代にどのような注目すべきプロジェクトを手がけましたか？
"-レオナルド・ダ・ヴィンチの技術力は彼のプロジェクトにどのように貢献したか？
"-レオナルド・ダ・ヴィンチとフランスのフランシスコ1世との関係はどのような意味を持っていたのか？"], "-レオナルド・ダ・ヴィンチとフランスのフランシスコ1世との関係はどのような意味を持っていたのか？
スペースを節約するためにインデックスを削除したい場合は、インデックスのルートを削除することができます。
# インポート
#
# shutil.rmtree(index_root)
要約
このブログでは、知識グラフを統合することでRAG技術を強化する革新的な手法であるGraphRAGについて説明した。GraphRAGは、マルチホップ推論や、異なる情報の断片を結びつける必要のある包括的な質問に答えるといった複雑なタスクに取り組むのに理想的である。
Milvus](https://zilliz.com/what-is-milvus)ベクトルデータベースと組み合わせることで、GraphRAGは大規模なデータセット内の複雑な意味的関係をナビゲートし、より正確で洞察に満ちた結果を提供することができる。この強力な組み合わせにより、GraphRAGは様々な実用的なGenAIアプリケーションの貴重な資産となり、複雑な情報を理解し処理するための堅牢なソリューションを提供する。
その他のリソース
グラフRAG論文:** ローカルからグローバルへ：クエリにフォーカスした要約へのグラフRAGアプローチ
GraphRAG GitHub:** https://github.com/microsoft/graphrag
その他のRAG拡張技術:**
HyDE - Hypothetical Document EmbeddingsによるRAGの改善 ](https://zilliz.com/learn/improve-rag-and-information-retrieval-with-hyde-hypothetical-document-embeddings)
WhyHowを使った知識グラフによるRAGの強化](https://zilliz.com/blog/enhance-rag-with-knowledge-graphs)
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/praticial-tips-and-tricks-for-developers-building-rag-applications)
カスタムAIモデルによるRAGのスケーリングにおけるインフラの課題](https://zilliz.com/blog/infrastructure-challenges-in-scaling-rag-with-custom-ai-models)
Cheney ZhangCheney Zhang is an accomplished Algorithm Engineer at Zilliz. With a profound passion for and expertise in cutting-edge AI technologies such as LLMs and Retrieval Augmented Generation (RAG), Cheney has actively contributed to many innovative AI projects, including Towhee, Akcio, and OSSChat. Before joining Zilliz, he worked for CMB Network Technology as an Algorithm Engineer. Cheney holds a master's degree from Nanjing University of Aeronautics and Astronautics.
読み続けて
Semantic Search vs. Lexical Search vs. Full-text Search
Lexical search offers exact term matching; full-text search allows for fuzzy matching; semantic search understands context and intent.
GPL: Generative Pseudo Labeling for Unsupervised Domain Adaptation of Dense Retrieval
GPL is an unsupervised domain adaptation technique for dense retrieval models that combines a query generator with pseudo-labeling.
Unlocking Rich Visual Insights with RGB-X Models
RGB-X models: advanced ML models in computer vision that extend traditional RGB data by combining additional depth, infrared, or surface normals data.