用 Clef 构建低延迟决策层:从 Workers AI 推理到强化学习微调

2026-10-01 31 预计阅读时间: 1 分钟
来源: blog.cloudflare.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:12 分钟

Clef 和 Clef-flash 的发布,瞄准的不是长篇内容生成,而是应用中更高频、更靠近控制面的任务:分类请求、选择工具、判断是否升级人工处理,以及决定智能体下一步动作。两款模型以开源形式提供,并托管在 Workers AI 上;配套的强化学习平台则允许开发者使用自己的数据微调决策模型。

这类模型值得关注,是因为很多 AI 系统真正的瓶颈并不在“能否生成答案”,而在“能否快速、稳定地做出正确选择”。

决策模型适合放在哪一层

一个典型智能体可能需要在每次请求中完成以下判断:

  • 这是退款、物流查询,还是账户安全问题?
  • 应调用搜索、数据库、工单系统,还是直接回复?
  • 当前结果是否足够可信,需要不需要交给更大的模型?
  • 某个操作是否涉及权限、资金或隐私,必须人工确认?

这些任务通常拥有有限的动作空间,输出也可以约束为标签、分数或结构化 JSON。与自由文本生成相比,它们更重视延迟、稳定性和可评估性。

Clef 与 Clef-flash 为这种决策层提供了新的模型选择。不过,仅从发布摘要无法得出两者精确的速度、成本和质量差异。实际选型时,应该使用自己的流量样本做基准测试,而不是根据模型名称推断适用场景。

一种稳妥的架构是:

用户请求
   │
   ▼
Clef 决策层 ── route=direct ──> 直接处理
   │
   ├── route=tool ────────────> 调用受控工具
   │
   ├── route=large_model ─────> 转交更强模型
   │
   └── route=human ───────────> 人工审核

决策模型负责缩小选择空间,业务代码继续负责权限检查、参数校验和最终执行。不要让模型输出直接绕过服务端安全策略。

在 Worker 中实现一个分类路由器

下面是一个可以改造的最小 Cloudflare Worker 示例。它假设目标模型接受文本输入,并返回可读取的文本或 response 字段;具体模型 ID、输入参数和返回结构需要按照 Clef 在 Workers AI 中的实际接口调整。

先创建 wrangler.toml:

name = "clef-decision-router"
main = "src/index.ts"
compatibility_date = "2025-01-01"

[ai]
binding = "AI"

[vars]
# 部署前替换成 Workers AI 中实际可用的 Clef 或 Clef-flash 模型 ID
DECISION_MODEL = "REPLACE_WITH_CLEF_MODEL_ID"

然后创建 src/index.ts:

interface Env {
  AI: any;
  DECISION_MODEL: string;
}

type Decision = {
  route: "direct" | "tool" | "large_model" | "human";
  confidence: number;
  reason: string;
};

const ALLOWED_ROUTES = new Set([
  "direct",
  "tool",
  "large_model",
  "human",
]);

function parseDecision(result: any): Decision {
  const raw =
    typeof result === "string"
      ? result
      : result?.response ?? result?.output ?? "";

  const parsed = JSON.parse(raw);

  if (!ALLOWED_ROUTES.has(parsed.route)) {
    throw new Error("Model returned an unsupported route");
  }

  const confidence = Number(parsed.confidence);
  if (!Number.isFinite(confidence) || confidence < 0 || confidence > 1) {
    throw new Error("Invalid confidence score");
  }

  return {
    route: parsed.route,
    confidence,
    reason: String(parsed.reason ?? ""),
  };
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    if (request.method !== "POST") {
      return new Response("Use POST", { status: 405 });
    }

    const body = (await request.json()) as { message?: string };
    const message = body.message?.trim();

    if (!message) {
      return Response.json({ error: "message is required" }, { status: 400 });
    }

    const prompt = `You are a request router.
Choose exactly one route:
- direct: simple question that can be answered without tools
- tool: requires an approved internal tool
- large_model: requires deeper reasoning
- human: security, payment, privacy, or irreversible action

Return JSON only:
{"route":"direct|tool|large_model|human","confidence":0.0,"reason":"short reason"}

Request:
${message}`;

    try {
      const result = await env.AI.run(env.DECISION_MODEL, { prompt });
      let decision = parseDecision(result);

      // 低置信度时采取保守策略,而不是盲目信任模型。
      if (decision.confidence < 0.65) {
        decision = {
          route: "human",
          confidence: decision.confidence,
          reason: `Low-confidence fallback: ${decision.reason}`,
        };
      }

      return Response.json(decision);
    } catch (error) {
      return Response.json(
        {
          route: "human",
          confidence: 0,
          reason: "Decision model failed; using safe fallback",
        },
        { status: 200 }
      );
    }
  },
};

安装 Wrangler 并本地运行:

npm install --save-dev wrangler
npx wrangler dev

发起测试请求:

curl -s http://localhost:8787 \
  -H 'content-type: application/json' \
  -d '{"message":"请删除我的账户以及全部历史订单"}'

这个例子刻意加入了三层保护:输出枚举校验、置信度阈值和异常降级。生产环境还应增加身份认证、速率限制、日志脱敏,以及针对高风险工具的二次授权。

用自己的数据做强化学习,重点是奖励定义

新的强化学习平台允许开发者使用自有数据微调决策模型。真正困难的部分通常不是“上传多少条数据”,而是如何把业务目标变成不会误导模型的奖励信号。

可以先把历史记录整理成如下 JSONL。以下只是建议的数据准备格式,不代表平台的官方上传协议:

{"input":"查询昨天的快递状态","action":"tool","reward":1.0,"metadata":{"tool":"shipment_lookup"}}
{"input":"帮我转账 5000 元到新账户","action":"human","reward":1.0,"metadata":{"risk":"financial"}}
{"input":"解释一下什么是幂等性","action":"direct","reward":1.0,"metadata":{"topic":"engineering"}}
{"input":"分析这份包含多个附件的合同","action":"large_model","reward":0.8,"metadata":{"complexity":"high"}}

训练数据至少需要区分三个概念:

  1. 输入:模型做决策时真实可见的信息。
  2. 动作:有限且稳定的候选决策集合。
  3. 奖励:该动作是否带来了可接受的业务结果。

不要简单地把“用户没有投诉”视为正奖励,也不要把“任务很快结束”当成唯一目标。否则模型可能学会拒绝复杂请求、过度转人工,或者选择成本最低但质量最差的路径。这就是典型的奖励投机。

在提交训练前,可以用下面的 Python 脚本检查 JSONL:

import json
import sys

ALLOWED_ACTIONS = {"direct", "tool", "large_model", "human"}


def validate(path: str) -> None:
    total = 0
    action_counts = {action: 0 for action in ALLOWED_ACTIONS}

    with open(path, "r", encoding="utf-8") as file:
        for line_number, line in enumerate(file, start=1):
            if not line.strip():
                continue

            row = json.loads(line)
            total += 1

            if not isinstance(row.get("input"), str) or not row["input"].strip():
                raise ValueError(f"line {line_number}: invalid input")

            action = row.get("action")
            if action not in ALLOWED_ACTIONS:
                raise ValueError(f"line {line_number}: invalid action {action!r}")

            reward = row.get("reward")
            if not isinstance(reward, (int, float)) or not -1 <= reward <= 1:
                raise ValueError(f"line {line_number}: reward must be between -1 and 1")

            action_counts[action] += 1

    if total == 0:
        raise ValueError("dataset is empty")

    print(f"valid rows: {total}")
    for action, count in sorted(action_counts.items()):
        print(f"{action}: {count} ({count / total:.1%})")


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("usage: python validate_dataset.py decisions.jsonl")
    validate(sys.argv[1])

运行方式:

python validate_dataset.py decisions.jsonl

类别分布检查很重要。如果历史系统几乎把所有请求都交给人工,模型很容易复制这一偏差,而不是学到更好的路由策略。

上线前不要只看准确率

决策模型的离线评估应该贴近动作后果。普通准确率可能掩盖严重问题:把一个简单问题错分给大模型只是增加成本,把资金操作错分为自动执行则可能造成安全事故。

建议至少追踪以下指标:

  • 每个动作类别的精确率与召回率;
  • 高风险请求被自动执行的比例;
  • 人工升级率及其变化;
  • P50、P95 和 P99 推理延迟;
  • 每千次决策的模型与工具成本;
  • 新模型与旧规则发生分歧时的真实结果;
  • 不同语言、地区和客户群体之间的错误率差异。

部署初期可以采用影子模式:新模型只记录建议,不实际控制流量。确认指标稳定后,再从低风险类别开始逐步放量。强化学习微调也应保留独立测试集,避免训练数据与评估数据混用。

是否应该采用 Clef

如果系统需要大量低延迟分类、工具选择或智能体路由,Clef 和 Clef-flash 值得进入基准测试名单。开源模型有利于理解和复现实验,Workers AI 托管则减少了自行部署推理服务的工作;新的强化学习平台进一步提供了利用私有业务反馈调整模型的路径。

采用前可以逐项确认:

  • 是否已经定义稳定、互斥的动作集合;
  • 是否存在可信的历史反馈,而不只是点击或停留时长;
  • 是否为低置信度和服务故障准备了安全降级;
  • 是否能阻止模型直接执行高风险操作;
  • 是否有独立评估集和可回滚的版本策略;
  • 是否对 Clef、Clef-flash、现有规则和其他模型做过同流量对比。

决策模型最适合做“受约束的选择器”,而不是系统中的最终授权者。把模型放在清晰的策略边界内,再用真实结果持续校准奖励,才能同时获得速度、成本和可靠性上的收益。


相关推荐