Salesforceは、自社のRAGアプリがテストで90%のスコアを出したのに実際の顧客では46%だった理由を突き止めた

Salesforceの検索拡張生成（RAG）パイプラインは、標準的なテキスト検索ベンチマークでは90%超の精度を達成していたが、複数ページにわたる表や結合セルを含む保険証券のような、顧客を代表する複雑なエンタープライズ文書に対してテストすると、精度は約46%まで低下した。この乖離は、2四半期にわたる顧客からのエスカレーションを経て初めて表面化し、明白な容疑者はLLMそのものであった。

モデルの交換やプロンプトの書き直しを行う代わりに、エンジニアリングチームは誤った回答それぞれから逆方向に作業を進めた。取得されたコンテキストは完全だったのか。そうでなければ、検索が誤ったチャンクを選んだのか、チャンキングが関連情報を分割したのか、それともパースが最初に情報を失ったのか。テストにより、表のヘッダーがページ区切りをまたいでデータから分離されていたこと、および固定サイズのチャンキングが手順を任意のトークン境界で切り刻み、意味を与えていた見出しや図を剥ぎ取っていたことが判明した。

その後チームは一度に1つのパイプライン段階を変更し、同じ段階別ベンチマークを再実行して各改善を帰属させた。複雑な表やグラフをモデルベースの処理に振り分けるページレベルの「インテリジェントパーシング」を追加すると、段階別ベースラインは65.1%から84.4%に上昇した。各チャンクをメタデータと質問表現で強化し、コンテキスト容量を512トークンから8,000トークンに拡張した埋め込みモデルと組み合わせることで、さらに2.4ポイント加わり86.8%となった。変更全体を通じて、より広範なエンタープライズ文書ベンチマークでの精度は約46%から90%超に上昇した。

モデルのせいにせず、パイプラインを逆方向に、一度に1つの分離された段階ずつデバッグした

パイプラインを段階ごとに逆方向にテストすることで、パース、チャンキング、強化、埋め込み、検索のうちどれが実際に各誤答を引き起こしたのかを推測ではなく特定した。

同じベンチマークを再実行する前に正確に1つの段階だけを変更したことで、各改善を帰属可能にした — 65.1%から84.4%、そして86.8%へ — 不透明な単一の合成スコアではなく。

ページを構造的な複雑さ（単純なテキストか、表・グラフ・図か）で振り分けることで、すべての文書を高コストなモデルベースのパースに通すことを避けた。

修正は、意味が失われていた箇所 — データから分離されたヘッダー、トークン境界で分割された手順 — を対象とし、欠落したコンテキストを補うようより賢いモデルに求めることではなかった。

AIシステムがベンチマークに合格しているにもかかわらず本番環境で失敗する場合、モデルに触れる前に各パイプライン段階を個別に分離して再テストすること — 失敗は通常、モデルの上流にある。

Salesforceはまた、小規模文書のインデックス作成をSparkベースのバッチアーキテクチャからサービスベースのジャストインタイムアーキテクチャに移行し、インデックス作成時間を3〜4倍短縮して、30分超からおよそ7〜10分に短縮した。チームは、マルチホップ質問のために文書をまたいで知識グラフをたどるGraphRAGを、2026年11月の一般提供に向けて位置付けた。