从提取结果到工单分流，字段状态应当对应下一步动作

Red Hat于2026年10月27日介绍了Atos的一项小模型结构化提取试验。供应商案例提供了一个观察入口，但本文不据此判断模型优劣，而讨论提取结果进入业务记录后的一项设计责任。案例原文

一张表格填得整齐，很容易让接收者以为每一格都经过同样的判断。然而，字段留空可能意味着原文没有提到、系统没读到、多个说法无法取舍，也可能意味着这个问题根本不适用。这些情况需要不同的后续动作。如果接口只交付一个空白，接收系统就得自行猜测，而猜测往往藏在默认值、重试规则和报表口径里。

空值怎样变成业务判断

下面是一个假设的售后工单流程，并非Atos案例的实施细节。客户写道：“上周收到替换件，原来的问题仍在。”提取程序需要填写订单日期、产品型号和故障是否解决。文本没有给出订单日期；产品型号可能出现在附件；“仍在”则需要与具体问题关联。若三个字段都填成空值，系统既无法知道该索要订单凭证，还是重新读取附件，也无法判断应否继续处理原故障。

JSON Schema官方文档明确区分了null与属性不存在。这个技术区别并不会自动给业务状态命名。团队仍须约定：缺失属性表示旧版接口不提供此字段，还是本次处理没有运行？显式空值表示无法确定，还是确认没有？把这些含义留到接入时再讨论，会让不同消费者各自形成一套答案。

一种可考虑的做法，是为重要字段同时保存值和处理状态。状态可以区分“原文未提供”“存在冲突”“尚未处理”和“有依据的结果”，但不必给所有字段都配一套庞大枚举。真正需要分开的，是那些会改变下一步动作的情况。低风险标签或许允许简单留空；决定退款、资格或账户处置的字段，则值得更细的交接约定。这里提出的是设计选择，不是通用行业标准。

保留解释空白的材料

状态标签本身也可能出错。因此，关键字段最好能回到对应输入版本和原文位置。保存一段支持材料，并不等于证明判断正确；它让复核人员有机会发现材料是否答非所问、是否漏掉限制条件。对于“未提供”的判断，还应明确已处理的范围：正文没有，不代表未读取的附件也没有。

仍以上述工单为例，系统可以把订单日期标为“正文未提供”，把型号标为“附件待处理”，把故障状态连到那句客户描述。这样，业务队列能够分流：第一项可能需要补充材料，第二项需要完成读取，第三项需要判断是否足以支持继续售后。没有必要要求模型为了完成一张表而替用户补全日期。保留未知，是把下一项工作交给合适的环节，而不是宣布流程失败。

这种约定也约束格式清洗。把“上周”转换成日期区间，需要参考日期和时区；把昵称归一为客户姓名，需要身份关联依据。如果输出只保留规范化后的值，复核者很难辨别原文说了什么、系统补做了什么。对高后果字段，保留原始表达、转换规则版本和结果之间的关系，比单独保留一个看似标准的字符串更有用。

自动化收益要与复核负担一起计算

更细的状态并非免费。它增加存储、界面和培训负担，也可能让人工队列膨胀。团队需要判断哪些未知值得拦截，哪些可以暂存，哪些不影响当前任务。例如，型号暂缺可能不妨碍登记投诉，却可能妨碍寄出替换零件。同一个字段在不同动作前，可以有不同的放行要求；不应把一次提取的结果当成永久通行证。

衡量改进时，只看字段填满率会鼓励系统把不确定内容写进去；只看转人工比例，又可能惩罚合理的谨慎。更有解释力的做法，是把最终处理结果与当时状态联系起来：哪些“有依据”后来被纠正，哪些“未提供”其实源于读取遗漏，哪些复核没有带来新的可用信息。这样的记录帮助团队调整具体环节，而不是把所有失败都归到模型能力上。

另一种合理观点是，早期产品应先用简单接口验证需求。对于低后果、可逆且人工逐条查看的任务，这可以减少过早设计。问题在于，接口常常在没人宣布的情况下获得新用途：原本供人参考的字段被报表引用，再被自动规则消费。若用途变化没有触发约定复审，最初可以容忍的含糊就会被放大。

因此，新增状态或改变空值含义时，需要像修改字段类型一样通知下游。可以保留样例输入及预期交接结果，检查升级后消费者是否仍把“未知”解释为“否”。历史数据也不应在没有说明的情况下套用新口径，否则缺失率变化可能只是定义变化，被误读为业务改善。

结构化提取的价值，在于让文本进入可协作的流程。这个流程需要知道何时能行动，也需要知道何时还缺一份材料。模型可以承担提取工作；字段的含义、允许的默认行为以及未知由谁继续处理，仍须由使用它的组织明确下来。