9月10日、Salesforce Engineeringが「Enterprise AI Accuracy: Building a More trustworthy RAG Application」と題した記事を公開した。標準ベンチマークでは精度90%超を記録していたRAGパイプラインが、複雑なエンタープライズ文書に対しては約46%まで落ち込むという現実に直面したSalesforceのチームが、パイプラインの各ステージを段階的に診断・改善することで最終的に90%超を達成するまでの実装記録だ。「なぜ本番環境でRAGは壊れるのか」という問いに、再現性のある方法論で答えている。

標準ベンチマークと実文書のあいだにある落差

Salesforceのチームは2四半期にわたる顧客エスカレーションの末、不快な事実に向き合った。標準的なテキスト検索ベンチマークでは精度90%超を記録していた同じRAGパイプラインが、複雑なエンタープライズ文書——保険証券、財務資料、製造マニュアルなど——に対して社内評価を実施すると約46%まで落ち込んだのだ。

整理しておくと、記事が示す数字には2つの文脈がある。標準ベンチマーク上でのベースライン精度は**65.1%であり、エンタープライズ文書に対する初期評価で観測されたのが約46%**だ。前者はパイプライン改善の出発点として測定された値、後者は「実運用でどれだけ壊れるか」を示す値として別文脈で登場する。この2つの数字が示すのは同じ問題の異なる側面だ——標準的な評価軸では見えない劣化が、実文書では深刻な形で現れる。

原因はどこにでも潜んでいた。パース、チャンキング、エンリッチメント、埋め込み、検索、回答生成——パイプラインのどのステージでも意味が静かに消えていく可能性がある。ある段階を直せば次の壊れた箇所が露わになる、という連鎖だ。

記事が強調する核心はシンプルだ。「LLMは元の文書を見ていない。RAGパイプラインが保全・検索したコンテキストしか見ていない」。つまり、モデルの推論能力を上げても、パイプライン上流で失われた情報は取り戻せない。

パースが最初の、そして最大のボトルネックだった

チームが診断を「回答生成から遡る」方式で進めたところ、失敗の原因は繰り返しパイプラインの上流——ドキュメントのパース段階——に行き着いた。

典型的な失敗パターンが保険証券の「カバレッジマトリクス」だ。マージされたセルと入れ子ヘッダーを持つ表が複数ページにまたがっている場合、2ページ目が独立したオブジェクトとして切り出されると、そこに含まれる行はヘッダーを失う。残ったフラグメントをLLMに渡しても、値の意味はすでに失われているため、モデルは「もっともらしいが誤った」答えを自信満々に返す。

これに対してチームが実装したのが「Intelligent Parsing」だ。ページの複雑度に応じてルーティングを分岐させるアプローチで、シンプルなテキストは高速な決定論的パスへ、表・図・図解を含むページはビジョンモデルやLLMベースの処理パスへ振り分ける。複数ページにまたがる表は論理的に1つのユニットとして保全され、ページ区切りをまたいでもヘッダーと行の関係が維持される。

段階的なベンチマークの結果：

19.3ポイントという上昇幅が示すとおり、パース戦略の改善が最大の効果をもたらした。

チャンキングは「ストレージの制約」ではなく「意味の境界」として設計する

次に大きな改善ポイントがチャンキング（文書の分割方法）だ。固定トークン数での分割は、製造マニュアルのデバッグ手順のような「見出し＋図解＋ステップの連続」が意味を持つコンテンツを壊す。手順のテキストは残っても、見出しや前置きの警告、参照図が消える。

記事の言葉を借りれば、「チャンキングをストレージの制約として扱うのをやめ、意味の境界を定める作業として扱え」。

実践的なテスト基準として記事が挙げるのは「チャンクを単独で評価した場合、それ自体として意味が成立するか？ファイル名を削除してもどのセクションか分かるか？」というチェックだ。

さらにチームは各チャンクを以下の3つの表現でインデックス化する「エンリッチドインデックス」を実装した：

• ソース表現：元のテキスト
• メタデータ表現：要約、タグ、構造的コンテキスト
• クエスチョン表現：ユーザーが実際に使いそうな言い回し

また埋め込みモデルとしてSFR Embedding v3を採用した。これはSalesforceが独自に開発した埋め込みモデルであり、コンテキスト長を512トークンから8,000トークン（16倍）に拡張することで、デバッグシーケンスのような長い単位を分割せずに扱えるようにした。汎用の埋め込みモデルをそのまま流用するのではなく、エンタープライズ文書の特性に合わせたモデル選定・設定がここでも精度に直結している。

検索精度：意味的類似度だけでは不十分な理由

意味的に近いチャンクが必ずしも正しい答えを持つわけではない。複数製品の類似トラブルシューティング記事がインデックスに混在する場合、ベクトル検索が誤った製品ラインの記事を返す可能性がある。文章は「それらしく見える」ため、LLMも評価者も見逃しやすい。

この問題への対処として記事が紹介するのが動的メタデータ事前フィルターだ。製品・地域・顧客ティアといった制約条件を類似度ランキングの前に適用し、「適格なセット」に絞ってから意味検索を走らせる。

また、複数ドキュメントにまたがる証拠を連鎖的に追う必要がある「マルチホップ質問」には、ベクトル検索だけでは対応が難しい。これに対してはグラフ構造で事実・レコード・文書間の関係を表現するGraph RAGが有効だとしており、2026年11月に一般提供予定とされている。

インデックス時間も3〜4倍短縮

精度以外の改善も報告されている。元のSparkベースのアーキテクチャはバッチ処理向けに設計されており、100MB未満のペイロードをアップロードしたユーザーでも30分以上待つ必要があった。これをサービスベースのJust-in-Time インデックスアーキテクチャに移行したことで、インデックス時間を約7〜10分に短縮した（3〜4倍の改善）。

デバッグの鉄則：1ステージずつ変えて測る

記事全体を通じて強調される方法論は一貫している。「変更を1ステージに限定し、同一の評価を繰り返す」だ。複数箇所を同時に変えれば、どの変更が効いたのかが分からなくなる。精度が下がったときに何を調べればいいかも分からなくなる。

具体的な診断手順として記事が示すのは、「回答の正確性→上位引用の正しさ→取得チャンクの十分性」という3層の確認を逆順に遡るアプローチだ。エンドツーエンドの精度を「1つの不透明な数字」として扱わないことが前提となる。

この診断ループが機能した根拠は、ベンチマーク表の数字に表れている。パース改善で+19.3pt、エンリッチドインデックスで+2.4ptと、各ステージの寄与が独立して可視化されている。もし複数の変更を同時に適用していれば、この分解は不可能だったはずだ。「何が効いたか分からない改善」を積み重ねるのではなく、再現性のある改善ループを確立することが、65.1%から90%超への到達を支えた実装上の核心といえる。

詳細はEnterprise AI Accuracy: Building a More trustworthy RAG Applicationを参照していただきたい。