RAGは「一回検索」では足りない

Last updated at 2026-08-27Posted at 2026-08-27

社内文書をAIへつないだのに、存在しない規則を自信満々に答える。

文書の中には正しい答えがあります。検索も動いている。それでも、質問の言い方が少し変わると別の文書を拾い、例外だけを根拠に結論を作る。最初のデモでは答えられたのに、実際の質問で急に不安定になります。

正直、僕も最初は検索を一回つなげれば、必要な知識を持ち込めたことになると思っていました。

2026年、RAGは社内知識をAIへつなぐ一般的な方法になりました。ただし、RAGを「一回検索して、上位の文書をモデルへ渡す仕組み」と捉えると、検索の失敗がそのまま回答へ流れ込みます。

RAGは、知識を覚えさせず、その場で持ち込む

RAGは、質問に関係する情報を外部から検索し、その情報を入力へ加えて回答させる構成です。モデルそのものへ社内の事実を覚え込ませるわけではありません。

最初に、質問を使って文書を探します。次に、見つけた部分を質問と一緒にモデルへ渡します。最後に、モデルがその根拠を使って回答します。

新しい事実や頻繁に変わる規則は、文書として持ち込むほうが更新しやすく、根拠も追えます。一方、回答形式や口調など、繰り返し必要な振る舞いを固定したい場合は学習が候補になります。

素朴なRAGは、質問を一度検索へかけ、上位の文書を固定件数だけ渡します。質問の言葉と文書の言葉が近く、一つの部分に答えが収まる場合は機能します。

長い文書は、検索できる大きさへ分割します。この単位をチャンクと呼びます。

利用者が「退職」と聞き、文書が「離職」と書いている。製品名ではなく用途で質問する。略称と正式名称が混ざる。一つの検索方法だけでは、言い換えを拾えない場合があります。

検索漏れが怖いと、上位の文書を多く渡したくなります。しかし、不要な文書が増えるほど、モデルが重要な箇所を使いにくくなります。

RAGの最終回答だけを見ると、原因を取り違えます。正しい根拠を取得できていないなら検索の問題です。根拠は取れているのに別の結論を作ったなら生成の問題です。

反復検索の本質は、検索を何度も行うことではありません。得られた根拠が質問へ答えるのに十分かを評価し、不足の理由に応じて次の検索を変えることです。

横断的な質問なら、部品へ分けます。「制度の対象者」と「申請期限」を別々に探し、最後に合わせる。言い換えで外したなら検索語を変える。候補が多すぎるなら再ランクし、根拠として強いものへ絞る。

検索方法を増やすと、候補文書も増えます。そのまま全部をモデルへ渡すと、今度は渡しすぎが起きます。

反復には、時間と費用がかかります。一回で十分な質問まで複雑なループへ通す必要はありません。

僕はそう考えません。最初から複雑にすると、検索、評価、生成のどこが悪いかを分けにくくなります。一回検索でどの質問を外したかがわかってから、必要な戻り道を足すほうがよい。

RAGを業務で使える形へ近づけるには、検索対象を広げる前に、何をもって正しいとするかを決めます。

繰り返し質問され、答えが特定の文書に明記され、更新者がわかる領域が向いています。範囲が狭いほど、検索漏れと回答誤りを区別できます。

同じ内容の文書が複数ある場合、検索は古い版も候補にします。文章が似ているほど、内容の新しさだけで自動的に順位が上がるとは限りません。

20件を試したら、失敗を一枚の表へ残します。症状だけを書くと「回答が違う」が並び、次の手が決まりません。

実際に来る質問を20件ほど集め、正しい回答だけでなく、どの文書のどの部分を根拠にすべきかを記録します。検索結果が期待する根拠を含むか、回答がその根拠から外れていないかを分けて見ます。

冒頭の問いに戻ります。素朴なRAGは最初のデモでは動くのに、なぜ実際の質問で根拠を外すのか。

質問と文書が同じ言葉で、一つのチャンクに答えが収まり、上位の文書だけで十分だという前提に立っているからです。実際には、文書が分かれ、言葉が変わり、不要な文脈へ根拠が埋もれます。

RAGは一回検索では足りません。ただし、最初から何度も検索すればよいわけでもありません。検索結果が足りるかを評価し、不足の理由に応じて問いや手段を変えて戻る。その判断が必要です。

僕なら、狭い文書群と20件の質問から始めます。同じようにRAGを評価している方がいれば、最初にどの失敗分類を置いたか、コメントで知見を交換できるとうれしいです。