摘要

  • Nutrient 于 9 月 10 日宣布 Data Extraction API 全面开放，将按结构要求提取字段与来源定位结合起来。
  • 官方指南明确：置信度不是概率，缺少分数不是低分；找到原文位置，也不等于完成业务批准。

一个字段没有置信度，审核队列是否就应该把它当成错误？Nutrient 的技术指南给出的答案是否定的：有时只是引擎没有提供分数。这个看似细小的区别，会影响哪些工作交给人、哪些结果继续流转，以及自动化究竟省下了多少劳动。

9 月 10 日的发布消息介绍了 Nutrient 的文档解析和结构化提取 API。它的实际用途不只在于产出一个值，还在于让使用者能够回到相应页面，检查这个值的依据。对于需要将文档信息送入业务系统的团队，这比只有一份答案更便于核查。

提取接口指南说明，extract 接口要求提供 JSON Schema，内部先做解析，再返回所声明的字段；parse 则面向整份文档的元素或 Markdown。字段引用保存在元数据中。引用指南补充了边界：引用默认开启，但可以关闭。关闭后不再计算引用，元数据对象为空。因此，空引用并不能单独证明系统曾经寻找来源却没有找到。

开启引用时，匹配标签区分单一来源块的精确匹配、多块匹配、部分解析、近似匹配和未能定位。指南建议把 fuzzy_match、not_found 等情况交给人工复核。这是用于设计处理逻辑的建议，不是已经替每位客户完成审批的现成流程。

置信度又是另一层信号。它虽然处于零到一之间，却不是经过校准的正确概率，也不能直接显示成百分比。分数缺失表示没有可用分数，不是零分或低置信度；对于高风险字段，指南要求不论分数如何都应人工复核。假设发票中的某个行项目金额被准确定位，它仍可能不是采购方要求的合计。这是分析用的假设例子，并非已发现的 Nutrient 故障。

官方基准页面所报的 0.932 也不能填补这一步判断。该分数来自 understand 模式对 200 份 PDF 的解析测试，考察阅读顺序、表格结构和标题层级。understand 与 agentic 是在公开语料上内部运行的测试；公开榜单收录的是 text/structure 开源工具。它不是“93.2% 的业务字段正确”的保证。本地处理耗时也不是 API 往返延迟，不能把一种模式的速度与另一种模式的准确性拼成同一结果。

产品展示页甚至明确区分了证据核查记录与结果批准：其决策环节视频是流程概念，不是已交付的产品界面。让错误变得可检查，是价值的起点；检查之后能否正确解决，才决定这项价值能否兑现。