两套提取引擎必须一致，数字才能进入你的模型

任何一款能从 PDF 中抽取数字的 AI 财务工具，都在下一个赌注:某一个解析器，或者某一个读取页面的模型，判断是正确的。Rexfin 拒绝下这个赌注。一个数字只有在至少两套独立引擎各自读取该页面并得出相同结果之后，才会被视为可引用，才能获得徽章、核对标记以及“点击溯源”链接。

为什么一套读取引擎永远不够

无论一条提取流水线多么优秀，它都会以某种没人能提前察觉的方式悄悄出错，直到数字已经出现在董事会材料上:一个合并单元格让列错位、一个脚注上标被当成数字的一部分读入、一页扫描件被解析器以虚假的高置信度读取，而不是被标记为不可读。这里的失败模式不是“工具崩溃了”,而是“工具生成了一个看似合理但错误的数字，并且交给你时没有任何信号提示出了问题”。这正是 Rexfin 整条信任链要防止的失败模式，而且它从提取环节就开始防范，而不是等到下游再补救。

各套引擎具体如何产生分歧，又是如何被解决的

Rexfin 会在同一页面上独立运行多套提取引擎:一个具备版面识别能力的表格提取器、一个基于文本与几何位置的提取器、一个专用表格解析器，以及一次基于像素的渲染页面 OCR 识读;此外还可以选配一个视觉语言模型，但它仅用作决胜手段，绝不作为两票必需独立投票中的一票。每个引擎对其他引擎产出的结果都毫无所知。

在进行任何比较之前，系统必须先跨引擎将同一个逻辑单元格对齐，即同一行项目、同一期间列，依据的是标签相似度和该单元格在页面上的几何位置，因为只有两套引擎确实在看同一个单元格时,“一致”才有意义。对齐之后，数值比较会在一个随报表舍入单位而变化的容差范围内进行，而不是使用固定的美元金额，因为在一份以千位舍入的 IFRS 报表上，一个引擎读出“4,914”、另一个读出“4,915”,并不算分歧，它们其实都是对的。

独立性必须真正名副其实

如果各票之间不是真正独立的，那么“计票”这件事本身就没有意义。两个基于同一套底层解析引擎的封装组件，不能仅仅因为打包方式不同就算作两票。Rexfin 的独立性策略明确按此方式对引擎进行分组，以确保“一致”不会由同一核心引擎的两种变体互相点头而人为制造出来。还有一条更严格的规则:在一份数字化 PDF 上，三个确定性解析器完全可能以三种不同方式读取同一段嵌入文本流，如果底层文本层本身损坏或映射错误，这三个解析器完全可能自信地对同一个错误数字达成一致。为了堵住这个漏洞，一个可引用的数字必须至少包含一次锚定在页面渲染像素上的读取，也就是一次 OCR 识读，而不仅仅是对文件内部文本的再次解析，这样“一致”才与人眼实际在页面上看到的内容挂钩，而不仅仅与文件本身声称的内容挂钩。

引擎意见不一致时会发生什么

如果一个数字只有一套引擎读取过，或者各引擎之间确实存在分歧，它既不会被悄悄丢弃，也不会被悄悄放行。它会进入一个隔离通道:在上下文中依然可见，不会从整体画面中消失，但会被明确标记为不可引用，且不带任何可点击的溯源链接。在没有重新进行一致性核验的前提下，隔离中的数字没有任何途径能凭空升级为可引用状态，置信度不能靠命令直接提升。

这为下游带来了什么

这道关卡位于整个模型的最上游。正是它让报表网格中的核对状态真正有意义，而不只是表面装饰;它也是溯源抽屉中展示的“引擎一致性”徽章的来源;更是导出关卡在董事会材料能够导出之前检查的两个硬性前提条件之一。如果一个数字从一开始就没有经过独立核验，那么这些下游保障就没有任何意义，这也正是为什么这项检查要先于一个数字被允许成为引用候选之前就运行。

对于正在评估某个 AI 是否真正读对了备案文件数字的团队而言，这一层正是值得直接追问的地方:问题不应是“它有没有提取数据”,而应是“有多少套独立引擎给出了一致结果，以及不一致时会发生什么”。想了解这一环节如何融入产品的其他部分，请参见产品导览中心。