株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
RAG（Retrieval-Augmented Generation）は、生成AIに自社固有のドキュメントを参照させる技術として、2025〜2026年にかけて多くの企業が導入を進めました。PoC段階では「思っていたより精度が出ない」「期待した回答が返ってこない」という問題が起きることがあります。原因はデータ整備・検索・生成の各段階にあり、モデルの性能も関係します。MicrosoftのRAG評価資料も、検索で必要な情報を取得できたかと、生成した回答が根拠に忠実で十分かを分けて評価しています。本記事では、RAGが失敗する原因を5つのフェーズ（前処理／チャンキング／埋め込み／検索／生成）別に分解し、各フェーズの典型的なハマりどころと改善手法を整理します。
RAGの精度問題は「Garbage In, Garbage Out」の問題
RAG構築の失敗を語るとき、最も重要な原則は「ゴミを入れればゴミが出る」です。モデル選定やプロンプト調整と並んで、データクレンジングの工数も見積もる必要があります。全体に占める割合は文書の品質・量・更新頻度によって変わるため、代表文書を処理し、抽出・補正・確認に要する時間を測定します。LLMが優秀でも、与えられた情報が壊れていれば優秀な回答は出ません。
以下、5フェーズに分けて典型的な失敗パターンと対策を見ていきます。
フェーズ1：前処理（データの取り込みとクレンジング）
失敗パターン1-1：PDFを生のまま投入する
PDFは見た目はテキストですが、実際には複雑な座標情報・複数カラム・表・画像・ヘッダー/フッターが混在する構造です。生のテキスト抽出では、表が崩れ、カラムが順番通りに読まれず、ヘッダーが本文に混入します。これだけで精度が大幅に下がります。
改善策：レイアウト認識ライブラリ（Document Intelligence、unstructured、PyMuPDF等）でレイアウトを保持したまま抽出する。表は表として、見出しは見出しとして構造化してから後段に渡す。
失敗パターン1-2：ノイズ・冗長情報を残したまま投入する
社内Wiki・議事録・古いドラフト・テンプレート文・規程の前文など、検索ノイズになる情報が大量に混入していると、LLMは「正解の文書」と「ノイズ文書」の区別がつきません。
改善策：ドキュメントの種類別に保持/廃棄ルールを決め、メタデータでフィルタできる状態にしてから取り込む。古いドラフトと最新版が混在する状態は最も危険です。
失敗パターン1-3：更新フローが設計されていない
初回投入時には精度が出ても、ドキュメントが更新されない・古い情報が残り続けることで、誤った情報を返し、利用者の信頼を損なうおそれがあります。
改善策：取り込み・更新・削除の自動化フローを最初から設計する。手動運用する場合も、更新量に見合う担当者と確認頻度を決め、処理漏れを監視します。
フェーズ2：チャンキング（文書分割）
失敗パターン2-1：すべてを一律サイズで分割する
「とりあえず500トークンで区切る」こと自体が誤りなのではなく、分割後の文脈を確認せず固定することが問題です。同じドキュメント内でも、章・節・段落・表・コード・FAQの粒度はまちまちで、一律分割は文脈を破壊します。
改善策：構造（見出し階層・段落・表・FAQ）を保持したセマンティックチャンキングを採用する。可能であれば、ドキュメントの種類別にチャンキング戦略を切り替える。
失敗パターン2-2：チャンクの中に複数のトピックが混在する
1つのチャンクに「料金の話」と「導入手順の話」と「サポート体制の話」が混ざると、LLMはどれを根拠にすべきか判断できず、回答が薄くなります。
改善策：チャンクは「1チャンク=1トピック」を原則にする。長いチャンクより、短くて意味が完結したチャンクのほうが検索精度が上がります。
失敗パターン2-3：オーバーラップを設定していない
チャンクの境目で文脈が途切れると、関連情報が複数のチャンクに分断されてしまい、検索時に取りこぼしが発生します。
改善策：Microsoftは固定長分割の開始点として512トークン・25%の重複を例示しています。重複量は文書と用途によって調整し、文脈の欠落・重複取得・処理費用を同じ評価セットで比較します。
フェーズ3：埋め込み（ベクトル化）
失敗パターン3-1：日本語性能を考慮せずに埋め込みモデルを選ぶ
英語データで評価が高い埋め込みモデルが、日本語データで同じ性能を出すとは限りません。日本語の専門用語・略語・カタカナ表記揺れに弱いモデルを選ぶと、検索段階で関連文書を取り逃がします。
改善策：自社のサンプルデータで日本語埋め込みモデルを複数比較してから選定する。OpenAI text-embedding-3-large、Cohere embed-multilingual、日本語特化モデル等の比較が推奨されます。
失敗パターン3-2：メタデータを埋め込み対象に含めない
本文だけをベクトル化し、タイトル・見出し・タグ・更新日・部門等のメタデータを無視すると、検索時の絞り込み力が大きく落ちます。
改善策：本文+タイトル+見出し+タグを組み合わせて埋め込み対象を構成するか、メタデータをハイブリッド検索のフィルタとして活用する。
フェーズ4：検索（リトリーブ）
失敗パターン4-1：ベクトル検索だけに頼る
ベクトル検索は意味的類似度に強い一方、固有名詞・型番・コード・略号などの完全一致では弱い場合があります。「型番A-1234の仕様」のような検索では、ベクトルだけだと類似品の文書を返してしまうことがあります。
改善策：ベクトル検索（意味検索）とキーワード検索（BM25等）を組み合わせたハイブリッド検索を実装する。これがAdvanced RAGの基本です。
失敗パターン4-2：取得件数（top-k）を固定する
top-kを固定すると、本来3件で十分な質問に10件返したり、10件必要な質問に3件しか返せなかったりします。前者はLLMが情報過多で焦点を失い、後者は情報不足で薄い回答になります。
改善策：類似度スコアによる動的な件数調整、または再ランキング（reranker）モデルを併用して上位件数を絞る。
失敗パターン4-3：質問の意図を事前分類しない
「料金が知りたい」「手順が知りたい」「比較したい」「定義を知りたい」では、検索すべきDB・参照すべきドキュメント・回答の出し方がまったく異なります。すべての質問を同じパイプラインに流すと、精度の上限が決まってしまいます。
改善策：Intent-First（意図優先）アーキテクチャを導入し、Routerで質問の意図を分類してからリトリーブを切り替える。これにより検索範囲が劇的に絞られ、精度が向上します。
フェーズ5：生成（LLM呼び出し）
失敗パターン5-1：プロンプトに「根拠を示せ」と書いていない
LLMに「根拠となる文書を引用せよ」「根拠がない場合は『情報なし』と答えよ」と明示しないと、ハルシネーションが量産されます。
改善策：システムプロンプトに、根拠の引用ルール、情報なし時の応答ルール、語尾・文体ルールを明文化する。
失敗パターン5-2：モデルの選定を後回しにする
必要な文書を取得できても、モデルが内容を正確に使えなければ回答品質は上がりません。価格帯だけで判断せず、根拠への忠実度・回答の十分さ・応答時間を実際の質問で比較します。
改善策：本番LLMは、候補モデルを同じ質問・参照文書で評価し、必要な品質と予算を満たすものを選定する。コスト最適化ではキャッシュ・モデルルーティングも比較し、品質が維持されるか再評価する。
RAG精度を継続的に改善する評価サイクル
RAGは「一度作って終わり」ではなく、「評価と改修を繰り返し続けるシステム」です。改善サイクルを回すには、評価データセットと自動評価基盤が必要です。
- 評価データセットの作成：質問・正解回答・正解参照文書のセットを最低50〜100件整備する
- 定量評価指標の選定：Faithfulness（根拠忠実度）、Answer Relevancy（回答関連度）、Context Recall（文脈再現率）等のRAGAS系指標を採用
- 人手評価との併用：定量指標だけでは見えない品質は、人手スコアリングを月次で実施
- 改修サイクルの高速化：1施策につき数日以内で評価結果を出せる体制を作る
RAG構築で押さえておきたい3つの原則
- 前処理に時間を投資する：モデル選定やプロンプトより、データの取り込み・クレンジング・チャンキングに最初の時間を集中させる
- Intent-Firstアーキテクチャを最初から設計に入れる：質問意図のRouter機構をPoC段階から組み込み、後付けにしない
- 評価データセットをPoC初期に作る：精度を主観で判断せず、最初から定量評価できる状態を作る