RAGの精度の低さに悩む企業へ

「うちもRAGを試してみたけど…思ったほどじゃなかったんだよね。」

最近、AI導入を検討する企業の会議室でよく耳にする言葉だ。LLMが初めて登場したとき、多くの企業はRAG（Retrieval-Augmented Generation）を魔法のような解決策だと考えた。社内文書をベクトルDBに入れて、質問が来たら関連文書を取り出してLLMに渡せばいい。コンセプトはシンプルで、デモは印象的だ。だからPoCを作る。経営陣が感嘆する。予算がつく。ところが実際に運用に乗せた瞬間、問題が始まる。精度が期待に届かず、ユーザーは一人また一人とシステムから離れていく。

この現象は一社だけの話ではない。世界中で同時に起きていることだ。

バラ色の期待と冷酷な現実の間

まず数字を見よう。

MIT NANDAイニシアチブが2025年に発表した「GenAI Divide: State of AI in Business」レポートは衝撃的だ。企業のGenAIパイロットプロジェクトの95%が、測定可能なビジネス成果を出せていない。 150名の経営幹部へのインタビュー、350名の従業員へのアンケート、300件の公開AI導入事例を分析した結果だ。レポートは失敗の核心的な原因として「データ準備の不備とRAGパイプライン統合の不十分さ」を明示的に指摘した。

Gartnerは2024年7月に警告を発した。2025年末までにGenAIプロジェクトの30%がPoC段階で破棄されると。理由は、データ品質の低さ、不十分なリスク管理、コスト増大、不明確なビジネス価値だ。2025年2月にはさらに強い予測を追加した。AI対応が整っていないデータを持つAIプロジェクトの60%が2026年までに破棄されると。Gartnerが248名のデータ管理リーダーを調査した結果、63%の組織がAIのための適切なデータ管理体制を整えていない、あるいは整えているかどうかすら分からないと回答した。RAGの前提条件である「きちんと整理されたデータ」が大多数の企業に存在しないということだ。

NTT DATAの2024年グローバルGenAIレポートはさらに直接的だ。GenAI導入の70〜85%が目標ROIを達成できていない。 S&P Global Market Intelligenceが1,000社以上を調査した結果、AI施策の大半を破棄した企業の割合が2024年の17%から2025年には42%へ急増した。2年も経たないうちに2.5倍に膨れ上がったのだ。

McKinseyの2025年AI現況レポートは別の側面を示している。**AIを1つ以上のビジネス機能で使用している組織は78%に上る。しかしAIが企業のEBITに測定可能な影響を与えたと回答した割合はわずか39%**にとどまる。それもほとんどがEBITの5%未満だ。PoCは溢れていたが、実質的な成果は稀だ。

RAGシステムに絞っても結果は同様だ。複数の業界分析によると、エンタープライズRAGシステムの73%はプロダクションで期待した成果を出せていない。 最初の1年以内に失敗する割合は72%に達する。エンタープライズユーザーが求める98%以上の精度に到達するには、90%から出発しても数か月の専任エンジニアリングが必要だ。

世界中の企業が直面している具体的な事例

法律AI：「ハルシネーションなし」という約束が崩壊する

Thomson ReutersのWestlaw AI-Assisted ResearchとLexisNexisのLexis+ AIは、いずれもRAG技術を基盤に「ハルシネーションフリー（hallucination-free）」なAIだと積極的にマーケティングしていた。検索ベースだから正確だという論理だった。

スタンフォード大学のRegLabとHAI研究チームが2024年、この主張を事前登録済みの実証研究で検証した。結果は惨憺たるものだった。

Westlaw AI-Assisted Research: 精度 42%、ハルシネーション率 33%
Lexis+ AI: 精度 65%、ハルシネーション率 17%
汎用LLM（ChatGPT、Llama、Claude）: 法律クエリのハルシネーション率 58〜80%

RAGがハルシネーションを減らしたのは事実だ。しかしマーケティングが主張した「ハルシネーションなし」とはほど遠かった。スタンフォードの研究チームは論文タイトルに「Hallucination-Free?」とクエスチョンマークを付けた。さらに深刻な発見もあった。RAGは検索された文書が実際には質問に答えていない場合でも、モデルが「分かりません」と言う代わりに、むしろ自信を持って間違った答えを生成してしまうということだ。検索された文書が存在するという事実自体が、モデルの確信度を引き上げてしまうのだ。Googleの研究チームも同じ現象を「不十分なコンテキスト（insufficient context）」問題として整理した。

DoNotPayというスタートアップの事例はさらに極端だ。「世界初のロボット弁護士」を自称し、AIが完璧な法的文書を生成し、弁護士なしで訴訟を支援できると主張した。FTCは2025年2月に最終制裁を下した。同社は実際に自社AIが人間の弁護士レベルで機能するかどうかテストしたことすらなく、連邦・州の法律データベースを基に訓練もしていなかった。19万3千ドルの制裁金とともに、AI弁護士関連のマーケティングが禁止された。

カスタマーサービス：Klarnaの教訓

スウェーデンのフィンテック企業Klarnaの話は、AI過信の教科書的事例となった。

2024年初頭、CEOのSebastian Siemiatkowskiは自社のAIチャットボットが700名のフルタイムオペレーターに相当する業務を処理していると発表した。「AIはすでに人間がやっていることすべてをこなせる」という発言もあった。メディアはこれをAI革命の狼煙として報じた。

1年も経たないうちに、同社は人間のオペレーターの採用を再開した。CEOは自ら認めた。

「コスト削減があまりにも支配的な評価基準になってしまい、結局品質が低下しました。私たちはやりすぎました。」

文書化された問題の数々：単純なFAQ質問でも最大20秒の応答遅延、ブランドボイスとかけ離れた汎用的な回答（「混乱させてしまい申し訳ございません」）、複雑な問題や感情的な顧客対応の処理不能。チャットボットの行き着く先は結局、人間のオペレーターへの引き継ぎだった。コスト削減はなく、顧客体験だけが悪化した。

航空会社：誤った回答が法的責任に

カナダのAir CanadaのAIチャットボットは、顧客Jake Moffattに対し、フライト搭乗後でも遺族割引運賃の遡及適用を受けられると案内した。実際のポリシーとは正反対だった。Air Canadaは法廷で「チャットボットは別個の法的主体である」と主張した。BC州民事調停委員会はこれを「驚くべき主張」として退け、Air Canadaに法的責任を課した。

この事件はAIチャットボットの責任に関する代表的な判例となった。チャットボットが誤った情報を伝えても、企業が全面的に責任を負う。

企業の社内ナレッジ管理：断念した企業たちの話

RAGベースのドキュメントアシスタントをCloudflare、Stripeなど200社以上のテック企業に提供しているkapa.aiが、顧客企業の分析を公開した。

大手通信事業者: 1年半かけてAIドキュメントアシスタントを開発し、完全に断念
エンタープライズソフトウェア企業: 6か月投資した後、ハルシネーション率を7%以下に下げられず破棄（社内基準未達）
Fortune 500テック企業: エンジニア1名がパートタイムで管理、1年放置後にドキュメントの変更によりシステムが自然劣化

kapa.aiの核心的な結論：社内でRAGナレッジベースを構築した企業の大半が6〜18か月以内に破棄もしくは置き換えている。90%の精度からエンタープライズが求める98%以上まで引き上げるには数か月の専任エンジニアリングが必要だ。しかしほとんどのチームはこの現実を事前に知らない。

Microsoft SharePointをナレッジソースとして使用するCopilot Studioも同様の問題を抱えている。Microsoftの公式Q&Aフォーラムには「一貫して低品質な応答」「クエリに直接対応しない不正確な回答」などの不満が蓄積している。原因はURLの深度制限、コンテンツフィルターによる必要な内容の除去、権限設定の不一致による検索エラーだ。

医療・ヘルスケア：命に直結する精度

2024年のMayo Clinicの研究は、ChatGPT、Microsoft Bing Chat、Google Bardが腎疾患の臨床質問に対して40%未満の精度を示すという結果を発表した。米国の43の主要医療システムを調査した結果、77%が未成熟なAIツールを導入の最大障壁として挙げた。ECRI Instituteの2026年医療技術リスクレポートは、医療現場でのAIチャットボットの誤用を今年の患者安全リスク第1位に指定した。

Mount Sinaiの2025年の研究はさらに深刻な問題を指摘した。RAGベースのシステムに誤った医学情報を含む文書が入力されると、システムはその誤情報を訂正するのではなく、むしろ確信を持って増幅させてしまうということだ。

金融サービス：たった一つのエラーも許されない環境

Goldman Sachsは2024年6月、「Gen AI: Too Much Spend, Too Little Benefit?」というタイトルのレポートを発刊した。チーフ・エクイティ・リサーチ・アナリストのJim Covelloはこう書いた。

「AI技術はあまりにも高価だ。コストを正当化するには、この技術が複雑な問題を解決できなければならないが、そのようには設計されていない。」

金融規制コンプライアンス領域でのRAGハルシネーションは、単なる不便さではない。コンプライアンスチャットボットが「当該取引タイプにはAML報告義務なし」と誤って案内したり、市場分析ツールが存在しないプレスリリースを根拠に特定の銀行が業績未達だったと報告したりすることは、法的リスクに直結する。金融安定理事会（FSB）、米国GAO、FINOSのいずれもが、RAGハルシネーションが金融サービスに与える具体的なリスクを公式警告として発表している。

「じゃあ文書全体をコンテキストに入れればいいんじゃない？」

RAGの精度問題に直面した一部の企業が選ぶ代替手段がある。Geminiの1Mトークン、Claudeの200Kトークンのように、Large Context Windowモデルに文書全体を投入する方法だ。検索そのものをなくしてしまおうという発想だ。概念的には魅力的だ。

しかしコストが問題だ。

現実的なコスト計算

CopilotKitの分析によると、同じ質問に対して：

Large Context方式（文書全体をコンテキストに）：クエリあたり約 $3.00
RAG方式（関連チャンクのみ）：クエリあたり約 $0.03
コスト差：100倍

Redisのエンタープライズスケールシミュレーション結果：

従業員1,000名、1日5回クエリの場合
Large Context：1日$15,000（年間約54億ウォン）
RAG：1日$150（年間約5,400万ウォン）

実測データでも差は明確だ。同じエンタープライズワークロードで比較すると、RAGはクエリあたり平均62,000トークンを、Long Contextは平均400,000トークンを処理する（約26倍の差）。応答速度はRAGが約1秒、Long Contextが30〜60秒だ。

データが数百万件に上る企業であれば、Large Contextはそもそも不可能な方式だ。技術的に1Mトークンをサポートするモデルでも、実際にはそれ以前にパフォーマンスが低下する。Databricksの研究によると、Llama-3.1-405Bは32Kトークン以降から、GPT-4は64Kトークン以降からパフォーマンスが落ち始める。いわゆる**「Lost in the Middle」現象** — コンテキストの中間に位置する情報は、先頭や末尾にある情報よりもモデルがはるかに頻繁に見落とす。精度が10〜20ポイント以上低下する可能性がある。

プロンプトキャッシング（Claudeは90%割引、Geminiは75%割引）を活用すれば、同一文書への繰り返しクエリでコストを大幅に削減できる。しかし文書が頻繁に更新されたり、クエリパターンが多様だったりすると、キャッシングの効果は限定的だ。結局、Large Contextはデータが静的で少量、かつクエリ頻度が低い特殊なケースでのみ現実的な選択肢となる。

この問題、韓国とアジアも例外ではない

ITWorld Koreaは2025年、「エンタープライズRAGはなぜ失敗するのか」という深層分析を掲載した。韓国企業が特に苦戦する理由として次のように指摘した。

商用RAGパッケージソフトウェアが韓国の複雑なレガシーデータ環境を十分に処理できない。文書の命名規則の不一致、非構造化された韓国語レガシー文書、エンコーディングエラーがエンベディングを歪めてしまう。そして最も核心的な指摘：実際の困難はプロンプト設計やモデル選択にあるのではない。データの収集・精製、検索最適化、メタデータ管理、バージョン管理、インデクシング、パフォーマンス評価、長期ガバナンスにある。ほとんどのチームはモデル選びに時間を費やし、データパイプラインを軽視している。

SK hynixはAWS Koreaの技術ブログを通じて、社内RAGプラットフォームのパフォーマンス評価結果を公開した。RAG推論レイヤー（エンベディング＋ナレッジ検索）を追加すると、最初のトークン応答時間（TTFT）が30〜40%増加することを発見した。レイテンシに敏感なプロダクション環境では無視できない変数だ。

KT Cloudの技術ブログはさらに直接的な事例を紹介した。精製されていないログをRAGソースとして活用したチャットボットが、完全に誤った回答を返した。エンコーディングエラーの修正や、広告・脚注などの不要なテキストを除去する前処理が必須であることを強調した。カスタマーサポート文書のパースエラーを放置したあるグローバル企業は、RAGチャットボット導入後に顧客満足度が27%低下してからようやくデータパイプラインを修正した。

Samsung SDSは社内GenAIハッカソンで企業向けRAG適用事例を公開し、Skelter LabsはRAG導入率が2023年の31%から2024年には51%へ急増したものの、実際のデプロイ成功率は期待を大きく下回っていると指摘した。

アジア全体を見ても同じパターンが見える。Deloitteの2024年アジア太平洋地域GenAI調査によると、企業の約75%が自社従業員のGenAIに対する期待水準に達していない。 日本はさらに深刻だ。政府の積極的なAI投資にもかかわらず、企業の33%のみが初期導入段階で測定可能なROIを報告した。 アジア太平洋地域の最大の問題はAIそのものではないという分析もある。国ごとに異なる規制、標準化されていないレガシーシステム、データ形式の不一致など、**断片化（fragmentation）**がRAGデプロイをより困難にしている。

なぜRAGはプロダクションで崩壊するのか

数百件のエンタープライズ導入事例を分析したarxiv論文「Seven Failure Points When Engineering a Retrieval Augmented Generation System」（2024年、IEEE/ACM）は、RAGの障害ポイントを7つに分類している。

ナレッジベースに答えがない — 文書の範囲がクエリをカバーしていない
検索の失敗 — 関連文書があるのに検索が見落とす
コンテキストウィンドウの限界 — 検索された内容が多すぎるか少なすぎる
LLMが誤った回答を生成 — 正しい文書を受け取ったのに間違った答え
出力形式のエラー — 求められた形式で回答できない
曖昧な回答 — あいまいで不完全な応答
不完全な回答 — 核心を欠いた応答

この論文が強調する最も重要なポイントはこれだ。RAGシステムの真の検証は運用中にしかできない。 ステージング環境で0.95のrecallを示していたシステムが、プロダクションではコーパスが50倍に増え、同時書き込みが発生することで0.71に低下することがある。それでもレイテンシは正常なため、アラートは一切鳴らない。チームがレイテンシは監視しているが検索品質は監視していないからだ。

データ品質の問題もある。企業内部データの80%以上がPDF、画像、スプレッドシートなどの非構造化形式だ。これをテキストに変換する過程で品質が劣化する。文書が増えるほどむしろ検索精度が低下する「汚染（pollution）」現象もよく見られる。そして企業のナレッジは常に変化する。製品仕様、規定、組織構造が変わるのに、RAGインデックスがそれに追いつかなければ、システムは古い情報で自信を持って回答してしまう。

実際に効果のある解決策

希望的な話もある。成果を出している企業は存在し、彼らが使っている手法は明確だ。ROI基準で整理すると以下の通りだ。

ステップ1：ハイブリッド検索 — 最初にやるべきこと

RAGの検索は大きく2つの方式に分かれる。

ベクトル検索（意味ベース） はテキストをエンベディングモデルで数値ベクトルに変換し、クエリベクトルと文書ベクトル間のコサイン類似度で関連文書を見つける。「子犬」と「犬」を似た意味として認識できるのが強みだ。一方、正確な数値、製品コード、固有名詞のように表現が変わってはならないキーワードには弱い。

BM25（キーワードベースのスパース検索） は伝統的な統計ベースのテキスト検索アルゴリズムだ。簡単に言えば3つの原則で動作する。第一に、検索語が文書に多く出現するほどスコアが高くなる。第二に、文書が長いために自然と語数が多くなることは、長さ補正で調整する。第三に、「は」「が」「の」のようにあらゆる文書に頻出する語は重みが低い。エンベディングなしにキーワードそのものを基準に検索するため、「2024年第3四半期営業利益」のように正確な数値と日付が重要なクエリではベクトル検索より格段に優れている。

両方式は互いの弱点を補完する。これを同時に実行し、RRF（Reciprocal Rank Fusion）で結果を統合するのがハイブリッド検索だ。RRFは各方式の生スコアを直接比較する代わりに、「何番目に良い結果か」という順位位置のみで合算するため、別途のスコア正規化なしに安定的に動作する。

エンタープライズ導入事例では一貫して15〜30%の精度向上が報告されている。Anthropicの自社実験でもエンベディング＋BM25の組み合わせはエンベディング単体より一貫して優れていた。実装難度に対する効果が最も大きいため、最初に適用すべき手法だ。

ステップ2：Re-ranking — 2段目のフィルターを設けよ

初期検索（ハイブリッドを含む）で上位20〜100件の候補を取得した後、Cross-EncoderやColBERTのような別のRe-rankingモデルがクエリと各文書を一緒に見て関連性スコアを再算定する。初期検索が「まずたくさん持ってくる」なら、Re-rankingは「本当に必要なものだけを選び出す」だ。

「時間がかかるのでは？」 その通りだ。しかし実際には許容可能な水準だ。初期のハイブリッド検索が数十msで候補を絞り込めば、Re-rankerはその絞り込まれた候補にのみ適用されるため、追加時間は50〜200ms程度だ。パイプライン全体は依然として1〜2秒以内に完了する。むしろRe-rankingなしで初期検索結果をそのままLLMに渡すと、LLMが関連のない文書まで処理するためより多くのトークンを消費し、精度も低下する。 Re-rankingの数百msはLLMの処理時間（数秒）よりはるかに短いため、体感速度にはほとんど影響しない。

測定された成果は印象的だ。SQuADベンチマークで81.22% → 92.35%（+11ポイント）、Llama2レビューデータでhit-rate 58.63% → 75.00%（+16ポイント）。Azure AIはクエリ書き換えとセマンティックランカーを組み合わせ、NDCG@3基準で**+22ポイントの向上を達成した（従来のプロダクションランカー比約2倍）。Re-rankingは一般的に10〜25%の追加精度向上**をもたらす。

プロダクションでよく使われるRe-rankerは、TinyBERTベースのCross-encoder（高速・低コスト）、Cohere Rerank API（精度が高い）、ColBERT（レイテンシと精度のバランス）だ。

ステップ3：チャンキング戦略の再設計

NVIDIAが5つの文書データセットで測定した結果、チャンキング戦略一つでrecallが最大9ポイントの差が生じた。他の変数は同一であってもだ。

固定長チャンキングの問題は、段落や文の途中で切ってしまうことだ。意味単位を分断するとエンベディング品質が低下する。セマンティックチャンキング（semantic chunking）は文間のエンベディングコサイン距離を見て、意味的な境界で分割する。臨床意思決定支援の研究では、固定チャンキング50% vs セマンティックチャンキング87%、つまり**+37ポイント**の精度差が見られた。

階層的チャンキング（Hierarchical Chunking）も効果的だ。検索には小さな子チャンク（100〜500トークン）を使って精度を高め、LLMに渡す際にはより大きな親チャンク（500〜2000トークン）を提供して十分なコンテキストを保証する。LangChainのParentDocumentRetrieverがこの方式を実装している。

Anthropicが2024年末に発表したContextual Retrievalはさらに一歩進んでいる。各チャンクをエンベディングする前に、LLMがそのチャンクが文書全体の中でどのようなコンテキストにあるかを説明する約100トークンの要約を先頭に付加し、要約文＋元のチャンク全体を一つのテキストとして結合してエンベディングする。

例えばこのような形だ：

[コンテキスト要約] 「この段落は2024年第3四半期の決算報告書において、前年同期比の営業利益の変化を説明する部分です。」 [元のチャンク] 「第3四半期の営業利益は前年同期比12%増の450億ウォンを記録し…」

要約を別途保存したり別に処理するのではない。2つのテキストを連結した全体を一つのベクトルとしてエンベディングする。元のチャンクだけをエンベディングすると、「第3四半期営業利益12%増」という文がどの企業の、どの年度の話なのかベクトルには分からない。コンテキスト要約を先頭に付加すれば、エンベディングが「このチャンクが文書全体のどの位置の情報なのか」を含んだ状態で生成されるため、検索精度が向上する。

結果は明確だった。Contextual Embeddings単体で検索失敗率が35%減少、BM25とRe-rankingまで組み合わせると67%減少だ。

ステップ4：HyDEでクエリを変換せよ

ユーザーは短くあいまいに質問する。文書は長く具体的に書かれている。この2つを直接比較すれば当然ミスマッチが生じる。

HyDE（Hypothetical Document Embeddings）はこの問題を迂回する。流れを見れば理解しやすい。

1. ユーザークエリ: 「返品ポリシーはどうなっていますか？」
        ↓
2. LLMが仮想回答文書を生成:
   「返品は購入後30日以内に可能であり、カスタマーセンターを通じて
    申請できます。処理には営業日基準で5日かかります…」
        ↓
3. この仮想文書をエンベディング → ベクトル検索を実行
        ↓
4. 実際の文書チャンクが返される
        ↓
5. 返された実際の文書をLLMに渡す → 最終回答を生成

核心は、検索には仮想文書のベクトルを使い、LLMには実際に検索された文書を渡すということだ。仮想文書そのものが最終回答になるのではない。仮想文書はあくまで「この質問にふさわしい実際の文書を見つけるためのおとり」の役割を果たすだけだ。

なぜ効果的なのか？短いユーザークエリ（「返品ポリシー」）と文書チャンク（「返品は購入後30日以内に可能であり…」）の間の語彙・長さ・スタイルの不一致を仮想文書が埋めてくれるからだ。特に日本語や韓国語のように表現の多様性が高い言語で効果が大きい。

ベンチマーク結果：「クエリ直接使用」比で**+14ポイント**の精度向上。ファインチューニングなしのゼロショットでドメイン特化検索器と競合できるレベルだ。

ステップ5：GraphRAG — 関係性が重要なクエリに

「自社の今年第3四半期の営業利益は前年同期比でどれだけ変動しましたか？」のような質問は、ベクトル検索ではうまく処理できない。複数の文書から数値を見つけ出し、計算まで行う必要がある。

通常のRAGは文書をチャンクに分割し、各チャンクを独立して保存する。「サムスン電子2024年第3四半期実績」と「Galaxy S24発売発表」は別々のチャンクとして保存され、つながりがない。

GraphRAGは異なるアプローチをとる。Microsoftが2024年にオープンソースで公開したこの方式は、文書を読みながらエンティティ（人物、企業、製品、概念）と関係を抽出してナレッジグラフを構築する。

文書分析プロセス:
1. エンティティ抽出: 「サムスン電子」「Galaxy S24」「第3四半期営業利益」
2. 関係抽出: 「サムスン電子 → 発売 → Galaxy S24」
              「サムスン電子 → 第3四半期営業利益 → 450億」
3. 接続の多いエンティティをコミュニティ（クラスター）にグルーピング
4. 各コミュニティの要約文を生成・保存

クエリが入るとグラフを探索する。「サムスン電子の第3四半期実績と新製品発売の関係」を問う質問は、標準RAGでは2つの独立したチャンクを偶然にも両方検索できなければ答えられない。GraphRAGではナレッジグラフで「サムスン電子」ノードをたどれば関連エンティティがつながっているため、構造的に答えを組み立てることができる。

FalkorDBの2025年ベンチマーク結果は劇的だ。

クエリ種類	標準RAG	GraphRAG
単純な事実質問	94%	95%
複雑な多段階推論	34%	91%
スキーマベース（KPI、予測値）	0%	90%+
数値推論	~50%	100%
時間的推論	50%	83%

スキーマベースのクエリで標準RAGが0%である一方、GraphRAGは90%以上という点が決定的だ。エンタープライズの多くの重要な質問がまさにこの領域に該当する。

GraphRAGは2026年現在も有効か？ その通りだ。ただし「あらゆるケースで使うデフォルトツール」ではない。グラフ構築自体にコストがかかり、クエリレイテンシも標準RAGの約2.4倍長い。2025年以降はMicrosoft GraphRAGよりも軽量で高速なバリエーション（HippoRAG、LightRAG）も登場している。現実的な選択は、単純な事実質問には標準RAG、関係性・多段階推論が必要なクエリにはGraphRAGにルーティングするハイブリッドアーキテクチャだ。

状況	推奨
単純FAQ、高速応答	標準RAG
KPI比較、数値分析、複数文書の連結	GraphRAG
グラフ構築コストが負担の場合	HippoRAG（GraphRAG比10〜20倍安価）

ステップ6：ドメイン特化エンベディングのファインチューニング

汎用エンベディングモデル（例：OpenAI text-embedding-ada-002）は一般的なインターネットテキストで訓練されている。医学の略語「MI」が心筋梗塞（Myocardial Infarction）なのか機械知能（Machine Intelligence）なのか区別できない可能性がある。法律・金融・製造などの専門ドメインでは、この問題は深刻だ。

重要な点を押さえておこう。これは新しいエンベディングモデルをゼロから作るのではない。 bge-base、E5のような既存の汎用エンベディングモデルをドメインデータで「ファインチューニング（fine-tuning）」してドメイン特化モデルに変えるのだ。

[ステップ1] ドメイン文書からLLMで合成QAペアを生成
        例: 「この段落に関する質問を5つ作ってください」
        → (質問, 答えが含まれるチャンク) のペアを数千件作成

[ステップ2] 汎用エンベディングモデルをそのQAペアでファインチューニング
        → モデルが当該ドメインの語彙、略語、関係を学習

[ステップ3] ファインチューニングしたモデルで既存のベクトルDBを再エンベディング
        → 検索精度の向上

ゼロから作るのではないため、データもコストも比較的少なくて済む。わずか6,300件の合成学習サンプルでも約7%の検索精度向上が可能だ。

DatabricksのInstructed Retrieverはこのアプローチで、従来のRAG比最大70%の向上を達成した（金融、Eコマース、ヘルスケア）。ドメイン特化データが多いほど効果は大きくなる。

ステップ7：評価なくして改善なし

成果を出しているチームとそうでないチームの最大の違いは継続的な評価体制だ。

RAGAS（Retrieval Augmented Generation Assessment）は現在、RAG評価の事実上の標準だ。リファレンスなしでLLMジャッジが4つの次元を自動評価する。Faithfulness（回答が検索内容に基づいているか）、Answer Relevance（回答が質問に答えているか）、Context Precision（検索されたコンテキストが関連しているか）、Context Recall（必要な情報がすべて検索されたか）。

プロダクションモニタリングにはTruLensが有用だ。TruLensが定義した**「RAGトライアングル（RAG Triad）」** は3つの関係をそれぞれ独立に評価する。

          ユーザー質問
              ↓           ← ① Contextual Relevance
    [検索] → コンテキストチャンク
              ↓           ← ② Groundedness
    [生成] → 最終回答
              ↑
              └─── ③ Answer Relevance ──→ ユーザー質問

① Contextual Relevance（コンテキスト関連性）: 「質問 ↔ 検索されたコンテキスト」の関係を評価する。検索器が本当に必要な文書を持ってきたか？このスコアが低ければ、チャンキング・エンベディング・検索方式を修正すべきだ。
② Groundedness（根拠性）: 「検索されたコンテキスト ↔ 最終回答」の関係を評価する。回答が検索された内容のみに基づいているか、それともモデルが勝手に作り上げたか？これが低ければハルシネーションが発生中だ。
③ Answer Relevance（回答関連性）: 「質問 ↔ 最終回答」の関係を評価する。回答が実際に質問に答えているか？これが低ければ、コンテキストはうまく見つけたがLLMが見当違いの内容を生成している状態だ。

3つを合わせて見る理由は、どの段階で問題が発生しているか診断するためだ。Groundednessは高いのにAnswer Relevanceが低ければプロンプト設計の問題だ。Contextual Relevanceが低く、他も連動して低ければ検索そのものを修正する必要がある。

プロダクション基準：規制領域（法律、医療、金融） ≥ 0.85、一般的なナレッジワーク ≥ 0.75。この数値がなければ、システムがどれほど悪い状態かすら分からないまま運用していることになる。

成果を出した企業の実例

Morgan Stanley：検索可能文書を7千件から10万件へ

Morgan Stanleyは10万件以上の独自金融文書からアドバイザーの質問に回答するシステムを必要としていた。初期システムは約7,000件の文書でしか効果的に機能せず、文書recallは**20%**だった。アドバイザーたちはシステムを信頼していなかった。

OpenAIと共に評価主導の最適化を繰り返し実施した。要約評価、プロンプトエンジニアリング、チャンキング戦略の改善が核心だった。結果：文書recall 80%に向上、全10万件の文書コーパスをカバー、アドバイザーチームの98%以上が実際にシステムを使用するようになった。

FalkorDB：スキーマクエリの精度 0% → 90%+

2023年のDiffbotベンチマーク基準で、標準ベクトルRAGの全体精度は56.2%だった。スキーマベースのクエリ（KPI、予測値など）は0%だった。2025年にFalkorDB GraphRAG SDKを適用した結果、全体で90%以上を達成。

Droptica：2段階評価で精度40%向上

ProjektMagazin向けの専門ナレッジ管理RAGチャットボットの初期バージョンは、「もっともらしいが間違った回答」でユーザーの信頼を失った。広範囲に検索した後、LLMが各チャンクの関連性を再評価する2段階文書評価を導入し、精度40%向上を実現。

結論：RAGは間違っていない、ただし思ったより難しい

「RAGはなぜこんなに難しいのか」という問いに対する率直な答えはこれだ。RAGは一つの技術ではなく、複数のコンポーネントが噛み合ったシステムだからだ。 エンベディングモデル、チャンキング戦略、検索方式、Re-ranking、データ品質、インデックスの鮮度、評価体制 — このうち一つでも間違えば全体の精度が崩壊する。

そして失敗の核心はほぼ常に同じ場所にある。データだ。RAND Corporationの研究は、AIプロジェクトの80%が失敗する理由の一つとして「AIで解決するには難しすぎる問題にAIを適用すること」を挙げている。しかし企業内部のデータは大抵きれいに整理されていない。一貫性がなく、重複し、散在している。「Garbage in, garbage out」はRAGにもそのまま当てはまる。

世界中で同じパターンが繰り返されている。デモはうまくいく。PoCも印象的だ。しかし実際のプロダクション、実際のユーザー、膨大な実データが入ってくると問題が始まる。韓国も、日本も、米国も同じだ。

だからといって諦めるには早い。方向性は明確だ。ハイブリッド検索から始めてRe-rankingを追加し、チャンキング戦略を改善し、RAGASで継続的に計測せよ。ドメイン特化データがあればエンベディングをファインチューニングし、関係性クエリが多ければGraphRAGを検討せよ。そして何よりも、まずデータを整理せよ。

Morgan Stanleyのように、最初は20%だったシステムが98%のチームが毎日使うシステムに変わることはできる。そこにたどり着くまでの道が、思ったより長く険しいだけだ。