在一句话背后，需要区分“事实”与“传播放大”

2026年9月，OpenAI 官方发布了一个与 Legora 合作的财务审阅案例。可获得的官方事实只有一句：Legora 使用 GPT-6 Astra 在几分钟内审阅了 41 份文档，找出了全部 4 个预先植入的错误，并且在该财务审阅工作流中让 performance 提升了接近 40%。

这句话很容易被转述成另外几个版本，例如“GPT-6 Astra 审查 41 份财报”“错误全捕获”“效率提升 40%”。但这些说法都不是原文。原文没有说 41 份 documents 是 41 份财报；没有说模型可以捕获任意真实错误；没有说提高的是效率，而是 performance；也没有解释 performance 的计算方式。在工具评测中，第一步不是相信结论，而是把结论还原到可核验的限定条件里。

对这个案例而言，边界条件至少有以下几条：文档数量是 41；植入错误数量是 4；运行时间被描述为“minutes”，而不是具体秒数或分位数；提升幅度的口径和基线均未说明。也就是说，这不是一个可用于横向对比的基准，更接近一次初步功能验证。

为什么“找对”不等于“能过审”

金融文档审阅的真实难度在于三点：长文档上下文、版式干扰、规则一致性。一个模型如果只是“碰巧发现了某些错误”，并不代表它能稳定发现同类错误。41 份文档、4 个植入错误的规模，通常只能用来做一个检查：模型在受控测试集里是否能被有效驱动。

从工程角度看，下一步值得复现的不是 GPT-6 Astra 的 API 性能，而是 Legora 这类工作流的验证方式：先准备一组包含已知问题的文档，让模型逐份审阅，最后统计模型是否能够把问题定位到足够精细的位置。如果模型不能给出“文档名 + 章节/页码 + 前后文对照”，即使结论正确，也很难接入正式审阅流程，因为复核人员仍然需要重新阅读全文来确认模型判断。

因此选型时要避免两个极端。其一，把这类官方案例当作业界标准，直接向团队传递“40%”。其二，把测试集设计成“只有加分题，没有正常题”。实际工作中大量内容是无错误的正常文本，模型如果为了找到植入错误而对正常表述过度报告，会显著增加人工复核负担。测试集中应该同时包含正常文档和带错文档，并把误报率纳入评估。

为金融审阅场景构建的验证清单

如果团队需要判断 GPT-6 Astra 或类似模型是否适用于自己的金融审阅场景，可以设计以下五层验证。以下内容不是对官方案例的补充说明，而是可复用的工程方法。

第一，错误植入。错误数量不需要多，但类型需要覆盖审阅中最常被检查的项目。例如金额抄写不一致、大小写金额不匹配、日期与会计期间错位、条款编号引用错误、表格内跨行合计不符。植入错误时，要记录每条错误的类型和位置，形成 ground truth。

第二，指标记录。对每一份测试文档，记录模型是否发现每条植入错误，以及模型额外标记的可疑项。最终计算召回率、精确率、端到端耗时和人工复核节约量。官方提到 performance 提升接近 40%，但由于没有定义，团队不需要去和三方数字比较，而要定义自己的基线。

第三，定位能力测试。检查模型输出是否包含原始引用。例如，模型在判断“某项目金额有误”时，是否指出了第几页、哪个栏目，以及它认为应与哪一个字段匹配。如果缺少这些信息，输出就不具备可审计性。

第四，中文特性测试。当前案例没有提供文档语言。若团队处理中文金融文档，应加入典型中文错误：中文大写数字与阿拉伯数字不一致、科目名称简繁变化、合同编号规则等。很多通用模型在中文场景上的退化并不发生在“看得懂”，而是发生在“精确比对”上。因此中文文档应单列测试组，并观察模型是否误用相邻字段作为正确值。

第五，延迟与批量处理。案例中的 41 份文档“几分钟”是一个结果，不等于团队在自己的文档长度和格式下也能达到。PDF 扫描件、表格型报表、多栏排版都会影响预处理时间和模型吞吐。至少应拿 20 份真实格式的脱敏文档做一次批量运行，记录单份平均耗时、失败重试率和 token 消耗。

提示工程能借鉴什么

案例分析中经常出现“借鉴 Legora 的提示工程策略”这种说法，但该官方资料并没有披露 Legora 的提示词、模型参数或系统流程。所以准确的判断是：我们无法照搬 Legora 的 Prompt，只能借用一个工作流思路，即把“看完文件并找出错误”拆成更小的步骤。

一个可操作的方法是三层提示结构。第一层，要求模型先抽取文档中的关键数据字段并附位置；第二层，要求模型按审阅规则逐项检查这些字段，例如核对数字一致性、日期顺序、条款引用是否存在；第三层，将异常项整理成差异报告。这样做的好处是，每一层输出都可以独立复现和验证，不会因为最终答案正确而忽略中间推理中的错误。

另一种工程实践是 few-shot 对照。在每个提示中提供一条“正常表述 + 正确判断”和一条“存疑表述 + 异常判断”示例，让模型的行为先被限定到审阅任务上。提示版本应该和被测模型、测试集固定保存下来，任何一次提示词修改都重新跑同一套植入错误集，避免靠主观印象调 Prompt。

选型判断

GPT-6 Astra 在这个案例中的表现，能说明它至少可以被第三方财务审阅工具驱动，并处理几十份文档的批量任务。但这个案例没有提供足够信息来说明：它相比其他模型好在哪里；它在复杂真实文档上会如何失败；它对中文支持程度如何；以及 performance 指标的定义。因此，更保守的选型结论应该是：官方案例可用于筛选候选模型，但不能替代自有语料的对比测试。

团队真正要做的，是把 Legora 这种“小批量受控验证”复制到自己的环境里。准备自己的错误植入集，跑同一个提示结构，用统一的召回率、误报率和定位能力指标横向比较几个模型。只有在这种情况下，“40%”这种数字才可能有意义。