规则引擎换成决策模型：换不换

先说结论

1. 这不是整体替换。TypeSafe 官方文档把 System One 模型定位为“做快速、结构化的判断，返回 typed answers 和 probabilities”的组件，而规则引擎适合确定、可审计、零模型成本的分支。两者可以先并行。
2. 值得换的信号：规则数量失控、维护成本高于收益、需要处理自然语言变体、需要给判断附不确定度。这些信号应具体到可以自查。
3. 不该换的情况：监管要求可追溯到具体规则、每个判断必须 100% 确定、调用量极低。模型概率不能保证个案正确，且官方写明模型不产出解释。
4. 迁移路径建议采用：影子模式并行跑 → 低风险分支放行 → 低置信度退回规则 → 稳定后再扩面。这是本文建议，不是官方建议。
5. 最好做最小对照实验：同一判定用规则版和决策模型版各写一遍，把两者分歧样本收集起来，作为评测和回退判断的素材。

证据与过程

先看输出形态：规则给答案，决策模型给答案加概率

工程上，规则引擎通常输出确定的布尔值或枚举值。这个对比基础来自工程实践，不是 TypeSafe 官方文档对规则引擎的结论。我们看官方对决策模型输出形态的说明。官方 System One 概念页写道：

“System One models are a class of AI models built to make fast, structured decisions that software can use directly. A System One model evaluates a state and returns typed answers and probabilities.”

来源是 System One。

同一页还说明了它和普通 LLM 的差异：

“Like an LLM, a System One model understands natural-language input. It returns typed decisions and probabilities rather than generated text.”

因此可以这样理解：规则引擎擅长给出确定分支，而决策模型的核心增量是同时给出答案和不确定度。官方 Primitives 页面列出三种问题类型，三种都返回结构化答案，其中 Choice 返回 choice、probabilities、confidence，Score 返回 score、legend、probabilities、confidence，Noul 返回 noul，官方数据范围是 0 到 1。官方原文是：

“There are three question types, each returning a different shape of answer.”

来源是 Primitives (Questions)。

规则引擎也可以返回枚举或分数，但通常不会天然附带校准过的概率。官方 System One 页面声明，这些概率经过校准训练：

“System One models are trained for calibrated decisions: their probabilities are optimized against outcomes to reflect uncertainty.”

同一句后半段也提醒，校准不保证单个答案正确。这个限制会直接影响“什么情况不该换”。

什么时候值得换：四个自查信号

官方 Example use cases 页面列出不少自然语言判断场景，例如客户支持：

“Customer support: Classify incoming tickets by issue, product area, and customer intent. Process call transcripts to extract customer issues, commitments, and follow-up actions. Detect urgency, frustration, churn risk, and refund requests. Route cases to the right team, queue, or automated workflow.”

从这些场景反推，我建议用下面四个具体信号自查，判断是否值得从规则引擎迁出一部分判断。这些信号是本文的工程建议，不是官方数据，也不是官方推荐的迁移标准。

1. 规则数量失控：同一入口的 if-else/正则分支累计接近或超过约 100 条，或者排错时需要同时查看 3 个以上分支文件。这个“100 条”和“3 个文件”是本文建议的粗糙触发线，目的是让信号可判断，不是行业标准。
2. 维护成本高于收益：每次业务变更都要改动多条规则，且规则之间出现难以解释的交互；新人接手时只能靠口口相传理解规则意图。
3. 需要处理自然语言变体：用户表达“我想退”“这钱能还吗”“不想要了”等说法，关键词规则要不断补充同义词，仍然容易漏判。决策模型能理解自然语言输入，这是官方文档写明的能力。
4. 需要给判断附不确定度：如果你需要做优先处理、人工复核或分层门控，而不是只要一个二值结果，官方 Confidence-gated routing 模式提供了可复用思路。

官方在 use-case map 还给出了实时应用的速度数据：”Frontier intelligence at real-time speeds (150ms) means AI can make decisions faster than human perception.” 这是官方数据，但它不直接决定你要不要迁移，因为规则引擎也可能比 150ms 更快。把它放在这里只是说明，速度未必是反对迁移的理由。

什么时候不该换：可追溯、100% 确定、调用量极低

决策模型有一个关键限制，官方 System One 页写道：

“System One models are trained for calibrated decisions: their probabilities are optimized against outcomes to reflect uncertainty. Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct.”

这直接意味着：如果某个判断必须 100% 确定，模型给出的概率不能作为“这个个案一定对”的保证。此时应保留规则，或者至少保留规则兜底。

另外，官方还写明：

“System One models do not write replies, produce code, or generate explanations of their reasoning.”

如果监管或审计要求每次决策都能逐条追溯到“因为命中了哪条规则”，那么规则引擎的可追溯性更强。需要说明：这是工程合规上的判断，不是 TypeSafe 官方文档说“监管场景必须保留规则”。官方 use-case map 虽然列了法律与合规等示例，但并未承诺逐条可追溯，因此严谨写法是：选择在监管要求可追溯时保留规则，是本文建议，不是官方结论。

调用量极低的情况也建议继续用规则。比如一天只有几十次调用、逻辑固定且不接触自然语言变体，引入模型会带来新的依赖、成本和不确定性，而收益很小。这是本文的判断，不是官方数据。

怎么换：我建议的影子模式四段式

下面这段迁移路径是我的建议，不是官方建议。官方没有说要替代规则引擎；它提供的是按置信度分层路由的模式。

官方 Confidence-gated routing 页面的核心句是：

“Use confidence as a second axis. The answer tells you what; confidence tells you whether to act.”

官方示例里，语音银行命令对不同动作使用不同置信度阈值：

action = response.answers["intent"]
# Below 0.6 confidence on any action, route to a human
if action.confidence < 0.6:
    route_to_support_agent(account_id)
elif action.choice == "check_balance":
    # Low stakes. 0.6 confidence is sufficient.
    show_balance(account_id)
elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        # High stakes, but high confidence. Safe to act automatically.
        approve_transfer(account_id)
    else:
        # High stakes, moderate confidence. Verify intent first.
        ask_user_to_confirm("Just to confirm: you would like to approve this transfer, is that correct?")
else:
    route_to_support_agent(account_id)

其中 0.6 和 0.85 是官方示例中的阈值，不是通用标准。官方也解释了按动作风险差异化设置阈值的逻辑。我们可以把这种“置信度门控”用在迁移过程中，但不是直接替代规则，而是把低置信度样本退回规则或者人工。

字段提醒（很容易抄错）：上面代码里读的 action.confidence 来自 Choice 答案——按官方 Primitives 的字段表，只有 choice 与 score 答案才有 confidence 字段；noul 答案只返回一个 0~1 的 noul 值，没有 confidence、也没有 probabilities（官方 Confidence 文档也写明 “Noul answers don’t carry one”）。如果你把 noul 判定写成 answer.confidence，会直接拿到 undefined。

我建议的迁移顺序：

1. 影子模式并行跑：规则引擎继续生产，模型结果只记录不干预。重点记录规则与模型的分歧样本。
2. 只对低风险分支放行：选择错误代价低的分支，比如客服标签分类，让模型结果参与，但保留规则兜底。放行标准要基于影子期分歧率和错误成本。
3. 低置信度退回规则：参考官方 confidence-gated routing，为不同动作设置不同置信度阈值。低于阈值时回到原规则或人工确认。这一步是迁移的关键，不是简单地把模型输出当作最终答案。
4. 稳定后再扩面：用影子期积累的分歧样本和线上数据评估是否扩大模型接管范围。扩面条件建议写死，例如连续两周分歧率低于某个可接受线；这是本文建议，不是官方数据。

最小对照实验：规则版、模型版、分歧记录

下面是一个最小对照实现，用“客服消息是否申请退款”作为判断目标。规则版用关键词，决策模型版用 TypeSafe 官方 Primitives 中展示的 Noul 问题。两者输出不一致时，把样本记下来，就是最好的评测集。

# 规则版：确定、可解释、零模型成本
def rule_refund_requested(text: str) -> bool:
    text = text.lower()
    kws = ["refund", "money back", "return", "退", "退款"]
    return any(k in text for k in kws)

# 模型版：自然语言理解 + 不确定度
from typesafe_sdk import Noul

state = {"message": text}
questions = {
    "refund_requested": Noul(
        instructions="Does the customer request a refund?",
    )
}
# 实际调用按官方 Quick start 的形态：response = client.system_one(state=state, questions=questions)
answer = response.answers["refund_requested"]

# 二值化阈值使用 0.5，这是本文选择的示例阈值，不是官方数据。
# 注意：noul 答案只有一个 0~1 的 noul 值，没有 confidence 字段，所以这里只能对 noul 本身设阈值。
model_says_yes = answer.noul > 0.5

# 分歧记录：影子模式期间持续保存两份结果
divergences.append({
    "text": text,
    "rule": rule_refund_requested(text),
    "model_noul": answer.noul,
})

这里需要说明：noul 返回 0 到 1 是官方 Primitives 页写明；但“用 0.5 转成二值结果”是本文为了方便对照选择的做法，不是官方推荐。实际生产里可以根据业务损失调整，而不是固定 0.5。

为什么分歧样本重要？因为规则版和模型版的分歧不是噪音，而是暴露两类错误来源：规则漏判的同义表达、模型误判的边界样本。每一批分歧都可以拆成两类：规则对模型错、规则错模型对。后者尤其值得加入回归集，用来判断模型是否真的带来了增量。

自己的判断/清单

情景	我的建议
同一入口规则约 100 条以上，或排错要跨 3 个以上文件	候选迁移，先做影子对照
规则改动频繁，维护成本高于新增规则收益	候选迁移
输入存在大量自然语言变体，关键词规则反复漏判	候选迁移
需要按不确定度做人工复核、优先路由或门控	候选迁移，优先采用 confidence-gated routing
监管要求逐条可追溯，规则命中记录必须完整	保留规则
判断必须 100% 确定，错一次不可接受	保留规则，或规则兜底
调用量极低、逻辑简单、几乎不变	保留规则
已经开始影子迁移	把分歧样本作为评测集和低置信度回退依据

表里“约 100 条”和“3 个以上文件”是本文的粗糙自查线，不是官方数据，也不是行业标准。实际阈值要根据代码库规模、调用量和错误成本来设。

这次没核实的

• TypeSafe 官方没有提供“从规则引擎迁移到决策模型”的完整迁移手册，本文的四段式路径是建议，不是官方要求。
• 官方没有量化“规则数量失控”的阈值，本文给出的约 100 条和 3 个文件是工程建议，未能对应到一手来源。
• 官方 use-case map 提到实时应用 150ms 和大数据场景 100x cheaper，但这些数据的具体测试条件、基准和适用边界未能进一步核实；引用时只作为官方页面上的表述，不作为普遍性能承诺。
• 监管可追溯性、低调用量保留规则、0.5 二值化阈值等判断，均来自工程实践，不是官方文档结论。

参考来源

• Primitives (Questions) – TypeSafe 官方文档
• System One – TypeSafe 官方文档
• Example use cases – TypeSafe 官方文档
• Confidence-gated routing – TypeSafe 官方文档