Clairic 技术实践：当 AI 不再生成文字，而是直接提取、计算和预测数据

我们习惯让大语言模型从一大段文本中提取订单号、金额、日期，再返回 JSON。但如果只需要几个具体数值，真的有必要调用一个生成式大模型吗？2026 年 10 月，Cloudflare 发布了新型 System One 抽取模型 Clairic。它不依赖逐 Token 生成答案，而是直接返回具有明确类型的数值、文本、日期和概率分布。本文介绍 Clairic 的工作机制，并通过售后邮件信息抽取、房产价格估计两个案例，演示如何用 Python 调用这个模型。

一、Clairic 是什么？为什么还需要一种新的 AI 模型？

先看一个很常见的需求。

用户给电商客服发了一封邮件：

订单 A-88412 在 9 月 28 日送达，但屏幕碎了，边角也有凹陷。我支付了 649 美元商品款和 52.10 美元税费。今天是 2026 年 10 月 9 日，希望能够维修或者退款。

业务系统希望得到：

• 订单号是什么？
• 商品实际支付了多少钱？
• 距离收货过去了多少天？
• 出现了哪些损坏？
• 有没有物流追踪号码？

以前我们通常会把这段文字交给大语言模型，要求它返回 JSON。

这个方案当然能用，但也有些尴尬：我们只想要几个字段，却需要模型逐个生成所有字符。

它甚至可能多输出一段解释，或者在缺失字段时猜出一个看起来合理的值。

Clairic 就是针对这种需求设计的。

Cloudflare 把它称为 System One Extraction Model（系统一抽取模型）。

它不是通用聊天大模型，而是一种专门完成结构化数据抽取和数值预测的模型。

1.1 它与 LLM 有什么不同？

传统生成式 LLM 的处理过程大致是：

输入文本
   │
   ▼
大语言模型
   │
   ▼
逐 Token 生成
   │
   ▼
JSON 字符串
   │
   ▼
解析和校验
   │
   ▼
业务数据

Clairic 则采用不同的思路：

输入文本 / 图片
       │
       ▼
      Clairic
   单次前向计算
       │
       ▼
按预定义字段类型解码
       │
       ▼
结构化数值 + 置信度
       │
       ▼
     业务系统

模型不需要自回归地生成文字，而是对输入进行一次前向计算，随后按照指定字段的规则得到结果。

严格来说，当请求的字段太多，无法放进单个推理过程时，Cloudflare 会将字段拆成多个并行计算批次，而不是无限制地塞入同一次前向计算。

1.2 Clairic 支持哪些任务？

这是它最有意思的地方。

Clairic 不仅能提取信息，还能执行一定的计算和预测。

我们可以把这些能力分成四类：

Extraction： 找到输入中已经存在的事实。

Computation： 根据输入中的事实，计算出新数值。

Estimation： 根据已知条件估计未知数值。

Forecasting： 根据历史序列预测未来值。

这里需要区分计算与估计：649 加 52.10 是计算；根据相似房屋估计售价，则属于预测未知量，结果天然存在不确定性。

1.3 与 Clef、LLM 的区别

一个简单的理解方式是：

• Clairic 回答“金额是多少”。
• Clef 回答“应该退款还是维修”。
• LLM 回答“如何向客户解释处理结果”。

三者可以组合，而不是互相替代。

二、如何使用 Clairic？

截至 2026 年 10 月 21 日，Clairic 已在 Cloudflare Workers AI 上开放 Preview，模型标识为：

@cf/cloudflare/clairic

目前通过 Cloudflare 托管服务使用。Cloudflare 已表示计划开放模型权重，但尚不能把它当作已经正式发布的本地开源模型。

其官方定价为每百万输入 Token 0.10 美元，不收取生成输出 Token 的费用。

2.1 API 请求格式

Clairic 使用 state 和 fields 两个主要参数。

{
  "model": "clairic",
  "state": "订单A-1001金额200元，运费15元。",
  "fields": {
    "order_id": {
      "type": "text",
      "instructions": "订单编号"
    },
    "total": {
      "type": "number",
      "decimals": 2,
      "instructions": "商品金额加运费"
    }
  }
}

这里：

• state 是待处理的数据。
• fields 描述希望得到哪些字段。
• type 决定返回值的数据类型。
• instructions 用自然语言描述字段含义。

与传统 JSON Schema 的一个区别是：Clairic 不只是要求输出满足数据格式，而是针对各个字段进行专门的抽取或数值解码。

下面通过两个案例实践。

三、实践案例一：自动提取客服售后邮件

3.1 场景介绍

第一个案例来自 Cloudflare 官方博客。

用户反映商品损坏，希望退款或维修。

我们希望在一次请求中完成：

1. 提取订单号。
2. 计算实际付款金额。
3. 计算收货天数。
4. 提取商品损坏情况。
5. 判断物流追踪号码是否存在。

这类场景很适合 Clairic，因为输入是不规则的自然语言，但业务系统需要的结果高度结构化。

3.2 环境准备

安装 Python 依赖：

pip install requests

在 Cloudflare 控制台获取 Account ID 和 Workers AI API Token。

然后去 Cloudflare Workers AI 文档的 REST API 页面，获取对应的完整推理地址。

API 路径为：

POST /client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/cloudflare/clairic

将完整请求地址与 API Token 分别保存到环境变量：

CLAIRIC_ENDPOINT
CLOUDFLARE_API_TOKEN

3.3 Python 完整示例

import os
import requests

# API 配置
ENDPOINT = os.environ["CLAIRIC_ENDPOINT"]
TOKEN = os.environ["CLOUDFLARE_API_TOKEN"]


def call_clairic(state, fields):
    """调用 Clairic 并返回各字段结果"""

    response = requests.post(
        ENDPOINT,
        headers={
            "Authorization": f"Bearer {TOKEN}",
            "Content-Type": "application/json"
        },
        json={
            "model": "clairic",
            "state": state,
            "fields": fields
        },
        timeout=60
    )

    response.raise_for_status()
    data = response.json()

    if data.get("success") is not True:
        raise RuntimeError(data.get("errors", data))

    return data["result"]["answers"]


# 官方示例改写：售后邮件
email = """
Hi, order A-88412 arrived on Sept 28, 2026
with a cracked screen and a dented corner.
I paid $649.00 plus $52.10 tax.
It's now Oct 9, 2026 and I'd like this
fixed or refunded.
Thanks, Dana
"""

# 定义要提取的字段
fields = {
    "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"
    },

    "tracking_number": {
        "type": "text",
        "instructions": "Shipping tracking number"
    }
}

# 执行
answers = call_clairic(email, fields)

for name, result in answers.items():
    print(name, "=>", result["value"])

3.4 如何理解返回结果？

对于这段邮件，Cloudflare 官方展示了如下关键结果：

order_id           => A-88412
amount_paid        => 701.10
days_since_delivery => 11
damage             => [
    "cracked screen",
    "dented corner"
]
tracking_number    => null

这里有三个值得关注的细节。

第一，它不仅提取，还进行了计算。

邮件没有直接写出总付款金额，但 Clairic 将 649.00 与 52.10 相加，得到 701.10。

第二，它能给出来源位置。

例如订单号的返回结构包含：

{
  "type": "text",
  "value": "A-88412",
  "span": [10, 17],
  "confidence": 0.999957
}

span 表示这个字段在输入文本中的字符范围，可以用于原文定位与审计。

第三，缺失字段可以返回 null。

由于邮件没有物流追踪号码，Clairic 在官方示例中返回：

{
  "type": "text",
  "value": null,
  "p_null": 1.0
}

p_null 表示模型认为输入不足以确定该字段的概率。

Clairic 还可能提供 guess，但即使模型给出了猜测值，也不意味着它可以被当作真实数据使用。

对于订单处理，这种缺失值机制比随便编造一个号码要有用得多。

四、实践案例二：根据历史成交数据估计房价

第一个案例主要展示了信息抽取和简单计算。

但 Clairic 还有一个更特别的能力：直接输出数值估计及其不确定性区间。

4.1 场景介绍

假设房地产平台拥有一些历史成交记录：

现在，我们需要估计一套新房产的价格：

• 面积：1620 平方英尺
• 卧室：3
• 建造年份：2001
• 地区：Elm Park

这里并没有可以直接提取的成交价，需要模型根据可比数据估计。

传统方法可能使用回归模型、梯度提升树等进行预测。

Clairic 提供了一种直接读取半结构化文本并输出估计分布的方式，适合快速构建基线。

4.2 Python 实现

沿用案例一的 call_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,
        "instructions": (
            "Estimate the sale price "
            "using comparable properties"
        )
    }
}

answers = call_clairic(state, fields)

estimate = answers["sale_price"]

print("估计价格：", estimate["value"])
print("中位数：", estimate["median"])
print("P10：", estimate["p10"])
print("P90：", estimate["p90"])

4.3 Clairic 输出了什么？

Cloudflare 官方使用这组数据演示时，返回的结果为：

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

这和普通 LLM 输出“我认为房价大约 42 万美元”有明显区别。

Clairic 不只给出一个点估计，还提供一个预测分布的摘要。

其中：

• value：模型的点估计。
• median：预测分布中位数。
• p10：预测分布的第 10 百分位。
• p90：预测分布的第 90 百分位。

因此，模型给出的中间 80% 预测区间为：

37 万～47 万美元。

不过，这里的 80% 是模型预测分布的区间含义，并不保证真实房价有 80% 的概率落在这个区间。只有经过独立样本检验，才能确定它在具体业务中的实际覆盖率。

此外，min、max 是允许模型输出的数值边界，不等于真实房价一定落在这些范围内。

4.4 Clairic 还能预测时间序列

Cloudflare 还测试了一个有趣的任务：根据美国机场历史旅客安检人数，预测下一天的客流量。

这时，字段类型从 estimate 改为 forecast：

{
  "travelers": {
    "type": "forecast",
    "horizon": 1,
    "interval": "day",
    "min": 500000,
    "max": 4000000,
    "scale": "log",
    "instructions": "Number of travelers tomorrow"
  }
}

在官方公布的 21 天连续测试中，预测的平均绝对百分比误差约为 3.3%，实际数值有 17 天落在模型给出的 80% 区间内。

这个结果说明 Clairic 能学习输入序列中的部分规律，但远远不足以证明它可以替代专门的时间序列预测模型。

尤其遇到节假日、政策冲击或者其他历史数据中没有体现的突发事件时，预测可能明显偏离实际。

五、工程实践：Clairic 有哪些限制？

看完两个案例，可能会觉得 Clairic 几乎可以替代所有结构化数据处理任务。

但目前还不能这么理解。

1. 强类型输出不等于数值一定正确。

模型可以保证一个 date 字段满足日期格式，却不能保证它一定找到了正确的日期。

对于金额、日期、订单号等关键字段，仍需要结合 confidence、p_null 和业务规则进行校验。

2. 简单计算可以，复杂数学不一定可靠。

Cloudflare 明确指出，目前一两步计算相对可靠，但复杂的多步运算和大量表格行聚合仍存在局限。

如果需要计算几十个账户的余额汇总，更合理的方式是让 Clairic 提取原始数据，然后交给 Python 或数据库完成计算。

3. 数值估计不等于专业预测。

对于估价、需求预测、信用风险参数等任务，不能因为模型返回了预测区间，就认为它经过了充分的统计验证。

应当根据真实业务数据评估 MAE、RMSE、预测区间覆盖率和校准误差。

4. 当前模型仍处于预览阶段。

截至本文撰写时，Clairic 尚未正式开放模型权重。当前可以使用 Cloudflare 的托管 API，但还不能按照普通开源模型的方式直接下载权重并离线部署。

官方支持纯文本及最多四张图片输入，但不应将其直接等同于完整的 PDF 版面解析系统。复杂文档仍可以先通过 OCR 或文档解析模型预处理。

六、总结：Clairic 在 AI 系统中的位置

Clairic 最值得关注的，不是它能够返回 JSON，而是它将原本由生成式大模型承担的结构化抽取任务，进一步拆成了专门的类型化预测问题。

这让模型能够直接输出业务系统真正需要的值，而不必逐字生成答案。

结合之前研究过的 ASR、OCR、Embeddings、Clef，可以构建一条比较清晰的处理链路：

语音 / 图片 / PDF / 文本
          │
          ▼
       ASR / OCR
          │
          ▼
       原始文本
          │
          ├────── Embeddings
          │         │
          │         ▼
          │     知识检索
          │
          ▼
        Clairic
          │
          ▼
     结构化业务字段
          │
          ▼
     Clef 决策模型
          │
          ▼
     业务系统 / LLM
          │
          ▼
       执行与回复

当然，并不是每个业务都需要把这些模型全部串起来。对于简单任务，规则和传统算法可能更便宜、更可靠。

Cloudflare 官方在一个售后处理示例中，将 Clairic、Clef 和生成式 LLM 组合，与全部使用 LLM 的方案进行比较。该演示中，组合方案端到端耗时 19.3 秒，而全 LLM 方案耗时 61.7 秒，成本也降低约 49%。

这是特定演示工作负载下的结果，不能直接推广到所有业务。但它展示了一种值得关注的工程方向：不要让通用大模型处理所有事情，而是把确定性较强、答案结构明确的任务交给专用模型。

如果说 ASR 是 AI 的耳朵，OCR 是眼睛，Embeddings 是语义检索工具，那么 Clairic 更像一个擅长整理表格、提取数字和做初步估算的业务助理。

它未必能帮你想清楚一个复杂问题，但能把大量杂乱信息整理成清晰的数据。

而很多时候，业务系统真正缺少的，恰恰就是这些可靠、可校验的数据。