Article

RAGの精度を改善する方法|検索できない・誤回答が多い原因と対策

「文書に答えが書かれているのに検索できない」

「質問と関係のない資料を参照してしまう」

「回答の一部は正しいが、重要な条件が抜けている」

「RAGを構築したものの、実務で使える精度にならない」

このような問題は、生成AIのモデルを変更するだけでは解決できない場合があります。

RAGの精度は、元となる文書、テキスト抽出、チャンク分割、検索方式、プロンプト、評価方法など、複数の要素によって決まるためです。

特に重要なのは、RAGの問題を「検索精度」と「回答精度」に分けて確認することです。

必要な文書を検索できていない状態では、どれだけ高性能な生成AIを使っても正確な回答は作れません。

この記事では、RAGの精度が低くなる原因と、検索できない場合や誤回答が多い場合の改善方法を解説します。

RAGの精度とは

RAGとは、質問に関連する文書を検索し、その内容をもとに生成AIが回答する仕組みです。

一般的なRAGは、次の流れで動作します。

ユーザーが質問する
↓
質問に関連する文書を検索する
↓
検索した文書を生成AIへ渡す
↓
生成AIが回答を作成する
↓
回答と参照元を表示する

この流れの中で、RAGの精度は大きく次の2つに分けられます。

  • 検索精度
  • 回答精度

RAGの検索精度

検索精度とは、ユーザーの質問に対して、必要な文書や文章を取得できているかを示します。

例えば、就業規則に申請期限が書かれているにもかかわらず、別の規程を検索してしまう場合は、検索精度に問題があります。

検索精度には、次の要素が関係します。

  • 登録されている文書
  • テキスト抽出の品質
  • チャンク分割
  • Embeddingモデル
  • ベクトル検索
  • キーワード検索
  • メタデータ
  • 検索件数
  • 類似度の基準
  • リランキング

RAGの回答精度

回答精度とは、検索した文書をもとに、生成AIが正しい回答を作れているかを示します。

必要な文書を取得できていても、生成AIが内容を誤って解釈したり、重要な条件を省略したりすることがあります。

回答精度には、次の要素が関係します。

  • 利用する生成AIモデル
  • プロンプト
  • 検索結果の渡し方
  • 検索結果の量
  • 回答形式
  • 情報がない場合の処理
  • 会話履歴
  • 出力文字数
  • 回答根拠の表示方法

RAGの精度を改善する際は、検索結果と最終回答を別々に確認することが重要です。

RAGの精度が低い症状と原因

発生している症状主な原因
必要な文書が検索結果にない文書未登録、抽出失敗、チャンク分割、検索方式
関係のない文書が多く表示される検索件数、類似度、Embedding、メタデータ
正しい文書を取得しているが回答が違うプロンプト、生成AIモデル、文書の渡し方
文書にない情報を回答する回答ルール、検索結果不足、ハルシネーション
古い情報を回答する旧文書の混在、更新処理、バージョン管理
回答の条件や例外が抜けるチャンクが小さい、関連文書不足
同じ質問でも回答が変わる生成設定、曖昧な質問、複数文書の矛盾
型番やエラーコードを検索できないベクトル検索だけを使用している

最初に、どの症状が発生しているかを整理し、原因となる工程を切り分けます。

RAGの精度が低くなる主な原因

登録している文書の品質が低い

RAGは、登録した文書を根拠に回答します。

そのため、元の文書に問題があると、検索や回答も不安定になります。

例えば、次のような状態です。

  • 古い規程と新しい規程が混在している
  • 同じ内容のファイルが複数登録されている
  • 文書内に誤った情報がある
  • 正式なルールが文書化されていない
  • ファイル名や見出しが分かりにくい
  • 更新日やバージョンが記録されていない
  • 部署によって異なるルールが一つにまとめられている

RAGは、社内に存在しない情報を自動的に補完する仕組みではありません。

検索技術を調整する前に、回答に必要な情報が正しく文書化されているか確認します。

PDFから正しくテキストを取得できていない

PDFをRAGへ登録できていても、内容を正しく読み取れているとは限りません。

特に、次のような文書ではテキスト抽出に失敗することがあります。

  • 紙をスキャンしたPDF
  • 表を多く含む資料
  • 画像中心のマニュアル
  • 複数段で構成された文書
  • 縦書きの資料
  • ヘッダーやフッターが繰り返される文書
  • 特殊なフォントを使用している文書
  • 図と文章を組み合わせて説明している資料

例えば、料金表の行と列が崩れた状態で登録されると、商品名と金額の組み合わせを正しく回答できません。

RAGの精度を確認するときは、元ファイルだけでなく、実際に抽出・登録されたテキストも確認する必要があります。

チャンクが大きすぎる

チャンクとは、検索のために文書を分割した文章の単位です。

チャンクが大きすぎると、質問に関係のない情報まで一緒に検索されます。

例えば、50ページのマニュアルを一つのチャンクとして登録すると、特定の操作方法を探したい場合でも、関係のない説明が大量に含まれます。

その結果、生成AIが重要な情報を判断しにくくなります。

チャンクが小さすぎる

チャンクが小さすぎる場合も精度が低下します。

例えば、社内規程を一文ずつ分割すると、申請期限は取得できても、対象者や例外条件が別のチャンクに分かれる可能性があります。

次のような情報は、ある程度まとまった単位で取得する必要があります。

  • 申請条件と申請期限
  • 操作手順と注意事項
  • エラーの原因と解決方法
  • 契約条件と例外
  • 商品仕様と利用条件
  • 質問と回答

単純な文字数だけで分割せず、見出しや段落などの文書構造を考慮します。

ベクトル検索だけを使用している

ベクトル検索は、質問と意味が近い文章を検索する方法です。

自然な文章による質問には向いていますが、すべての情報を正確に検索できるわけではありません。

特に、次のような情報はキーワード検索の方が適しています。

  • 商品型番
  • エラーコード
  • 契約番号
  • 管理番号
  • 法令や規程の条文番号
  • 人名
  • 部署名
  • 固有のシステム名
  • 数字や日付

例えば「エラーコードE101」と質問した場合、意味が似ている文書よりも、E101という文字列が含まれる文書を優先する必要があります。

このような場合は、ベクトル検索とキーワード検索を組み合わせます。

検索結果の件数が多すぎる

検索結果を多く取得すれば、回答精度が上がるとは限りません。

関連度の低い文書まで生成AIへ渡すと、どの情報を優先すべきか判断しにくくなります。

例えば、質問に関連する上位3件だけで回答できるにもかかわらず、20件の文書を渡すと、古い情報や関係のない情報が混ざる可能性があります。

取得件数は固定せず、実際の質問を使って調整します。

類似した文書が大量に登録されている

同じ内容の文書が複数登録されていると、検索結果が似た文書で埋まります。

例えば、次のような状態です。

経費精算規程_2024.pdf
経費精算規程_2025.pdf
経費精算規程_最新版.pdf
経費精算規程_修正版.pdf
経費精算規程_確定版.pdf

どれが正式な最新版か判断できない状態では、RAGも正しい文書を選べません。

古い文書を削除できない場合は、更新日、バージョン、有効期限などを付与し、検索時に最新版を優先します。

プロンプトで推測を禁止していない

生成AIは、検索した文書だけで回答できない場合でも、一般知識や推測を使って文章を補うことがあります。

業務用のRAGでは、次のようなルールを設定します。

  • 検索結果に含まれる情報だけで回答する
  • 情報がない場合は推測しない
  • 回答できない場合は担当部署を案内する
  • 回答と一緒に参照元を表示する
  • 複数文書で内容が異なる場合は違いを示す
  • 日付や数値を省略しない
  • 重要な判断は原文の確認を促す

ただし、プロンプトだけですべての問題を解決することはできません。

検索結果に正しい情報が含まれていることが前提です。

RAGの精度を改善する方法

1.検索対象の文書を整理する

最初に、検索対象となる文書を整理します。

確認する項目は次のとおりです。

  • 最新版の文書か
  • 古い文書が混在していないか
  • 内容が重複していないか
  • 正式な文書か
  • 管理部署が明確か
  • 更新日が記録されているか
  • 有効期限が設定されているか
  • 回答に必要な情報が含まれているか
  • 閲覧権限が正しいか

検索精度を上げるには、検索技術よりも文書整理の方が効果的な場合があります。

不要な文書を大量に登録するのではなく、対象業務に必要な文書だけから始めます。

2.抽出されたテキストを確認する

PDFやWordを登録した後は、検索データとして保存されたテキストを確認します。

次の問題がないか確認してください。

  • 文字化け
  • 文章の順序が不自然
  • 表の行と列が崩れている
  • ページ番号が本文に混ざっている
  • ヘッダーやフッターが重複している
  • 画像内の文字を取得できていない
  • 改行が多すぎる
  • 見出しと本文の関係が失われている

スキャンPDFでは、OCRによる文字認識が必要です。

表や画像が重要な文書では、単純なテキスト抽出ではなく、文書解析や画像認識を組み合わせることも検討します。

3.文書の構造に合わせてチャンク分割する

すべての文書を同じ文字数で分割するのではなく、文書の種類に合わせて分割します。

文書の種類分割単位の例
業務マニュアル見出し、操作手順
社内規程条文、項目
FAQ質問と回答
議事録議題
製品資料製品、機能
障害報告書事象、原因、対応策
契約書条項
提案書課題、提案内容、導入効果

チャンクの境界付近にある情報を失わないように、一部を重複させる方法もあります。

ただし、重複を増やしすぎると、似た検索結果が大量に返されます。

複数の設定を比較し、実際の質問で評価します。

4.チャンクに見出し情報を含める

本文だけをチャンクとして保存すると、どの章に書かれていた情報か分からなくなる場合があります。

例えば、次のような形で見出しを含めます。

文書名:経費精算規程

第3章:交通費

第2条:申請期限

交通費の申請は、利用日の翌月5日までに行うものとする。

見出し、文書名、章、項目名を含めることで、短い文章でも意味を判断しやすくなります。

5.メタデータを付与する

文書本文とは別に、検索条件として利用できる情報を付与します。

代表的なメタデータは次のとおりです。

  • 文書タイトル
  • 文書カテゴリ
  • 部署
  • 製品名
  • 公開日
  • 更新日
  • バージョン
  • 有効期限
  • 対象年度
  • 文書の種類
  • 閲覧権限
  • プロジェクト名

メタデータを利用すると、次のような検索ができます。

2026年度の規程だけを検索する

製品Aのマニュアルだけを検索する

営業部が閲覧できる資料だけを検索する

有効期限内の文書だけを検索する

意味の近さだけで検索するよりも、業務上の条件を反映しやすくなります。

6.ベクトル検索とキーワード検索を組み合わせる

ベクトル検索とキーワード検索には、それぞれ異なる特徴があります。

検索方法得意な検索
ベクトル検索意味が近い文章、自然な質問、言い換え
キーワード検索型番、固有名詞、エラーコード、数字
メタデータ検索部署、年度、カテゴリ、権限
ハイブリッド検索意味と文字列の両方が重要な検索

複数の検索方法を組み合わせる仕組みを、ハイブリッド検索と呼びます。

例えば、次の質問を考えます。

製品AでE101が表示された場合の対応方法を教えてください

この場合は、次の条件を組み合わせます。

  • 「対応方法」という意味をベクトル検索する
  • 「製品A」と「E101」をキーワード検索する
  • 製品カテゴリをメタデータで絞り込む

業務文書では、ベクトル検索だけよりも安定しやすい構成です。

7.検索前に質問を整形する

ユーザーの質問が短すぎたり、曖昧だったりすると、適切な文書を検索できません。

例えば、次の質問だけでは情報が不足しています。

申請はいつまで?

どの申請について質問しているか分からないためです。

会話履歴や入力内容を利用し、検索用の質問へ変換します。

元の質問:
申請はいつまで?

検索用の質問:
国内出張の交通費精算は、利用日からいつまでに申請する必要があるか

検索前の質問整形は、クエリリライトとも呼ばれます。

略語を正式名称へ変換したり、会話の文脈を補ったりする処理も有効です。

8.検索結果の件数を調整する

検索結果として取得する件数は、質問の内容によって適切な数が異なります。

件数が少なすぎると、必要な情報が不足します。

件数が多すぎると、関係のない情報が混ざります。

例えば、次のように検証します。

取得件数確認する内容
3件必要な情報が不足しないか
5件回答に必要な条件が揃うか
10件関係のない情報が増えないか

固定値だけでなく、検索結果の類似度が一定以下の場合は除外する方法もあります。

関連度の低い文書を無理に生成AIへ渡さないことが重要です。

9.リランキングを利用する

リランキングとは、最初に取得した検索結果を、質問との関連性に基づいて並べ替える処理です。

一般的には、次の流れになります。

ベクトル検索などで候補を20件取得
↓
質問との関連性を詳しく評価
↓
関連性の高い上位5件を選択
↓
生成AIへ渡す

最初の検索は高速ですが、意味が似ているだけの文書が含まれることがあります。

リランキングを利用すると、質問への回答に直接関係する文書を上位へ移動できます。

ただし、処理時間や利用料金が増える可能性があるため、必要な業務に限定して使用します。

10.回答用プロンプトを改善する

検索結果が正しい場合は、生成AIへの指示を調整します。

例えば、次のようなルールを設定します。

提供された参考情報だけを使用して回答してください。

参考情報に答えがない場合は、推測せず「確認できません」と回答してください。

日付、金額、対象者、例外条件を省略しないでください。

回答の最後に参照した文書名を表示してください。

複数の文書で内容が異なる場合は、違いを明示してください。

回答形式も指定できます。

結論

対象者

申請期限

必要な手続き

注意点

参照元

業務に合った形式を指定することで、重要な条件の抜けを減らせます。

11.回答できない場合の処理を設計する

RAGの精度改善では、正しい回答を増やすだけでなく、答えがないときに回答しないことも重要です。

例えば、次の場合は回答を控えます。

  • 関連する文書が取得できない
  • 検索結果の関連度が低い
  • 複数文書の内容が矛盾している
  • 質問が曖昧
  • 利用者に閲覧権限がない
  • 重要な判断を伴う
  • 文書の有効期限が切れている

回答できない場合は、次の動作へつなげます。

  • 追加の質問をする
  • 担当部署を案内する
  • 問い合わせフォームを表示する
  • 有人対応へ引き継ぐ
  • 原文の確認を促す
  • 関連資料だけを表示する

無理に回答を生成するよりも、安全な運用につながります。

RAGの精度を評価する方法

RAGの精度改善には、評価用の質問と正解データが必要です。

目視で数件を確認するだけでは、変更前後の精度を比較できません。

評価データを作成する

実際の業務で使われる質問を収集し、次の情報を整理します。

評価項目内容
質問利用者が入力する質問
正解期待する回答
参照文書回答の根拠となる文書
参照箇所ページ、章、条項
必須要素回答に含める条件
禁止事項回答してはいけない内容
回答可否回答するべきか、拒否するべきか

例えば、次のように作成します。

質問:
交通費の申請期限はいつですか?

期待する回答:
利用日の翌月5日まで

参照文書:
経費精算規程

必須要素:
期限、対象となる交通費

禁止事項:
文書にない例外を追加しない

検索精度を評価する

検索精度では、回答に必要な文書を取得できているか確認します。

主な評価項目は次のとおりです。

  • 正解文書が検索結果に含まれているか
  • 正解文書が何番目に表示されているか
  • 関係のない文書が多くないか
  • 最新版を取得できているか
  • 閲覧権限外の文書が含まれていないか

最終回答だけを見るのではなく、検索結果そのものを記録します。

回答精度を評価する

回答精度では、生成された内容を確認します。

主な評価項目は次のとおりです。

  • 結論が正しいか
  • 文書の内容と一致しているか
  • 必要な条件を含んでいるか
  • 数字や日付が正しいか
  • 文書にない情報を追加していないか
  • 参照元が正しいか
  • 読みやすいか
  • 回答できない質問を拒否できているか

自動評価だけでなく、業務を理解している担当者による確認も必要です。

評価用の質問を分類する

正常な質問だけでなく、さまざまなパターンを用意します。

  • 答えが一つの質問
  • 複数文書を参照する質問
  • 言い換えた質問
  • 略語を含む質問
  • 型番やエラーコードを含む質問
  • 曖昧な質問
  • 文書に答えがない質問
  • 古い情報を尋ねる質問
  • 閲覧権限外の質問
  • 誤った前提を含む質問

このような質問を使うことで、本番運用に近い状態を確認できます。

RAGの精度改善を進める手順

1.問題のある質問を収集する

最初に、正しく回答できなかった質問を集めます。

質問だけでなく、次の情報も記録します。

  • 入力された質問
  • 検索された文書
  • 文書の順位
  • 生成された回答
  • 期待する回答
  • 問題の内容
  • 利用したモデル
  • プロンプト
  • 検索設定

2.検索と回答を切り分ける

正解文書が検索結果に含まれているか確認します。

含まれていない場合は検索側の問題です。

正解文書が含まれているのに回答が間違っている場合は、回答生成側を確認します。

3.一つずつ条件を変更する

複数の設定を同時に変更すると、どの変更が効果を出したか分からなくなります。

例えば、次の順番で検証します。

文書の整理
↓
テキスト抽出
↓
チャンク分割
↓
検索方式
↓
取得件数
↓
リランキング
↓
プロンプト
↓
生成AIモデル

変更前後で同じ評価用質問を実行し、結果を比較します。

4.本番の質問履歴を分析する

導入後は、利用者が実際に入力した質問を確認します。

次のような問題が見つかることがあります。

  • 想定していなかった言い回し
  • 社内独自の略語
  • 文書化されていない業務ルール
  • よく検索されるが回答できない内容
  • 更新されていない資料
  • 質問が集中している業務

質問履歴は、RAGの改善だけでなく、社内文書の不足や業務課題を発見する材料にもなります。

RAGの精度改善で避けたい対応

高性能な生成AIへ変更するだけ

検索結果が間違っている状態では、高性能な生成AIへ変更しても根本的な解決にはなりません。

モデル変更の前に、正しい文書を取得できているか確認します。

文書をすべて登録する

文書量を増やせば精度が上がるとは限りません。

古い資料、重複資料、関係のない資料が増えると、検索精度が下がる可能性があります。

対象業務に必要な文書だけから始めます。

チャンクサイズを一律に設定する

マニュアル、規程、FAQ、議事録では、適切な分割単位が異なります。

すべての文書を同じ文字数で分割するのではなく、文書構造に合わせます。

プロンプトだけを繰り返し変更する

プロンプトは重要ですが、検索結果に正しい情報が含まれていなければ回答できません。

検索精度と回答精度を分けて改善します。

数件の質問だけで判断する

特定の質問にだけ最適化すると、別の質問への精度が下がる可能性があります。

複数の業務パターンを含む評価データを用意します。

RAGの精度改善が必要になるタイミング

次のような状態になった場合は、RAGの見直しが必要です。

  • 誤回答の報告が増えた
  • 新しい文書を追加してから精度が下がった
  • 古い情報を回答する
  • 利用部署が増えた
  • 対象文書の種類が増えた
  • 検索速度が遅くなった
  • 閲覧権限の要件が変わった
  • 生成AIモデルを変更した
  • 文書管理方法が変わった
  • 利用者が期待する回答形式が変わった

RAGは、一度構築して終わりではありません。

文書、業務、利用者の変化に合わせて継続的に改善する必要があります。

RAGの精度改善に関するよくある質問

RAGを導入すればハルシネーションはなくなりますか?

完全にはなくなりません。

RAGを利用すると、検索した文書を根拠に回答できますが、生成AIが情報を誤って解釈したり、文書にない内容を補ったりする可能性は残ります。

回答根拠の表示、回答できない場合の処理、人による確認を組み合わせます。

チャンクサイズはどのくらいがよいですか?

すべての文書に共通する正解はありません。

文書の種類、質問の内容、利用するモデルによって適切な大きさが異なります。

文字数だけで決めず、見出し、段落、条項、質問と回答などの意味のまとまりを優先します。

Embeddingモデルを変えれば精度は上がりますか?

改善する可能性はありますが、必ず上がるとは限りません。

元文書、テキスト抽出、チャンク分割、検索方式に問題がある場合は、Embeddingモデルだけを変更しても十分な効果が出ないことがあります。

高性能な生成AIモデルを使うべきですか?

複雑な文章の理解や複数文書の整理には、高性能なモデルが有効な場合があります。

一方、単純なFAQ回答では、小型モデルでも対応できる可能性があります。

精度、応答速度、利用料金を比較して選びます。

検索結果は何件取得すればよいですか?

質問と文書によって異なります。

最初は3件、5件、10件など複数の条件を比較し、必要な情報が揃う最小の件数を探します。

RAGの精度は何%あれば実用化できますか?

業務の重要度によって異なります。

社内の参考情報を探す用途と、契約や医療など重要な判断に使う用途では、求められる基準が違います。

正答率だけでなく、誤回答した場合の影響や、人による確認工程を含めて判断します。

文書が増えると精度は下がりますか?

適切に管理されていれば、必ずしも下がるわけではありません。

ただし、古い文書、重複文書、関係のない文書が増えると、必要な情報を見つけにくくなります。

文書の追加と同時に、分類、更新日、バージョン、閲覧権限を管理します。

hiro-dev-labのRAG構築・精度改善支援

hiro-dev-labでは、社内文書やマニュアルを活用したRAGシステムの構築・改善を支援しています。

主な対応内容は次のとおりです。

  • RAGのPoC構築
  • 社内文書のAI検索
  • PDF・Word・Excelのデータ取り込み
  • 文書のチャンク分割
  • Embeddingとベクトル検索
  • キーワード検索との組み合わせ
  • メタデータ検索
  • リランキング
  • プロンプト設計
  • 回答根拠の表示
  • 誤回答の分析
  • 評価データの作成
  • 既存システムへのRAG組み込み
  • Difyを利用したRAG構築
  • APIを利用した独自開発

RAGの精度が低い場合は、生成AIモデルだけでなく、文書、検索、回答生成、運用の流れを確認します。

新規構築だけでなく、すでに作成したRAGの精度改善についても相談できます。

RAGの検索精度と回答精度を分けて改善する

RAGの精度が低い場合は、最初に検索結果を確認します。

必要な文書を取得できていなければ、文書整理、テキスト抽出、チャンク分割、検索方式を見直します。

正しい文書を取得できているにもかかわらず回答が間違っている場合は、プロンプト、検索結果の渡し方、生成AIモデルを確認します。

RAGの精度改善で重要なポイントは次のとおりです。

  • 検索精度と回答精度を分ける
  • 登録文書を整理する
  • 抽出されたテキストを確認する
  • 文書構造に合わせてチャンク分割する
  • メタデータを付与する
  • ベクトル検索とキーワード検索を組み合わせる
  • 検索結果の件数を調整する
  • リランキングを検討する
  • 情報がない場合は回答させない
  • 評価用の質問と正解を用意する
  • 本番の質問履歴から継続的に改善する

RAGは、文書を登録して生成AIへ接続するだけで完成する仕組みではありません。

実際の業務で使われる質問をもとに評価し、問題の原因を切り分けながら改善することが重要です。

「RAGを構築したが、必要な文書を検索できない」

「誤回答が多く、本番導入できない」

「チャンク分割や検索方式が適切か確認したい」

「既存のRAGシステムを改善したい」

このような段階からでも、お気軽にお問い合わせください。

RAG構築・社内文書AI検索について相談する

Contact

お問い合わせ

業務委託での開発支援、Webアプリケーション開発、AI導入などのご相談を受け付けています。

技術だけでなく、使う方や運用する方の立場を考え、分かりやすく丁寧に進めることを大切にしています。

まずはお気軽にお問い合わせください。