模型给一个表格单元格多加了一个字，模式校验抓不到

一个被要求转录表格的模型，有时会顺手"改进"它。不是恶意，也不常发生——但发生得足够稳定，以至于我们必须为它专门写一道检查。

让我们写这道检查的案例很小。一份借贷文件里有个单元格写着「循环贷款」。模型返回的是「循环贷款等」——同样的词，后面多了个「等」，把一个具体的金融工具变成了"循环贷款之类"。一个字。如果你只是拿输出和扫描件对照着扫一眼，你根本看不出来。

为什么常规校验抓不到

大多数表格抽取是用模式校验的。列在不在？类型对不对？行数合不合理？模式校验能回答这三个问题并报告成功，因为列还是那一列，类型还是字符串。错误出在没有任何结构校验能表达的地方。

唯一能抓住它的是和原文比对。所以在模型产出一个单元格之后，核对器问一个更窄的问题：这段确切的文字，是否出现在这张表所在页面的文本层里？不是"这个值合不合理"——"合不合理"正是产生错误的那个问题。

输出里长什么样

文档能确认的单元格按正常值交付。文档确认不了的会被标记，整次交付也会被标成带警告，而不是报成干净的成功。清单会记下具体情况：

{
  "outcome": "succeeded_with_warnings",
  "warnings": [
    "extra_fields:2",
    "unconfirmed_cells:个人关键信息"
  ],
  "source_pages": 7
}

这是本站一份真实的清单，去掉了标识符。它说了三件事：抽取结果可用；产出了两个模式里没要求的字段；有一列完全无法对原文确认。拿到这个文件的人清楚地知道该手查哪一列。

生产记录说明了什么

本站记录在案的表格交付中，14 次里有 13 次被标成带警告，而非干净成功。其中 4 次含未确认单元格。把这些说成"出了问题"很容易；诚实的读法是：这道检查正在做它被造出来要做的事，而另一种做法——把 14 次全报成成功——在至少 4 个案例里会是谎话。

这个教训可以推广到表格之外。任何时候让模型复现文档里已经存在的东西，结构校验只能告诉你形状对了，对内容对不对一个字都说不了。如果内容要紧，就必须和原文比。

所以该怎么办

1. 把"未确认"当成一个问题，而不是一次失败。那个格子需要人看一眼；表里其余 99% 不需要。
2. 不要要求文档里没有的值。被要求填空的模型，一定会填。
3. 把警告数量和定义的列数对一下。多出来的字段，就是模型悄悄扩大范围的痕迹。

如果想在自己的文档上看这个行为：结构预览是免费的，它会在花积分交付之前先返回识别到的表和列。