Introducing Clairic, a new System One class of extraction models

介绍 Clairic，一种新型的 System One 类提取模型 | Cloudflare 博客

post

研究

Workers AI

AI

开发者

机器学习

2026 年 10 月 19 日

介绍 Clairic，一种新型的 System One 类提取模型

Alex Reneau , Michelle Chen , Kevin Flansburg

16 分钟阅读时间

复制链接

今天，我们宣布推出一种新型 System One 风格模型的预览版：提取模型。我们的首个模型 Clairic 已托管在 Workers AI 上，可通过 @cf/cloudflare/clairic 访问。我们计划很快开放模型的权重。Clairic 是一种提取模型，能够从非结构化输入中提取、计算、估算和预测值——相比传统大语言模型（LLMs），它在准确率、延迟和成本方面都有显著提升。

背景

一个月前，当 TypeSafe 宣布推出 System One 模型时，整个行业为之轰动。如 TypeSafe 博客所述，并参考 Daniel Kahneman 在《思考，快与慢》中的定义，System One 模型应具备快速和精准的特性，这与需要进行深思熟虑推理的 System Two 模型（如 LLMs）形成对比。基于此，TypeSafe 推出了 Jev——一种专为特定用例设计的模型，由于其领域狭窄，定价也更具吸引力。Jev 在 LLMs 失败的领域表现出色，帮助用户基于概率和类型正确的输出做出决策。Jev 的推出促使人们开始思考一类非 LLMs 的新型模型，以及如何将它们整合到工作流程中。

我们受到 System One 模型概念的启发，开始思考 LLMs 在哪些任务上效率低下。目前，许多结构化输出请求反复发送给前沿 LLMs，问题形式也高度重复：发票总额是多少？何时送达？延迟了多少天？维修费用是多少？未来 24 小时的交通状况如何？这些问题的答案都无法提前列出，而这正是决策模型需要提供概率预测的必要条件。这促使我们今天推出这一类模型：System One 提取模型。

介绍 System One 提取模型

迄今为止，所有 System One 模型都是决策模型：Jev 和 Clef 接收输入状态和问题列表，并对输入和列出的问题提供概率预测。Clairic 是首个新型类别的模型：System One 提取模型。它依然保持快速、类型明确和低成本，但能够直接从输入中提取值、从中计算得出值，或预测超出输入范围的值。

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

提取模型可以返回：

• 提取的值：从输入中复制的文本，如名称、订单 ID 或描述。每个值都以包含字符偏移量和置信度评分的片段形式返回。

• 包括计算值：数字、日期、时间、时间戳、持续时间和列表，这些值可以从输入中读取或通过输入推导得出。它们遵循各自类型的规则（例如，以两位小数表示分），并附带置信度评分。

• 估算值：输入中未明确说明但提供证据支持的值。每个估算值都会以您声明的范围内、指定的网格上的分布形式返回，包含中位数和80%置信区间。

• 预测值：时间序列的未来值，每个预测步长对应一个估算值，每个值都附带自己的80%置信区间。

由于不生成任何token，它无法像LLM那样产生拼写错误或“幻觉”（当然，它仍可能犯错）。输出结果是您请求的类型值，或在模型无法在输入中找到答案时返回null。输出还附带置信度评分，帮助您评估是否应该信任模型或需要进一步核查。

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

System One: 提取 System One: 决策 System Two

示例模型

Clairic Jev, Clef GPT, Claude, Gemini, DeepSeek

采样方式

一次并行处理 逐个token处理

目的

预测值 做出决策 撰写和推理

机器学习框架

回归和提取 分类 生成

思考模式

System 1: 快速，单次处理 System 2: 慢速，深思熟虑

输出

类型化值：文本片段、数字、日期、时间、列表、分布（附带校准概率） 类型化决策：带校准概率的选项 自由文本字符串

输出空间

连续值，但类型化且受您的模式约束 有限的选项集合 任意内容

回答的问题类型

金额是多少？何时发生？会达到多少？ 属于哪个类别？是否合法？应采取什么行动？ 为什么会发生？应如何应对？能否解决？

输出是否总是有效响应？

是：每个答案都是其声明类型的值（或null），且在您的约束范围内 是：答案始终是您列出的选项之一 否：字符串必须解析和验证

这些模型可以协同工作，帮助您更有效地解析真实世界数据、基于输入做出决策并采取行动。提取模型将原始输入转换为类型化值，决策模型将值转换为决策，LLM则将决策转换为文字。

请求的处理流程

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

一个请求包含一个状态（要读取的文本，最多四张可选图像）和一个类型化字段映射。您为每个字段命名，指定类型和可选的自然语言指令，然后会从一次并行处理中获得每个字段的一个类型化答案。整个过程没有推理，也没有输出token——所有计算都在单次前向传递中完成，这意味着它既快速又经济。

类型

返回值

text

输入中的特定文本片段及其偏移量

number

读取或计算的数字（支持整数和小数）

date, time, datetime

ISO格式的日历日期和有效时间

duration

您选择单位的时间长度

list

按输入顺序匹配的文本、数字或日期

estimate

在您指定的[min, max]范围内的分布，基于您设定的步长网格（线性或对数尺度）

forecast

对序列中每个未来步骤的预测

每个标量答案都附带 p_null（该值不在输入中的概率）和置信度。每个预测答案都包含中位数和80%置信区间（p10到p90），并可根据要求提供所有99个百分位数。字段数量没有限制：如果一次处理无法容纳所有字段，服务器会将其拆分为多个并行处理流程，每个流程都能看到完整输入，然后合并结果。

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

示例：提取值

提取可能是当前分配给大型语言模型（LLM）最常见的任务："以JSON格式返回发票号、供应商和到期日"。这种方法在大多数情况下有效，但失败模式难以捕捉。输出可能不是有效的JSON，生成过程中数字可能被错误识别，一旦返回文本摘录，就无法追溯其在源文档中的位置。大多数人会构建多层解析、模式验证、重试和抽样检查的提取流水线来应对这些问题。此外，您需要为每个文档中每个字段的推理和输出令牌付费。

Clairic 的运作方式不同；它不生成文本答案。相反，您会获得：

• 从输入中提取的值，因此答案具有依据。

• 计算值，因此它可以解析未经预处理的非结构化数据。

• 字符偏移范围，因此您可以追溯数据在输入中的位置。

• 置信度标签，因此您可以确定哪些值需要进一步检查。

• 强类型输出，因此数字和日期会根据其类型规则生成（例如，分字段会有两位小数）。

• 对空值的处理，缺失字段会以 null 作为答案返回（同时附带 null 的概率估计和猜测值）。

• 更便宜且更快的答案，因为每个字段都在同一并行处理流程中回答。因此，请求30个字段的成本大约与请求3个字段相同。

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

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

从 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
}
}
}

可以看到，Clairic 成功从图像中提取了所有字段值，并附带了置信度评分。它还正确指出收据中未显示折扣，将该字段值设为 null。

示例：估算值

一些值在输入中根本不存在，但输入中包含支持这些值的证据。例如，某些值可能不会以明文形式出现，但可以通过周围值推断出来。如果你向大语言模型（LLM）请求估算，通常只会得到一个数字，而无法感知模型的置信度。模型可能会做出保守猜测、产生幻觉，或通过推理绕开答案。如果你得到一个估算结果，后续处理无法区分一个置信度高的 $180 和置信度低的 $180，也就无法帮助你判断在特定情况下哪些内容适合自动化。此外，通过大语言模型进行推理的速度更慢且成本更高。

决策模型可以通过选择区间（"低于 $100"，"$100–500"，…）来近似估算，但区间划分过于粗糙，每个区间都会增加输入标记，而每个新类别都会在模型决策过程中引入更多混淆源。

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 个月的数据粘贴到大语言模型中并要求预测接下来的 3 个月。第一种方法虽然准确，但为每个新序列设置的成本和时间都很高昂。第二种方法虽然简单，但你只能得到没有置信区间的点预测，预测结果会因提示词的措辞而变化，且答案的置信度有限。

Clairic 处于两者之间 —— 它并不声称要取代专业的时序模型，但相比常规的 LLM，它在速度和成本上都有一定优势。预测字段会以纯文本形式接收状态中的历史数据，并为每个未来步骤返回一个值和一个 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 将电子邮件转换为结构化数据
const
facts
=
(
await
env.
AI
.
run
(
"@cf/cloudflare/clairic"
, {
state: email,
fields: {
customer_name:       { type:
"text"
, instructions:
"客户的名字"
},
order_id:            { type:
"text"
, instructions:
"订单号"
},
amount_paid:         { type:
"number"
, decimals:
2
, unit:
"USD"
, instructions:
"含税总支付金额"
},
days_since_delivery: { type:
"duration"
, unit:
"days"
, integer:
true
,
instructions:
"从送货到客户写信日期的天数"
},
damage:              { type:
"list"
, items:
"text"
, instructions:
"描述的每种损坏类型"
},
repair_cost:         { type:
"estimate"
, unit:
"USD"
, min:
10
, max:
5000
, scale:
"log"
, step:
1
,
instructions:
"修复描述损坏的预估费用"
},
},
})).answers;
const
{
customer_name
,
order_id
,
amount_paid
,
days_since_delivery
,
damage
,
repair_cost
}
=
facts;
// 2. Clef 根据 Clairic 提取的结构化数据和政策进行决策，而非原始邮件
const
options
=
{
refund:
"全额退款已支付金额"
,
repair:
"免费维修并附带预付运费标签"
,
};
const
{
choice
}
=
(
await
env.
AI
.
run
(
"@cf/cloudflare/clef"
, {
state:
`订单 ${
order_id
.
value
} 的损坏索赔。
已支付：$${
amount_paid
.
value
.
toFixed
(
2
)
}。送货 ${
days_since_delivery
.
value
} 天前。
报告的损坏： ${
damage
.
value
.
join
(
", "
)
}.
预估维修费用：$${
repair_cost
.
median
}（80% 范围 $${
repair_cost
.
p10
}-$${
repair_cost
.
p90
}）。
政策：送货后30天内退款。当维修费用低于价格的60%且损坏不影响产品功能时优先维修。`
,
questions: {
resolution: { type:
"choice"
, instructions:
"我们应该提供什么方案？"
, criteria: options },
},
})).answers.resolution;
// 3. LLM 根据决策和所需事实生成回复
const
{
response
}
=
await
env.
AI
.
run
(
"@cf/zai-org/glm-5.3"
, {
messages: [{
role:
"user"
,
content:
`给 ${
customer_name
.
value
} 写一个简短温暖的回复。仅使用这些事实：订单 ${
order_id
.
value
}; `
+
`损坏： ${
damage
.
value
.
join
(
", "
)
}; 接下来会发生： ${
options
[
choice
]
}. 不超过60个字。`
,
}],
});

每个步骤都比前一个步骤获得更清晰的输入。Clef 是基于类型值的五句话摘要进行决策，而不是自由格式的电子邮件，这也可以防止提示注入。LLM 从不接触原始邮件，只看到决策和所需的预测，因此可供其误用的数字更少。每一步都是类型化且可审计的，只有最后一步生成文本。在全LLM版本的此流程中，这三个步骤都是生成式调用，回复中的每个值都必须手动检查。

我们用全LLM版本测试了此流程，其中GLM-5.3在两种版本中都负责撰写回复。在全LLM版本中，GLM-5.3还从同一封电子邮件、政策和提示中执行提取和决策：

Clairic → Clef → GLM-5.3

GLM-5.3 执行所有步骤

端到端延迟

19.3 秒

61.7 秒

1. 提取

Clairic: 0.46 秒

GLM-5.3: 16.1 秒

1. 决策

Clef: 0.22 秒

GLM-5.3: 21.9 秒

1. 回复

GLM-5.3: 18.6 秒

GLM-5.3: 16.4 秒

输入token数

701（每百万索赔184美元）

390（每百万索赔546美元）

输出token数

1,329（每百万索赔5,848美元）

2,544（每百万索赔11,194美元）

每百万索赔成本

6,032 美元

11,740 美元

级联流程仅耗时19.3秒，而对比方案耗时61.7秒：节省了69%的时间，速度提升了约3.2倍。Clairic和Clef在提取和决策环节的总耗时不足1秒，而GLM-5.3完成相同两步操作耗时38秒。使用级联流水线相比全大语言模型流水线成本降低49%。在GLM方案中，两种流水线在每次运行中都能正确获取事实和决策，但Clairic的维修估算值始终一致，而GLM-5.3的估算值每次运行都不同（250美元、250美元和220美元，每次的范围也不同）。

值得注意的是，在全大语言模型流水线中，Gemma 4和Qwen均未能完成该任务，因为它们无法从输入中推导出如维修成本等数值，这表明大语言模型在数据提取任务上表现欠佳。

预览版发布

今天，我们将在Workers AI上发布Clairic的托管端点。我们计划不久后开放模型权重。我们希望先花时间介绍系统一级提取模型的概念，以便您思考这类模型如何适配合适的流程。

当前端点是早期版本，我们预计其性能将逐步提升。以下是我们的初步观察：

• 阅读理解能力较强，但多步骤算术尚未成熟。单步和双步计算（总计、差值、单位换算、日期运算）表现可靠。对于需要多次依赖步骤的长链计算，或需要跨多行表格汇总的场景，任何单次通过模型都难以处理。至少目前，建议让Clairic预测数值，由代码执行数学运算。

• 估算需要依据证据。Clairic最擅长根据可比数据、历史记录或输入中的描述性文本进行估算。若要求其估算缺乏证据的数值，其结果可能不够具体。

• 校准基于测量而非绝对保证。置信区间经过校准训练，在大多数测试集上表现良好，但在不熟悉的数据上可能范围较窄。

• 预测功能基础。该模型未设计为准确替代或预测基于特定数据训练的时间序列模型。应将其用于适当场景，如非关键性的一般模式匹配，而非详细长期预测。

• 善用置信度指标。架构确保每个答案格式完整，但未必绝对正确。请结合置信度、p_null值和置信区间判断哪些内容适合自动化处理（在合适的流程上下文中），哪些需要转交人工复核。

我们将持续改进模型的算术、估算和预测能力。经过进一步优化后，我们计划向所有人开放模型权重。

立即体验

Clairic现已作为预览版在Workers AI上发布，地址为@cf/cloudflare/clairic。可通过Worker中的env.AI.run()调用，或通过REST API从任何位置访问。我们在此处提供了完整的模型文档，以及关于提取模型API的新文档说明。

P.S. 既然你喜欢名字 Clef 的词源，那么我们如何最终确定名字 Clairic 的由来就值得分享了。我们最初希望模型的名字在主题和发音上与 Clef 保持相似。"Clair" 这个词首先浮现出来，它与 Clef 共享相同的 "cl" 发音，并且在音乐领域有深厚渊源（如 "Clair de Lune"）。更重要的是，我们希望这个名字能够体现模型的特性。Clairic 模型应该能够帮助你完成诸如从输入语料库中清晰提取数据等文书工作，并在记账等任务中保持准确性。模型的预测功能则呼应了 "Clair" 的词根——就像预知能力一样，让你能够估计和预测未来值。最后，我们喜欢将这个模型定义为 [Cl]oudflare 的 [AI R]egression 模型。因此，Clairic 诞生了。希望你会喜欢它。

目录列

讨论列

相关标签和社交媒体链接

相关标签

关注社交媒体

• Cloudflare

• Michelle Chen

电子邮件订阅 /