PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
RAGの精度が上がらないときに最初にやるべきことは、検索が失敗しているのか生成が失敗しているのかを分けることです。この切り分けをせずにチャンクサイズや埋め込みモデルを触っても、当たりを引くまで試行が続きます。
原因は課題設定・元データ・検索器の3層に分かれます。検索側だと分かったら、検索器のパラメータより先に元データを見ます。そして、打ち切り基準を先に決めない限り、精度改善は終わりません。
- 診断の順：検索の失敗か、生成の失敗かを先に分ける
- 着手の順：元データを直してから検索器を触る
- 終了の条件：評価セットと合格ラインを着手前に決める
RAGの精度が上がらない原因はどこにあるのか？
原因は課題設定・元データ・検索器の3層に分かれます。検索器のパラメータだけが原因であるケースは少なく、上の層に問題を抱えたまま下の層を調整しても効果が出ません。まず自分の詰まりがどの層にあるかを特定します。
| 層 | 典型的な症状 | 最初に打つ手 |
|---|---|---|
| 課題設定 | 「精度が低い」の中身が人によって違う | 代表クエリと正解文書を書き出す |
| 元データ | 古い版・重複・断片が回答に混ざる | 失効文書の削除と版管理 |
| 検索器 | 正解文書が上位k件に入らない | ハイブリッド検索・リランキング |
課題設定の層でつまずいている状態は、実務でよく起こります。例えば、利用者が「精度が低い」と言っている中身が、担当者Aは回答の言い回し、担当者Bは参照文書の間違い、担当者Cは応答の遅さを指している、という状態が考えられます。何を直せば合格なのかが定義されていないため、改善作業が終わりません。
この記事では2つの「順番」を扱います。1つは診断の順で、検索と生成のどちらが失敗しているかを分ける手順です。もう1つは着手の順で、元データを直してから検索器を触るという優先順位です。
RAGの仕組みそのもの（検索・チャンク分割・生成の流れ）は本記事の対象外です。基本構造はRAGとはなにか？なぜ企業活用で必須なのか？で解説しています。本記事は、RAGを採ると決めて動かした後、精度が出ないときの話に限定します。
RAGを採るかどうかという手前の判断も本記事の対象外です。ファインチューニングや長文コンテキストとの選び分けはRAGとファインチューニングの違いは？選び方を解説で整理しています。
検索と生成のどちらが失敗しているのか？
失敗したクエリについて、正解となる文書が検索結果の上位k件に入っていたかを人の目で確認すれば分かります。入っていれば生成側、入っていなければ検索側の問題です。この2値の記録だけで、次に触るべき場所が決まります。
OpenAIは公式ドキュメント「Optimizing LLM Accuracy」で、RAGアプリケーションの壊れ方を2箇所に分けています。1つは検索側で、間違った文脈を渡してモデルが答えられなくなるか、無関係な文脈を渡しすぎて本当の情報が埋もれハルシネーションを起こす場合です。もう1つはモデル側で、正しい文脈を得ているのに誤った処理をする場合です。
検索側とモデル側という2分類は、改善作業の順番ではなく診断の分岐として使います。OpenAIは同ドキュメントで、評価によって何が壊れたのかを知り、そのうえで最適化の一手を打つという原則を示しています。どちらが壊れているか分からないまま打つ手は、当たり外れの試行になります。
具体的な手順は表計算1枚で足ります。失敗したクエリを20〜30件集め、各クエリについて①正解文書が検索結果に入っていたか、②回答が正しかったか、の2つを2値で記録します。記録が20件も溜まれば、失敗がどちらの側に偏っているかは目視で分かります。
検索側が原因のときは何を見るのか？
指標はrecall@kです。recall@kは、正解文書が検索結果の上位k件に含まれていた割合を指します。生成側をどれだけ改良しても、渡す文脈に正解が入っていない限り正しい回答は出ないため、この数値が低い状態では他の施策の効果が見えません。
recall@kが低い場合、原因は元データか検索器のどちらかにあります。着手の順は元データが先です。理由は、元データに正解文書が存在しない、あるいは失効版しか存在しないケースでは、検索器を何に変えても数値が動かないためです。
生成側が原因のときは何を見るのか？
正解文書を手でコンテキストに入れて再現テストをします。手で入れれば正しく答えるなら、生成は機能しており、犯人は検索側だと確定します。手で入れても間違えるなら、生成側の問題として切り分けが確定します。
生成側の失敗で頻出するのが、渡す量の詰め込みすぎです。Liu らが2023年にarXivへ投稿した論文「Lost in the Middle: How Language Models Use Long Contexts」は、関連情報の位置を変えると性能が大きく劣化すると報告しています。同論文によれば、性能は関連情報が入力の先頭か末尾にあるときに最も高く、長い文脈の中間にあるときに著しく落ちます。
同論文は、位置による性能の劣化が長文コンテキスト対応をうたうモデルでも起きると明記しています。この報告から考えると、生成側の最初の一手は、渡すチャンク数を絞ることと、確度の高い文書を先頭か末尾に置くことになります。上位20件を全部渡すより、上位5件に絞ったほうが正答率が上がる場合があります。
元データを直さずに検索器をチューニングして意味はあるのか？
費用対効果が著しく低くなります。整備の対象は、重複と版違い・失効文書・粒度・本文が抽出できない形式の4つで、このうち失効文書の削除が最も安く効きます。削除はインデックスから外すだけで済み、検索器の再構築を伴わないためです。
元データが原因だと分かる症状は限定的です。回答に古い規程の内容が混ざる、同じ質問に対して日によって違う版が返る、検索結果に本文が数十文字しかない断片が並ぶ、といった症状が該当します。検索器の設定を変えても症状の種類が変わらない場合も、元データを疑う根拠になります。
ベクトル検索は「どちらが最新か」を判断しません。同じ規程の旧版と新版が両方インデックスにあれば、意味的にはどちらも近い文書として返ります。この仕組みから考えると、日付や版数をメタデータに持たせ、失効版をインデックスから外す作業が、埋め込みモデルの変更より先に来ます。
私が扱ってきたのは約2,000件規模の社内データですが、いちばん手間がかかったのは文書からテキストを構造的に整理する工程でした。LLMに整理させても間違ったりするので、そこのチェックが必要になります。
公開情報から取ってきてデータベースを整備する作業も、私の実務で大変だったところです。
データの更新については、定期的に回すことが大事なので、私の実務ではETL的なものを組んでいます。
元データの整備は1回やって終わりではなく、運用として回し続ける対象になります。整備した直後は精度が出ていても、参照元の文書が更新されれば、インデックス側は古いまま取り残されるためです。
整備の具体的なやり方（メタデータの持たせ方、非テキストの扱い、チャンキング）はRAGにおけるデータクレンジングの重要性で扱っています。本記事は、データが原因だと分かる症状と、最も安い一手までを担当します。
検索器のチューニングはどこまで効くのか？
効きますが、報告されている効き幅には上限があります。Anthropicの実験では、文脈を付けた埋め込みとBM25の併用で上位20チャンクの検索失敗率が49%削減され、リランキングを加えると67%削減されました。元データの粒度が悪いままでは、この幅は出ません。
Anthropicは「Introducing Contextual Retrieval」で、3段階の削減率を報告しています。文脈を付けた埋め込み（Contextual Embeddings）単体で35%削減（5.7%→3.7%）、Contextual BM25を併用して49%削減（5.7%→2.9%）、さらにリランキングを加えて67%削減（5.7%→1.9%）です。
Anthropicが報告した35%・49%・67%という削減率は同社自身の実験条件に紐づくもので、どのRAGでも同じ幅が出るという意味ではありません。指標はtop-20-chunkの検索失敗率であり、リランキングは初期検索で上位150件を取り、リランキングモデルでスコアリングして上位20件に絞る手順で実施されています。自社のデータで同じ幅が出るかは、評価セットで測る対象です。
コスト側の但し書きも同じ記事にあります。Anthropicは、リランキングが実行時に1ステップ増えるため、すべてのチャンクを並列でスコアリングしてもレイテンシがわずかに増えることは避けられないと述べています。検索精度と応答速度・コストは同時には取れないため、要件のどちらを優先するかを先に決めます。
施策は1つずつ入れて評価セットで測ります。ハイブリッド検索とリランキングとチャンク分割の変更を同時に入れると、効いた施策と効かなかった施策を分離できず、次に何を残すかの判断ができなくなるためです。
チャンクはどこで切るべきか？
文字数ではなく意味の切れ目で切ります。固定文字数で機械的に分割すると、1つの手順の途中や表の途中で切れ、断片だけ読んでも意味が取れないチャンクが生まれます。検索でヒットしても回答に使えないチャンクは、recall@kの数値を実態より良く見せるだけです。
各チャンクの先頭に文書タイトルと見出しパスを付ける対処は、費用が小さく効果が見込めます。例えば「就業規則 > 第4章 休暇 > 年次有給休暇」という1行が先頭にあれば、そのチャンクだけを読んだモデルが何についての記述かを判断できます。主語が分からないチャンクを減らすことが、この処置の目的です。
ベクトル検索とキーワード検索はどう使い分けるのか？
固有名詞を含むクエリはキーワード検索、言い換えの多いクエリはベクトル検索が優位です。社内システム名・部署名・案件コードのように表記が1つしかない語は、完全一致で拾うほうが確実です。正式名称を知らない利用者の問い合わせは、意味の近さで拾うベクトル検索でなければヒットしません。
実務では両方を持ちます。Anthropicが報告した49%という削減幅も、文脈を付けた埋め込み単体ではなくBM25というキーワード検索の手法を併用した条件で出た数値です。両方式の組み合わせ方はHybrid(ハイブリッド)RAGとはなにか？従来のRAGとGraphRAGの新手法で整理しています。
検索方式そのものの仕組みはベクトル検索とは？仕組みとRAGでの役割で解説しています。方式を選ぶ前に、埋め込みが何を近いと判断しているかを押さえておくと、検索結果の外し方を読めるようになります。
ベクトル検索をやめる選択肢はあるのか？
あります。ベクトル検索を前提にせず、メタデータと文書構造を整備してエージェントに探させる構成が選択肢になります。Anthropicも、意味検索はエージェント検索より速いが、精度・保守性・透明性で劣るとして、まずエージェント検索から始めることを推奨しています。
Anthropicは「Building agents with the Claude Agent SDK」で、意味検索（semantic search）を、関連するコンテキストをチャンクに分割し、ベクトルとして埋め込み、そのベクトルへの問い合わせで概念を検索する手法だと説明しています。そのうえで、意味検索は通常エージェント検索より速いが、精度が低く、保守が難しく、透明性に劣ると述べています。
同社の推奨は「まずエージェント検索から始め、より速い結果やより多くのバリエーションが必要な場合にのみ意味検索を足す」というものです。意味検索が不要だという主張ではなく、速度と多様性が要件になったときに足す順序の話です。同記事は、エージェントのフォルダとファイルの構造そのものがコンテキストエンジニアリングの一形態になるとも述べています。
私自身は、精度改善はそこまでやっておらず、ベクトル検索だとブラックボックス化しやすいから、エージェントが探しに行く、みたいな流れでClaude Codeとかに近いアプローチをとっています。
メタデータを整備して、コンテキストを整備して探しに行かせるアプローチを、私はよくとっています。
エージェントに検索させる時は、意外と丁寧にデータテーブルを教える必要があったり、コンテキストを注入する必要があります。私の実務では、意外といけるのかと思いきや緻密なコンテキスト注入が必要になる点が、すごく見落としがちなポイントでした。
エージェントへ何をどの順で教えるかという設計は本記事の対象外です。データテーブルの定義や例の渡し方を含むコンテキストの組み立てはコンテキストエンジニアリングとは？RAG・メモリ・ツールの設計で扱っています。
ブラックボックス化という言葉が指しているのは、なぜその文書が返ったのかを人が説明できない状態です。埋め込みの類似度は数値としては出ますが、なぜ不正解の文書のほうが上位に来たのかを言葉で説明できないため、改善の仮説が立ちません。
検索の結果を説明できないことは、記事前半で述べた切り分けの効きにも響きます。検索が失敗した理由を説明できない構成では、recall@kが低いと分かった後の一手を、試行錯誤でしか決められません。メタデータと文書構造で探させる構成は、どの条件で絞り込んだかが手順として残るため、失敗の理由を追える点で診断しやすくなります。
精度改善はどこで打ち切ればよいのか？
評価セットと合格ラインを着手前に決めることでしか止まりません。合格ラインは技術的な理想値ではなく、失敗1件あたりのコストと成功1件あたりの価値から決めます。100%を目指す限り、改善作業に終わりはありません。
OpenAIは「Optimizing LLM Accuracy」で、本番運用に必要な精度を金額から逆算する試算を示しています。カスタマーサポートを想定し、AIによる解決を+$20、エスカレーションを-$40、最悪ケースの解約を-$1000（発生率5%と見積り）と置いたとき、損益分岐となる精度は81.5%と計算されています。
同ドキュメントは、失敗の15%が主に早期のエスカレーションであるなら、85%の精度でも問題ない場合があるとしています。損益分岐81.5%も85%も、特定の金額前提を置いたときの試算であり、RAG一般の合格ラインではありません。自社の数字を入れれば、損益分岐は60%にも95%にもなります。
私の実務では、検索の精度に目が行きがちですが、UI側で期待値をコントロールすることも大事で、ここはユースケース依存です。
負例が出てきたら著しく困るのか、該当のアイデアが出てくればいいのか、というユースケースの違いで、検索に求められる精度も変わります。だから、私の見方では検索精度だけでなくUIでコントロールすることも大事になります。
評価セットは小さく始めて構いません。Anthropicは「Demystifying evals for AI agents」（2026年1月9日公開）で、何百件も必要だと思って評価の構築を遅らせるチームがいるが、実際には実際の失敗から拾った20〜50件の単純なタスクが良い出発点になると述べています。同記事は、待つほど評価は作りにくくなるとも指摘しています。
評価セットのクエリは、実際の問い合わせログから拾います。開発者が思いつきで書いたクエリは、利用者の言い回しや略語から外れるため、本番で起きる失敗を再現しません。切り分けのために集めた失敗クエリ20〜30件は、そのまま評価セットの初版に使えます。
私の実務では、精度は人でのレビューが主で、実際に見てもらうというやり方が主でした。ただ、最近は評価セットをしっかり作った方がいい、という流れになっています。
評価セットには、打ち切り以外の効用もあります。文書を1件追加すると、既存クエリの検索結果は変動します。この仕組みから考えると、評価セットを持っているチームだけが追加後の劣化を検知でき、常時チューニングを続ける状態から抜けられます。
よくある質問
社内文書がスキャンPDFしかない場合、何から手を付ければよいですか？
テキストが抽出できているかの確認からです。スキャンPDFは画像として保存されているため、そのままインデックスに入れても検索対象にならず、まずOCRでテキスト化して抽出結果を数十件サンプリングし、人が読める文章になっているかを確かめます。表や図中の文字は崩れやすいため、重要度の高い文書ほど抽出後の目視確認に手をかける価値があります。
LLMをより高性能なものに変えれば、RAGの精度は上がりますか？
生成側が原因のときだけ上がります。正解文書が検索結果に入っていない状態では、どのモデルに変えても回答は正しくなりません。モデル変更を検討する前に失敗クエリで検索ヒットの有無を確認するのが先で、モデル選定そのものの観点は企業でLLMを活用する時にどのLLMを選択するべきか？で整理しています。
精度の評価はLLMに任せて自動化できますか？
部分的にできますが、自動化する前に人手判定との一致率を確認します。同じ50件をLLMと人の両方で判定し、判定が割れる件数を数えれば、自動評価をどこまで信用してよいかが分かります。一致率が低いまま自動評価の数値だけを追うと、改善しているように見えて実際は変わっていない、という状態が起こります。
RAGの精度改善は何から学べばよいですか？
評価の作り方からです。合格ラインと評価セットがなければ、施策を入れた前後で良くなったのかを判定できず、改善の打ち切りも決められません。次に検索側の指標（recall@k）とデータ整備、最後に検索方式の選択という順序が依存関係に沿っており、体系的に学び直すならキカガクの生成AI講座のような社会人向けのコースも選択肢になります。
まとめ
RAGの精度が上がらないときは、検索と生成のどちらが失敗しているかを先に分けます。失敗クエリを20〜30件集め、正解文書が上位k件に入っていたかを記録すれば、次に触る場所が決まります。
原因の層は課題設定・元データ・検索器の3つで、着手は元データが先です。そして、評価セットと合格ラインを着手前に決めない限り、精度改善は終わりません。
PR
評価と検索の基礎を、自分の業務で試せる状態にする
評価セットの作り方や検索方式の選び分けは、公式ドキュメントを読むだけでは自分の業務に落ちません。手を動かしながら学ぶなら、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の選び方そのものは生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
にほんブログ村
