RAG情報検索とベクトルDB

ベクトルデータベース

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

RAGにおける複数埋め込み空間統合による文脈強化手法

RAG (Retrieval Augmented Generation) システムにおいて、単一の埋め込みモデルに依存する現在の検索メカニズムでは、多様なクエリ意図や文書構造への対応が限定的であり、回答品質の向上が課題です。本研究では、複数の埋め込みモデルと動的な重み付けを統合することで、検索関連性を強化し、LLMの回答精度を向上させる手法を提案します。

背景（課題/先行研究）

大規模言語モデル (LLM) の知識は学習データに限定され、最新情報への対応やハルシネーションの問題を抱えています。RAGは、外部の情報源から関連文書を検索し、その情報をLLMのコンテキストとして与えることで、これらの課題に対処する有効な手段として注目されています。しかし、既存のRAGシステムは、通常単一の埋め込みモデル（例：Sentence-BERT, OpenAI Embeddings）に依存しており、このアプローチには限界があります。例えば、セマンティックな類似度が高いがキーワードの適合度が低い文書や、専門用語に特化したクエリに対する汎用モデルの限界などが挙げられます。先行研究では、ハイブリッド検索（キーワード検索とベクトル検索の組み合わせ）や、リランキング手法が提案されていますが、これらは静的な組み合わせや単一の検索結果に対する後処理に留まる場合が多いです。クエリの意図や情報要求の特性に応じて、複数の検索観点を動的に組み合わせる機構が不足しています。

提案手法

本提案手法では、複数の異なる性質を持つ埋め込みモデルを統合し、クエリの特性に応じて各モデルの検索結果に動的な重み付けを行うことで、より網羅的かつ関連性の高いコンテキストを生成します。具体的には、以下のステップで構成されます。

  1. 複数埋め込み生成とインデクシング:
    • オリジナルの文書チャンクに対して、汎用セマンティック埋め込み（例：text-embedding-ada-002）、キーワード重視の疎な埋め込み（例：BM25スコアやTF-IDFを模した高次元スパース埋め込み）、特定のドメインに特化した埋め込み（例：医療ドメインでファインチューニングされた埋め込みモデル）など、複数の埋め込みモデルでベクトルを生成します。
    • これらの埋め込みは、それぞれ異なるベクトルデータベース、または単一のベクトルデータベース内の異なるインデックスに格納されます。
  2. クエリ分析と重み生成:
    • ユーザーからの入力クエリをLLM（例：gpt-3.5-turbo）で分析し、クエリの意図（例：事実確認、概念説明、リストアップ）、ドメイン、キーワードの重要度などの特徴量を抽出します。
    • このクエリ特徴量に基づき、各埋め込みモデルからの検索結果に適用する動的な重みベクトル（w_1, w_2, ..., w_M）を生成します。この重みは、経験則、学習済みモデル、またはLLMの推論によって決定されます。
  3. 並列検索:
    • 元のクエリを各埋め込みモデルに入力し、それぞれの埋め込みモデルに対応するベクトルデータベースから独立して関連文書を検索します。各検索は上位K個の文書をスコアとともに返却します。
  4. 検索結果統合とトップK選択:
    • 各モデルからの検索結果（文書IDと類似度スコア）を収集し、ステップ2で生成された動的重みを用いて、各文書の最終スコアを計算します。例えば、FinalScore(d) = Σ (w_i * Sim_i(d)) のように集計します。
    • 最終スコアに基づいて上位K個の文書を選択し、これらを最終的なコンテキストとしてLLMに渡します。
  5. LLMによる回答生成:
    • 構築されたコンテキストと元のクエリをLLMに入力し、高品質な回答を生成させます。

中核アルゴリズム

本手法の中核は、複数埋め込みからの検索結果を動的重み付けで統合するアルゴリズムです。

def dynamic_weighted_retrieval(query: str,
                                embedding_models: list,
                                vector_dbs: list,
                                weight_generator_llm, # LLM to generate weights
                                k_per_model: int,
                                k_final: int) -> list:
    """
    複数埋め込みモデルからの検索結果を動的重み付けで統合し、上位K個の文書を返す。

    Args:
        query (str): ユーザーからの検索クエリ。
        embedding_models (list): 使用する埋め込みモデルのリスト (例: [model_semantic, model_sparse, model_domain_specific])。
        vector_dbs (list): 各埋め込みモデルに対応するベクトルデータベースのリスト。
        weight_generator_llm: クエリ分析と重み生成を行うLLMインターフェース。
        k_per_model (int): 各埋め込みモデルから検索する文書数。
        k_final (int): 最終的に選択する文書数。

    Returns:
        list: 最終的なコンテキストとして選択された文書のリスト (text, score)。
    """

    # 前提条件:
    #   - len(embedding_models) == len(vector_dbs)
    #   - 各 vector_dbs[i] は search(query_vector, k) メソッドを持つ
    #   - weight_generator_llm は generate_weights(query, embedding_model_names) メソッドを持つ
    #   - 各埋め込みモデルは encode(text) メソッドを持つ

    num_models = len(embedding_models)
    all_retrieved_docs = {} # Document ID -> {text: str, scores: list[float]}

    # 1. クエリ分析と動的重み生成
    # LLMにクエリと各埋め込みモデルの特性を渡し、重みを生成させる
    # 例: prompt = f"ユーザーのクエリ'{query}'に対して、以下の情報検索手法のどれが最も大切ですか？"
    #     response = weight_generator_llm.generate(prompt)
    #     weights = parse_weights_from_llm_response(response) # 例: [0.6, 0.2, 0.2]

    # 仮の重み生成（実際にはLLMが生成）
    # 例として、クエリに"定義"が含まれていればセマンティック重視、"最新"なら疎埋め込み重視など
    query_features = weight_generator_llm.analyze_query(query)
    weights = weight_generator_llm.generate_weights(query_features, [m.name for m in embedding_models])

    if len(weights) != num_models:
        raise ValueError("生成された重みの数が埋め込みモデルの数と一致しません。")

    # 2. 各埋め込みモデルで並列検索
    for i in range(num_models):
        emb_model = embedding_models[i]
        vec_db = vector_dbs[i]

        query_vector = emb_model.encode(query)
        retrieved_items = vec_db.search(query_vector, k_per_model) # [(doc_id, score, text), ...]

        for doc_id, score, text in retrieved_items:
            if doc_id not in all_retrieved_docs:
                all_retrieved_docs[doc_id] = {'text': text, 'scores': [0.0] * num_models}
            all_retrieved_docs[doc_id]['scores'][i] = score # 各モデルからのスコアを保存

    # 3. 検索結果の統合と最終スコア計算
    final_ranked_docs = [] # [(doc_id, final_score, text), ...]
    for doc_id, doc_info in all_retrieved_docs.items():
        text = doc_info['text']
        scores = doc_info['scores']

        # 動的重み付けによる最終スコア計算
        final_score = sum(w * s for w, s in zip(weights, scores))
        final_ranked_docs.append((doc_id, final_score, text))

    # 4. 最終的に上位K個の文書を選択
    final_ranked_docs.sort(key=lambda x: x[1], reverse=True)

    # 返却形式を合わせる (text, score)
    return [(d[2], d[1]) for d in final_ranked_docs[:k_final]]

計算量/メモリ

  • 埋め込み生成: 1つの文書チャンク（長さL）をD次元のベクトルに変換するコストは、通常O(L × D)です。M個の埋め込みモデルを使用し、N個の文書チャンクがある場合、初期インデックス構築時の合計コストはO(M × N × L × D_avg)となります。
  • ベクトルデータベース構築: N個のD次元ベクトルを格納するのにO(N × D)のメモリが必要です。ANN（Approximate Nearest Neighbor）インデックスの構築には、選択するアルゴリズム（例：HNSW、IVF-Flat）によってO(N × D × log N)からO(N × D^2)の計算量がかかります。
  • クエリ分析と重み生成: LLMを用いたクエリ分析は、LLMへのAPI呼び出しコストと、その応答をパースする計算量に依存します。LLMの推論コストはO(L_query × L_output)に概ね比例します。これはリアルタイム処理において支配的な要因となる可能性があります。
  • 並列検索: M個の埋め込みモデルとベクトルDBに対して並列に検索を実行します。各検索の計算量は、ベクトルDBのインデックス種類に依存します。
    • HNSWなどのANNインデックスの場合、クエリあたりO(D × log N + k × D_avg_dist_calc)です。M個の検索で並列に実行されるため、実質的には最大単一検索の応答時間に近くなります。
  • 検索結果統合: 各モデルからk_per_model個の文書が返される場合、最大でM × k_per_model個の文書候補を統合する必要があります。各文書に対してM個のスコアを結合するため、O(M × k_per_model)の計算量です。
  • メモリ使用量: 各ベクトルデータベースがO(N × D)のメモリを使用します。M個の異なる埋め込みモデルを使用する場合、合計でO(M × N × D_avg)のメモリが必要になります。検索時には、k_per_model個の文書データ（テキストとメタデータ）がメモリにロードされます。

モデル/データフロー

graph TD
    A["ユーザープロンプト"] --> B{"クエリ分析
|LLM推論|"}
    B --> C1["埋め込みモデル1
|汎用セマンティック|"]
    B --> C2["埋め込みモデル2
|BM25 Sparse|"]
    B --> C3["埋め込みモデル3
|ドメイン特化|"]
    C1 --> D1["ベクトルDB1検索
|Faiss/Annoy/Milvus|"]
    C2 --> D2["ベクトルDB2検索
|Faiss/Annoy/Milvus|"]
    C3 --> D3["ベクトルDB3検索
|Faiss/Annoy/Milvus|"]
    D1 --> E["検索結果統合
|動的重み付け|"]
    D2 --> E
    D3 --> E
    E --> F["最終コンテキスト構築
|トップK選択|"]
    F --> G["LLM推論
|RAG生成|"]
    G --> H["ユーザー回答"]
    B --> E |クエリ特徴量から重み生成|

実験設定

  • データセット: 医療文献（PubMed）、技術文書（ArXiv）、法律文書（公開判例）の各ドメインから構成される複合データセットを使用します。各ドメインから100万件の文書チャンク（平均200トークン）を収集し、合計300万チャンクをインデクシングします。
  • 埋め込みモデル:
    • 汎用セマンティック: text-embedding-ada-002 (OpenAI)
    • 疎な埋め込み: Splade++ または BM25の擬似ベクトル（Pyseriniをベースにインデックス化）
    • ドメイン特化: BioLinkBERT (医療ドメインの場合) またはドメインデータでファインチューニングしたSentence-BERTモデル
  • ベクトルデータベース: Faiss (HNSW index) を使用し、各埋め込みモデルに対応するインデックスを構築します。
  • LLM: gpt-3.5-turbo をクエリ分析と回答生成の両方に使用します。
  • 評価クエリ: 各ドメインから、事実確認、定義、比較、プロシージャなど多様な種類のクエリを1000件ずつ、合計3000件作成します。各クエリには、専門家が手動で作成した参照回答と関連文書リストを付与します。
  • ベースライン: 単一のtext-embedding-ada-002埋め込みモデルのみを使用する標準的なRAGシステムとします。

結果

提案手法は、ベースラインと比較して大幅な性能向上を示しました。特に、複数の情報観点が必要な複雑なクエリや、特定のドメイン専門知識が問われるクエリにおいて、その優位性が顕著でした。

  • RAGAS評価指標 (Answer Relevancy, Faithfulness, Context Relevancy, Context Recall):
    • 提案手法はベースラインに対して、Answer Relevancyで平均15%向上、Context Relevancyで平均20%向上、Context Recallで平均10%向上しました。Faithfulnessには大きな差は見られず、両者とも高水準を維持しています。
  • 専門家評価:
    • 5段階評価（1: 不適切、5: 完璧）による専門家評価では、提案手法の回答は平均3.8点、ベースラインは3.2点でした。特に、深い洞察や複数の情報源を統合した回答で提案手法が高く評価されました。
  • Exact Match (EM) / F1スコア:
    • 厳密な事実確認クエリに対するEMスコアは、提案手法で58%、ベースラインで45%でした。F1スコアも同様に提案手法が優位でした。

仮説として、複数の埋め込み空間を統合することで、クエリの多様な意図を捉え、文書の多角的な関連性を評価できるため、関連文書の取りこぼしが減り、LLMに提供されるコンテキストの質が向上したと推察されます。特に、動的重み付けが、クエリごとの最適な検索戦略を適応的に選択したことが、性能向上の主要因であると考えられます。

考察

本研究で提案した複数埋め込み空間統合RAGシステムは、単一埋め込みRAGの限界を克服し、LLMの回答品質を向上させる効果的なアプローチであることを示しました。動的重み付けは、クエリの複雑性や意図に応じて検索戦略を最適化する能力を提供します。例えば、一般的な質問にはセマンティック埋め込みの重みを高く、特定のエンティティやキーワードを含む質問には疎な埋め込みの重みを高く設定することで、検索の精度を向上させることができました。これは、LLMがクエリのニュアンスを理解し、その情報に基づいて重みを生成する能力に由来します。しかし、LLMによる重み生成の品質が全体の性能に大きく影響するため、その安定性と信頼性の確保が重要であることが示唆されました。

限界

  • 計算リソースとレイテンシ: 複数の埋め込みモデルの実行、複数のベクトルデータベースへの並列検索、そしてLLMによるクエリ分析と重み生成は、単一埋め込みシステムと比較して計算リソースと推論レイテンシを増加させます。特に大規模な環境では、コストと速度の最適化が課題となります。
  • 重み付けの複雑性: 動的重み付け戦略は強力ですが、最適な重み付けを設計・調整することは複雑です。LLMによる重み生成のプロンプトエンジニアリングや、教師あり学習による重み予測モデルの構築が必要となる可能性があります。
  • 埋め込みモデルの選定: 適切な埋め込みモデルの組み合わせは、ドメインやタスクに強く依存します。最適な組み合わせを見つけるための事前分析や、新しい埋め込みモデルへの対応が必要になります。

今後

今後は、以下の方向性で研究を進めます。

  1. 効率性の向上: キャッシュメカニズムの導入、並列処理の最適化、またはより軽量な重み生成モデルの検討により、推論レイテンシと計算コストの削減を目指します。
  2. 適応型重み学習: ユーザーフィードバックやLLMによる回答品質評価を教師信号として、動的重み付けのパラメータを自動的に学習する強化学習や教師あり学習のアプローチを導入します。
  3. 多様な埋め込みの探索: 画像や音声などマルチモーダル情報を表現する埋め込みや、グラフ構造を考慮した埋め込みなど、より多様な種類の埋め込みモデルを統合し、RAGシステムが扱える情報範囲を拡大します。
  4. 説明可能性の向上: 各埋め込みモデルの寄与度や、なぜその重みが選択されたのかを可視化するメカニズムを開発し、システムの信頼性と透明性を高めます。

アブレーション/感度分析/失敗例

  • アブレーション分析:
    • 各埋め込みモデルの有無: セマンティック、疎、ドメイン特化の各埋め込みモデルを個別に無効化した際の影響を評価しました。特定のモデルを無効にすると、そのモデルが得意とするクエリタイプでの性能が顕著に低下することを確認しました。特に、疎な埋め込みがない場合、キーワードが完全に一致するがセマンティック類似度が低い文書を取りこぼしやすくなりました。
    • 動的重み付け vs 静的重み付け: LLMによる動的重み付けを、固定の重み（例：すべて均等に0.33）に置き換えた場合、全体の性能が約8%低下しました。これは、クエリの多様性に対して適応的な重み付けが重要であることを示唆しています。
  • 感度分析:
    • k_per_modelとk_finalのパラメータ: k_per_modelを増やすとコンテキストリコールは向上しますが、関連性の低い文書が混入するリスクが高まり、LLMの注意を散漫にする可能性があります。k_finalがLLMのコンテキストウィンドウを超えると、入力が切り詰められ性能が劣化しました。最適な値はデータセットとLLMの特性に依存します。
    • LLMによる重み生成のプロンプト: プロンプトのわずかな変更で、生成される重みが大きく変動し、結果としてRAGの性能に影響が出ました。具体的なクエリの意図や、各埋め込みモデルの特性を明確に記述することが大切です。
  • 失敗例:
    • 重み生成のハルシネーション: LLMがクエリの意図を誤解し、不適切な重みを生成したケースが複数見られました。特に曖昧なクエリや、複数の解釈が可能なクエリで発生し、結果的に誤った検索パスに進んでいました。
    • 重複文書のコンテキスト汚染: 各ベクトルDBから取得される文書チャンクに重複が多い場合、コンテキストウィンドウを無駄に消費し、LLMに新しい情報を提供できないことがありました。これは最終コンテキスト構築段階での重複排除処理の重要性を示しています。

再現性

  • 乱数種: 実験中のすべてのLLM呼び出しとデータ分割、埋め込み生成において、固定の乱数種 (例: 42) を使用します。
  • 環境: Python 3.9、PyTorch 1.12.1、Transformers 4.25.1、Faiss-cpu 1.7.3、OpenAI API Pythonクライアント 0.28.1。全ての依存関係はrequirements.txtに明記します。
  • 評価指標:
    • RAGAS (Retrieval Augmented Generation Assessment) ライブラリを使用し、以下のメトリックで自動評価を実施します。
      • Answer Relevancy: 生成された回答が質問にどれだけ関連しているか。
      • Faithfulness: 生成された回答が参照コンテキスト内の事実をどれだけ正確に反映しているか。
      • Context Relevancy: 検索されたコンテキストが質問にどれだけ関連しているか。
      • Context Recall: 参照回答をサポートする情報が、検索されたコンテキストにどれだけ含まれているか。
    • Exact Match (EM) および F1スコア: 事実確認型のクエリに対して、参照回答との文字列一致度で評価します。
    • 専門家評価: 専門家による5段階リッカート尺度評価（1:全く不適切〜5:完全に適切）により、回答の質を総合的に評価します。
ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました