Cloudflare Clairic：零输出token的抽取模型实战指南

Cloudflare 在 Workers AI 上推出了一款名为 Clairic 的抽取模型，它不生成任何输出 token，只返回结构化字段答案。这种设计让抽取任务更快、更便宜，但也带来一个新问题：你该读哪个字段？本文基于官方文档和第三方分析，给出一份可落地的接入指南。

什么是 Clairic：一次前向传播完成抽取

据 Cloudflare 官方博客，Clairic 于 10 月 19 日发布，模型 ID 为 @cf/cloudflare/clairic，定位为“System One”抽取模型。你传入文本和一组带类型的字段定义，模型在单次前向传播中为每个字段返回一个值。它不写文本，也不产生输出 token。这与 Clef 形成互补——Clef 是 Cloudflare 在 10 月 1 日发布的决策模型，返回固定选项上的概率分布（据 Unite.AI 和 eWeek 报道）。

Clairic 能处理四类任务：抽取输入中已有的值、根据输入中的事实计算值、估计输入未固定的值、以及预测序列。官方示例展示了从开票日期加“net 30”计算到期日。定价方面，每百万输入 token 收费 0.10 美元，没有输出价格；上下文窗口为 65,536 token；每次处理可容纳 8,192 token 的字段加输入，更多字段会拆分到并行批次；最多支持 4 张嵌入图片（PNG、JPEG 或 WebP），不支持远程 URL。

需要注意两个风险提示：模型按“AS IS”和“AS AVAILABLE”提供，Cloudflare 可能随时停止服务且不退款；权重尚未公开，官方表示“很快”会发布，目前只能在 Cloudflare 端点运行。

前向传播与输出 token：在 Transformer 架构中，前向传播指输入序列从嵌入层、注意力层逐层计算到输出层的完整过程。传统生成式 LLM 需要在每次前向传播后采样一个 token，再把该 token 拼回输入、重新前向传播，直到生成终止符，因此输出长度直接决定推理次数与成本。Clairic 的“零输出 token”意味着它复用最后一次前向传播得到的表示，直接对每个字段做分类或回归，不进入自回归解码循环。这解释了为何它只按输入计费、速度更快，也解释了它为何不擅长多步算术——没有中间推理步骤可供展开。

核心陷阱：读 value，不要读 guess

官方文档示例中有一张发票，没有采购订单号。模型返回的 po_number 答案是 "value": null 和 "p_null": 1，但同一个答案对象里还有 "guess": "INV-2291"——那是发票号。如果你的代码读 guess，发票号就会落进采购订单列。这是接入前最需要知道的一条规则。

每个标量答案都包含多个键。以官方示例的 po_number 为例：type 是 text，p_null 为 1，span 为 [8, 16]，guess 为 INV-2291，confidence 为 0.9995，value 为 null。value 才是答案，p_null 表示输入中不包含该值的概率。guess 看起来像模型被迫选择时的猜测，而这里的 span 与发票号位置相同。Cloudflare 没有说明 value 为 null 时 confidence 衡量什么，所以 0.9995 旁边跟着 null 时，没有理由信任 guess。官方抽取模型页面指出，单值结果为 null 意味着模型认为输入信息不足。

因此，每个标量字段在写入数据前都必须经过门控。下面是一个 TypeScript 辅助函数，包含占位阈值（实际阈值应从标注样本中调整）：

type Scalar = {
  value: unknown;
  p_null: number;
  confidence: number;
};

function accept(a: Scalar, minConf = 0.95, maxNull = 0.05) {
  if (a.value === null) return { ok: false, why: "absent" };
  if (a.p_null > maxNull) return { ok: false, why: "unsure" };
  if (a.confidence < minConf) return { ok: false, why: "low" };
  return { ok: true, value: a.value };
}

这个函数覆盖文本、数字和日期答案，它们携带 p_null 和 confidence。列表返回带 span 和置信度分数的值，估计值返回 median、p10 和 p90 而非 p_null，需要单独检查。

p_null、span 与 confidence 的语义：p_null 是模型对“输入中不存在该字段值”给出的概率，属于校准前的原始分数；span 是答案在输入文本中的字符偏移区间，可用于回溯原文、校验抽取位置是否合理；confidence 是该答案对象的整体置信度，但 Cloudflare 未明确其在不同 value 状态下的定义。当 value 为 null 时，confidence 仍可能接近 1，这并不表示猜测可靠，而更可能反映模型对“该字段缺失”这一判断本身很确定。因此门控逻辑应优先检查 value 是否为 null 和 p_null 是否过高，再考虑 confidence，且三者都需在自有数据上校准后才能作为阈值依据。

让代码做算术，而不是模型

Cloudflare 博客直言短板：“读取很强，但多步算术还不行。”其建议是：“至少目前，让 Clairic 预测值，让代码做数学。”官方文档示例要求计算 total 字段并得到 1080。对于任何涉及计费的结果，应该请求组成部件，而不是直接要总和。

下面是一段未在端点上实际运行的示意代码，sendToReview 代表你自己的工作流：

const res = await env.AI.run("@cf/cloudflare/clairic", {
  model: "clairic",
  state: "Invoice 1042. 4 pallets at $250.00 each, "
    + "shipping $80.00, net 30.",
  fields: {
    quantity: { type: "number" },
    unit_price: { type: "number", decimals: 2, unit: "USD" },
    shipping: { type: "number", decimals: 2, unit: "USD" },
  },
});

const a = res.answers;
const parts = [a.quantity, a.unit_price, a.shipping]
  .map((x) => accept(x));
if (parts.some((r) => !r.ok)) return sendToReview(res);

const [q, p, s] = parts.map((r) => r.value as number);
const total = q * p + s; // 4 * 250 + 80 = 1080

这样即使某个数字读错，也可能表现为该字段分数偏低，而算术留在可测试的代码里。

字段定义就是账单的大头

官方示例响应报告了自身用量：61 个 state_tokens 用于发票文本，472 个 schema_tokens 用于字段定义，总计 655 个 input_tokens，output_tokens 为 0，passes 为 3。在短输入上，字段名和指令的成本大约是文档本身的八倍。

按每百万输入 token 0.10 美元计算，这次 655 token 的调用成本为 0.0000655 美元，即每百万次调用 65.50 美元。Workers AI 每个账户每天有 10,000 个 Neurons 免费额度，定价页面列出 Clairic 为每百万输入 token 9,091 个 Neurons，因此免费额度大约覆盖每天 110 万输入 token。保持指令简短，把同一文档的多个字段批量放在一次调用中，而不是每个字段调一次。

Neurons 与 Workers AI 计费：Neurons 是 Cloudflare Workers AI 的统一计量单位，不同模型按每百万输入/输出 token 折算成不同的 Neuron 数量，账户每天有 10,000 个免费 Neuron 额度。Clairic 每百万输入 token 计 9,091 个 Neurons，意味着免费额度大致对应每天约 110 万输入 token。由于 Clairic 没有输出 token 计费项，成本完全由 state_tokens 与 schema_tokens 决定；在短文档场景下 schema 占比极高，因此压缩字段名、合并同文档多字段到一次调用，是控制成本最直接的手段。

记录分数，然后校准它们

Cloudflare 的头条数字来自内部测试。在一个损坏产品索赔流程中，Clairic 做抽取、Clef 做决策、GLM-5.3 做回复，耗时 19.3 秒，每百万索赔成本 6,032 美元；GLM-5.3 独自完成三步耗时 61.7 秒，成本 11,740 美元。这一差距就是 Cloudflare “降低 49%” 说法的来源。但据 PPC Land 指出，该对比是 Cloudflare 自己的测试，只覆盖一种索赔类型，且未说明平均了多少次运行。

博客还写道：“校准是测量出来的，不是保证的。”在你自己的发票上，0.95 的置信度可能并不代表 95% 正确。唯一知道的办法是记录模型输出，并与人工后续确认的结果比较：

console.log(JSON.stringify({
  field: "unit_price",
  value: a.unit_price.value,
  p_null: a.unit_price.p_null,
  confidence: a.unit_price.confidence,
  input_tokens: res.usage.input_tokens,
}));

把这些日志与复核队列中的修正值关联。每个字段积累几百条后，你就能看出每个置信区间实际带来多少准确率，并据此调整 accept() 中的阈值。Cloudflare 的指导也指向同一方向：在不可逆操作前考虑人工审核。

置信度校准（calibration）：校准指模型输出的置信度分数与实际正确率之间的一致性。一个校准良好的模型，在置信度 0.95 的样本中应有约 95% 正确；但未经校准的分数往往过度自信，尤其在分布外输入上。常用度量包括期望校准误差（ECE）和可靠性图：把样本按置信度分桶，比较每桶平均置信度与实测准确率。对 Clairic 而言，应把日志中的 confidence 与人工复核结果关联，按字段分别绘制可靠性图，再据此设定 accept() 的阈值；不同字段的校准曲线可能差异很大，不能共用一个全局阈值。

是否该把抽取任务移出 LLM？

如果你已经付费让 LLM 把邮件、收据或表单转成 JSON，Clairic 值得一试。它返回带字符偏移和字段缺失概率的类型化字段，比裸 JSON 字符串提供更多信息。Cloudflare 称该端点“是一个早期检查点，我们预期它会变得更好”。

但目前建议把 LLM 路径保留在同一接口后面。模型是预览版，仅由 Cloudflare 托管，且条款允许 Cloudflare 撤回。在你自己的标注样本上同时运行两者，并按字段比较。本文作者尚未亲自运行 Clairic，因此文中数字应视为 Cloudflare 的数据。

一个值得思考的问题：一个告诉你字段多可能缺失的模型，是否比一个总是返回格式良好 JSON 的模型更值得信任？答案取决于你是否愿意为可测量的不确定性付出接入成本。

总结：接入前的检查清单

如果你要尝试 Clairic，保留上一节的日志行。每个字段的值、置信度和 token 计数记录，是你后续调整阈值或更换模型的依据。具体来说：始终读取 value 而非 guess；对每个标量字段做门控；让代码处理算术；把字段定义压缩到最低；记录并校准置信度分数。

Clairic 代表了一种“零输出 token”的抽取范式，优势在于成本和速度，代价是引入了新的字段语义复杂性。把它当作流程中的一个可测试组件，而不是一个黑盒答案生成器，是当前最稳妥的接入方式。