RAGの精度が出ないときの見直し所｜チャンク分割と埋め込みの詰め方
社内資料を読ませたチャットボットを作った。 デモでは、いい感じに答えてくれた。「これはいけそうですね」と言われて、現場に出した。
——そして今、「そのような情報は見つかりませんでした」と「明らかに違う資料を引っ張ってきた答え」が並んでいます。 上からは「精度、もう少し上げられない？」。悪気のない一言なのに、いちばん困る一言です。
というのも、「精度を上げる」には触れる場所が多すぎるからです。 モデルを新しくすればいいのか。プロンプトを直すのか。資料を増やすのか。ベクトルDBを変えるのか。どれも一理あって、どれも決め手に欠ける。手当たり次第に触ると、良くなったのか悪くなったのかも分からなくなる——ここがRAGのいちばんしんどいところだと思います。
先に言っておきたいのは、精度が出ないのは設計が下手だったからではないということです。RAG（社内資料などをAIに参照させて答えさせる仕組み。詳しくはRAGとは）は、デモが通りやすく、現場で崩れやすい。これは仕組みの性質で、ほぼ誰もが通る道です。
結論：RAGの精度が出ないときは、モデルやプロンプトを触る前に、「検索が正しい資料を拾えているか」を見ます。手順は、①失敗した質問で検索結果の上位を実際に目で見る→②正解の資料が入っていなければ検索側（チャンク分割・検索方式）の問題、入っているのに答えを間違えたなら生成側（プロンプト・モデル）の問題、と仕分ける。経験上、詰まりの多くは検索側にあります。そして検索側でまず効くのは、チャンク分割の見直しとハイブリッド検索（キーワード検索の併用）の2つです。
この記事では、その切り分けから順番に整理していきます。全部を一度にやる必要はありません。今日は「検索結果を目で見る」ところまでで十分です。
まず切り分ける：検索が悪いのか、生成が悪いのか
RAGは、ざっくり2つの工程でできています。
- 検索：質問に関係のありそうな資料を、社内文書の山から探してくる
- 生成：探してきた資料をプロンプトに入れて、AIに答えを書かせる
精度が出ないとき、このどちらでつまずいたのかを先に決める。ここを飛ばすと、生成側（プロンプトやモデル）ばかり触って、実は検索が正解を拾えていなかった、という空振りが起きます。
切り分けはとても簡単で、こうします。
正解が書いてある資料を、あなたが手で見つけて、そのままプロンプトに貼り付けて聞いてみる。
- 正しく答えられた → 生成は問題なし。検索が正解を拾えていないのが原因です。
- それでも間違える → 生成側（プロンプト・モデル・資料の書き方）の問題です。
拍子抜けするほど原始的ですが、これがいちばん速い。そして多くの場合、前者になります。資料を目の前に置けばAIはちゃんと答えられる。ただ、その資料にたどり着けていない。
つまり、RAGの精度問題は、その多くが検索の問題です。ここが腑に落ちると、触る場所がぐっと減ります。
明日いちばん最初にやること：検索結果を目で見る
切り分けの次にやることは、ひとつだけです。
失敗した質問について、検索が拾ってきた資料の上位5件を、そのまま画面に出して読む。
これは、驚くほど多くの現場で飛ばされている工程です。RAGは検索結果を裏でプロンプトに詰めてしまうので、開発している側からも見えない。見えないまま「精度が悪い」とだけ言い合うことになります。
やり方は、大げさなものでなくて構いません。
- 検索フェーズの戻り値（拾ったチャンクの本文・元ファイル名・スコア）をログに出す
- 開発環境だけでいいので、回答の下に「参照した資料」を並べて表示する
そのうえで、失敗した質問を10個ほど集めて、1件ずつこう見ていきます。
| 見るところ | 判定 |
|---|---|
| 上位5件に、正解が書かれた資料が入っているか | 入っていない → 検索の問題 |
| 入っているが、順位が低い（4〜5位） | → 並び順の問題（リランキングで改善余地） |
| 入っているのに答えが違う | → 生成の問題 |
| そもそも正解の資料が社内に存在しない | → 資料の問題（AIでは直せない） |
この表を10行埋めるだけで、次に何を触るかが決まります。逆に、ここを埋めずに手を動かすと、ほぼ確実に迷子になります。
最後の行——そもそも書いていない——は、思っているより頻繁に起きます。「AIが答えられない」と報告が上がってきた質問が、実は社内のどこにも明文化されていなかった。この場合、RAGをいくら詰めても答えは出ません。それは仕組みの失敗ではなく、発見です。「この質問には資料がありません」と分かること自体に価値があるので、堂々と報告して大丈夫です。
検索が拾えていないとき（1）チャンク分割を見直す
検索側が原因と分かったら、最初に見るのはチャンク分割です。
チャンクとは、資料を検索できる単位に切り分けた、その一切れのことです。RAGは資料を丸ごと扱わず、小さく切ってから検索します。この切り方が、検索の精度をかなり左右します。
切り方でよくある詰まり
- 短すぎて文脈が切れる
「この機能は管理者のみ利用できます」だけが切り出されても、「この機能」が何なのか分かりません。検索でも当たらないし、当たっても答えに使えない。
- 長すぎて焦点がぼやける
1ページ丸ごとを1チャンクにすると、いろんな話題が混ざります。混ざったものをベクトル（意味を数値化したもの）にすると、どの話題にも中途半端に近い平均的な点になり、結果としてどの質問にもうまく当たらなくなります。
- 構造を無視して機械的に切っている
「500文字ごと」のような固定長で切ると、見出しと本文が分断されたり、表の途中でぶつ切りになったりします。
まず試す設定
絶対の正解はありませんが、日本語の社内文書なら、この辺りから始めると外しにくいです。
- 1チャンク＝300〜800字程度。まずは500字前後で作り、検索結果を見ながら調整する
- チャンク同士を1〜2割ほど重ねる（オーバーラップ）。境目で文脈が切れるのを防げる
- 見出し・セクション単位で切る。固定長より、文書の構造に沿って切るほうが素直に効く
- チャンクの先頭に「どこの何か」を書き添える（文書名／見出しの階層／更新日）
最後のひとつは、地味ですが効きます。たとえばチャンクの頭に
【出典】経費精算規程 v3 > 第4章 交通費 > 4-2 上限額（2026-04-01改訂）と付けておくだけで、検索でも当たりやすくなり、AIが答えるときも「いつ・どの文書の話か」を踏まえてくれます。改訂版と旧版が混在している社内資料では、この一行が効きます。
近年は、チャンクを保存する前にそのチャンクが文書全体の中でどういう位置づけかを一文足しておくやり方（文脈付きチャンク）も広く使われています。「この記述は、経費精算規程のうち交通費の上限を定めた箇所である」といった一文を、AIに生成させて先頭に足しておくイメージです。前処理のコストは増えますが、「それ」「本項」といった指示語だらけの社内文書ではよく効きます。手を出す前に、まずは素直な見出し単位＋出典付与から始めるのがおすすめです。
検索が拾えていないとき（2）ベクトル検索だけに頼らない
チャンクを直しても当たらない場合、次に見るのは検索のやり方です。
RAGの検索は、多くの場合ベクトル検索（意味の近さで探す方法）で作られています。「有給の残りって何日？」と聞くと「年次有給休暇の残日数」の記述を、言葉が違っても意味で拾ってくれる。ここがベクトル検索の強みです。
ただ、この方式には苦手があります。
- 固有名詞・型番・エラーコードに弱い
「E4021のエラー」「TX-300の設定」のような、意味を持たない文字列。ベクトルにすると似た番号同士が近くなってしまい、狙った1件を当てにくい。
- 質問と文書の書き方が違いすぎると当たらない
ユーザーは「経費っていくらまで出る？」と口語で聞き、文書には「旅費交通費の支給限度額は次の通りとする」と硬く書いてある。人間には同じ意味でも、ベクトル上では思ったほど近くならないことがあります。
そこで効くのがハイブリッド検索です。難しい話ではなく、ベクトル検索と、昔ながらのキーワード検索を両方走らせて、結果を混ぜるというだけのものです。
- ベクトル検索 → 言い回しが違っても意味で拾える
- キーワード検索 → 「E4021」「TX-300」のような固有の文字列を確実に拾える
この2つは弱点が噛み合っているので、混ぜると素直に精度が上がります。社内文書のRAGでは、ハイブリッド検索が入っているだけでかなり景色が変わることが多く、最初に検討する価値があります。多くのベクトルDB・検索基盤が標準機能として持っているので、自前で実装しなくて済むことがほとんどです（お使いの基盤のドキュメントで、現時点の対応状況をご確認ください）。
そのうえで、まだ足りなければ次の手があります。
- リランキング：検索で拾った20件ほどを、専用のモデルで「質問への答えらしさ」で並べ直し、上位5件だけをAIに渡す。「正解は入っているが順位が低い」ときの直球の解です。
- クエリの書き換え：ユーザーの短い質問を、AIに検索向きの言葉へ言い換えさせてから検索する。口語と文書語のズレを埋められます。
- 埋め込みモデルの見直し：日本語をきちんと扱えるモデルか確認する。英語中心のモデルでは日本語の精度が落ちることがあります。ここは進化が速い領域なので、採用時点の最新情報を提供元のドキュメントで確認してください。
渡す件数（top-k）も一度は疑う
AIに渡す資料の件数も、地味に効きます。少なすぎれば正解が漏れ、多すぎればノイズに埋もれて、肝心の記述が薄まります。
まず3〜5件あたりで始めて、検索結果を見ながら決めるのが無難です。「増やせば増やすほど良い」ではないことだけ、頭の隅に置いておいてください。
それでも直らないとき：資料そのものを疑う
検索も生成も詰めたのに、どうしても答えが安定しない。そういうときは、AIの外側——資料そのものに原因があることがあります。
- PDFのテキスト抽出が壊れている
とくに表。テキストとして抜き出すと、行と列の対応が崩れてただの数字の羅列になっていることがあります。人間が見れば読める表が、機械には意味不明になっている。実際に抽出後のテキストを一度目で見てみると、驚くことが多いです。
- 新旧の版が両方入っている
改訂前と改訂後の規程が両方インデックスにあり、AIが古いほうを引いてくる。これは検索の性能では防げません。取り込む段階で古い版を外すのが正解です。
- どこにも書かれていない
前述のとおり。これは仕組みの問題ではありません。
RAGの精度は、資料の整い具合を映す鏡のようなところがあります。逆に言えば、RAGを詰めていく作業は、社内のドキュメントの弱点を洗い出す作業でもあります。「AIの精度が上がらない」ではなく「この資料が機械から読めない状態でした」と報告できると、話が前に進みやすくなります。
精度は「感想」ではなく「数」で見る
ここまで直したら、最後にもうひとつだけ。
「なんとなく良くなった気がする」で進めると、次の変更で悪くなったことに気づけません。かといって、本格的な評価基盤をいきなり作る必要もありません。
質問と正解の資料をセットにしたリストを、20〜30件、スプレッドシートで持つ。これで十分に始められます。
| 質問 | 正解が書いてある資料 | 検索で拾えたか | 回答は正しいか |
|---|---|---|---|
| 経費の上限は？ | 経費精算規程 4-2 | ○ | ○ |
| E4021の対処は？ | 障害対応手順書 3-1 | × | × |
変更を入れるたびにこれを流して、○の数を見る。それだけで「良くなった／悪くなった」が言葉ではなく数で言えるようになります。上に説明するときも、「体感で改善しました」より「30問中18問→24問になりました」のほうが、ずっと落ち着いて話ができます。
この数を作っておくと、「精度100%にして」と言われたときにも、「今24/30です。残り6問はこういう性質のもので、うち3問はそもそも社内に資料がありません」と、事実で返せます。期待値の調整は、数字があるといちばん静かに進みます。
明日やること（この順番で）
一度に全部やらなくて大丈夫です。上から順に、今日できるところまでで十分です。
- 失敗した質問を10個集める（現場から上がってきた「答えられなかった」を拾う）
- 検索結果の上位5件をログに出して、目で読む（ここがいちばん大事）
- 「正解が入っていたか」に○×をつける→ 検索の問題か、生成の問題か仕分ける
- 検索の問題なら → チャンク分割（500字前後・見出し単位・出典の一行）を見直す
- それでも当たらなければ → ハイブリッド検索（キーワード検索の併用）を入れる
- 正解は入っているのに順位が低ければ → リランキングを検討する
- 質問と正解のリストを20〜30件作って、変更のたびに流す
3番まで進めば、もう「どこを触ればいいか分からない」状態からは抜けています。
チェックリスト
そのままコピーして、手元のメモやチケットに貼って使ってください。
【切り分け】
- 正解の資料を手で貼れば、AIは正しく答えられるか（＝生成は無事か）
- 失敗した質問について、検索結果の上位5件を実際に目で見たか
- 上位に正解の資料が入っていたか／入っていなかったか、記録したか
- そもそも正解が社内資料に存在するか、確認したか
【チャンク分割】
- 1チャンクは300〜800字程度に収まっているか
- 見出し・セクションの構造に沿って切れているか（固定長のぶつ切りになっていないか）
- チャンク同士に1〜2割の重なりがあるか
- チャンクの先頭に、文書名・見出し・更新日など出典の情報が付いているか
- 指示語（「この機能」「本項」）だけのチャンクになっていないか
【検索】
- ベクトル検索だけになっていないか（キーワード検索を併用しているか）
- 固有名詞・型番・エラーコードで、狙った資料が拾えるか
- AIに渡す件数（top-k）は3〜5件あたりから調整したか
- 埋め込みモデルは日本語を扱えるものか（採用時点の最新情報を確認したか）
【資料】
- PDFから抽出したテキストを、一度目で見て確認したか（とくに表）
- 改訂前の古い版が、インデックスに残っていないか
【評価】
- 質問と正解のセットを20〜30件、リストにしてあるか
- 変更のたびにそれを流して、数で良し悪しを見ているか最後に
RAGの精度が出ないとき、いちばんつらいのは、どこを触ればいいか分からないまま「精度を上げて」と言われることだと思います。触る場所が多すぎて、何をしても手応えがない。あの感じは、本当に消耗します。
でも、検索結果を10問分だけ目で見れば、霧はだいたい晴れます。 「検索が拾えていない」のか「拾えているのに答えを間違えている」のか。それが分かるだけで、触る場所は数分の一に減ります。
デモで動いたRAGが現場で崩れるのは、あなたの設計が甘かったからではありません。社内の資料は、もともと機械に読ませる前提で書かれていないからです。それを機械が読める形に整えていく仕事は、地味ですが、AIの精度以上に長く効きます。
今日はまず、ログを1行足すところから。それだけで、明日の「精度を上げて」は、ずっと答えやすい問いになります。