“把文档切块、写进向量库，再接一个聊天框”可以做出 RAG 演示，却不足以证明系统能处理真实企业文档。
Databricks 发布的 OfficeQA Pro 不是一款企业文档 Agent 产品，而是一套端到端 grounded reasoning 基准。它要求 Agent 在陌生的大型文档集合中找出证据、理解表格、完成跨文档计算，并给出可核对的最终答案。
基准到底测什么
原版 OfficeQA Pro 包含 133 道题，文档来自 1939 至 2025 年的美国财政部公报。技术报告描述的语料规模约为 89,000 页，包含超过 2,600 万个数值。问题横跨非结构化文字和密集财务表格，常常需要同时完成文档定位、字段对齐、单位处理和算术推理。
这些数字来自 Databricks 的论文与仓库，不是本站复测。2026 年 8 月，Databricks 又发布了 OfficeQA Pro V2；因此本文讨论的是原版 OfficeQA Pro 所揭示的工程问题，而非宣称当前排行榜或题集永远不变。
技术报告给出的核心观察是：只靠模型参数知识或普通网页搜索，成绩很低；即使给 Agent 文档语料，平均仍有大量问题无法正确解决。结构化文档表示能改善表现，但离可靠的企业级自动化仍有明显距离。
第一道门：解析，而不是向量检索
财政公报包含历史 PDF、扫描页、跨页表格、脚注、单位和版式变化。系统将 PDF 转成文本或结构化块时，已经在做一次高风险转换：列标题错位、负号丢失、年份与数值错配，都会让后续推理建立在错误材料上。
OfficeQA 论文专门比较了文档表示方式。其结果支持一个工程常识：解析质量不是 RAG 上游的琐事，而是答案准确率的硬上限。企业项目应先对最脏的文件做 OCR、表格和来源定位验收，再讨论 embedding 或模型选择。
第二道门：检索必须服务于计算
语义相似度擅长找“谈论同一主题”的段落，却不保证找齐计算需要的全部年份、表格行和脚注。许多 OfficeQA 问题要求跨多个页面甚至多份公报组合证据。
因此检索层至少要保留：原文件、页码、表格位置、时间、单位和上下级标题。对于需要计算的问题，还要能判断证据是否齐全；缺一年数据时，系统应该停止并报告缺口，而不是让模型补一个看似合理的数字。
第三道门：答案要能回放
端到端系统出错，原因可能发生在任何一层：
| 环节 | 常见失败 | 应保留的证据 |
|---|---|---|
| 解析 | OCR 错字、列错位、单位丢失 | 原页截图与结构化结果 |
| 检索 | 漏页、只召回相似但无关内容 | 查询、候选页与排序分数 |
| 推理 | 选错行列、混淆口径 | 中间变量与引用位置 |
| 计算 | 百分比、汇率或时间范围错误 | 可重算表达式 |
| 输出 | 答案与引用不一致 | 最终答案到证据的映射 |
只记录最终回答，就无法判断应该修 OCR、召回、提示还是计算工具。真正的企业文档 Agent 需要端到端可观测性，而不是把所有错误统称为“幻觉”。
给企业团队的最小评测集
可以从真实业务里选一组需要查表、跨页或计算的问题。每道题不仅保存标准答案，还应保存来源文件、页码、表格单元、单位、计算步骤和允许误差。然后分别报告解析成功率、证据召回率、计算正确率与端到端通过率。
扩权也应分阶段：先做只读检索和引用，再开放计算与报告生成；只有当错误能定位、答案能回放、关键题能稳定通过，才考虑让系统影响下游业务流程。
OfficeQA Pro 的价值不在于又多了一张模型榜单，而是把企业文档任务重新定义为一条证据链：解析正确、检索完整、推理可查、计算可重放，最后答案才值得信任。
参考资料
资料复核日期：2026-08-23。本文没有采用无法在原论文或官方仓库稳定对应的未来模型宣传分数；所有基准数字均标明为发布方口径。