🐱

RAG Q/Aペア自動生成(3/8)

に公開
AI
OpenAI
RAG
Gemini
tech

RAG Q/Aペア生成システム

本ドキュメントでは、RAGシステムの中核となる「Q/Aペア生成サブシステム」の仕様、アーキテクチャ、および実行方法について解説します。

最新の Gemini 3, Gemini 2.0 Flash モデルに対応し、用途に合わせて（検討、研究用に）選択可能な3つの生成エンジン（アプローチ）を提供します。

メインのシステムである: rag_qa_pair_qdrant.pyでは 標準並列処理のa02_make_qa_para.py　を採用しています。

フルスクラッチでRAG作りました。rag_qa_pair_qdrant.py
Gemini活用型RAG Q&A生成・Qdrant管理の統合Streamlitアプリケーションです。

Gemini 3 (2.0 Flash)世代に対応したRAG（Retrieval-Augmented Generation）システムの統合管理ツールです。

Gemini API版とOpenAI API版の両方あります。
実用的で、かなり、いいよ。

Gemini API でRAGの全ソース：
https://github.com/nakashima2toshio/gemini3_rag_qa

OpenAI APIでRAGの全ソース：
https://github.com/nakashima2toshio/openai_rag_qa_jp

アプリ：　それぞれ
rag_qa_pair_qdrant.py

解説・シリーズ予定：

機能 説明
（1）チャンク分割 段落優先・MeCab活用のセマンティック分割で意味を保持
（2）プロンプト設計 2段階構成・構造化出力による高品質なQ/A生成制御
（3）Q/Aペア自動生成 LLM（GPT-4o等）を使用してドキュメントからQ/Aを生成
（4）Celery並列処理 大規模データの高速処理（24ワーカーで約20倍高速化）
（5）Qdrant登録 Q/AペアをEmbedding化してベクトルDBに登録
（6）類似度検索 コサイン類似度によるセマンティック検索
（7）RAG応答生成 検索結果を基にAIが回答を生成
（8）カバレージ分析 Q/Aがドキュメントをどの程度網羅しているか評価

RAG Q/Aペア生成システム

本ドキュメントでは、RAG（Retrieval-Augmented Generation）システムの中核となる「Q/Aペア生成サブシステム」の仕様、アーキテクチャ、および実行方法について解説する。
最新の Gemini 3, Gemini 2.0 Flash モデルに対応し、用途に合わせて選択可能な3つの生成エンジン（アプローチ）を提供する。

目次

1. システム概要

1.1 目的と役割

本サブシステムは、ニュース記事、Webページ、Wiki等のテキストデータから、RAGシステムの検索精度を高めるための高品質な 「質問(Question)と回答(Answer)のペア」 を自動生成する。

生成されたQ/Aペアは、単なるキーワード一致ではなく、「ユーザーの意図（質問）」と「ドキュメントの意味（回答）」を橋渡しする 重要な役割を担う。

1.2 共通アーキテクチャ

すべてのアプローチは以下の共通基盤上に構築されている。

  1. Gemini 2.0 Flash 標準対応:
    • 高速・低コスト・長文脈対応のモデルをデフォルト採用。
    • UnifiedLLMClient によるプロバイダ抽象化。
  2. Pydanticによる構造化:
    • すべてのQ/A出力はJSONスキーマで厳密に定義され、パースエラーを最小化。
  3. セマンティック・チャンク:
    • SemanticCoverage クラスにより、意味のまとまり（段落）を考慮した分割を実施。

2. 生成エンジンの選択（3つのアプローチ）

本システムは、プロジェクトのフェーズや要件に応じて3つの異なるアプローチを提供する。

2.1 アプローチ比較

特徴 a10: 最適化ハイブリッドバッチ
(a10_qa_...)		 a03: 高カバレッジ・多様性
(a03_rag_...)		 a02: 標準並列/分散処理
(a02_make_...)
概要 効率性 & スケーラビリティ
大規模バッチ処理でAPI呼出を最小化		 網羅性 & 品質の深さ
多様な戦略でカバレッジ95%超を目指す		 堅牢性 & 分散処理
Celeryによるタスクキュー管理
API効率 最高 (90%削減)
10文書/1リクエストなどで処理		 中〜高
品質向上のため複数戦略を併用		 中
チャンク単位で並列リクエスト
生成Q/Aの質 標準〜高品質
効率重視だが品質モードで向上可		 最高品質
「理解」「応用」など階層化された質問		 標準
汎用的なQ/A生成
インフラ 低 (Pythonのみ)
単一プロセスで高速動作		 低 (Pythonのみ)
ロジックで完結		 高 (Redis必須)
ワーカー管理が必要
カバレッジ 95% (品質モード時) 95%以上 (最大化) 95%前後、最大化可能
コスト 最安 普通〜低 (テンプレート併用時) 普通
推奨シーン デフォルト / 大規模データ
迷ったらこれを使用		 教育 / 高精度検索
漏れなく深い質問が必要な場合		 分散環境 / 厳密な管理
サーバー群で処理する場合

2.2 Approach 1: 最適化ハイブリッドバッチ (a10)

  • スクリプト: a10_qa_optimized_hybrid_batch.py
  • 概要: a10 スクリプトは、大規模バッチ処理とハイブリッド生成を組み合わせ、Gemini 3,Gemini 2.0の性能を最大限に引き出す最適化エンジンです。

技術・機能詳細

  1. 効率化・最適化 (Efficiency & Optimization)
方式・技術 詳細・目的
Large-scale Batching 大規模バッチ処理。
10〜20文書（またはチャンク）を1つのプロンプトに結合してLLMに送信。Geminiの長文脈（Long Context）を活かし、APIリクエスト数を約90%削減。
Embedding Caching 埋め込みキャッシュ。
生成した埋め込みベクトルをローカル (qa_cache/) に保存。2回目以降の実行やパラメータ調整時の再計算をスキップし、処理時間を50%以上短縮。
Batch Embedding バッチ埋め込み生成。
LLMだけでなく、Embedding生成も最大300〜500件単位でバッチ処理し、スループットを最大化。
  1. 生成戦略・品質 (Generation Strategy)
方式・技術 詳細・目的
Hybrid Generation ハイブリッド生成。
ルールベース（定型質問）とLLM（生成的質問）を組み合わせ、効率と品質のバランスを最適化。
Quality Mode 品質重視モード。
gemini-embedding-001 でリアルタイムにカバレッジを計測し、目標値（例: 95%）に達するまで追加生成を試行する適応的ループ。
Progressive Improvement 段階的品質向上。
初回は速度優先（カバレッジ85%目標）、後から時間をかけて品質向上（95%目標）させる運用が可能。
  1. 前処理・言語対応 (Preprocessing)
方式・技術 詳細・目的
MeCab (日本語) 自動MeCab検知。
日本語データセット処理時、環境にMeCabがあれば自動的に利用して高精度な文境界検出を行う（ない場合は正規表現）。
Document Type Detection 文書タイプ自動判定。
記事の種類（ニュース、技術文書、学術）に応じて、生成するQ/Aの傾向（5W1H、手順、定義など）を調整。
  • 利点:
    • APIレート制限（RPM）に引っかかりにくい。
    • 圧倒的な処理速度と低コスト。
  • 欠点:
    • 極端に巨大なバッチサイズにすると、個々のチャンクへの注目度が下がる可能性がある（通常は10-20程度で問題なし）。

2.3 Approach 2: 高カバレッジ・多様性戦略 (a03)

  • スクリプト: a03_rag_qa_coverage_improved.py
  • 概要: a03 スクリプトは、「高カバレッジ（網羅性）」 と 「質問の多様性」 を実現するために、複数の高度な技術を組み合わせています。

技術・機能詳細

  1. チャンク分割・前処理
方式・技術 詳細・目的
Semantic Chunking 段落優先のセマンティック分割。
gemini-embedding-001 の埋め込みベクトルを使用し、意味の変わり目で分割す...
MeCab (日本語) 日本語テキストの高精度な文境界検出に使用。
「。」だけでなく、括弧や引用符を考慮した自然な文分割を実現（...
Chunk Complexity... チャンク複雑度分析。
専門用語の密度、平均文長、統計情報の有無などを分析し、難易度（Low/Medium/High）を...
  1. Q/A生成戦略 (Hybrid Approach)
方式・技術 詳細・目的
Hierarch... 3階層11タイプの質問定義。
基礎（定義・識別）、理解（因果・プロセス）、応用（統合・評価）のフレームワークに基づき...
Domain A... ドメイン適応戦略。
データセット（ニュース、Wiki、Web）ごとに、生成すべき質問タイプの優先度やトーンを動的に調整。
Hybrid G... ハイブリッド生成。以下の3手法を組み合わせてカバレッジを高める.\n1. Rule/Template: キーワードや構文に基づく定...\n2. LLM (Gemini): 文脈理解が必要な深い質問生成（高品質）。\n3. Context-Enhanced: 前後の文脈を含めた質問生成。
UnifiedL... LLM抽象化レイヤー。
gemini-2.0-flash を使用し、Pydanticモデルによる構造化出力（JSON）を強制してパースエラーを防止。
  1. 品質保証・分析
方式・技術 詳細・目的
Multi-level Cover... 多段階カバレージ分析。
生成されたQ/Aと元チャンクの類似度を gemini-embedding-001 で計算。Strict (0.8...
Chunk Characteris... チャンク特性分析。
チャンクの「長さ（Short/Long）」や「位置（冒頭/末尾）」ごとのカバレッジを分析し、弱...
Batch Embedding バッチ埋め込み生成。
Gemini APIのバッチ処理を活用し、大量のQ/Aペアの埋め込みベクトルを高速に生成。
  • 利点:
    • 情報の網羅性が非常に高い（カバレッジ95%以上）。
    • 単純な事実確認だけでなく、推論を要する深い質問を作成できる。
  • 欠点:
    • ロジックが複雑で、a10に比べると処理時間は長くなる傾向。

2.4 Approach 3: [推奨]標準並列処理 (a02)

  • スクリプト: a02_make_qa_para.py
  • 概要: a02 スクリプトは、Celery + Redis を用いた分散タスクキュー方式を採用し、大規模かつ堅牢な処理基盤を提供します。

技術・機能詳細

  1. 分散処理・実行基盤 (Distributed Processing)
方式・技術 詳細・目的
Task Queue (Celery) 分散タスクキュー。
Celery + Redis を使用し、1チャンク（または小バッチ）を1タスクとして非同期に管理。サーバー障害時でも未処理タスクを保持し、確実に処理を完了させる。
Worker Scalability ワーカーのスケーラビリティ。
複数のサーバーやコンテナにワーカープロセスを分散配置し、水平スケールで処理能力を増強可能。
Result Backend 結果の永続化。
各タスクの処理結果をRedisに保存し、親プロセスが非同期に回収・結合。
  1. 生成戦略・チャンク処理 (Processing Strategy)
方式・技術 詳細・目的
Dynamic QA Count 動的Q/A数生成。
チャンクのトークン数（Short/Medium/Long）や文書内の位置（結論部分は重要度高）に応じて、生成するQ/A数を自動調整。
Small Chunk Merging 小チャンク統合。
短すぎるチャンク（情報量不足）を検出し、前後のチャンクと統合して十分なコンテキストを持つ処理単位を作成。
LLM Generation LLMベース生成。
gemini-2.0-flash を使用し、プロンプトエンジニアリングによって高品質なQ/Aペアを生成。
  1. 分析・評価 (Analysis)
方式・技術 詳細・目的
Coverage Analysis カバレッジ分析。
生成されたQ/Aが元のチャンクをどれだけ網羅しているか、gemini-embedding-001 を用いてコサイン類似度で評価。
Chunk Position Analysis 位置別分析。
文書の前半・中盤・後半ごとのカバレッジを計測し、情報の偏りを検出。

  • 利点:

    • タスク単位のリトライやエラーハンドリングが堅牢。
    • 複数のサーバーにワーカーを配置して水平スケールが可能。

  • 欠点:

    • Redisサーバーの構築・運用が必要。
    • API呼び出し回数自体は削減されないため、大規模実行時はレート制限に注意が必要。

3. 共通技術仕様

3.1 LLM抽象化レイヤー (UnifiedLLMClient)

helper_llm.py により、モデルの違い（Gemini vs OpenAI）を隠蔽し、統一的なインターフェースで構造化データ（JSON）を取得する。

  • 機能: generate_structured() メソッドにより、Pydanticモデルに基づいたJSON出力を強制し、パースエラーを防ぐ。

3.2 セマンティック・チャンク分割とMeCab

helper_rag_qa.py 内の SemanticCoverage クラスは、テキストを機械的に分割せず、意味のまとまりを維持する。

  • 日本語処理 (MeCab):
    • 環境にMeCabがインストールされている場合、自動的に利用する。
    • 「〜です。」のような単純な文末だけでなく、括弧や引用、複合的な文構造を解析し、不自然な位置での切断を防ぐ。
    • 利用できない場合は正規表現モードにフォールバックする。

3.3 多段階カバレージ分析

生成されたQ/Aペアが元文書をどれだけ網羅しているか、ベクトル類似度で評価する。

  • Strict (0.8以上): 専門用語や正確な定義が問われているか。
  • Standard (0.7以上): 一般的な内容理解。
  • Lenient (0.6以上): 関連情報が含まれているか。

4. 操作・実行ガイド

4.1 a10: バッチ実行

最も効率的で、通常利用に推奨される方法。

# 基本実行（バッチサイズ10）
python a10_qa_optimized_hybrid_batch.py --dataset cc_news --batch-size 10

# 品質重視モード（目標カバレッジ95%、キャッシュ有効）
python a10_qa_optimized_hybrid_batch.py \
  --dataset livedoor \
  --model gemini-2.0-flash \
  --quality-mode \
  --target-coverage 0.95 \
  --use-cache

4.2 a03: 高品質生成実行

教育用データや、深い理解が必要な場合に推奨。

# カバレッジ分析付きで実行
python a03_rag_qa_coverage_improved.py \
  --input OUTPUT/preprocessed_cc_news.csv \
  --dataset cc_news \
  --qa-per-chunk 10 \
  --analyze-coverage

4.3 a02: Celery分散実行（推奨）

Redis環境があり、大規模な分散処理を行いたい場合。

# 1. Redisとワーカーの起動
./start_celery.sh start -w 8

# 2. 生成実行
python a02_make_qa_para.py \
  --dataset wikipedia_ja \
  --use-celery \
  --celery-workers 8 \
  --batch-chunks 3

5. Gemini 3時代に向けたa02の改善戦略（ロードマップ）

Gemini 3（超高速・長文脈・マルチモーダル）の特性を最大限に活かすため、分散処理版である a02 は以下の方向でアーキテクチャを刷新する計画である。

5.1 改善の方向性

従来のLLM（短いコンテキスト、遅い生成速度）に最適化された「細粒度タスク処理」から、Geminiの強みを活かした「大粒度・高コンテキスト処理」へと移行する。

No. 改善項目 目的・効果 Gemini 3時代のアプローチ
1 タスク粒度の拡大
(チャンク単位 → ドキュメント単位)		 API効率と文脈理解の向上
Redisのオーバーヘッド削減		 長いコンテキストを活かし、1記事丸ごと（または数十チャンク）を1タスクとして処理する。
2 プロンプトのコンテキスト拡張 Q/A品質の向上
全体像を踏まえた深い質問生成		 チャンク単体ではなく、前後の文脈やドキュメント全体をプロンプトに入力し、より高度な推論を行わせる。
3 リトライロジックの強化 分散処理の堅牢性向上
レート制限への自律的な対応		 429エラー（Rate Limit）発生時に、指数関数的バックオフで賢く待機・再試行するロジックを組み込む。
4 非同期処理の最適化 スループットの最大化 同期的なAPI呼び出しを排除し、ワーカー内でも非同期I/Oを活用して待機時間をゼロにする。

5.2 具体的な実装方針

  1. タスク粒度の拡大 (Coarser Granularity)

    • 現状: batch-chunks (デフォルト3) 単位。
    • 変更後: 「1ドキュメント = 1タスク」 または 「20〜50チャンク = 1タスク」。
    • 効果: タスク管理（Redis通信）のオーバーヘッドを削減し、APIごとのトークン効率を最大化。

  2. プロンプトのコンテキスト拡張 (Global Context Aware)

    • 現状: 対象チャンクのみを入力。
    • 変更後: プロンプトに 「ドキュメント全体の要約」 や 「前後のチャンク」 を追加。
    • 効果: 「そのチャンクには書かれていないが、記事全体を知っていれば答えられる重要な背景」を加味した、質の高いQ/A生成。

  3. リトライロジックの強化 (Robust Error Handling)

    • 実装: Celeryの autoretry_for 機能や、tenacity ライブラリを活用した Exponential Backoff (指数関数的待機) の徹底。
    • 効果: 分散環境でのレート制限（429エラー）に対する自律的な回復力の確保。

  4. コード構造の刷新

    • a02 を純粋な「Celeryタスク・プロデューサー」に特化。
    • 実際の生成ロジックは helper_rag_qa.py に集約し、a10 と共通化することでメンテナンス性を向上させる。

6. トラブルシューティング

  • Error: GOOGLE_API_KEY not set
    • .env ファイルにAPIキーを設定してください。
  • レート制限エラー (429)
    • a10: --batch-size を小さくするか、スクリプト内の待機時間を調整してください。
    • a02: --celery-workers の数を減らしてください。
  • MeCabが見つからない
    • 必須ではありませんが、日本語の分割精度向上のために pip install mecab-python3 unidic-lite の導入を推奨します。
  • Redis接続エラー (a02のみ)
    • redis-server が起動しているか確認してください。

Discussion