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%——而不是一个不透明的综合分数。

按结构复杂度（简单文本与表格/图表/示意图）对页面进行路由，避免让每份文档都经过昂贵的基于模型的解析。

修复针对的是含义丢失之处——表头与数据分离、流程在 token 边界处被切分——而不是要求更聪明的模型来弥补缺失的上下文。

当 AI 系统尽管通过了基准测试却在生产环境中失败时，在改动模型之前，应单独隔离并重新测试每个流水线阶段——故障通常发生在模型的上游。

Salesforce 还将较小文档的索引从基于 Spark 的批处理架构迁移到基于服务的即时架构，使索引时间缩短三到四倍，从 30 多分钟降至约七到十分钟。团队计划让 GraphRAG 于 2026 年 11 月正式可用，该技术通过遍历跨文档的知识图谱来回答多跳问题。