先看证据
把机制串起来
生成式 LLM 通常先写出一段答案，再由程序解析成 JSON；即使 JSON 格式合法，里面的值也可能错。Clairic 把字段名和类型当作请求的一部分，目标是直接返回可用的类型化值；但结构正确不等于事实正确，仍需校验。
请求由原始文本或最多 4 张图像组成的 state，以及带名称、类型和说明的 fields 构成；模型按字段返回文本、数字、日期、估算或预测等值，而非生成一段供解析的答案。官方所说的“一次前向计算”指字段能与输入一起放进同一计算时；字段过宽就拆成多个并行计算，每次仍读取完整输入。因而字段没有固定上限，却不代表宽 Schema 免费：字段说明会占输入 token，官方示例中 61-token 发票因 Schema 拆成 3 次，计费输入达 655 token，其中 472 to
['适合发票、邮件、票据等重复的类型化抽取', '字段说明要精简；宽Schema可能拆批并抬高成本', '缺失值用p_null辅助判断，关键字段仍须复核', '多步算术、跨行汇总和长周期预测别单独依赖']
从生成一段话，转向交付字段值
Cloudflare于2026年10月19日将Clairic作为Workers AI预览模型发布，面向从非结构化文本或图像中提取金额、日期、编号等信息的任务。开发者过去常把这类工作交给通用大语言模型，让模型读完发票或邮件后生成JSON，再由程序解析和检查。Clairic的做法不同：调用方先声明需要哪些字段及其类型，模型直接返回对应的值，而不是先写一段自由文本。
这一变化的关键不在于“结构化输出”这个目标本身，而在于模型和业务程序之间的接口变了。传统生成流程把自然语言生成、格式遵循和事实抽取混在一次回答里，格式出错时还要处理解析失败。Clairic试图把交付物收窄为数字、日期、文本片段或空值，让程序更容易接手。但类型正确只能说明结果长得符合预期，不能证明其中的金额或日期就是事实。
Cloudflare把这类模型放在一个三层分工里理解：抽取模型把原始输入转成类型化值，决策模型在给定选项中作选择，通用LLM再把决定组织成文字。Clairic处理的是“答案无法预先列成选项”的问题，例如一张发票的总额是多少。它与Cloudflare的Clef、TypeSafe的Jev不同，后两者属于决策模型，主要是在预先列出的候选项之间评分。这样的拆分有工程上的吸引力，因为不同环节可以用不同接口和模型承担，但也意味着系统设计者必须先判断任务究竟是抽取、选择还是生成。
字段不是免费的控制层
一次请求由输入内容和一组命名字段组成，字段可附带类型、自然语言说明和可选约束。支持的类型包括文本、数字、日期、时间、时长、列表、估算和预测。文本结果可以标出它在原文中的位置，标量结果带有confidence和p_null，后者表示模型认为该值不存在的概率。估算和预测可以返回中位数及从p10到p90的80%区间，预测最多覆盖64步。
这种接口不仅是在规定输出格式，也是在描述任务本身。Clairic可以从邮件中的金额和税额计算总价，也能根据日期计算经过天数，因此它并非只把原文逐字抄进字段。Cloudflare展示的例子中，邮件没有出现最终总额，模型仍计算出701.10美元，也计算出自送达以来经过11天。对只需要一两步的局部计算，这种能力可以省去额外的模型调用，但官方也说明，多步算术和跨多行汇总并不可靠。
“一次前向计算”也不能理解成字段再多都只执行一次。字段放不进输入所在的一次计算时，系统会将任务拆成多个并行计算，每次仍读取完整输入。官方文档中的一个61-token发票请求拆成了3次，计费输入达到655个token，其中472个来自字段定义。这个例子揭示了容易被忽略的成本：文档很短，不代表请求就轻，字段说明过宽也会占用输入预算。Cloudflare称字段没有固定数量上限，但工程上的上限仍受输入容量和实际计费影响。
索赔流程显示了分工收益，也暴露了瓶颈
Cloudflare公布的主要性能比较来自一条损坏商品索赔流程。组合方案由Clairic抽取事实、Clef在退款与维修之间作选择，再由GLM-5.3撰写回复；对照方案则让GLM-5.3处理全部三个环节。Cloudflare报告称，组合方案总耗时19.3秒，对照方案为61.7秒。每百万条索赔的估算成本从11,740美元降到6,032美元，约减少49%。
分项数据说明，收益集中在前两段。抽取环节从GLM-5.3的16.1秒降到Clairic的0.46秒，决策环节从21.9秒降到Clef的0.22秒。可是在19.3秒的组合流程中，生成客户回复仍耗时18.6秒，几乎占据全部总时长。换句话说，专用模型加快了事实整理和决策，却没有让需要自然语言表达的最后一步消失。要优化端到端体验，团队仍须检查剩余生成步骤，而不能只看抽取模型的单次延迟。
这个案例也包含质量和复现方面的限制。Cloudflare称两种流程都正确抽取了事实并作出正确决定，Clairic给出的维修估价在多次运行中保持一致，而GLM-5.3三次返回了250美元、250美元和220美元。公司还称Gemma 4和Qwen在全LLM方案中失败，但没有在材料中给出完整测试协议或标准化准确率基准。因此，19.3秒、61.7秒和成本差异应被读作特定索赔流程的公司测试结果，而不是所有抽取任务都能获得的普遍加速比例。
置信度与空值是信号，不是免责条款
Clairic把缺失值也纳入了返回接口，这一点对业务流程很重要。通用模型面对缺字段时，可能会生成一个听起来合理的补全；Clairic可以返回null，并同时给出p_null和confidence。Cloudflare展示过一封缺少追踪编号的邮件，模型没有编出编号，而是返回null。另一张倾斜的收据照片里，它读出了7个存在的值，并把缺失的折扣识别为空值，最低置信度是订单号上的0.776。
这些信号能帮助系统决定哪些字段进入自动处理，哪些字段需要复核，但不能直接当作正确性证明。置信度是模型对答案的信号，p_null表达的是模型对缺失状态的判断，两者都可能在陌生数据上失准。Cloudflare的官方文档特别提醒，预测区间在陌生数据上可能偏窄，格式正确的输出也仍可能答错。对于退款金额、身份信息或合规记录，业务规则和来源核对仍应承担最终把关责任。
预测示例进一步说明了“有区间”与“已校准”不是一回事。Cloudflare称，Clairic对TSA检查点客流连续预测21天，平均误差为3.3%，实际值有17天落在模型给出的80%区间内。4次区间外结果中有3次发生在哥伦布日周末，这个背景提示节假日可能构成特殊变化，但短样本不足以证明模型在节假日普遍失效或可靠。21天的单项测试可以展示模型如何表达不确定性，却不能替代跨时间、跨场景的校准评估。
适合先做窄任务验证，不适合跳过治理
部署条件决定了Clairic目前更像一个可接入的云端组件，而不是可自行托管的模型。它以预览版运行在Cloudflare托管GPU上的Workers AI，模型入口为`@cf/cloudflare/clairic`，上下文窗口为65,536个token，每次请求最多支持4张图像。Cloudflare计划开放模型权重，但没有给出发布时间，所以目前没有本地部署选项。对需要把数据留在自有环境、或必须控制模型版本的团队，这不是次要细节，而是上线前的架构约束。
当前价格是每百万输入token 0.10美元，模型不生成输出token，因此官方称不收输出token费用。这个计价方式让模型输出短、字段清楚的抽取任务看起来有吸引力，但字段定义也会计入输入，分批计算还可能重复读取完整输入。成本测算应以真实请求的文档长度、字段数量和拆分行为为基础，而不是只看标价或模型是否“零输出token”。若每条记录的schema比正文更长，低输入单价不一定能转化为低端到端成本。
技术负责人可以从范围窄、答案可由现有规则校验的字段开始试用，例如发票日期、订单编号或明确的金额，再用内部样本观察缺失值、置信信号和字段错误如何分布。对于长链计算、跨行汇总和长周期预测，不应仅凭这次预览功能推断适用性。现阶段最稳妥的判断是把Clairic放进可回退、可审计的抽取环节，保留业务校验和人工复核，并单独测量包含schema开销的成本与端到端延迟。等权重、独立评测和更完整的适用边界公开之后，再决定是否扩大自动化范围。