扣子混合模型(Hybrid Model)联合调度开发测评指南

混合调度的本质，是把确定性规则与泛化推理拆分开来，各管各的。用户问“冻结账户”——意图明确，直接走规则校验就好；但如果用户说的是“上次冻结后，我还能登录吗”，这就得交给大模型，结合知识库做语义推演。

在扣子平台里实现这种分工，核心是不让单一模型大包大揽，而是让确定性逻辑与泛化推理各自独立运转。具体做法如下：

划定混合调度触发边界

先在工作流编辑器里新建一个「意图预判」节点，类型选「LLM分类器」，输入字段设为用户的原始消息文本。这个节点的任务，是输出两个关键字段：【intent_confidence】（置信度）和【primary_intent】（主意图）。

阈值定在0.82——这是反复验证过的经验值。低于这个数，说明意图模糊，需要转给大模型做深度推理；高于或等于它，直接走规则引擎，效率最高。

然后，加一个条件分支节点。判断逻辑很直接：intent_confidence ≥ 0.82 → 走规则引擎分支；否则 → 跳转到「RAG增强生成」节点。这一步是分水岭，不能含糊，否则规则和模型会相互覆盖输出，结果一团糟。

规则引擎侧：高频确定性任务快速响应

方法一：用「关键词+正则」双校验构建轻量规则集

以“密码重置”意图为例。在规则引擎模块里，配置两条并行规则：① 匹配“重置密码|改密|忘记密码”等关键词；② 同时校验消息里是否包含11位手机号或邮箱格式字符串。两条规则都命中，才触发流程。这种做法简单可靠，能过滤掉很多模糊请求。

方法二：接入外部API做实时状态校验

规则命中后，别急着执行动作。中间插入一个「HTTP请求」节点，调用内部鉴权服务，接口是 /auth/status?uid={{user_id}}。只有当返回的 status=“active” 时，才允许进入下一步。这个设计能防止规则误触已注销账户的重置流程——不然用户都注销了，你还给他发重置密码的链接，那不合理。

大模型侧：模糊意图的语义理解与上下文补全

第一步：配置RAG增强节点

知识库源选择「FAQ向量库」和「工单历史摘要表」，相似度检索时，top_k设为3就够了。但有个关键过滤条件：强制排除创建时间早于90天的条目。老数据容易误导当前业务逻辑，比如历史工单里的旧流程，可能已经完全不适用了。

第二步：设计提示词模板

在系统指令里明确写入：“你只能基于以下检索结果回答，禁止编造未提及的流程步骤；若检索结果为空，回复‘我需要更多上下文，请说明具体场景’。”这能防止大模型自由发挥，确保输出可控。

第三步：启用「上下文窗口压缩」开关

将对话历史按角色分段后，仅保留最近2轮用户提问和1轮机器人回复参与本次生成。长对话会导致大模型忽略最新意图，压缩上下文相当于帮它聚焦焦点。

联合状态同步：确保规则与模型共享同一上下文

在工作流全局变量里声明一个 session_state 的JSON对象，初始值设为 {"stage": "init", "pending_action": null, "last_rule_hit": ""}。这相当于一个全局状态本，让规则和大模型都知道当前进行到哪一步了。

每次规则引擎触发操作时，自动更新 session_state.last_rule_hit = “reset_password”。每次大模型生成回复后，检查其输出中是否含 action_tag 字段（比如 {"action_tag": "escalate_to_human"}），如果有，就同步写入 session_state.pending_action。

后续所有节点都可以读取 session_state.stage 来判断当前处于开户引导、投诉受理还是人工转接阶段。【这个变量必须在所有分支节点中显式传递，不能依赖默认继承】——否则一旦分支路径不同，状态就丢了。