RAG救済 ─ 「賢くないRAG」を実用レベルに引き上げる

RAG（検索拡張生成）は、社内ドキュメント・FAQ・契約書などを根拠にしてLLMに回答させる手法として、企業導入が急速に進んでいます。しかし、実際に作ってみると「思ったほど賢くない」というケースが大半です。その原因は、RAGの7層に渡って点在しています。

第一層はソース文書の品質。そもそも元の文書が冗長・矛盾・古い情報を含む場合、RAGは古い情報を引いてくるため誤答します。文書の棚卸し・正本化が出発点です。

第二層は前処理（Parsing）。PDFからのテキスト抽出が崩れている、表構造が無視されている、改行で文脈が切れている。PyMuPDF / Unstructured / LlamaParse など、コンテンツに応じた最適なパーサ選びが重要です。

第三層はチャンキング戦略。固定文字数で分割すると意味の途中で切れる。逆に大きすぎると検索精度が下がる。セマンティックチャンキング、階層チャンキング、文書構造に従ったチャンキングなど、内容に応じた最適化が必要です。

第四層は埋め込み（Embedding）モデル。text-embedding-ada-002 と text-embedding-3-large でも精度が大きく違う。日本語特化モデル（multilingual-e5, intfloat/multilingual-e5-large）の選択肢もある。データ特性に応じたモデル選定で精度が劇的に変わります。

第五層は検索（Retrieval）。コサイン類似度だけだと取りこぼしが多い。BM25とのハイブリッド検索、メタデータフィルタ、クエリ拡張（HyDE）などで Recall を改善します。

第六層は再ランキング（Reranking）。初段で広く取り、Cohere Rerank や Cross Encoder で絞り込むと、上位N件の精度が劇的に上がります。

第七層は生成プロンプト。「以下の文脈を参考に答えてください」だけでは不十分。引用形式、確信度の表現、「分からない時は分からないと言う」プロトコルなど、生成プロンプトの設計が出力品質を決めます。

計測なくして改善なし、というのが私たちの哲学です。RAG救済では、必ず評価データセットの構築から始めます。Q&Aペアを30〜100組用意し、各バージョンで Recall@k, MRR, nDCG, Answer Relevancy, Faithfulness の各指標を計測。改善仮説を一つひとつ検証していきます。感覚的な「これで良くなった気がする」ではなく、「Recall@5 が 68% → 84% に改善」という形で報告します。

RAG救済の標準スコープは6つです。既存RAGシステムの診断レポート作成（指標ベース）、評価データセット構築、改善仮説の優先順位付け、改善実装と効果検証、本番デプロイ支援、モニタリング設計（精度劣化の早期検知）。短期的な改善で「使える」状態に、中期的にはユーザーフィードバックを取り込み続けて自己改善するRAGへ。

「これからRAGを作りたい」「PoCを終えて本番化したい」「すでに運用しているが精度が悪い」── どの段階でもご相談ください。私たちは、最も投資対効果が高いステップから始めるご提案をします。