别再让大模型吐 JSON 了：Cloudflare 推出不生成 token 的抽取模型 Clairic
Cloudflare 在 Workers AI 上预览抽取模型 Clairic：不生成 token，按字段类型直接解码，输入每百万 token 0.10 美元、不收输出费，权重计划“很快”开放。
一个常见的需求
大家可能都遇到过这样的需求：从一封客服邮件里，拿出订单号、金额和到货日期。
这件事听上去很简单，人看一眼就知道。
但是，交给程序去做，就有点麻烦。
现在最常见的做法，是把邮件丢给大模型，再附一段提示词："请提取以下字段，以 JSON 格式返回。"
大模型确实能做到，大多数时候也做得不错。
问题在于"大多数时候"。
它可能多写一句客套话，可能漏掉一个括号，可能把日期写成你没想到的格式，还可能在原文没有的情况下，自己编一个订单号出来。
所以，很多程序在大模型后面，还要再接一层校验代码，检查 JSON 能不能解析，字段类型对不对，不对就重试。
那么，一个让人好奇的问题就来了：抽取字段这件事，是不是一定要让模型"写"出来？
10 月 19 日，Cloudflare 给出了一个不同的答案。
Clairic 是什么
据 Cloudflare 官方博客和 Workers AI 更新日志，Cloudflare 在 Workers AI 上推出了一个预览版的抽取模型，叫做 Clairic，模型名是 @cf/cloudflare/clairic。
它最大的特点是：不生成 token。
普通的大模型，是一个字一个字往外写答案的。
Clairic 不这样做。官方称，它一次前向计算读完全部输入，然后按照你指定的字段类型，直接把答案解码出来。
所以，它的答案必然是一个合法的类型值，或者是 null（表示原文里没有）。
打个比方，普通大模型像一个答题时自由发挥的学生，你让它填表，它可能在表格外面写满了字。
Clairic 更像一张印好格子的表格，日期栏只能填日期，金额栏只能填数字，填不出来就空着。
（这个比方是我自己打的，不是官方的说法。）
能抽哪些类型
官方文档列出的字段类型如下。
1、text：返回原文里的精确片段，同时给出字符偏移，也就是这段文字在原文的什么位置。
2、number：数字。
3、date / time / datetime：日期、时间、日期时间。
4、duration：时长。
5、list：列表。
6、estimate：估计值。你给出最小值、最大值和步长，它在这个范围里给出一个分布，包括中位数和 80% 区间（p10–p90），也可以要求返回全部 99 个分位数。
7、forecast：序列预测，最多预测 64 步。
每个答案还附带 p_null 和 confidence，前者大致可以理解为"原文里没有这个值"的可能性，后者是置信度（这一层解释是我的理解，以官方文档为准）。
另外，每次请求最多可以附 4 张图片，格式支持 PNG、JPEG 和 WebP。
这里面最有意思的，是 estimate 和 forecast 这两种类型。
一般的抽取，是"原文里写了什么，就拿出什么"。
estimate 不一样，原文里可能根本没有一个确切的数，它要做的是"根据原文，估一个范围"。
举一个假设的场景：一段房源描述里没有写面积，只写了几室几厅、朝向和楼层，你让它在你给定的范围里估计面积。
这时候，它不会硬编一个看起来很精确的数字，而是给出一个分布，告诉你中位数大概在哪里，80% 的可能落在哪个区间。
一个带区间的答案，比一个假装精确的答案更诚实。
forecast 则是把这个思路用到序列上，根据输入里的历史数据，往后推若干步。
我觉得 text 类型返回字符偏移这一点，特别实用。
因为你拿到的不只是一个答案，还知道它出自原文哪里，可以直接回去核对，或者在界面上把原文高亮出来。
字段多，成本不一定高
Clairic 的上下文长度是 65,536 个 token。
字段数量不设上限。
官方的说法是，放不进单次 8,192-token pass 的字段，会拆成多个并行的 pass 来处理，所以要 30 个字段和要 3 个字段，成本差不多。
这跟大模型的思路很不一样。
用大模型抽字段，字段越多，它要写的 JSON 越长，输出 token 越多，花的钱和时间也越多。
Clairic 没有"写"这一步，自然也就没有这笔开销。
价格和速度
价格是输入每百万 token 0.10 美元，没有输出费用。
官方称，通常 1 秒内返回结果。
Cloudflare 还说，计划"很快"开放权重。具体时间，官方没有给出。
抽值、判断、执行
Cloudflare 博客把 Clairic 放在一条流水线里介绍。
第一步，Clairic 负责抽值，从输入里拿出带类型的字段。
第二步，Clef 负责判断。据官方介绍，Clef 是一个决策模型，在你预先设定的几个选项里，给出每个选项的概率。
第三步，才轮到大模型，负责写回复和执行动作。
博客里举了一个客服邮件的例子，从邮件里抽出订单号、金额和到货日期。
还有一个 21 天的预测例子。据 Cloudflare 博客自报，平均误差为 3.3%，21 天中有 17 天落在 80% 区间之内。
这种分工，我觉得很有道理。
大模型擅长写和推理，但是让它做填表这种死板的活，就像请一位作家来抄写发票，不是不能做，而是用错了地方。
把"拿数据"和"做决定"从大模型那里拆出来，交给更专门的模型，大模型只做它最擅长的部分。
（这段评论是我的看法。）
它不擅长什么
难得的是，Cloudflare 在博客里写明了这个模型的局限。
（1）一两步的算术可靠，但是长链条的计算、跨多行的聚合，它做不好。官方建议，把需要的值抽出来以后，在代码里计算。
（2）多步预测会趋向平缓。
（3）在陌生的数据上，给出的区间可能偏窄。
（4）格式对，不等于答案对。
我觉得第 4 条最值得记住。
Clairic 保证的是"类型合法"，日期栏里一定是日期。但是，那是不是正确的日期，模型并不能保证。
类型约束解决的是格式问题，不是正确性问题。
所以，校验这一步不能省，只是从"检查 JSON 能不能解析"，变成了"检查值对不对"。
我的看法
结构化抽取，是 AI 应用里最常见、也最不起眼的一类工作。
邮件、票据、表单、合同，每天都有大量这样的文本需要变成数据库里的一行。
过去几年，大家习惯了什么事都交给大模型。Clairic 提醒我们，有些事情其实不需要"生成"。
它目前还是预览版，权重也没有开放，效果怎么样，需要大家拿自己的数据去测。
如果你需要从邮件、票据里批量抽取字段，又不想再写一层 JSON 校验和重试代码，可以试试它。
（完）
来源：Cloudflare 官方博客（2026-10-19）；Workers AI 更新日志；Workers AI 模型页；抽取模型概念文档。Clairic 为预览版；3.3% 平均误差、21 天中 17 天落在 80% 区间等效果数字为 Cloudflare 自报，“通常 1 秒内返回”为官方说法，未见第三方评测；价格以模型页为准；开放权重暂无时间表。