Salesforce 找出為何其 RAG 應用程式在測試中得分 90%，實際客戶卻只有 46%

Salesforce 的檢索增強生成（RAG）流程在標準文字檢索基準上準確率超過 90%，但以複雜、具客戶代表性的企業文件（例如含多頁表格與合併儲存格的保險保單）測試時，準確率卻降至約 46%。這個落差是在歷經兩季的客戶升級投訴後才浮現，而最顯而易見的嫌疑對象就是 LLM 本身。

工程團隊並未更換模型或改寫提示詞，而是從每個錯誤答案往回追查：檢索到的上下文是否完整？若不完整，是檢索挑錯了區塊，還是切塊拆散了相關資訊，抑或解析階段就先遺失了？測試顯示，表格標頭在跨頁時會與其資料分離，而固定大小的切塊則在任意的 token 邊界切斷流程說明，連帶移除賦予其意義的標題與圖表。

團隊接著一次只改動一個流程階段，並重新執行同一套分階段基準，以歸因每一項增益。加入頁面層級的「智慧解析」，將複雜表格與圖表導向基於模型的處理，使分階段基準從 65.1% 提升至 84.4%。為每個區塊充實中繼資料與問題表徵，並搭配將上下文容量從 512 個 token 擴展至 8,000 個 token 的嵌入模型，又增加了 2.4 個百分點，達到 86.8%。在整套變更之下，更廣泛的企業文件基準準確率從約 46% 提升至超過 90%。

逐一隔離每個階段、往回除錯流程，而非歸咎於模型

逐階段往回測試流程，能隔離出究竟是解析、切塊、充實、嵌入還是檢索真正導致每個錯誤答案，而非憑猜測。

在重新執行同一基準前只改動一個階段，使每項增益都可歸因——65.1% 到 84.4% 再到 86.8%——而非一個不透明的合併分數。

依結構複雜度（純文字 vs. 表格／圖表／示意圖）分流頁面，避免讓每份文件都經過昂貴的基於模型解析。

修正針對的是意義流失之處——標頭與資料分離、流程在 token 邊界被切斷——而非要求更聰明的模型來彌補缺失的上下文。

當 AI 系統儘管通過基準測試卻在生產環境中失敗時，應先隔離並分別重新測試每個流程階段，再動模型——失敗通常發生在模型的上游。

Salesforce 也將較小文件的索引從基於 Spark 的批次架構改為基於服務的即時架構，將索引時間縮短三到四倍，從 30 分鐘以上降至約七到十分鐘。團隊將 GraphRAG（跨文件遍歷知識圖譜以回答多跳問題）定位為 2026 年 11 月正式推出。