【2026年版】RAG精度を爆上げする7つのステップ｜MarkItDownから評価手法まで網羅

RAG（検索拡張生成）を導入したものの、期待したほど精度が出ないという悩みを抱えている人は多い。結論から言うと、RAGの精度問題の8割は検索品質と評価の不在に起因する。どれほど優秀なLLMを使っても、渡されるコンテキストが不適切であれば、回答も不適切になる。これをガベージイン・ガベージアウトと呼ぶ。

この記事では、RAG精度向上のための黄金ルートを7つのステップで解説する。Microsoft製の最新ツールであるMarkItDownによる前処理から、感覚的な調整を卒業するためのGolden Setを用いた評価手法までを網羅する。この記事を読み終える頃には、何をどう改善すればいいか明確になるはずだ。

1. RAG精度向上のための前提知識

RAGを構築するために必要なものは、Pythonの実行環境とLLMのAPIキー、そして適切なベクトルデータベースだ。しかし、これらを揃えるだけでは不十分だ。初心者が陥りがちな罠は、回答が正しくないときにプロンプトをいじり倒してしまうことだ。

プロンプトを調整する前に、まずは検索結果が正しいかどうかを確認する癖をつける。検索で正しい情報がヒットしていないのであれば、プロンプトをどれだけ工夫しても無駄に終わる。検索品質の改善こそが、RAG開発における最優先事項だ。

2. ステップ1：MarkItDownによる前処理の徹底

RAGの精度を左右する最初の関門は、ドキュメントのテキスト化だ。特にPDFやExcel、PowerPointといったファイルは構造が複雑で、単純にテキストだけを抽出すると情報のつながりが壊れる。ここで登場するのが、Microsoftが公開したMarkItDownというツールだ。

MarkItDownを使えば、OfficeファイルやPDFをLLMが理解しやすいMarkdown形式に変換できる。このツールの最大の特徴は、見出し構造や表データを保持したまま変換できる点にある。表形式のデータは、単純なテキスト抽出では行と列の関係が崩れて意味不明な文字列になりがちだが、Markdownのテーブル形式であればLLMは正しく構造を把握できる。

まずは手元のファイルをMarkItDownで変換し、情報の欠落がないか確認する。前処理を丁寧に行うだけで、検索精度は安定する。

3. ステップ2：チャンキング戦略の最適化

テキストをベクトルデータベースに登録する際、一定の長さに分割する工程をチャンキングと呼ぶ。初心者は1,000文字ごとに区切るといった固定長分割を選びがちだが、これは避けるべきだ。文章の途中で意味が分断され、検索のヒット率が下がる原因になる。

RecursiveCharacterTextSplitterのような、意味的な区切り（句点や改行）を優先して分割する手法が有効だ。1チャンクのサイズは200から500トークン程度を目安に設定し、前後のチャンクと10パーセントから20パーセント程度の重複（オーバーラップ）を持たせる。これにより、境界付近にある情報も漏らさず検索対象に含めることができる。

<!-- IMAGE_1 -->

4. ステップ3：ベクトル検索の限界を知り、類似度を理解する

RAGの基本はベクトル検索だ。これはテキストを数値の配列（ベクトル）に変換し、質問文と意味が近い文書を探し出す仕組みだ。ここで使われるのがコサイン類似度という指標で、1.0に近いほど意味が似ていると判断される。

しかし、ベクトル検索には弱点がある。それは固有名詞や型番、製品名といった「キーワードの完全一致」に弱い点だ。例えば「A-100」という型番を検索したいとき、意味の近さを重視するベクトル検索では、似たような機能を持つ「B-200」を拾ってくることがある。この限界を理解しておくことが、次のステップへ進むための鍵となる。

5. ステップ4：ハイブリッド検索（ベクトル＋BM25）の導入

ベクトル検索の弱点を補うために、キーワード検索の定番アルゴリズムであるBM25を組み合わせる手法がハイブリッド検索だ。意味の近さを探すベクトル検索と、単語の一致を重視するキーワード検索の両方を実行し、その結果を統合する。

結果の統合にはRRF（Reciprocal Rank Fusion）という手法を用いるのが一般的だ。これは各検索手法での順位をスコア化して合算する仕組みで、両方のリストで上位に来ている文書を最終的な候補として採用する。これにより、曖昧な質問にはベクトル検索が、具体的な型番指定にはキーワード検索が機能するようになり、検索の死角がなくなる。

6. ステップ5：リランキングによる精度のダメ押し

検索エンジンから返ってきた上位50件ほどの候補を、さらに高精度なモデルで並び替える工程がリランキングだ。ベクトル検索やBM25は高速だが、精度には限界がある。そこで、Cross-Encoderのような計算コストは高いが極めて正確なモデルを使い、検索結果の上位を再評価する。

リランキングを導入するメリットは、LLMに渡すノイズを減らせる点にある。検索結果の1位に関連性の低い文書が紛れ込んでいると、LLMはそれに引きずられて誤答を出す。リランキングによって本当に正しい情報を1位に持ってくることができれば、回答精度は向上する。実装の手間に見合うだけの、コスパの良い手法だ。

しんたろー：
Claude Codeを使って1人SaaS開発をする際、RAGのロジックを書くときもClaude Codeとの対話で進める。ターミナル上でリランキングのライブラリをインストールし、そのまま実装まで一気に指示できるスピード感は一度味わうと戻れない。複雑な検索ロジックも、Claude Codeなら文脈を理解した上で最適なコードを提案する。

<!-- IMAGE_2 -->

7. ステップ6：Golden Setによる定量評価の開始

「なんとなく精度が上がった気がする」という主観的な判断は、RAG開発において危険な行為だ。改善したつもりが、別の質問では答えられなくなっているという回帰現象に気づけないからだ。これを防ぐために、質問と正解のペアを集めたGolden Set（黄金データセット）を作成する。

まずは主要なユースケースを想定した50問程度のテストデータを用意する。モデルを入れ替えたり、チャンクサイズを変えたりするたびに、この50問に対してどれだけ正解できたかを数値で記録する。数値化することで初めて、その施策が本当に有効だったのかを客観的に判断できるようになる。

8. ステップ7：自動評価指標（Ragas）の活用

Golden Setを用いた評価をさらに効率化するために、Ragasなどの自動評価ツールを導入する。RagasはLLMをジャッジ役として使い、忠実性（回答が根拠に基づいているか）や関連性（質問に答えているか）をスコア化する。

人間の目によるチェックも重要だが、全件を毎回確認するのは現実的ではない。自動評価でアタリをつけ、スコアが低い部分だけを人間が精査するというサイクルを回す。この定量的な改善サイクルこそが、実用レベルのRAGを構築するための最短ルートだ。

9. RAG最適化手法の比較まとめ

ここまで紹介した手法を、特徴別に表にまとめる。自分のプロジェクトで何が不足しているかを確認する。

| 手法 | 役割 | メリット | デメリット |

| :--- | :--- | :--- | :--- |

| MarkItDown | 前処理 | 表構造や見出しを維持できる | ファイル数が多いと処理に時間がかかる |

| チャンキング最適化 | データ分割 | 意味の分断を防げる | 最適なサイズの試行錯誤が必要 |

| ハイブリッド検索 | 検索 | 固有名詞と意味の両方に強い | 実装と設定のコストが増える |

| リランキング | 順位補正 | 回答精度が向上する | わずかなレイテンシが発生する |

| Golden Set | 評価 | 改善を数値で証明できる | データセット作成に工数がかかる |

10. しんたろー流・RAG開発のつまずきポイント

初心者がRAG開発でハマりやすいポイントを3つ挙げる。

第一に、プロンプトエンジニアリングで全てを解決しようとすることだ。 前述の通り、検索が不適切であればプロンプトをどう変えても無駄だ。まずは検索結果のTop-5に正解が含まれているかを徹底的に確認する。

第二に、チャンクサイズをデフォルトのまま使い続けることだ。 ドキュメントの性質によって最適なサイズは異なる。マニュアルなら短く、物語のような文脈が重要なものは長めに設定するなど、データに合わせた調整が必要だ。

第三に、評価を後回しにすることだ。 開発の初期段階から数問でもいいのでテスト用の質問を用意しておかないと、改善の方向性を見失うことになる。

しんたろー：
MarkItDownはMicrosoft製ということもあって、Officeファイルの扱いに関しては期待できる。以前、無理やりテキスト抽出して構造がボロボロになった経験があるから、こういうツールはありがたい。実験段階ではあるが、RAGの前処理パイプラインに組み込む価値は十分にある。

11. よくある質問（FAQ）

Q1：なぜプロンプトをいじる前に検索を改善すべきなのか

RAGの回答精度は、LLMに渡されるコンテキストの質に依存しているからだ。検索で誤った文書や無関係なノイズが渡されると、どれほど優秀なLLMでも正しい回答を生成できない。まずは正しい情報がLLMに届いているかを検証し、改善するのが先決だ。

Q2：Golden Setは最低何問必要か

最低でも50問から100問程度を用意する。少なすぎると改善の傾向が掴めず、多すぎると管理コストが膨らむ。まずは主要なユースケースを網羅する50問から開始し、運用しながら回答の傾向に合わせて問題を追加していくのが現実的なアプローチだ。

Q3：MarkItDownを使うと検索精度は必ず上がるのか

必ず上がるとは限らないが、PDFやOfficeファイルをそのまま扱うより精度が安定しやすくなるのは事実だ。特に表データや見出し構造が重要なドキュメントの場合、Markdown化することでLLMが文脈を理解しやすくなる。前処理として有効な選択肢だ。

Q4：リランキングはどのタイミングで導入すべきか

ベクトル検索単体で、検索自体はできているがLLMに渡す情報にノイズが多いと感じたタイミングで導入するのがベストだ。実装コストに対する精度向上の効果が高いため、複雑な手法を試す前に、まずはリランキングを試すことを推奨する。

Q5：RAGの評価指標（Ragasなど）は必須か

必須ではないが、定量的な改善を行うなら導入を推奨する。主観的な判断は開発者のバイアスがかかりやすく、回帰に気づけないリスクがある。自動評価ツールを使うことで、客観的な基準で改善サイクルを回せるようになる。

<!-- IMAGE_3 -->

12. まとめ

RAGの精度向上は、地道な前処理と検索の工夫、そして数値に基づく評価の積み重ねだ。

1. MarkItDownで構造を保ったままテキスト化する。
2. 意味を壊さないチャンキングを設定する。
3. ハイブリッド検索とリランキングで検索品質を極める。
4. Golden Setで改善を数値化する。

このステップを一つずつ踏んでいけば、実用的なRAGへと進化させることができる。まずは手元のドキュメントをMarkItDownで変換するところから始める。