Cloudflare AI 发布新型 System One 提取模型 Clairic

今天，我们宣布推出全新类别的 System One 风格模型：提取模型（extraction models）的预览版。我们的第一个提取模型 Clairic 现已在 Workers AI 上托管提供，形式为 @cf/cloudflare/clairic.。我们计划很快开源该模型的权重。Clairic 是一种提取模型，能够从非结构化输入中提取、计算、估计和预测数值 —— 其准确率显著更高、延迟更低、成本也比传统 LLM 更便宜。

背景

一个月前，TypeSafe 宣布推出 System One 模型时，曾在业界引起轰动。正如 TypeSafe 在其博客中所述，且正如丹尼尔·卡尼曼（Daniel Kahneman）的著作《思考，快与慢》（Thinking, Fast and Slow）所定义的，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 或描述。每个返回结果都包含一个带有字符偏移量和置信度得分的文本区间（span）。
• 包括，计算出的值： 从输入中读取或推导出的数字、日期、时间、日期时间、持续时间和列表。它们遵循各自类型的规则（例如，美分保留两位小数）并带有置信度得分。
• 估计值：输入中未直接说明但提供了证据的值。每一个值都会在你声明的边界内、指定的网格上以分布形式返回，带有中位数和 80% 的区间。
• 预测值：序列的未来值，每个超前步长对应一个估计值，各自带有 80% 的区间。

而且因为它不生成词元，所以它不会产生拼写错误的答案，也不会像大语言模型（LLM）那样“产生幻觉”（当然，它也可能会犯错）。输出是你所要求的类型的值，当模型无法在输入中找到答案时则返回 null。它还附带针对输出的置信度分数，帮助你评估是否适合信任该模型或进行二次检查。

以下是提取模型在“系统一”和“系统二”模型格局中的定位：

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

请求的工作原理

Clairic 的设计与 LLM 不同。类似于决策模型，它仅通过单次前向传递处理输入词元，因此不收取输出词元费用。对于某些用例，它比 LLM 快得多、便宜得多，也更准确。

一个请求是一个 state（要读取的文本，外加最多四个可选图像）和一组类型化 fields 的映射。你为每个字段命名，为其指定一个类型和可选的纯文本 instructions，每个字段返回一个类型化的答案，全部通过一次并行传递完成。没有推理，也没有输出词元——一切都在单次前向传递中计算，这意味着它既快又便宜。

每个标量回答都附带 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 人左右。

Data: TSA checkpoint travel numbers, accessed Oct. 15, 2026.

在这 21 天里，Clairic 的预测平均误差为 3.3%，21 个实际统计数据中有 17 个落入其 80% 的置信区间内，这符合 80% 置信区间的预期表现。它仅凭数字就捕捉到了每周的规律：周二和周六较为冷清，周四、周五和周日较为繁忙。

预测失误的情况同样耐人寻味：落在那四个置信区间之外的日子中，有三天正值哥伦布日（Columbus Day）周末，当时乘机出行的人数比前几周预示的要多。Clairic 根据序列中的模式进行预测，但无法解释序列中未显示的事件，例如节假日。

思考，快与慢

这些模型旨在与你现有的智能体工作流无缝契合。提取模型负责预测数值，决策模型决定如何处理这些数值，而 LLM 则利用它们采取行动。这是“系统一”和“系统二”模型之间的完美结合。它弥补了现有的鸿沟：以往你要么必须为 LLM 手动提取数据，要么让 LLM 解析混乱的数据（这成本高昂、耗时且容易导致幻觉）。有了“系统一”提取模型，你就能以更高的速度、效率和精度处理现实世界的数据。

以下是前面提到的损坏商品索赔示例，展示了所有模型如何协同工作。 我们将其做成了你可以在此处体验的实时演示。

// 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 版本的流水线中，所有三个步骤都是生成式调用，回复中的每一个值都必须人工检查。

我们将此流水线与全 LLM 版本进行了对比，两者均由 GLM-5.3 负责撰写回复。在全 LLM 版本中，GLM-5.3 还根据相同的邮件、策略和提示词来执行提取和决策：

级联流水线的完成时间为 19.3 秒，而对比组为 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）提取模型的概念，这样您就可以开始思考这类模型将如何适合相应的业务流程。

当前的端点是一个早期检查点，我们期待它会变得更好。以下是我们最初的感受：

• 阅读能力很强，但多步骤算术运算尚显不足。 一到两步的计算（总计、差值、换算、日期算术）似乎很可靠。对于没有草稿板的任何单次传递（one-pass）模型来说，更长的相关步骤链都很困难。跨表格多行进行聚合也是如此。至少目前，让 Clairic 预测数值，然后用代码来计算。
• 估算需要依据。 Clairic 最擅长根据输入中的可比对象、历史记录或描述性文本进行估算。向它索取没有依据的数值，其具体性可能会受到限制。
• 校准是经过测量的，而非保证。 区间经过训练以实现校准，并且在大多数保留集（held-out sets）上确实如此，但在不熟悉的数据上它们可能会变得狭窄。
• 预测功能较为基础。该模型并非旨在准确替代或预测在特定数据上训练的时间序列模型。您应该在适当的场景下使用它，例如非关键的通用模式匹配，而不是详细的长期预测。
• 使用置信度。 该架构使每个答案都格式良好，但不一定正确。利用 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 模型应该能够协助您处理诸如从输入语料库中清晰地（clearly）提取数据并保持簿记等任务的文书（clerical）工作。该模型的预测特性倾向于“Clair”词根——使您能够估算和预测未来的数值，类似于透视力（clairvoyance）。最后，我们喜欢将其定位为 [Cl]oudflare 的 [AI R] regression（回归）模型的构思。就这样，Clairic 诞生了。希望你们会喜欢它。