Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Knowledge Base 検索アーキテクチャ:Vector Search + Full-Text Search + Rerank 三層パイプラインの設計思想

はじめに

RAG(Retrieval-Augmented Generation)は、LLM の幻覚(ハルシネーション)を抑制し、企業固有の知識に基づいた回答を生成するための基本的なアーキテクチャパターンである。しかし「RAG を導入すれば精度が上がる」という単純な話ではない。検索精度が低ければ、LLM に渡される文脈が不正確になり、回答品質は劣化する。

Dify は Knowledge Base の検索アーキテクチャとして、Vector Search(ベクトル検索)、Full-Text Search(全文検索)、Rerank(再ランキング)の三層パイプラインを採用している。本稿では、なぜこの三層が必要なのか、各層がどのような問題を解決するのかを、企業文書検索の実例を交えて解説する。


1. 三層パイプラインの全体像

graph TB
    Q[ユーザークエリ] --> P[クエリ前処理]
    
    P --> VS[Vector Search<br/>意味的類似性]
    P --> FTS[Full-Text Search<br/>キーワード一致]
    
    VS --> M[Merge<br/>候補統合]
    FTS --> M
    
    M --> RR[Rerank Model<br/>関連度再スコアリング]
    
    RR --> TOP[Top-K 選択]
    TOP --> LLM[LLM<br/>回答生成]
    
    style VS fill:#4a9,stroke:#333,color:#fff
    style FTS fill:#49a,stroke:#333,color:#fff
    style RR fill:#a49,stroke:#333,color:#fff

1.1 なぜ単一の検索手法では不十分なのか

企業文書に対するクエリは、以下のように多様な性質を持つ:

クエリの種類最適な検索手法
意味的検索「退職する際に必要な手続きは?」Vector Search
キーワード検索「ERR-4052 の原因」Full-Text Search
混合型「第24条に基づく個人情報の取り扱い」Hybrid + Rerank
曖昧な表現「休みの取り方」Vector Search
専門用語「FISC 安全対策基準 第9章」Full-Text Search

単一の検索手法でこのすべてをカバーすることは原理的に困難である。


2. 第一層:Vector Search(ベクトル検索)

2.1 仕組み

Vector Search は、テキストを高次元ベクトル(Embedding)に変換し、ベクトル空間上の距離(コサイン類似度など)で類似性を計算する:

graph LR
    subgraph "インデックス構築時"
        D1[文書チャンク] --> E1[Embedding Model]
        E1 --> V1[ベクトル<br/>0.12, -0.34, ..., 0.56]
        V1 --> VDB[(Vector DB)]
    end
    
    subgraph "検索時"
        Q[クエリ] --> E2[Embedding Model]
        E2 --> V2[クエリベクトル]
        V2 --> S[類似度計算]
        VDB --> S
        S --> R[Top-K 候補]
    end

2.2 Vector Search が得意なこと

  • 表現の揺れを吸収: 「退職手続き」と「会社を辞めるときにやること」を意味的に近いと判定
  • 口語的な質問への対応: 自然言語で書かれた質問を、形式的な文書とマッチング
  • 多言語対応: 多言語 Embedding モデルを使えば、日本語の質問で英語文書を検索可能

2.3 Vector Search の限界

限界具体例影響
キーワードの正確な一致が弱い「ERR-4052」で検索しても、意味的に近い別のエラーコードが上位に来る技術文書の精度低下
数値・コードの扱いが苦手「第24条」が「第23条」の文書とも高い類似度を示す法務文書の信頼性低下
Embedding モデルの品質に依存日本語の専門用語が適切にベクトル化されない場合があるドメイン特化文書の精度低下
短いクエリの意図推定が不安定「経費」だけでは、申請方法か規定か精算かが不明確検索結果のばらつき

2.4 Embedding モデルの選択

Dify は複数の Embedding モデルをサポートしており、ユースケースに応じた選択が可能:

モデル次元数日本語性能コスト適用シナリオ
text-embedding-3-small (OpenAI)1536良好一般的な社内文書
text-embedding-3-large (OpenAI)3072良好高精度が必要な場合
multilingual-e5-large1024良好無料(ローカル)閉域網・コスト重視
Cohere embed-multilingual-v31024良好多言語混在環境
BGE-M31024優良無料(ローカル)日本語重視・閉域網

3. 第二層:Full-Text Search(全文検索)

3.1 仕組み

Full-Text Search は、トークン化(形態素解析)されたテキストに対して、TF-IDF や BM25 アルゴリズムでキーワードの一致度を計算する:

graph LR
    subgraph "インデックス構築時"
        D1[文書チャンク] --> T1[トークナイザー<br/>形態素解析]
        T1 --> I1[転置インデックス]
        I1 --> FTI[(全文検索<br/>インデックス)]
    end
    
    subgraph "検索時"
        Q[クエリ] --> T2[トークナイザー]
        T2 --> K[キーワード抽出]
        K --> S[BM25 スコアリング]
        FTI --> S
        S --> R[Top-K 候補]
    end

3.2 Full-Text Search が得意なこと

  • 正確なキーワード一致: エラーコード、条項番号、製品型番、人名の完全一致
  • 専門用語の検索: 業界固有の略語、社内用語への対応
  • 高速な応答: 転置インデックスによる高速検索
  • 解釈可能性: なぜその結果が返されたかが明確(キーワードの一致)

3.3 Full-Text Search の限界

限界具体例影響
表現の揺れに弱い「退職」と「離職」が別物として扱われる関連文書の見逃し
同義語の処理が必要「PC」「パソコン」「コンピュータ」シノニム辞書の運用負荷
日本語形態素解析の精度新語、社内造語、カタカナ語の分割ミス検索漏れ
文脈的な意味の無視「Apple」が果物か企業かを区別できないノイズの増加

3.4 日本語全文検索の特殊性

日本語は英語と異なり、単語間にスペースがないため、形態素解析器の品質が検索精度に直結する:

入力: 「個人情報保護法に基づくデータ取扱規定」

MeCab/Sudachi の解析結果:
個人情報 / 保護法 / に / 基づく / データ / 取扱 / 規定

N-gram (bi-gram) の場合:
個人 / 人情 / 情報 / 報保 / 保護 / 護法 / 法に / ...

企業文書では、形態素解析器に社内辞書を追加することで精度を向上させることが一般的だが、Dify の場合はベクトル検索との組み合わせにより、形態素解析の弱点を補完する設計になっている。


4. 第三層:Rerank(再ランキング)

4.1 なぜ Rerank が必要なのか

Vector Search と Full-Text Search はそれぞれ異なるスコアリングロジックを持つ。両者の結果を単純にマージしても、最適な順序にはならない:

graph TB
    subgraph "Rerank なしの問題"
        VS_R[Vector Search 結果<br/>スコア: 0.89, 0.85, 0.82, ...]
        FTS_R[Full-Text Search 結果<br/>スコア: 12.3, 8.7, 6.2, ...]
        
        VS_R --> MERGE[単純マージ]
        FTS_R --> MERGE
        MERGE --> PROB[問題: スコアの尺度が異なる<br/>どちらを優先すべきか不明]
    end
    
    subgraph "Rerank ありの解決"
        CAND[統合候補リスト]
        CAND --> RR[Rerank Model<br/>クエリと各候補の<br/>関連度を直接評価]
        RR --> SORTED[統一スコアで再ソート]
    end
    
    style PROB fill:#f99,stroke:#333
    style SORTED fill:#9f9,stroke:#333

4.2 Rerank Model の仕組み

Rerank Model は、クエリと文書ペアの関連度を Cross-Encoder で直接スコアリングする:

# Rerank の概念モデル
def rerank(query: str, documents: list[str], model: str) -> list[RerankResult]:
    """
    各文書をクエリとの関連度で再スコアリング。
    Cross-Encoder は Bi-Encoder (Embedding) より精度が高いが、
    計算コストが高いため、候補を絞った後に適用する。
    """
    results = []
    for doc in documents:
        # クエリと文書を連結して入力し、関連度スコアを出力
        score = cross_encoder.predict(f"{query} [SEP] {doc}")
        results.append(RerankResult(document=doc, score=score))
    
    return sorted(results, key=lambda x: x.score, reverse=True)

4.3 Rerank が解決する問題

問題Rerank による解決
Vector / Full-Text のスコア尺度の違い統一的な関連度スコアで再評価
表面的に関連するが実質的に無関係な文書クエリとの文脈的整合性を精密に評価
候補数が多すぎる場合のノイズ上位候補のみを LLM に渡すことでコンテキスト品質を向上
長文チャンクの部分的な一致チャンク全体とクエリの関連性を評価

4.4 Rerank Model の選択肢

モデル提供元日本語対応コスト特徴
Cohere Rerank v3Cohere多言語対応API 課金高精度・簡単導入
bge-reranker-v2-m3BAAI多言語対応無料(ローカル)閉域網対応
cross-encoder/ms-marcoHugging Face英語中心無料(ローカル)英語文書向け
Jina Reranker v2Jina AI多言語対応API 課金高速

5. Hybrid Search:三層の統合

5.1 Dify の Hybrid Search 設定

Dify は Knowledge Base の作成時に、以下の検索方式を選択可能:

検索方式構成適用シナリオ
Vector Searchベクトル検索のみ意味検索中心の FAQ
Full-Text Search全文検索のみ技術文書のキーワード検索
Hybrid Searchベクトル + 全文 + Rerank汎用的な企業文書(推奨)

5.2 Hybrid Search の処理フロー詳細

sequenceDiagram
    participant U as ユーザー
    participant API as Dify API
    participant VS as Vector Search
    participant FTS as Full-Text Search
    participant RR as Rerank Model
    participant LLM as LLM

    U->>API: クエリ送信
    API->>API: クエリ前処理
    
    par 並列検索
        API->>VS: Embedding + ANN検索
        VS-->>API: Vector候補 (Top-N)
        API->>FTS: トークン化 + BM25検索
        FTS-->>API: Full-Text候補 (Top-N)
    end
    
    API->>API: 候補の統合・重複排除
    API->>RR: 統合候補リスト + クエリ
    RR-->>API: 再ランキング結果
    API->>API: Top-K 選択
    API->>LLM: クエリ + Top-K 文書チャンク
    LLM-->>API: 回答生成
    API-->>U: 回答返却

5.3 Weight 設定の考え方

Hybrid Search では、Vector Search と Full-Text Search の重み配分を調整できる。Dify ではスライダーで 0.0 ~ 1.0 の範囲で設定可能:

Weight 設定Vector : Full-Text適用シナリオ
1.0 : 0.0Vector のみ社内 FAQ、自由記述クエリ中心
0.7 : 0.3Vector 寄り一般的な社内文書(推奨初期値)
0.5 : 0.5均等混合的なクエリが予想される場合
0.3 : 0.7Full-Text 寄り型番・コード検索が多い場合
0.0 : 1.0Full-Text のみエラーコード検索、規程条文検索

6. インデキシング設計:検索精度の前段階

6.1 チャンキング戦略

検索精度は、インデキシング段階のチャンク分割方法に大きく依存する:

チャンキング方式説明メリットデメリット
固定長分割500トークンずつ分割シンプル・一貫性文脈が分断される
セパレータ分割見出し・改行で分割文書構造を保持チャンクサイズの不均一
セマンティック分割意味的まとまりで分割高品質な検索単位処理コスト高
親子チャンク小チャンクで検索、親チャンクを返却検索精度と文脈の両立実装複雑性

Dify は複数のチャンキング方式をサポートしており、文書の種類に応じた選択が可能。

6.2 インデックス方式の選択

Dify は2種類のインデックス方式を提供している:

graph TB
    subgraph "高品質モード (Recommended)"
        HQ_D[文書] --> HQ_C[チャンク分割]
        HQ_C --> HQ_E[Embedding Model<br/>ベクトル化]
        HQ_E --> HQ_V[(Vector Index)]
        HQ_C --> HQ_F[(Full-Text Index)]
        HQ_V --> HQ_H{Hybrid Search<br/>+ Rerank}
        HQ_F --> HQ_H
    end
    
    subgraph "経済モード"
        EC_D[文書] --> EC_C[チャンク分割]
        EC_C --> EC_K[キーワードインデックス]
        EC_K --> EC_S{キーワード検索のみ}
    end
    
    style HQ_H fill:#4a9,stroke:#333,color:#fff
  • 高品質モード: Embedding + Full-Text Index を両方構築。Hybrid Search + Rerank が利用可能。コストは高いが精度が高い。
  • 経済モード: キーワードインデックスのみ。Embedding Model の API コストが不要だが、意味検索ができない。

7. 企業文書における検索精度の実践的な考慮事項

7.1 文書タイプ別の推奨設定

文書タイプ推奨検索方式WeightRerank理由
社内規程・就業規則Hybrid0.5:0.5有効条項番号と意味検索の両方が必要
技術マニュアルHybrid0.3:0.7有効エラーコード・パラメータのキーワード検索が重要
FAQ データVector1.0:0.0任意質問の表現揺れが大きい
契約書Hybrid0.5:0.5有効条項番号 + 法的概念の意味検索
議事録Vector0.7:0.3有効口語表現が多く意味検索が有効
API ドキュメントHybrid0.3:0.7有効エンドポイント名・パラメータ名の完全一致

7.2 精度改善のためのチューニングポイント

graph TB
    subgraph "チューニングの4つのレバー"
        A[1. チャンキング<br/>サイズ・方式の調整] --> E[検索精度]
        B[2. Embedding Model<br/>モデル選択・ファインチューニング] --> E
        C[3. 検索 Weight<br/>Vector vs Full-Text の比率] --> E
        D[4. Rerank<br/>モデル選択・Top-K 設定] --> E
    end
    
    E --> F[LLM への入力品質]
    F --> G[最終回答品質]
  1. チャンクサイズの調整: 小さすぎると文脈が失われ、大きすぎると検索の粒度が粗くなる。一般的に 300-500 トークンが出発点。
  2. Embedding Model の選択: 日本語文書が中心なら多言語対応の高品質モデル(text-embedding-3-large、BGE-M3)を検討。
  3. Weight の調整: 検索ログを分析し、ユーザーのクエリパターンに応じて調整。
  4. Rerank の Top-K: LLM のコンテキスト長に応じて、Rerank 後に渡すチャンク数を決定(通常 3-5 チャンク)。

7.3 検索精度の評価方法

指標定義目標値
Recall@K正解文書が Top-K に含まれる割合> 0.85
Precision@KTop-K のうち正解文書の割合> 0.70
MRR (Mean Reciprocal Rank)正解文書の順位の逆数の平均> 0.75
NDCG@K順位を考慮した関連度スコア> 0.80

8. 三層パイプラインの設計思想

8.1 なぜ「三層」なのか:設計原則

Dify の三層パイプラインは、以下の設計原則に基づいている:

原則説明
多様なクエリへの対応意味検索とキーワード検索の相互補完
段階的な精度向上広く集めて(Recall)、精密に絞る(Precision)
計算コストの最適化軽量な検索で候補を絞り、重量な Rerank は候補のみに適用
設定可能性Weight、Top-K、Rerank の ON/OFF をユースケースに応じて調整可能

8.2 「Recall then Precision」パターン

三層パイプラインの本質は「まず広く候補を集め(高 Recall)、その後精密に絞り込む(高 Precision)」というパターンである:

段階処理RecallPrecision計算コスト
第一段階Vector + Full-Text(並列)低〜中
第二段階Rerank維持中〜高
第三段階Top-K 選択維持最高なし

この段階的な絞り込みにより、「広く集めたが精度が低い」でもなく「精度は高いが見逃しが多い」でもない、バランスの取れた検索結果を実現している。


まとめ

Dify の Knowledge Base 検索アーキテクチャは、三つの相互補完的な検索層を組み合わせることで、企業文書検索の本質的な課題に対応している:

  1. Vector Search: 意味的な類似性に基づく検索で、表現の揺れやユーザーの曖昧なクエリに対応
  2. Full-Text Search: キーワードの正確な一致に基づく検索で、型番・条項番号・専門用語に対応
  3. Rerank: 異なるスコアリング体系の統合と、クエリとの文脈的関連度の精密な評価

これらは単なる「アルゴリズムの積み重ね」ではなく、企業文書検索において異なる種類のクエリに対応するための分業設計である。そして、各層の Weight、Top-K、Rerank モデルの選択を調整可能にすることで、文書の特性やユーザーのクエリパターンに応じた最適化を可能にしている。


参考資料