Cloudflare 发布 System One 抽取模型 Clairic，上线 Workers AI 预览

今天，我们宣布推出一类全新的 System One 风格模型预览版：抽取模型。我们的首个模型 Clairic 已托管在 Workers AI 上，可通过 @cf/cloudflare/clairic. 使用。我们计划很快发布该模型的开源权重版本。Clairic 是一个抽取模型，能够从非结构化输入中抽取、计算、估计和预测数值——相比传统 LLM，其准确率显著更高、延迟更低、成本更便宜。

背景

一个月前，TypeSafe 发布 System One 模型时，整个行业为之震动。正如 TypeSafe 在其博客中 所引用、并由 Daniel Kahneman 的著作 《思考，快与慢》 所定义的那样，System One 模型应当快速且精确，这与具备审慎推理能力的 System Two 模型（如 LLM）形成对比。基于此，TypeSafe 推出了 Jev——一个针对特定用例量身定制、并因其细分领域而定价亲民的模型。它在 LLM 表现不佳的地方表现出色，帮助用户基于概率和类型良好的输出做出决策。Jev 的推出促使人们开始思考一类并非 LLM 的新型模型，以及如何将它们集成到自己的工作流中。

我们受到 System One 模型概念的启发，开始思考其他 LLM 效率低下的任务。如今有大量结构化输出调用发往前沿 LLM，且形状反复相同：发票总额是多少？何时送达？迟了多少天？这次维修要花多少钱？未来 24 小时的交通状况会怎样？ 这些问题的答案都无法事先列出，而决策模型需要事先列出答案才能给出概率。这引导我们走向今天推出的这类模型：System One 抽取模型。

推出 System One 抽取模型

到目前为止，所有 System One 模型都是决策模型：Jev 和 Clef 接收一个输入状态和一组问题，并针对输入和你列出的问题给出概率。Clairic 是全新类别中的首个模型：System One 抽取模型。它同样快速、类型化且成本低廉，但它以数值作答——这些数值直接从输入中抽取、由输入计算得出，或对输入之外进行预测。

大多数模型任务要求三种输出之一：一个数字、从固定集合中做出的选择，或开放式文本。Clairic 处理第一种，返回带有 80% 区间的数字，同时还能从输入中提取姓名、日期和列表等类型化数值。Clef 处理第二种：它在选项中进行选择，并为每个选项返回概率。LLM 处理第三种。我们称 Clairic 和 Clef 为 System One 模型，因为它们单次通过即可作答，无需推理或生成 token。它们仅对输入收费，通常在一秒内响应，而一个对相同步骤进行推理的 LLM 则需要数秒。

抽取模型可以返回：

• 抽取值：从输入中复制的文本，例如姓名、订单 ID 或描述。每个值都以带有字符偏移量和置信度分数的片段形式返回。
• 包括计算值：数字、日期、时间、日期时间、时长和列表，从输入中读取或由输入计算得出。它们遵循其类型的规则（例如，以分为单位保留两位小数），并附带置信度分数。
• 估计值：输入未明确说明但提供了证据的值。每个值都会以分布的形式返回，位于你声明的边界内、你指定的网格上，并附带中位数和 80% 区间。
• 预测值：序列的未来值，每一步向前一个估计，每个估计都有自己的 80% 区间。

而且由于它不生成 token，它不会像 LLM 那样产生拼写错误的答案或“幻觉”（当然，它也可能出错）。输出是你所要求类型的值，或者当模型在输入中找不到答案时为 null。它还附带针对输出的置信度分数，帮助你评估是否适合信任该模型或需要再次检查。

以下是提取模型在 System One 和 System Two 模型格局中的定位：

这些模型可以协同工作，帮助你更接近解析真实世界数据、对输入做出决策，然后采取行动。提取模型将原始输入转化为类型化值，决策模型将值转化为决策，LLM 将决策转化为文字。

请求如何工作

Clairic 的设计与 LLM 不同。与决策模型类似，它仅通过一次前向传递处理输入 token，因此不收取输出 token 费用。在某些用例中，它比 LLM 更快、更便宜、更准确。

一个请求是一个 state（要读取的文本，加上最多四张可选图片）和一个类型化 fields 的映射。你为每个字段命名，赋予其类型和可选的自然语言 instructions，然后每个字段返回一个类型化答案，全部来自一次并行处理。没有推理，也没有输出 token——一切都在一次前向传递中计算，这意味着它既快速又便宜。

每个标量答案都附带p_null （该值不在输入中的概率）和confidence。每个estimate 答案都附带中位数和 80% 区间（p10 到p90），并可按需提供全部 99 个百分位数。 字段数量没有限制：如果一次处理无法在输入旁容纳所有字段，服务器会将它们拆分为多个并行处理，每个处理都能看到完整输入，然后再合并答案。

以下示例用于说明该模型的功能。当然，在工作流中使用这些功能需要合适的输入。

示例：提取值

提取可能是当今交给 LLM 最常见的任务：“将发票号、供应商和到期日以 JSON 返回。”大多数情况下它都能工作，但失败模式很难被发现。输出可能不是有效的 JSON，数字在生成时可能被误读，而且一旦返回一段文本摘录，就无法追溯它在源文本中出现的位置。大多数人为此构建提取流水线，包含多层解析、模式验证、重试和抽查。除此之外，你还要为每份文档的每个字段支付推理和输出 token 的费用。

Clairic 的运行方式不同；它不生成文本答案。相反，你会得到：

• 值 从输入中提取，因此答案是有依据的。
• 计算值，因此它可以解析非结构化数据而无需预先清洗。
• 字符偏移区间，因此你可以引用数据在输入中的位置。
• 置信度标签，因此你可以确定哪些值需要复核。
• 强类型输出，因此数字和日期按其类型规则生成（例如，美分字段有两位小数）。
• 空值处理，缺失字段会以null 作为答案返回（同时附带估计的空值概率和一个猜测值）。
• 更便宜、更快速的答案，因为每个字段都在同一个并行处理中回答。因此请求三十个字段的成本与请求三个字段大致相同。

让我们通过一个示例来说明 Clairic 如何从非结构化数据中提取值并进行估计。以一封客户支持邮件为例：

你好，订单 A-88412 于 2026 年 9 月 28 日送达，屏幕破裂，边角凹陷。我支付了 $649.00 外加 $52.10 税费。现在是 2026 年 10 月 9 日，我希望修复或退款。谢谢，Dana

从 Worker 中，你会向 Clairic 发出请求来处理这些数据：

const { answers } = await env.AI.run("@cf/cloudflare/clairic", {
  state: email,
  fields: {
    order_id:            { type: "text", instructions: "Order number" },
    delivered_on:        { type: "date", instructions: "Delivery date" },
    amount_paid:         { type: "number", decimals: 2, unit: "USD", instructions: "Total paid including tax" },
    days_since_delivery: { type: "duration", unit: "days", integer: true,
                           instructions: "Days from delivery to the date the customer wrote" },
    damage:              { type: "list", items: "text", instructions: "Each kind of damage described" },
    tracking_number:     { type: "text" },
  },
});

Clairic 返回提取的值、输入中的区间、为空值的概率（p_null）和置信度分数：

{
  "order_id": {
    "type": "text",
    "p_null": 3.4e-6,
    "span": [10, 17],
    "guess": "A-88412",
    "confidence": 0.999957,
    "value": "A-88412"
  },
  "delivered_on": {
    "type": "date",
    "p_null": 6.5e-8,
    "guess": "2026-09-28",
    "confidence": 0.999999,
    "value": "2026-09-28"
  },
  "amount_paid": {
    "type": "number",
    "p_null": 1.6e-5,
    "guess": 701.1,
    "confidence": 0.999944,
    "value": 701.1
  },
  "days_since_delivery": {
    "type": "duration",
    "p_null": 6.1e-9,
    "unit": "days",
    "guess": 11,
    "confidence": 0.999999,
    "value": 11
  },
  "damage": {
    "type": "list",
    "value": ["cracked screen", "dented corner"],
    "spans": [[50, 64], [71, 84]]
  },
  "tracking_number": {
    "type": "text",
    "p_null": 1,
    "span": [106, 112],
    "guess": "$52.10",
    "confidence": 0.416016,
    "value": null
  }
}

有几点需要注意：

• amount_paid 并未写在邮件中的任何地方。在此示例中，Clairic 在同一次处理中加上了价格和税费并返回总和。
• days_since_delivery 也是根据文本中的两个日期计算出来的，并非直接来自输入。
• damage 将两种损坏都列为精确区间，因此你可以在源文本中高亮它们。
• tracking_number 不在邮件中，因此它返回null 而不是一个看似合理的猜测。guess 显示了模型原本会选什么。

Clairic 也支持图像

这是一张真实的收据照片——文字并不完美，图像角度也不利于辨认。我们将这张图像传给 Clairic，看看它能提取出什么：

{
  "model": "clairic",
  "answers": {
   "order_number": {
    "type": "number",
    "p_null": 0.0040206750854849815,
    "guess": 77245,
    "confidence": 0.776249383996532,
    "value": 77245
   },
   "purchased_at": {
    "type": "datetime",
    "p_null": 4.136094133855295e-08,
    "guess": "2026-07-01T13:34:00",
    "confidence": 0.831464227002992,
    "value": "2026-07-01T13:34:00"
   },
   "quantity": {
    "type": "number",
    "p_null": 5.2313655629632194e-08,
    "guess": 2,
    "confidence": 0.9997007500403496,
    "value": 2
   },
   "unit_price": {
    "type": "number",
    "p_null": 0.001599092734977603,
    "guess": 7.99,
    "confidence": 0.9991279019989127,
    "value": 7.99
   },
   "subtotal": {
    "type": "number",
    "p_null": 9.69956488461321e-08,
    "guess": 15.98,
    "confidence": 0.9999881983893096,
    "value": 15.98
   },
   "sales_tax": {
    "type": "number",
    "p_null": 2.5511653802823275e-06,
    "guess": 0,
    "confidence": 0.9999800924450729,
    "value": 0
   },
   "tip": {
    "type": "number",
    "p_null": 5.953857908025384e-05,
    "guess": 2.39,
    "confidence": 0.9335768781214697,
    "value": 2.39
   },
   "discount": {
    "type": "number",
    "p_null": 0.9994148015975952,
    "guess": 0,
    "confidence": 0.91852733929319,
    "value": null
   }
  }
}

如你所见，它能够从图像中提取所有数值，并附带置信度分数。它还正确地指出收据中没有显示折扣，并将该值设为 null。

示例：估算数值

有些数值根本不在输入中，但输入中带有支持它们的证据。例如，数值可能并非以纯文本形式出现，但可以从其周围的数值推断出来。如果你让 LLM 进行估算，通常只会得到一个数字，而无法感知模型有多确定。它会做出保守的猜测，或产生幻觉，或通过推理绕开答案。如果你得到一个估算值，任何下游处理都无法区分一个有把握的 $180 和一个没把握的 $180，因此它无法帮助你在具体情况下决定什么适合自动化。而且通过 LLM 进行推理要慢得多，成本也高得多。

决策模型可以通过在分桶（“低于 $100”、“$100–500”……）中进行选择来近似估算，但分桶是粗粒度的，每个分桶都会增加输入 token，而每新增一个类别都会在模型决策过程中增加更多混淆来源。

Clairic 会在你声明的范围内返回一个分布：一个点值、一个中位数、一个 80% 区间，以及按需提供的每个百分位数。估算值被设计为落在你的边界内，因此之后无需进行截断或取整。区间的宽度反映了数据置信度：窄区间表示高确定性，宽区间表示低确定性，你可以利用这一信息来安排另一项检查。

下面是另一个示例，Clairic 查看历史房价和可比销售额来确定估算值：

const { answers } = await env.AI.run("@cf/cloudflare/clairic", {
  state: `Comparable sales:
sqft,beds,year_built,neighborhood,sale_price
1450,3,1998,Elm Park,412000
2100,4,2006,Elm Park,585000
980,2,1975,Riverside,265000
1600,3,2003,Elm Park,449000
1300,3,1990,Riverside,318000

Subject property:
sqft,beds,year_built,neighborhood
1620,3,2001,Elm Park`,
  fields: {
    sale_price:     { type: "estimate", unit: "USD", min: 50000, max: 5000000, scale: "log", step: 1000 }
});

Clairic 将返回一个估算值：

{
  "sale_price":     { "type": "estimate", "value": 418000, "median": 415000, "p10": 370000, "p90": 470000, "p_below": 0.0, "p_above": 0.0 }
}

数值始终落在你的边界内，区间的宽度显示了输入对预测的贡献程度：价格区间较窄（$370,000-$470,000），上市天数区间较宽（24-148）。由于字段数量不受限制且并行作答，你可以在一次调用中对许多项目进行评分（每个候选、线索或房源一个估算值），并在代码中对它们排序。

示例：预测数值

在时间序列中预测数值对于通用模型来说相当困难——这通常意味着你要么为每个指标构建特定的流水线（解析数据、拟合模型、调优、部署），要么把 36 个月的数字粘贴到 LLM 中并要求预测未来三个月。第一种方法准确，但为每个新序列进行设置既昂贵又耗时。第二种方法简单，但你得到的是没有区间的点预测，预测结果会因提示词的措辞而变化，而且答案的置信度有限。

Clairic 介于两者之间——它并不声称要取代专门的时间序列模型，但比常规 LLM 稍快且更便宜。一个 forecast 字段以纯文本形式在 state 中接收历史数据，并针对每个向前步长，在你声明的边界内返回一个值和一个 80% 区间。它按照你现有的方式读取历史数据，无论是 CSV 导出、粘贴的仪表板，还是与笔记混在一起的行，并且通常无需事先清理数据即可工作。

为了检验它在真实数据上的表现，我们使用了一个公开序列：美国运输安全管理局（TSA）每天在美国机场检查站筛查的人数。连续 21 天，我们每天早上都向 Clairic 询问第二天的计数，并给出截至当时的真实计数：

const { answers } = await env.AI.run("@cf/cloudflare/clairic", {
  state: `Daily number of people screened at TSA checkpoints at US airports.
date,weekday,travelers
2026-07-16,Thu,2850229
...
2026-10-13,Tue,2353356
Forecast date: 2026-10-14 (Wed)`,
  fields: {
    travelers: { type: "forecast", horizon: 1, interval: "day",
                 min: 500000, max: 4000000, scale: "log",
                 instructions: "Number of people screened tomorrow" },
  },
});

其返回：

{
  "travelers": { "type": "forecast", "value": [2416117], "median": [2419283], "p10": [2270774], "p90": [2556769] }
}

实际上，TSA 当天筛查了 2,419,474 人，正好接近 Clairic 预测的中位数 2,419,283。

数据：TSA 检查站旅客数量，访问于 2026 年 10 月 15 日。

在这 21 天里，Clairic 的预测平均偏差为 3.3%，21 个实际计数中有 17 个落在其 80% 区间内，这符合 80% 区间应有的表现。它仅凭数字就捕捉到了每周的节奏：周二和周六较清淡，周四、周五和周日较繁忙。

偏差的情况也很有意思：落在区间外的四天中有三天恰逢哥伦布日周末，当时乘机人数比前几周所预示的更多。Clairic 依据序列中的模式进行预测，但不会考虑序列未体现的事件，比如节假日。

快思考与慢思考

这些模型旨在与你现有的智能体工作流配合使用。提取模型预测数值，决策模型决定如何处理这些数值，而 LLM 则据此采取行动。这是 System One 与 System Two 模型的完美结合。它弥合了现有的鸿沟——你要么得为 LLM 手动提取数据，要么让 LLM 去解析杂乱的数据（这既昂贵又耗时，还可能导致幻觉）。借助 System One 提取模型，你可以更快速、更高效、更精准地处理真实世界的数据。

下面是前面那个损坏产品索赔的例子，展示了所有模型如何协同工作。 我们把它做成了一个你可以在此处尝试的在线演示。

// 1. Clairic turns the email into values
const facts = (await env.AI.run("@cf/cloudflare/clairic", {
  state: email,
  fields: {
    customer_name:       { type: "text", instructions: "Customer's first name" },
    order_id:            { type: "text", instructions: "Order number" },
    amount_paid:         { type: "number", decimals: 2, unit: "USD", instructions: "Total paid including tax" },
    days_since_delivery: { type: "duration", unit: "days", integer: true,
                           instructions: "Days from delivery to the date the customer wrote" },
    damage:              { type: "list", items: "text", instructions: "Each kind of damage described" },
    repair_cost:         { type: "estimate", unit: "USD", min: 10, max: 5000, scale: "log", step: 1,
                           instructions: "Cost to repair the damage described" },
  },
})).answers;
const { customer_name, order_id, amount_paid, days_since_delivery, damage, repair_cost } = facts;

// 2. Clef decides from Clairic's values and the policy, not from the raw email
const options = {
  refund:  "Full refund of the amount paid",
  repair:  "Free repair, with a prepaid shipping label",
};
const { choice } = (await env.AI.run("@cf/cloudflare/clef", {
  state: `Damage claim for order ${order_id.value}.
Paid: $${amount_paid.value.toFixed(2)}. Delivered ${days_since_delivery.value} days ago.
Damage reported: ${damage.value.join(", ")}.
Estimated repair cost: $${repair_cost.median} (80% range $${repair_cost.p10}-$${repair_cost.p90}).
Policy: refunds within 30 days of delivery. Prefer repair when it costs less than 60% of the price and the damage doesn't stop the product from working.`,
  questions: {
    resolution: { type: "choice", instructions: "What should we offer?", criteria: options },
  },
})).answers.resolution;

// 3. An LLM writes the reply, from the decision and the facts it needs
const { response } = await env.AI.run("@cf/zai-org/glm-5.3", {
  messages: [{
    role: "user",
    content: `Write a short, warm reply to ${customer_name.value}. Use only these facts: order ${order_id.value}; ` +
             `damage: ${damage.value.join(", ")}; what happens next: ${options[choice]}. Under 60 words.`,
  }],
});

每一步的输入都比前一步更干净。Clef 依据五行结构化数值摘要做决策，而不是依据自由格式的邮件——邮件还可能容易受到提示注入攻击。LLM 从不见到邮件，只看到决策以及它所需的预测结果，因此可供它误用的数字更少。每一步都是结构化且可审计的，并且只有一步会生成文本。而在全 LLM 版本的流水线中，三个步骤都是生成式调用，回复中的每个数值都必须人工核对。

我们用 GLM-5.3 在两种流水线中撰写回复，将这条流水线与全 LLM 版本进行了对比。在全 LLM 版本中，GLM-5.3 还基于同一封邮件、同一政策和提示词完成提取和决策：

级联流水线耗时 19.3 秒，而全 LLM 版本为 61.7 秒：时间减少 69%，约快 3.2 倍。Clairic 和 Clef 合计在不到一秒内完成了提取和决策，而 GLM-5.3 完成同样两步用了 38 秒。使用级联流水线相比全 LLM 流水线还降低了 49% 的成本。使用 GLM 时，两种流水线在每次运行中都把事实和决策做对了，但 Clairic 的维修估价每次都完全相同，而 GLM-5.3 的估价每次都在变（分别为 250 美元、250 美元和 220 美元，且每次区间不同）。

值得注意的是，在全 LLM 流水线下，Gemma 4 和 Qwen 在这项任务上都失败了，因为它们无法从输入中推断出 repair_cost 之类的数值，这表明 LLM 并不擅长数据提取任务。

预览版

今天，我们在 Workers AI 上发布 Clairic 的托管端点。我们打算很快以开放权重发布该模型。我们想先花点时间介绍 System One 抽取模型的概念，这样你就可以开始思考这类模型如何融入合适的工作流。

当前端点是早期检查点，我们预计它会变得更好。以下是我们早期的印象：

• 阅读能力强，但多步算术还不行。 一步和两步计算（总计、差值、换算、日期运算）似乎可靠。对于任何没有草稿纸的单遍模型来说，较长的依赖步骤链都很难。跨表格多行进行聚合也是如此。至少目前，让 Clairic 预测值，让代码来做数学运算。
• 估算需要证据。 Clairic 最适合根据输入中的可比对象、历史记录或描述性文本进行估算。向它索要没有证据支持的值，其具体性可能有限。
• 校准是经过测量的，而非保证的。 区间经过训练以保持校准，并且在大多数留出集上确实如此，但在不熟悉的数据上可能偏窄。
• 预测是基础的。该模型并非设计用来准确替代或预测在特定数据上训练的时间序列模型。你应在适当的地方使用它，例如非关键的、一般模式匹配，而不是详细的长期预测。
• 使用置信度。 该架构使每个答案格式良好，但不一定正确。使用 confidence、p_null 和区间来决定哪些可以自动化（在适当的工作流上下文中），哪些需要送去额外审查。

我们会在每个检查点继续改进模型的算术、估算和预测方面。再做一些工作后，我们计划以开放权重发布该模型，供大家试用。

试一试

Clairic 作为预览版在 Workers AI 上以 @cf/cloudflare/clairic 提供。你可以从 Worker 中使用 env.AI.run() 调用它，或通过 REST API 从任何地方调用。我们有完整的模型文档 在此，以及一份新的文档说明 介绍抽取模型 API 的样子。

附言：既然你喜欢 Clef 这个名字的词源，这里说说我们是如何定下 Clairic 这个名字的。 我们一开始希望模型名称在主题和发音上都与 Clef 相似。Clair 浮现在脑海中，它有着相同的“cl”发音，也有音乐根源（“Clair de Lune”）。更重要的是，我们希望这个名字能描述模型的本质。Clairic 模型应该能帮助你完成文书任务，比如从输入语料中清晰地提取数据，并在记账等任务中保持准确性。模型的预测方面则倾向于“Clair”词根——让你能够估算和预测未来值，类似于千里眼。最后，我们喜欢把它看作 [Cl]oudflare 的 [AI R]egression 模型。于是，Clairic 诞生了。希望你喜欢它。