
RAG(Retrieval-Augmented Generation)の精度を高めるための完全ガイド
はじめに
こんにちは。Altam Easeの本田直輝です。
近年、生成AIの活用が進む中で、RAG(Retrieval-Augmented Generation)は、外部ストレージに格納されたナレッジを活用しながら高精度な回答を生成できる手法として注目を集めています。
RAGは、単にベクトル検索とLLMを組み合わせれば精度が出るというものではなく、「検索精度」や「プロンプト設計」「モデルの微調整」など複数の工夫が必要です。
本記事では、RAGの基本構成から各フェーズにおけるチューニングポイント、そして特に重要な「検索精度向上」のためのベクトルDB(FAISS)の使い方に至るまで、体系的に解説します。
RAGの全体構成
RAGは、大きく次の6つのフェーズで構成されています:
1. Query Construction(クエリ構築)
ユーザーからの自然言語クエリを、データソース(ベクトルDB・リレーショナルDB・グラフDB)に適した形式へ変換します。
・Relational DBs:Text-to-SQL により構造化検索を実現
・Graph DBs:Text-to-Cypher により知識グラフを活用
・Vector DBs:Self-query retriever によるメタデータ自動生成
2. Query Translation(クエリ翻訳)
複雑な質問を再構成・分解し、より正確な検索ができるようにします。
・Multi-query / Step-back / RAG-Fusion による分解・再質問
・HyDE による仮想文書生成(Pseudo-documents)
3. Routing(ルーティング)
質問の種類や意味に応じて、どのデータベースに問い合わせるか、どのプロンプトを使うかを判断します。
・Logical Routing:LLMがDBを選択
・Semantic Routing:Embedding類似度に基づくプロンプト切り替え
4. Retrieval(検索)
各DBから関連情報を抽出し、必要に応じて再検索や絞り込みを行います。
・Ranking:Re-Rank、RankGPT、RAG-Fusion
・Refinement:関連性による再圧縮(CRAG)
・Active Retrieval:不要な結果なら再検索 or Web検索へ切り替え
5. Indexing(インデックス構築)
より正確で効率的な検索のために、文書の構造やEmbedding方法を最適化します。
・Semantic Splitter:チャンクサイズの最適化
・Multi-representation:要約+原文など複数の表現を同時に登録
・Specialized Embedding:BERT/CoL-BERTなどの専門埋め込み
・RAPTOR:文書の階層構造を活かしたクラスタリング・インデックス構造
6. Generation(生成)
LLMによって最終的な回答を生成します。
生成結果に応じて再検索を促すような「自己改善型RAG」も可能です。
・Self-RAG、RRR(Re-ranking-Rewriting-Retrieval)などを活用
・回答の質に応じてプロンプトの改善や再検索を自動実行
https://medium.com/@samarrana407/mastering-rag-advanced-methods-to-enhance-retrieval-augmented-generation-4b611f6ca99a
検索精度(Retrieval)のチューニングポイント
1. チャンク分割の工夫
目的:ドキュメントを意味的に一貫した単位に分割し、関連情報をより正確に検索可能にすること。
-
300〜500トークン程度を基準に分割(例:段落単位)
-
セクション見出しや文構造を意識して分割
-
高度な分割手法として「MoGG(Mix-of-Granularity-Graph)」が有効
→ 複数サイズのチャンクをグラフ化し、検索時に動的に選択
2. Embeddingの最適化
目的:「意味的に近い」情報を数値化されたベクトル空間で近くに配置すること。
モデル選定例:
ドメイン | モデル名 |
---|---|
一般用途 | text-embedding-ada-002(OpenAI) |
日本語対応 | LaBSE, cl-tohoku/bert-base-japanese |
法律 | LegalBERT |
医療 | BioBERT, ClinicalBERT |
技術・コード系 | CodeBERT, GraphCodeBERT |
all-MiniLM-L6-v2を使ってます。
チューニング方法:
-
自社データを用いてファインチューニング
-
対話ログやFAQの実データを使うとより実践的なベクトル空間に
3. FAISSのインデックス選定(精度重視)
FAISSでは複数のインデックス方式が用意されています。精度を最優先にする場合、以下の比較が役立ちます:
インデックスとは、「ベクトル(数値化された文章など)を検索しやすくするためのデータ構造のことです
インデックス | 精度 | 検索速度 | 備考 |
---|---|---|---|
IndexFlatL2 | ★★★★★(100%) | 遅い(線形検索) | 小〜中規模で最適、再現率1.0 |
IndexIVFFlat | ★★★★☆ | 高速 | nprobeを調整して精度向上(〜95%) |
IndexHNSWFlat | ★★★★★(〜98%) | 超高速 | メモリ多めだが、再現率非常に高い |
IndexPQ | ★★★☆☆ | 高速 | 圧縮により精度が低下するが、大規模向け |
-
小〜中規模(〜数万件)ならまず IndexFlatL2 を選ぶのが安全(私は普段これを使ってます)
-
高速化が必要な場合は HNSW が第一候補(検索精度と速度のバランスが非常に優秀)
-
データ量が増えたら IVF+再ランク で最適化
-
メモリ制限がある大規模案件では PQ を検討
FAISSインデックス構造の比較と選択
1. 再ランク付け(Reranking)
Embedding検索だけでは、関係性の薄い情報が混じる場合も。
そこで、上位20件ほどを取得し、別モデルやコサイン類似度などで再度スコアをつけ、最終的に上位5件などをLLMに渡すと精度が安定します。
2. プロンプト設計(Prompt Engineering)
プロンプトの設計次第で生成精度は大きく変わります。以下のような構成が効果的です:
3. LLMの追加学習(LoRA/PEFT)
-
OpenAIのChatGPTやAnthropic Claudeなどの商用LLMでは学習できませんが、
ローカルLLM(例:LLaMA, Mistral, Gemma)ではLoRAなどで簡易な微調整が可能です。
おわりに
RAGの本質は「検索と生成の融合」です。LLMの性能だけでなく、検索側の設計が問われる仕組みです。
本記事で紹介したチューニングポイントを押さえることで、より高精度かつ実用的なRAGシステムが構築できるはずです。
この記事へのコメントはありません。