讲一下这个

回复 joye： 这篇讲的是 Cloudflare 发布 Clairic，一个新类别：System One 抽取模型。核心思路是，把“从杂乱输入中取值”这项任务从 LLM 中拆出来，交给一个只做单次前向、不生成 token 的专用模型。 为什么值得做 现在大量结构化输出请求都在调用前沿 LLM，而且形状反复出现：发票总额是多少、几号送达、迟了几天、运费多少、明天流量多少。这些任务其实用不上推理，用 LLM 就是拿最贵的模型做最笨的活：慢，按输出 token 收费，还可能把数字生成错、JSON 不合法，而且取出来的内容没法回溯到原文。 三类模型的分工 Clairic 管“值”：文本抽取、数量、日期、时长、列表、估计、预测，输出带类型的值，附置信度。 Clef（也是 TypeSafe 的）管“选”：在给定选项里挑一个，输出各选项的校准概率。 LLM 管“写和推理”：为什么、怎么处理、帮我修。 关键设计细节 请求就是一个 state（文本加最多 4 张图）加一组带类型的 fields，一次并行前向全部算完。没有输出 token，所以只按输入计费，通常亚秒级返回。 每个字段返回强制类型的结果，金额就是两位小数，日期就是 ISO 格式；还有 p_null（这个值不在输入里的概率）和 confidence。 character offset span 让结果可回溯到原文位置；找不到就返回 null，而不是编一个看起来像的。 字段数不限，塞不进一次 pass 就服务端拆成并行多路，每路都看完整输入，再合并。所以问 30 个字段和问 3 个字段成本差不多。 estimate 返回的是分布，不是单点：你给 [min,max] 和网格，它给中位数加 p10–p90；forecast 按步给未来值加区间。 官方跑的例子 客服邮件那条：amount_paid 邮件里没写，它把 649 加 52.1 一步算出 701.1；days_since_delivery 从两个日期推出 11 天；damage 抽成两个精确 span；tracking_number 不存在，返回 null 并把“本来会选错的 $52.10”放在 guess 里。这个 null 加 guess 的设计挺实用，方便你看它被试错成什么。 TSA 客流预测实测 21 天，平均误差 3.3%，21 天里 17 天落在 80% 区间内，符合区间定义；四天超出的里有三天在哥伦布日周末，因为序列本身没有节假日特征。 性能对比（Clairic → Clef → GLM-5.3 对比全用 GLM-5.3） 端到端 19.3s 对 61.7s，快 3.2 倍；每百万次成本 6032 对 美元，省 49%。抽取环节 0.46s 对 16.1s，决策 0.22s 对 21.9s。还有一点更重要的差别：Clairic 的维修估价每次一样，GLM 每次都在变（250 250 220，区间也不同），说明抽取任务需要的是确定性而不只是“差不多对”。文中提到 Gemma 4 和 Qwen 在全 LLM 版本里这个任务直接失败。 我的判断 这事的真正意义不在“又一个便宜模型”，而在于把 agent pipeline 里最脏、最高频的那一段（非结构化到结构化）变成可审计的类型化步骤。三个接着往下收敛：Clairic 出值，Clef 基于五行摘要做决策，LLM 只见决策和必要事实、根本没看到原始邮件，prompt injection 面也跟着收窄了。以前做这类系统只能堆解析层、schema 校验、重试和人抽检。 要泼的冷水 现在只是 Workers AI 上的 preview checkpoint，官方自己说读到很强但多步算术还不行，开放权重是“将要”。extraction 类任务分布外风险比 LLM 高：字段语义稍微一偏，它照样给你一个高 confidence 的错值，所以 still 得靠 confidence 和 p_null 做路由，并不是免检。预测那块也只是“比 LLM 好、比专用时序模型省事”，官方明说不替代专用模型，节假日这种序列外的信息它没有。 对你这类做 agent 的：值得看的是它的接口形状——state 加 typed fields、一次 pass、null 加 guess、offset span。这套 schema 直接决定了上层怎么编排和怎么断言，比模型本身能不能用更值得抄。