社内RAGの精度を上げる5つのチューニング：チャンク設計からRerankerまで

AI・ローカルLLM活用上級メンバー限定
RAGLLMAzure OpenAIEmbeddingRerankerRAGAS

結論: RAG精度不足の原因は①チャンク設計②Embeddingモデル③ハイブリッド検索設定④Reranker欠如⑤評価指標不在の5層にある。この順で診断し、数値で確認しながら修正する。

社内文書をRAGに読み込ませたはずなのに、「住所変更の手順を聞くと6ステップのうち4ステップしか返ってこない」「製品の型番で検索しても全然ヒットしない」——試験導入から3ヶ月が経っても、こうした具体的な不具合が消えない状況は珍しくない。

問題は回答の質そのものではなく、どのコンポーネントに起因するかが判断できないことにある。チャンクを疑って変更してみたが改善しない。Embeddingモデルが原因かと思ったが確認方法が分からない。評価フレームワークがない状態では、どこを直しても当てずっぽうになる。

本記事では、チャンク設計→Embeddingモデル→ハイブリッド検索→Reranker→評価フレームワークという5つの調整ポイントを、実験データと実装例とともに扱う。詰まっている箇所に心当たりがある場合は「5つのチューニングをどこから手をつけるか」の診断チェックリストから読んでもよい（診断チェックリストへ）。

なぜ「とりあえずRAGを入れた」だけでは精度が出ないのか

RAGは単一のコンポーネントではなく、複数の処理レイヤーが連鎖して動くシステムだ。

文書入力
  ↓
① チャンク分割（サイズ・オーバーラップ設定）
  ↓
② Embeddingモデル（ベクトル化）
  ↓
③ ベクトルDB保存
  ↓
④ クエリ受付 → ハイブリッド検索（BM25 + ベクトル検索 → RRF統合）
  ↓
⑤ Reranker（上位候補の再スコアリング）
  ↓
⑥ LLM（コンテキスト＋プロンプト → 回答生成）
  ↓
⑦ 評価（faithfulness / context_precision 等で数値化）

精度の問題がどの層で起きているかを特定しないまま調整を始めると、⑥LLMのプロンプトを変えても①チャンク起因の欠落は直らない。「どのコンポーネントを疑うべきか分からない」という状態の正体は、⑦の評価フレームワークが存在しないことが多い。症状は出ているが、数値がないため診断できない。

もう一つ見落とされがちな問題がある。PDFの2段組みレイアウトがOCR誤認識されてそのままチャンクに混入する、改ページを跨いだ箇条書きが1文として扱われず文脈が切れるといったケースだ。入力データの品質がそもそも低い場合、チューニングで補える範囲には限界がある。チャンクを触る前に、テキスト抽出後の内容を目視で数件確認しておくことが前提になる。

以降のセクションでは5つの調整を順番に扱う。①→②→③→④→⑤の順で診断することを推奨する。

チューニング1：チャンク設計——サイズとオーバーラップの実験データを読む

精度低下の根本原因として最も多いのはチャンク設計の問題だ。

チャンク分割の4パターンと用途適合

分割方式概要向いている文書
固定長指定トークン数で機械的に切る均質なテキスト・ログデータ
再帰的段落→文→単語の順に優先して分割一般的な文章・ブログ・FAQ
文書構造ベース見出し・条項番号・箇条書き番号を境界にする手順書・規程集・マニュアル
セマンティック意味的なまとまりで動的に分割トピックが混在する長文

手順書や規程集のような文書は、文書構造ベースの分割が適している。「ステップ3：〇〇を確認する」という番号付き手順が固定長で途中から切れると、後半ステップが別チャンクに分離し、前半の文脈から切り離される。この「6ステップのうち4ステップしか返ってこない」という症状の多くはここに起因する（SCSKのusize-techブログ、チャンキング戦略）。

チャンクサイズとオーバーラップの実験値——どこから始めるか

Fintan「RAGの性能を改善するための8つの戦略」が参照しているMicrosoftの実験データでは、Recall@50の値はチャンクサイズによって次のように変化する。

チャンクサイズ（トークン）Recall@50
51242.4
102437.5
409636.4
819134.9

この数値だけを見ると「チャンクは小さいほどよい」という結論になるが、実際はそうならないケースがある。エクサ株式会社のコラム（第7回）では、Azure AI Search + GPT環境（社内システム「たまちゃん」）でチャンクサイズを変えた実験が公開されている。

チャンクサイズオーバーラップ評価データ正解率
900文字100文字60%
3000文字900文字69%

この事例では、大きいチャンクサイズで精度が向上している。対象文書の構造と質問の粒度によって最適値は異なるため、自社データで実験することが必要だ。

出発点の目安として、Azure AI Searchの推奨値は512トークン＋25%オーバーラップとされている。AWS Advanced RAGガイドでも、一般的には256〜1024トークンの範囲で調整するケースが多いとされている。

オーバーラップのサイズはチャンクサイズの10〜20%を起点に調整するのが実用的だ（usize-tech）。回答が断片的になる場合はオーバーラップを増やし、関係のない情報が混入する場合は減らす。

日本語特有の注意点: トークナイザの仕様によって、日本語テキストは同じ文字数でもトークン数が英語より多くなりやすい。文字数でサイズを指定すると意図した範囲を超えるため、トークン数ベースで管理することが重要だ（usize-tech）。

よくある失敗パターン:

  • チャンクが小さすぎる場合：「ただし〜」「ただしこの条件では〜」といった例外条件が境界で切れ、回答から落ちる。「6ステップのうち4ステップしか返ってこない」問題の正体がこれに当たることが多い。
  • チャンクが大きすぎる場合：1チャンク内に複数トピックが混在し、ベクトルが平均化されてクエリとの類似度が下がる。
  • オーバーラップなしの固定長：文章の途中で切れ、主語や前提条件が消える。

チューニング2：Embeddingモデル——日本語評価データで選ぶ

チャンク設計の次に精度へ直結するのがEmbeddingモデルの選定だ。モデルが変わると同じチャンクを与えても検索ヒット率が大きく異なる。

OpenAI Embeddingモデルの性能・コスト比較

OpenAI公式ブログ（2024年1月25日発表）およびOpenAI API Docsによると、主要3モデルの特性は以下の通りだ。

モデルMIRACL（多言語検索）MTEB最大入力コスト（公表時点）
text-embedding-ada-00231.4%61.0%—基準
text-embedding-3-small44.0%62.3%8192トークンada-002の約1/5
text-embedding-3-large54.9%64.6%8192トークンada-002の約6.5倍

3-smallはMIRACLで44.0%とada-002から大幅に改善しており、コストも約1/5（$0.00002/1kトークン、2024年1月発表時点）と低い。日本語を含む多言語検索を行う場合、ada-002からの移行を最初に検討する価値がある。最新料金はOpenAI公式の料金ページで確認すること。

Azure OpenAI Serviceでの利用料金は、エクサ株式会社のコラム（第7回）が2025年4月時点の参考値を公開している。text-embedding-3-smallで¥0.003020/1000トークン、text-embedding-3-largeで¥0.019629/1000トークン（いずれも2025年4月時点の参考値・為替・プランにより変動）。

日本語特化モデルの選択肢と実験結果

Fintan「RAGの性能を改善するための8つの戦略」では、日本語を含む評価（Hit Rate@10 / MRR@10）による複数モデルの比較が公開されている。

モデルHit Rate@10MRR@10
multilingual-e5-base0.76790.5352
multilingual-e5-large0.84570.6364
text-embedding-ada-0020.83550.6436
embed-multilingual-v3.0（Cohere）0.85840.6485
multilingual-e5-large-finetuned（人手データ）0.89800.6660

ドメイン固有のQ&Aデータでfinetuningしたmultilingual-e5-largeが最高値を出している。ただし、finetuning用のQ&Aデータセット作成が前提になる。まず選定するモデルを固定し、評価スコアを計測してから改善を検討する順序が現実的だ。

よくある失敗パターン:

  • インデックス作成時とクエリ時で異なるモデルを使う：ベクトル空間の基準が異なるため検索ヒット率が激減する。一度インデックスを作ったモデルはクエリ側でも同じモデルを使うこと（Fintan）。
  • オープンソースモデルで全角/半角の前処理を省略する：モデルによっては全角入力を前提とする場合があり、前処理なしでは性能が低下する（Fintan）。

チューニング3：ハイブリッド検索——BM25を「そのまま」組み合わせると逆効果になる

型番や製品コードが検索でヒットしないケースは、ベクトル検索の弱点に起因することが多い。ベクトル検索は意味的な類似性に強いが、完全一致を前提とする固有名詞や型番には弱い。BM25（キーワードマッチング）を組み合わせたハイブリッド検索がその解法として知られているが、設定を誤ると単体より性能が落ちる。

ハイブリッド検索の基本的な構造は以下の通りだ。

クエリ
  ├── BM25による全文検索（型番・固有名詞の完全一致に強い）
  └── ベクトル検索（意味的な類似性・言い換えに強い）
         ↓
  RRF（Reciprocal Rank Fusion）で統合 → 上位50〜100件
         ↓
  Reranker（次のセクション）へ

Fintan「RAGの性能を改善するための8つの戦略」では、ハイブリッド検索の設定によって性能が大きく変わることが実験データで示されている。

構成Hit Rate@10MRR@10
ada-002単体0.83550.6440
ada-002 + BM25（LangChainデフォルト設定）0.78190.5855
ada-002 + BM25（ja.lucene）0.82520.6185
ada-002 + 改善版全文検索0.89540.6616

LangChainのデフォルト設定でBM25を単純に追加すると、ada-002単体より性能が低下している。「ハイブリッド検索にすれば精度が上がる」という前提は成立しない。

改善版全文検索が単体ベクトル検索を超えるためには、形態素解析・Ngramインデックス・ストップワード除去といった日本語向けの全文検索チューニングが前提になる（Fintan）。Azure AI Searchを使っている場合はja.microsoftアナライザーの適用が出発点になる。

RRFのパラメータについては、デフォルトのk=60が一般的に使われているが、k=10に下げると上位文書をより強く重視したスコアリングになる。Azure AI SearchおよびElasticsearchの両方でRRFパラメータの変更は対応している。

よくある失敗パターン:

  • デフォルト設定のBM25をそのまま追加する：上記の実験データが示す通り、単体ベクトル検索より性能が下がるケースがある。BM25を加えた後は必ず評価スコアを計測して確認すること。

チューニング4：Reranker——2段構成でコストと精度を両立する

ベクトル検索で取得した上位候補の中に関係のない文書が混じる場合、Rerankerの欠如が原因のことが多い。

Bi-EncoderとCross-Encoderの仕組みの違い

Embeddingモデル（Bi-Encoder）とReranker（Cross-Encoder）は役割が異なる。

Bi-Encoder（Embedding）: クエリと文書をそれぞれ個別にベクトル化し、コサイン類似度でスコアリングする。文書側のベクトルは事前計算できるため、大規模な文書集合に対しても高速に動作する。ただし、クエリと文書の関係を個別にエンコードするため、ペア間の細かい意味関係を捉えにくい。

Cross-Encoder（Reranker）: クエリと文書をペアで結合してTransformerモデルに入力し、スコアを算出する。全ペアをリアルタイム計算するため低速だが、ペア間の意味的な関係を直接モデルが評価するため精度が高い（NVIDIA技術ブログ「リランキングモデルによるRAGの日本語検索精度の向上」）。

2段構成の実装パターンと日本語での効果

速度と精度を両立するための実用的な構成は、Bi-Encoderで広く取ってCross-Encoderで絞る2段構成だ。

Bi-Encoder（Embedding）
  → 全文書から上位50〜100件を高速取得
       ↓
Cross-Encoder（Reranker）
  → 50〜100件を再スコアリングし上位3〜5件に絞る
       ↓
LLM（絞り込まれたチャンクをコンテキストとして利用）

日本語RAGへのReranker追加効果として、NVIDIA技術ブログのJMTEB評価結果では、Llama-3.2-NV-EmbedQA-1B-v2にLlama-3.2-NV-RerankQA-1B-v2を組み合わせることで3.7ポイントの向上が確認されている。mE5-large / Ruri-large / NV-EmbedQAいずれの埋め込みモデルでも、NV-RerankQAを追加すると検索精度が改善している。

BM25とRerankerを組み合わせた場合の効果もFintanが数値で示している。BM25単体でHit Rate@10=0.5804だったのが、bge-reranker-largeを加えることで0.7730まで改善している。

ただし、ベクトル検索単体にRerankerを追加しても改善しないケースもある。万能ではないため、追加後は評価スコアで効果を確認すること。

Rerankerモデルの選択肢（2026年7月時点・用途の参考として）:

  • bge-reranker-large（BAAI）: XLM-RoBERTaベースのOSSモデル。日本語を含む多言語に対応。
  • Cohere rerank-multilingual-v2.0: API経由で利用可能。日本語を含む多言語に対応。料金はCohere公式で確認のこと。
  • NVIDIA Llama-3.2-NV-RerankQA-1B-v2: NIM（Dockerコンテナー）で提供。ローカル環境でのセルフホストが可能（NVIDIA技術ブログ）。

よくある失敗パターン:

  • 10,000件超の文書に対してRerankerを直接全件適用しようとすると、推論時間が実用不能なレベルになる。Embeddingで上位50〜100件に絞ってからRerankerを適用する2段構成が前提だ。

チューニング5：評価フレームワーク——どのコンポーネントに問題があるかを数値で判断する

「回答がおかしい気がする」という感覚は診断には使えない。どのコンポーネントに問題があるかを特定するには、評価メトリクスを数値で取ることが必要だ。評価フレームワークがない状態では、チューニング1〜4のどれを変えても効果の確認ができない。

RAGASで測る4つのメトリクス

RAGASはRAGシステムの評価に特化したOSSライブラリで、LangChainおよびLlamaIndexと連携できる。

pip install ragas datasets langchain-openai

HelpMeTest「Evaluating RAG with RAGAS and TruLens」が示す実務目安として、4つの主要メトリクスと推奨閾値は以下の通りだ（業界標準として固定された値ではなく、実務上の参考値として扱うこと）。

メトリクス計測内容実務目安閾値
faithfulness回答がコンテキストに根拠を持つか（ハルシネーション検出）0.85以上
answer_relevancy回答が質問に答えているか0.80以上
context_precision取得チャンクが質問に関連しているか0.75以上
context_recall取得チャンクが正解をカバーしているかグラウンドトゥルース（正解データ）が必要

各メトリクスの値から診断の方向が決まる。

  • faithfulnessが0.5未満: ハルシネーションが深刻。コンテキストに存在しない情報を回答に含めている可能性が高い。チャンク設計またはEmbeddingモデルの改善を先に行う。
  • context_precisionが低い: 検索がずれている。関係のないチャンクが上位に来ている。ハイブリッド検索の設定またはRerankerの導入を検討する。
  • answer_relevancyが低い: 回答生成側のプロンプト設計または上位チャンクの質に問題がある可能性がある。

TruLensとAWS RAGCheckerの位置づけ

TruLensはRAG Triad（Context Relevance・Groundedness・Answer Relevance）をOpenTelemetryトレーシング付きで評価するOSSライブラリ（Snowflake傘下）。既存のLangChainパイプラインにTruChainラッパーを追加するだけで計装できる。

pip install trulens trulens-providers-openai

HelpMeTestによると、トレースログを残しながら評価スコアを収集できるため、改善前後の比較が容易になる。

AWS RAGChecker（github.com/amazon-science/RAGChecker）はAmazon Scienceが公開したOSSの評価ライブラリで、RAGASと並んでオフライン評価に利用されている（AWSブログ）。

なお、日本語LLMとの組み合わせ時の動作については、本記事執筆時点で検証データがない。英語ベースのLLMをEvaluator LLMに使う構成で動作確認することを推奨する。

5つのチューニングをどこから手をつけるか——診断チェックリスト

症状ごとに最初に疑うべき層をまとめる。

症状最初に疑う層参照セクション
手順が途中で欠落する / ステップが全部返ってこないチャンクサイズ・オーバーラップ不足チューニング1
型番・固有名詞でヒットしないBM25の全文検索チューニング未実施チューニング3
関係のない文書が上位に来るRerankerなしまたはEmbeddingモデルの精度チューニング4→2
ハルシネーションが止まらないfaithfulnessをRAGASで計測→チャンクかEmbeddingに戻るチューニング5→1→2
どのコンポーネントが問題か分からない評価フレームワーク（RAGAS）を先に導入するチューニング5

試験導入から本番品質に引き上げるまでのサイクルは、1回の調整で完結することはほとんどない。評価スコアを計測→調整→再計測というループを複数回回すことが前提になる。

自社のRAGがどの層で詰まっているか判断に迷う場合や、評価フレームワークの導入から優先度をつけたい場合は、設計の診断から対応することも可能だ。

RAG構築・精度改善の相談はこちら

まとめ

社内RAGの精度不足は単一の原因ではなく、5つの層が連鎖して起きることが多い。

  1. チャンク設計: 文書構造ベースの分割を基本とし、サイズとオーバーラップは自社データで実験する。日本語はトークンベースでサイズを管理する。
  2. Embeddingモデル: ada-002からtext-embedding-3-smallへの移行を起点に検討する。インデックス作成時とクエリ時で同じモデルを使うことが必須条件。
  3. ハイブリッド検索: BM25をデフォルト設定で追加すると単体より性能が下がるケースがある。日本語向け形態素解析チューニングが前提。
  4. Reranker: Bi-Encoder（上位50〜100件）→ Cross-Encoder（上位3〜5件）の2段構成で速度と精度を両立する。
  5. 評価フレームワーク（RAGAS）: faithfulness / context_precision 等のスコアを計測しないと、どの層を修正すべきか判断できない。

自社RAGのどのコンポーネントで詰まっているかを数値で特定し、修正→再計測のループを回せる状態を作ることが本番品質への道筋になる。

RAG構築・精度改善の相談はこちら

関連記事

この続きはメンバー限定です

メールアドレスを登録すると、本記事の続き（設定ファイル・コード）と全 6 本のメンバー限定記事がその場で読めます。無料・いつでも解除可。

関連記事

AI・ローカルLLM活用RAG（検索拡張生成）とは：社内文書検索AIをゼロから理解するAI・ローカルLLM活用自社RAGシステム構築代行：依頼前に確認すべき要件定義チェックリストAI・ローカルLLM活用プライベートGPT（機密データ対応LLM）の設計パターン4選
記事一覧に戻る