Graph RAG エンティティ抽出（グラフラグエンティティチュウシュツ）
Graph RAGにおけるエンティティ抽出とは、テキストコーパスの各チャンクからLLMを用いて固有表現（人物・組織・技術・概念等）とそれらの間の関係を構造化データとして抽出するプロセスである。NERベースの手法とLLMベースの手法を組み合わせ、共参照解決やエンティティ正規化を通じてグラフ構築の基盤を形成する。
エンティティ抽出の概要
Graph RAGにおけるエンティティ抽出は、非構造化テキストから構造化されたエンティティ（ノード候補）と関係（エッジ候補）を抽出するプロセスであり、ナレッジグラフ構築の最初のステップかつ最も品質に影響を与える工程である。
従来のNER（Named Entity Recognition）がBERT/SpaCy等の専用モデルで固有表現を認識するのに対し、Graph RAGではLLMのゼロショット/Few-shot能力を活用して、エンティティだけでなくエンティティ間の関係まで一度に抽出する。この統合的なアプローチにより、パイプラインの簡素化と柔軟性の向上を実現している。
エンティティ抽出の品質はGraph RAG全体の性能に直結する。抽出精度が低いとナレッジグラフにノイズが混入し、コミュニティ検出の品質が劣化する。逆に再現率が低いと重要な情報が欠落し、クエリ時に不完全な回答が生成される。
NERベースの手法
従来のNERパイプライン
NER（Named Entity Recognition）は自然言語処理の基本タスクであり、テキスト中の固有表現を認識・分類する。Graph RAGの文脈では、LLMベースの抽出の補完や前処理として活用される。
| NERツール | ベースモデル | 対応言語 | エンティティ型 | 処理速度 |
|---|---|---|---|---|
| SpaCy | Transformer/CNN | 60+ | PERSON, ORG, LOC等 | 高速 |
| Stanza (Stanford NLP) | BiLSTM-CRF | 66 | PER, ORG, LOC, MISC | 中速 |
| Flair | Transformer | 20+ | カスタム可能 | 中速 |
| Hugging Face NER | BERT/RoBERTa | 100+ | カスタム可能 | モデル依存 |
| GiNZA | Transformers | 日本語特化 | 人名, 組織, 地名等 | 中速 |
NERとLLM抽出の使い分け
NERベースの手法は処理速度とコスト効率に優れるが、定義されたエンティティ型以外の概念的エンティティ（技術手法、理論、トレンド等）の認識が困難である。一方、LLMベースの抽出は柔軟性が高いが、コストと処理時間がかかる。
実運用では、NERで基本的な固有表現を高速に抽出した後、LLMで概念的エンティティと関係を補完的に抽出するハイブリッドアプローチが効果的である。
LLMによる関係抽出
プロンプト設計の詳細
Graph RAGの関係抽出プロンプトは、エンティティ抽出と統合された形で設計される。Microsoft GraphRAGのデフォルトプロンプトでは、以下の出力フォーマットが定義されている。
エンティティの出力形式:
- entity_name: エンティティ名（正式名称）
- entity_type: エンティティ型（PERSON, ORGANIZATION, TECHNOLOGY等）
- entity_description: エンティティの説明文（1〜3文）
関係の出力形式:
- source_entity: ソースエンティティ名
- target_entity: ターゲットエンティティ名
- relationship_description: 関係の説明文
- relationship_strength: 関係の強度（1〜10のスコア）
関係の方向性と型
Graph RAGでは関係に方向性を持たせることが可能だが、デフォルト実装では無向グラフとして扱われる。関係の型は自由記述であり、LLMが文脈に応じて適切な関係説明を生成する。
| 関係パターン | 説明 | 例 |
|---|---|---|
| 所属関係 | 人物・組織間の帰属 | 「AはBに所属している」 |
| 開発関係 | 技術・製品の開発者 | 「AがBを開発した」 |
| 使用関係 | 技術・ツールの利用 | 「AはBを使用している」 |
| 比較関係 | 競合・代替技術 | 「AはBの代替手法である」 |
| 依存関係 | 技術的依存性 | 「AはBに依存している」 |
| 発展関係 | 技術の進化・改良 | 「AはBを発展させたものである」 |
抽出品質の向上手法
抽出品質を向上させるための主要な手法は以下のとおりである。
- Few-shot例の最適化: ドメイン固有の抽出例を3〜5件提供することで、抽出精度が大幅に向上する。例はコーパスのドメインに合わせて選定する
- エンティティ型の事前定義: 抽出対象のエンティティ型リストを明示的に提供することで、無関係なエンティティの抽出を抑制する
- チャンクサイズの調整: 小さすぎるチャンクではエンティティ間の関係が分断され、大きすぎるチャンクではLLMの注意が分散する。300〜600トークンが推奨範囲
- チャンクオーバーラップ: 隣接チャンク間に50〜100トークンのオーバーラップを設けることで、チャンク境界でのエンティティ・関係の欠落を防ぐ
共参照解決（Coreference Resolution）
共参照解決の必要性
テキスト中では同一エンティティが代名詞（「彼」「それ」「同社」等）や略称、別名で参照されることが頻繁にある。これらの共参照を解決しないと、ナレッジグラフに重複ノードが生成され、グラフの品質が低下する。
共参照解決の手法
| 手法 | 説明 | 精度 | コスト |
|---|---|---|---|
| ルールベース | 代名詞と直近の固有名詞を対応付け | 低〜中 | 最低 |
| SpaCy/NeuralCoref | ニューラルネットワークベースの共参照解決 | 中 | 低 |
| LLM統合 | 抽出時に共参照をLLMに解決させる | 高 | 高 |
| 後処理マージ | 抽出後にエンティティ類似度で統合 | 中〜高 | 中 |
Graph RAGでは、LLM統合アプローチが最も効果的である。エンティティ抽出プロンプトに「代名詞は正式名称に展開すること」という指示を含めることで、抽出段階で共参照が解決される。ただし完全な解決は困難であり、後処理でのエンティティマージも併用する。
エンティティ正規化
名称の揺れへの対処
同一エンティティが異なる表記で出現する問題は、日本語テキストで特に顕著である。
| 正規化対象 | 変換前の例 | 正規化後 |
|---|---|---|
| 略称展開 | MS, MSFT | Microsoft |
| 表記統一 | グーグル, Google, google | |
| 別名統合 | GPT-4, GPT4, gpt-4 | GPT-4 |
| 敬称除去 | 田中教授, 田中先生 | 田中（PERSON） |
| 組織名正規化 | 東大, 東京大学, UTokyo | 東京大学 |
エンティティマージ戦略
類似エンティティの統合では、以下の戦略を段階的に適用する。
- 完全一致: 名称が完全に一致するエンティティを統合
- 正規化一致: 小文字化・空白除去後に一致するエンティティを統合
- 類似度ベース: 文字列類似度（Jaro-Winkler > 0.9）で候補ペアを特定し、LLMで判定
- セマンティック: Embeddingの類似度が高いペアをLLMで判定（コスト高だが精度最高）
エラー分析と品質改善
一般的な抽出エラー
| エラー型 | 説明 | 対処法 |
|---|---|---|
| 過剰抽出 | 非エンティティをエンティティとして抽出 | エンティティ型の制限、後処理フィルタ |
| 抽出漏れ | 重要エンティティの見逃し | Gleaning回数増加、チャンクサイズ縮小 |
| 型誤分類 | エンティティ型の誤判定 | Few-shot例の追加、型定義の明確化 |
| 関係幻覚 | 存在しない関係の捏造 | 関係強度の閾値フィルタ、元テキスト検証 |
| 粒度不一致 | 抽象度の異なるエンティティの混在 | 抽出プロンプトでの粒度指示 |
よくある質問（FAQ）
Q1: エンティティ抽出にGPT-4とGPT-4o-miniのどちらを使うべきですか？
コストと品質のトレードオフで判断する。GPT-4はエンティティ抽出の精度と関係の記述品質で優れるが、大規模コーパスではコストが数百ドルに達する。GPT-4o-miniは精度が10〜15%低下するが、コストは1/10以下になる。推奨戦略は、初回の実験・チューニングにはGPT-4o-miniを使い、プロンプトが安定した後の本番インデックス構築にGPT-4を使う二段階アプローチである。Claude 3.5 SonnetやGemini 1.5 Proも同等の精度で利用可能であり、コスト比較を行ったうえで選択する。
Q2: 日本語テキストのエンティティ抽出で注意すべき点は何ですか？
日本語テキストでは、単語境界の曖昧さ、敬称・接尾辞の処理、漢字・カタカナ・ひらがなの表記揺れが課題となる。GiNZAやSudachiによる形態素解析を前処理として適用し、LLMには正規化されたテキストを入力する方法が有効である。また、日本語の固有表現は英語より長い傾向があるため、チャンクサイズをトークン数ではなく文字数で管理することを推奨する。エンティティ型の定義に日本語の例を含めることで、LLMの抽出精度が向上する。
Q3: 抽出したエンティティの品質をどう検証しますか？
ゴールドスタンダード（人手でアノテーションした正解データ）との比較が最も信頼性の高い検証方法である。ただし大規模なアノテーションはコストが高いため、実運用ではサンプリング検証が一般的である。100〜200チャンクをランダムに抽出し、人手で正解を作成して精度（Precision）・再現率（Recall）・F1スコアを算出する。F1 > 0.75が実用的な品質基準とされる。自動検証として、抽出されたエンティティの次数分布やパワーロー適合度をチェックする手法も有効である。