VectorStoreからGraphRAGへ検索・回答精度を高める情報構造

2024/08/08

1. はじめに：RAGの限界とGraphRAGの可能性

　社内情報の検索精度を高める手段として、RAG（Retrieval-Augmented Generation）を導入する企業が増えています。ベクトル検索によって関連文書を取得し、LLM（大規模言語モデル）に渡して回答を生成するこの手法は、比較的早くPoCが可能で、一定の効果も得られます。

　しかし、実際の導入・運用フェーズでは、いくつかの限界が顕在化しています。たとえば、「正しい文書を引けているのに、なぜそれが選ばれたのかが説明できない」「複数の文書や部署をまたぐような質問に弱い」といった課題です。これらは、RAGが文書同士の関係性や文脈を考慮せず、類似性のみに基づいて情報を抽出していることに起因します。

　このような課題を補う手法として注目されているのが GraphRAG です。GraphRAGは、文書やエンティティ間の関係性を明示的に構造化し、LLMの生成に必要な文脈を「意味的なつながり」に基づいて提供します。これにより、検索の精度向上だけでなく、「なぜこの情報が選ばれたのか」といった根拠を示すことも可能になります。

　特に、業務マニュアル・手順書・規程・フロー図といった社内のドメイン知識が複雑に絡み合う領域では、GraphRAGの有効性が際立ちます。従来のRAGやファインチューニングだけではカバーしきれない構造的な知識を、グラフ構造として扱うことで、より説明性と信頼性の高いQAエンジンの構築が可能になります。

2. GraphRAG導入で改善した社内QA事例

私たちが社内で構築したQAエンジンでは、以下のような状況でGraphRAGが有効に機能しました：

背景：数百ページにわたる社内手続きマニュアル、業務フロー図、FAQなどが点在
課題：類似検索だけでは、業務間のつながりやフローを理解できない
実装：各業務をノードに、業務間の関係（前工程→後工程、承認フローなど）をエッジにしてGraphを構築
効果：「A業務の関連部門と手順は？」のような質問に、関係図とともに根拠付きで回答できるようになった

Graph設計で重要になるのが、「何をノードとし、何をエッジとするか」の設計思想です。

ノードの粒度：

業務単位 / 文書の章節 / 固有名詞（制度名・プロジェクト名）
NLPベースで抽出しつつ、社内用語辞書でチューニング

エッジの関係性：

「参照関係」「前提条件」「更新関係」「関連部署」などを定義
エッジタイプに重みづけをして、検索時に優先度を調整

3. 従来の知識グラフとgraphiti

従来の知識グラフとその制約

　従来の知識グラフは、明確なスキーマ（エンティティの種類や関係性の定義）をあらかじめ設計し、それに従ってデータを収集・構造化する手法が主流でした。ノードやリレーションの構造、属性、制約（ユニーク性、型など）を精密に定義する必要があり、そのためにはドメイン知識とモデリング技術に長けた専門家の関与が不可欠でした。

　この設計手法は、一貫性や拡張性に優れる一方で、柔軟性に欠けるという課題を抱えていました。例えば、非構造な社内文書や口語的なやりとり、定義が曖昧な概念などはスキーマに即して取り込むのが難しく、前処理やデータ整形に膨大な工数がかかるケースが多発していました。

　さらに、運用フェーズではスキーマ変更が困難なため、設計初期の誤りや未定義だったケースに柔軟に対応できないという制約も生じます。加えて、ナレッジグラフをLLMなど生成系AIと連携させようとした場合にも、従来の構造では連携設計が煩雑になり、迅速なプロトタイピングが困難でした。

従来の知識グラフの制約を補完するgraphiti

　こうした従来の知識グラフの制約を補完する存在が graphiti です。graphitiは、LangChainと統合できる軽量なグラフストアであり、LLMによる非構造テキストからの自動グラフ構築を支援するために設計されたツールです。

　最大の特徴は、事前スキーマが不要で、JSONやYAMLによるシンプルなノード・エッジ定義が可能な点です。LLMから出力された関係情報をそのままGraph構造として取り込み、LangChainのGraphQAChainなどに接続して即座にQAシステムとして検証できます。

　この柔軟さにより、社内文書やFAQなどの構造化が難しい知識を、段階的にナレッジグラフ化し、運用・評価・再設計のサイクルを高速に回すことが可能です。さらに、graphitiで構築した知識グラフは、安定した構造に整形したうえでNeo4jなどの本番環境に移行することもできます。

　つまりgraphitiは、従来の知識グラフ設計の“硬直性”を補う柔軟で軽量なGraph基盤として、プロトタイピングやLLM時代の知識統合における中核的な役割を担います。

4. GraphRAGが向く領域・向かない領域

VectorStoreによる類似文書検索の限界と、その課題を保管するGraphRAGを紹介してきましたが、GraphRAGがどのような場合にも有用ということではありません。要件によってはVectorStoreでも十分な場合も多く、GraphRAGは過剰になるケースもあります。

RAGを検討する際には、現状の課題や要件を考慮したうえで、どのようなRAGパイプラインが求められるのかを検討することが必要です。

向く領域：

社内規程・手順・フローが複雑で、関係性が重要なドメイン
データがある程度構造化されている or 関係が設計できる
「なぜその回答なのか」説明性が求められる場面

向かない領域：

単発のFAQ、ナレッジベースの検索精度がそもそも高い場合
ドキュメント間の関係性が薄く、ただのキーワード検索で十分な場合

5. まとめ：RAGを次のレイヤーに引き上げる選択肢としてのGraph設計

　GraphRAGは、単なる精度向上ではなく、知識の構造を意識した設計そのものです。RAGの延長線上というより、別の思想体系に近いとも言えます。

　情報が複雑になるほど、「構造」が武器になります。社内情報の“見える化”や“活用”に課題を感じている企業こそ、GraphRAGという選択肢を考えてみてはいかがでしょうか？