不写一个字，只读一张单：Cloudflare Clairic 把「发票总额是多少」变成确定性填空题

过去两年企业上 AI，最常见的第一刀都砍在单据处理上：发票录入、运单核对、合同要素提取、报销单据审查。逻辑看起来天衣无缝——大模型读懂自然语言，单据就是自然语言写成的，所以让大模型读单据天经地义。

真跑起来才发现别扭。你要的是「金额 1203.50 元」这一个数字，模型却先写一段「根据您提供的发票信息，总金额为……」；你要的是结构化数据，模型偶尔给你一个多了括号的字符串；最要命的是幻觉——发票上明明没有折扣项，它会一本正经地编一个出来，因为它的训练目标就是「写出看起来合理的东西」。

工程上的补丁层出不穷：提示词里写十遍「只输出 JSON」「不确定就返回空」；后端再加一层正则校验、一层类型转换、一层业务规则兜底；最后还要配人工抽检。这一整套「防模型乱说话」的工程量，很多时候比模型调用本身还贵。问题不在工程师，而在于用生成式模型干抽取的活，本来就是错配。

Clairic 的做法相当决绝：它根本不生成词元。你提交一段输入（文本，最多再带 4 张图片）和一张字段表，定义好每个字段的类型——文本、数值、日期、时间、日期时间、时长、列表、估算、预测——它在一次并行前向传播里把每个字段的值解出来，通常不到一秒。

没有词元就意味着没有「写错一个字母」这件事。金额字段解码出来一定是符合两位小数规则的数，日期字段一定是真实存在的日历日，文本字段返回的是原文里真实存在的片段，还带着字符偏移量，你可以反查到它在原文的哪个位置。

最有意思的设计是它对「不知道」的处理。每个标量答案都带两个指标：p_null（输入其实没有决定这个值的概率）和置信度。当模型判断输入不支持这个字段时，它返回空值——而不是编一个。文档里还提到会附带一个猜测字段，告诉你「如果非要它猜，它会猜什么」，但这个猜测不会进入正式答案。对财务、法务、结算这类场景，「明确说不」比「给个差不多的」值钱得多。

官方把答案分成四类，这个分类本身就很实用。第一类是抽取：原文里写了什么就抄什么，比如发票号、联系人姓名、订单编号，返回精确片段加偏移量。第二类是计算：原文里能推出来的值，比如「含运费的应付总额」「签发日加上账期的到期日」「发货日到投诉日之间隔了多少天」。

第三类是估算：原文没有明说但有证据的值，比如根据周边成交描述估一套房子的价格。这类答案会给一个分布——在你声明的上下界与步长网格上，返回中位数和 80% 区间。第四类是预测：给一个序列，预测未来若干步，最多 64 步，每一步自带区间。

官方给出的例子都很接地气：一封客服邮件里，它算出 649.00 美元加 52.10 美元税等于 701.10 美元，算出 9 月 28 日发货到 10 月 9 日来信间隔 11 天，把「屏幕碎裂」「边角磕碰」作为原文片段摘出来，同时对邮件里根本不存在的运单号返回空值。一张收据照片里，它把订单号、购买时间、数量、单价、小计、税、小费逐项抽出并给出置信度，对收据上没有的折扣返回空值。

值得单独说的是估算与预测为什么一定带区间。企业里大量的 AI 需求本质上是预测：这批货大概什么时候到、这台设备还能撑多久、下个月的客流大概多少、这笔维修大概多少钱。用大语言模型问这种问题，得到的往往是一个孤零零的数字，没有任何不确定性信息——这在工程上是危险的，因为你没法据此设置阈值。

Clairic 强制给出 80% 区间（需要时还可以返回全部 99 个百分位），这就让「自动化到什么程度」有了一把尺子。官方的 21 天预测测试里：预测次日机场安检客流，平均误差 3.3%，21 天里有 17 天的真实值落在区间内；4 次未命中的里有 3 次集中在哥伦布日假期周末。10 月 14 日那天，实际 2,419,474 人次，预测中位数 2,419,283——这种精度的对照，比任何广告语都更有说服力。

更有价值的是那个误差分布：模型自己知道什么时候不确定（假期周末），而这正是业务系统需要的信号。遇到宽区间的预测，流程自动转人工或降级处理；遇到窄区间，直接放行。这就是「置信度驱动的流程分派」，也是 AI 真正能进核心业务的前提。

最有说服力的测评是官方给出的级联对比。一个破损商品理赔流程，拆成三步：从客户来信里抽取事实、判断是否赔付、给客户写回复。全用 GLM-5.3 做，全流程 61.7 秒；改成「Clairic 抽取 + Clef 决策 + GLM-5.3 写回信」，全流程 19.3 秒，快了 3.2 倍。

成本对比同样明显：处理每百万件理赔，全大模型方案 11,740 美元，级联方案 6,032 美元，降了 49%。其中抽取加决策两步加起来不到一秒，而 GLM-5.3 单独做这两步要 38 秒。官方还提到在对照组里，另外两个常用模型无法推导出维修成本这类值，导致任务直接失败。

这组数字背后的架构观值得每个做 AI 应用的人记住：把一件事拆开，每个环节用最合适的工具。抽取用抽取模型、决策用决策模型、回复用生成模型，而不是一个全知全能模型包打天下。这和软件工程里「一个模块只做一件事」是同一个道理，只是行业花了两年才重新想起它。

定价上 Clairic 是每百万输入词元 0.10 美元，因为没有输出词元，输出侧费用为零。传统计费模型里，抽取任务的输出往往是结构化内容，虽然不长但计费不低，业内估算能占到整体成本的三到五成。现在这部分直接消失。

对大批量单据处理来说，这个结构的意义大于数字本身：成本变得完全线性可预测——你只要估算自己每月要处理多少字的输入，账单就算出来了。做预算的人最怕的不是贵，是算不准。

还要注意两点。一是当前它是托管在 Workers AI 上的云服务，数据要过云端，合规敏感业务需评估；二是官方明说是早期检查点，权重开放没有日期。对国内企业而言，近期更现实的用法是把它当作架构参照——照着这个思路设计自己的抽取环节，用国产可私有化的组件实现，而不是直接把业务搬上去。

Cloudflare 在文档里坦白了自己的边界，这种坦白值得赞许，也必须在选型时被认真对待。官方说：一到两步的算术——求总额、算差额、做单位换算、算日期差——看起来是可靠的；但更长的依赖步骤链、跨多行表格的聚合，对一个没有草稿纸的单次前向传播模型来说仍然困难。

这个局限划定了清晰的适用边界。适合它的任务：从一份单据里抽出十几个字段、做一两步推导、给出带区间的估算或预测。不适合它的任务：跨二十行明细逐项加总核对、需要多步中间变量的复杂核算、需要回溯修正的长推理。后者仍应交给生成式模型或传统的确定性程序。

还有一个工程提示：单次前向传播的输入窗口是 8192 词元，字段多到放不下时会拆成多个并行批次，每个批次都能看到完整输入，最后合并——所以字段数量没有上限，但延迟会随批次数上升。做极致延迟优化时要考虑这一点。

把这场发布放回企业的日常，它的价值不在技术新鲜感，而在于把一类老大难问题从「AI 问题」降级成了「流程问题」。过去单据自动化的失败，绝大多数不是读不懂，而是不敢信——读出来八成对、两成幻觉，就必须配 100% 人工复核，自动化的收益被复核成本吃光。

有了带 p_null 与置信度的类型化答案，复核第一次可以被量化：置信度高于阈值自动过账，低于阈值转人工，中间地带抽检。人力从「每张都看」变成「只看看起来有问题的那几张」，这才是自动化真正该有的样子。而空值的存在让系统可以诚实地告诉业务：这张单子上缺一个字段，请补——而不是悄悄编一个填进去。