RAGとは｜仕組み・構成要素・精度が出ない原因と改善方法

RAG（Retrieval-Augmented Generation：検索拡張生成）は、質問に関連する社内文書を検索で取り出し、その文書を根拠にLLM（大規模言語モデル）に回答させる仕組みです。構成要素は、文書の取り込みと分割、埋め込みとベクトルDBによる検索、LLMによる回答生成の3つです。精度が出ない原因は、データ品質・チャンク設計・検索・評価の4層のどこかにあることが多く、モデルを替える前にこの4層を順に確かめます。

ChatGPTなどのLLMにそのまま質問しても、社内のマニュアルや過去案件の中身は答えられません。LLMは学習時点の公開情報をもとに文章を作っており、自社の文書を知らないためです。APIでLLMを呼び出すシステムを作るだけでは足りず、自社データを検索してLLMに渡す設計が要ります。

RAGとは：検索した社内文書を根拠にLLMが回答する仕組み

RAGは、ユーザーの質問に対して社内ドキュメントのデータベースから関連する文章を検索（Retrieval）し、その文章をLLMに渡して回答を生成（Generation）させます。LLMは渡された文章の範囲で答えるため、ハルシネーション（AIが事実と異なる内容を作り出すこと）を減らせ、回答に参照元の文書を添えられます。

自社データをLLMに使わせる方法には、RAGのほかにファインチューニング（モデルの追加学習）があります。ファインチューニングはモデル自体に学習させるため、口調や出力形式をそろえる用途に向く一方、文書が更新されるたびに学習し直す手間がかかります。RAGは検索対象の文書を差し替えれば回答に反映でき、出典も示せるため、社内規程やマニュアルのように更新される知識を扱う場面で選ばれます。社内での主な用途は次の4つです。

• 社内規程・就業ルールへの問い合わせ対応
• 製品仕様書・設計マニュアルからの回答
• 過去の見積もり・クレーム対応記録の検索
• 営業資料・提案書の再利用

RAGシステムの構成要素

① ドキュメントの取り込みとチャンキング

PDF・Word・Notionページ・社内WikiなどのドキュメントをテキストにしてRAGシステムに取り込みます。長い文書は「チャンク（意味のある断片）」に分割し、1チャンクは通常200〜800トークン（おおよそ数百文字分）程度が目安です。分割の仕方は検索精度に直結します。

② ベクトル埋め込みとベクトルDB

分割したチャンクを「埋め込みモデル」（文章の意味を数値の並びに変換するAI）でベクトル（意味を表す数値）に変換し、専用のデータベース（ベクトルDB。Pinecone・Weaviate・pgvector等）に保存します。ユーザーの質問もベクトルに変換し、意味が近いチャンクを高速に探します。

③ LLMによる回答生成とプロンプト設計

検索で得た上位のチャンクとユーザーの質問をまとめてLLMに渡し、回答を生成させます。「以下の文書のみを根拠に回答し、記載がなければ分からないと答える」といった制約をプロンプトに書くと、ハルシネーションを抑えられます。

「RAGの精度が出ない」と一言でまとめると、対策が的外れになります。原因は複数の層に分かれているため、どの層に問題があるかを切り分けてから手を打ちます。

① データ品質の問題か

取り込んだ文書が古い・重複している・表記がバラバラ、といった状態では、検索やモデルをどれほど工夫しても正しい回答にたどり着けません。「文書を全部読ませれば賢くなる」という期待が外れる典型で、最初の切り分けはソースデータの棚卸しです。

② チャンク設計の問題か

文書の分割サイズや区切り方が実際の質問の粒度と合っていないと、関連する情報が別々のチャンクに分かれ、検索に引っかからなくなります。対処法は次章の「チャンキング戦略の見直し」にあります。

③ 検索（Retrieval）の問題か

文書もチャンクも適切なのに、検索で関連の薄いチャンクばかり拾うケースです。埋め込みモデルが日本語の文書に合っていない、上位候補を絞り込む再ランキングが入っていない、といった要因がよく見られます。

④ 評価の仕組みがあるか

「なんとなく精度が悪い」という感覚で改善を進めると、どの施策で良くなったのかが分からず、同じ議論を繰り返します。テスト用のQ&Aペアでスコアを定点観測する仕組みがあるかどうかも、切り分けの観点の一つです（評価の方法は末尾のFAQで答えています）。

このうち②と③は、分割の方法や検索の部品を入れ替えて改善を試せる層です。

RAG精度向上のチューニング手法

チャンキング戦略の見直し

文字数で機械的に区切る方法から、見出し・段落・文の境界に沿って区切る「意味的チャンキング」に変えると、検索のヒット率が上がるケースがあります。前後のチャンクを少し重ねる「スライディングウィンドウ」も、文脈の途切れを防ぐ手段です。

埋め込みモデルの選定

日本語の文書を扱う場合は、日本語を含む多言語に対応した埋め込みモデル（multilingual-e5-large等）を選びます。英語向けに作られたモデルで日本語を処理すると、検索精度が落ちます。選ぶ際は、日本語の埋め込みモデルを比べる評価ベンチマーク（JMTEB等）のスコアが参考になります。スコアと自社文書の特性（専門用語の多さ、表や図の比率）を照らし合わせて選びます。

再ランキング（Re-ranking）の導入

ベクトル検索で取得した上位数十件を、「再ランカー」（検索結果を関連度順に並べ直すAI）で並び替えてからLLMに渡す手法です。Cross-Encoderモデル（質問と文章の関連度を精密に測り直すAI。Cohere Rerank・BGE-Reranker等）を使うと、ベクトル検索のみの場合より関連の薄いチャンクを除けます。効果の大きさは文書と質問の性質で変わるため、導入前後のスコアを評価用のQ&Aで比べます。

ローカルLLM導入のメリットとデメリット

• メリット：機密データが社外に出ない・API従量課金がない・モデルや動作環境を自社で調整できる
• デメリット：AI計算用の専用機材（GPUサーバー）の調達費用が高額（数百万〜数千万円）・最先端の大規模AI（フロンティアモデル）より複雑なタスクで精度が劣る・運用負荷が高い

機密要件が高い場合でも、最初はクラウドLLM（OpenAI・Claude等）でPoC（概念実証＝小さく試して効果を確かめる工程）を行い、結果を見てから本番でローカルLLMに切り替える方法があります。GPUへの投資判断を効果の確認後に回せるため、費用の無駄を抑えられます。クラウドとローカルのどちらを選ぶ場合も、情報漏えいや権限管理などのセキュリティ論点は導入前に決めます。決める項目は生成AIのセキュリティ対策｜企業が導入前に決める論点と費用の目安に一覧があります。

RAG導入の進め方と期間の目安

• 初期のPoC（特定ドキュメント1カテゴリ・クラウドLLM）：2〜4週間で効果を検証
• 本番RAGシステム構築（全社マニュアル・クラウドLLM）：1〜2ヶ月
• ローカルLLM環境構築込み（GPUサーバー調達含む）：3〜6ヶ月。機密要件が高い場合の選択肢
• 保守・モデルアップデート対応：継続運用として別途

進め方の例として、従業員80名規模の製造業を想定します。社内に設計マニュアル・クレーム対応記録・仕入れ先の仕様書が約1,200ファイルあり、担当者が必要な情報を探すのに平均30〜40分かかっているとします。設計マニュアルに絞った3週間のPoCで検索時間を平均5分以下に縮められれば、その数字を全社展開の稟議の根拠に使えます。費用は対象範囲・データ量・ローカルかクラウドかで変わります。外注する場合の費用の内訳はRAG構築を外注する費用相場｜内訳と依頼前に確認すべき3つのことにまとめました。

RAG導入で失敗しやすい3つのパターン

• 文書を整えずに全部読み込ませる：散らかった文書をそのまま入れても検索がヒットせず、精度は出ない。精度はまずチャンキングと元データの整備で決まり、最新モデルを使うかどうかはその次
• PoCの結果をそのまま全社に広げる：特定1カテゴリで精度が出ても、対象を全社文書に広げると質問の幅が増えて精度が落ちる。本番の範囲は、カテゴリを1つずつ足しながら評価する
• 作って終わりにする：文書は日々更新される。更新を検知してインデックスを作り直すパイプラインを最初の設計に含めないと、古い回答を返し続け、数ヶ月で誰も使わなくなる

構築済みのRAGを見直すときの確認項目

原因の切り分けは、これから構築する場合に限らず、「外部に構築を依頼したが精度が伸びない」「社内で内製したが使われていない」というケースにも当てはまります。既存のRAGを見直すときも、新規構築と同じ枠組みで棚卸しすると抜けが出ません。

• ドキュメントの状態：古い版や重複が混ざっていないか、更新日が管理されているか
• チャンク設計：区切り方と長さが、よく来る質問の粒度に合っているか
• 検索の構成：日本語に対応した埋め込みモデルか、再ランキングが入っているか
• 評価の仕組み：テスト用のQ&Aと基準スコアがあり、変更のたびに測っているか

まとめ：意思決定者が決める3つのこと

技術的な詳細はエンジニアに任せるとして、意思決定者が決めることは、①最初に取り組む検索業務を1つ選ぶ（担当者が最も時間をかけている業務が候補）、②その業務に絞った2〜4週間のPoCで、検索時間や正答率がどこまで変わったかを測る、③クラウドLLMかローカルLLMかを機密データの扱い方で決める、の3つです。この3つを決めれば、効果の見えない大規模投資を避けながらAI活用を進められます。

PoCで対象にする文書の範囲を決め、検索時間と正答率のどちらで効果を測るかを設計する工程は、awaiが担えます。構築済みのRAGであれば、本文の4項目のうち手つかずの層を洗い出すところから始めます。