社内のマニュアルをRAGに食わせてチャットボットを作った。動いてはいる。でも「それ、うちのことじゃないですよ」みたいな回答が来たり、明らかに関係ない文書を引っ張ってきたりする。
「もっとデータを追加すれば精度が上がるはず」と思って文書を足すが、変わらない。
このパターン、かなりよく見ます。
3層の分類
RAGの回答がズレる理由を整理すると、だいたい3つの層のどれかに落ちます。
①データ粒度の問題 入れている文書の「塊の大きさ」が検索に合っていない。
②検索戦略の問題 どうやって文書を探すか、キーワードなのか意味なのか、その組み合わせ方がチューニングされていない。
③Embedding設計の問題 文書をベクトル化（数値に変換）するときのモード設定や、インデックスの品質が低い。
この3つは原因が別なので、直し方も別になります。「精度が悪い」で一括りにして同じ対処をしても、どれか1層しか改善されない。
①データ粒度の問題
RAGは文書を適切なサイズに分割（チャンキング）して保存し、質問と似た塊を取り出して回答を作ります。
この塊が大きすぎると「なんとなく関係ありそうな文書の一部」が引っかかって、ピントのぼけた回答になります。逆に小さすぎると文脈が切れて、単語は合っていても意味が通らない。
顧客向けの精度改善ガイドを作ったとき、適切なサイズの目安として「500トークン前後、数段落程度」を使っていました。長いマニュアルや規程類は、それより大きい「親の塊」を持ちながら、検索用に小さい「子の塊」に分ける2層構造にするとうまく動きやすいです。
もう一つ厄介なのが、文書そのものの「ノイズ」です。ヘッダー、フッター、ページ番号、目次、画像の代替テキスト。こういうものがそのまま入っていると、関係ない塊が検索で浮上します。入れる前に除去するクリーニングが要ります。
②検索戦略の問題
文書をどう探すかには、大きく2つの方向があります。
キーワード検索: 文字の一致で探す。「スマートフォン」と聞いたら「スマートフォン」という単語が含まれる文書を返す。
セマンティック検索（意味検索）: 言い方が違っても意味が近ければ返す。「スマートフォン」と聞いたら「携帯端末」「モバイル機器」を含む文書も候補に出る。
RAGはセマンティック検索を前提にしていることが多いですが、固有名詞や型番など「文字が一致しないと意味がない」ケースではキーワード検索の方が正確です。
現場で効いたのはハイブリッド、セマンティックとキーワードを混ぜる方法です。どちらに重みを置くかは調整が必要で、7:3くらいから試して変えていくのが実際の感触です。
それと、よく見落とされるのが「質問の前処理」です。
ユーザーが入力した文章をそのままRAGに投げても、うまく動かないことがあります。
たとえば対話型のヒアリングボットを作ったとき、ユーザーが自由に書いた長めの回答をそのままRAG検索に投げると、関係ない文書が引っかかってばかりでした。解決したのは、会話がいまどのフェーズにあるかを判定して、フェーズに合わせた固定クエリでナレッジ検索する設計に変えることでした。ユーザーの入力文をそのまま検索キーには使わない、という切り分けです。
「入力をそのまま検索に使わない」というのは、RAGを実装するときに一番早く気づく詰まり所だと思います。
③Embedding設計の問題
Embeddingは、文書の意味を数値の配列に変換する処理です。この品質が低いと、意味的に似た文書を正確に探せなくなります。
Difyのような構築ツールでは、インデックスモードとして「高品質」と「経済的」の選択があります。精度を上げたいなら「高品質」を選ぶほうが結果が変わりやすいです。そのぶんコストは上がるので、扱う文書量に対して見合うかを見て決めます。
もう一点、Embeddingと検索の「しきい値」があります。これは「どれくらい似ていれば候補として返すか」の設定です。しきい値が低すぎると無関係な文書がたくさん来る、高すぎると何も返ってこない。その両方を調整しながら、使えるラインを見つけるしかありません。
直す順番
3層のうち、どこから手をつけるかは「どの症状が出ているか」で決まります。
| 症状 | まず見る層 |
|---|---|
| 関係ない文書が引っかかる | ①データ粒度（チャンク大きすぎ・ノイズ） |
| 言い方を変えると結果が変わる | ②検索戦略（セマンティック比率の調整） |
| 文書は合ってるのに回答がおかしい | ②または③（クエリ前処理・Embedding品質） |
| 何も返ってこない | ③しきい値 |
精度改善で一番避けたいのは「全部まとめていじる」ことです。何が効いたか分からなくなる。1点変えて、テスト質問10〜20問で確認して、次の1点を変える。この繰り返しが地味ですが一番早いです。
プロンプト設計
RAGはデータと検索だけの話ではありません。「どんな回答を返すか」の指示がシステムプロンプトに書かれていないと、引っ張ってきた文書の内容をそのままコピーするような回答になったり、知らないのに知ってる風な回答を作ったりします。
最低限入れておきたいのは2点です。
「社内文書だけを参照して回答すること。文書に該当する情報がない場合は、その旨をはっきり伝えること」
「回答の形式の例を2〜3個具体的に示す（Few-shot）」
特に後者は効果がはっきり出ます。「この聞き方でこう答えてほしい」という例を入れると、回答の形が安定します。
3層を切り分ける
RAGの精度が上がらないとき、「データが足りない」だけが原因だと思うと、いくら追加しても変わりません。
3層を別々に切り分けて、症状に合わせて一点ずつ直す。それだけです。地味ですが、実際に精度が上がったときはこのパターンでした。