9.2 场景分流决策树

9.2 场景分流决策树

本节摘要：把第 9.1 节的六轴坐标系变成一棵可操作的决策树。分流逻辑按「先硬约束后软偏好」排序：数据能不能出域是一票否决项（出不了域直接排除 Jev）；延迟预算卡多严（几十毫秒内只有 laya 合格，官方口径对照）；选项规模过不过高基数线（约 20 个以上，官方口径 Jev 更强）；精度要求与自建能力配不配（精度敏感且有训练工程能力走 Kev，精度敏感但不能自建回 Jev）；剩下的大盘——高频、封闭、可攒偏好数据的任务——是 laya 的主场。树之外还有第四条路：混合架构，laya 前置过滤加 Jev 兜底，一边吃毫秒级与边际免费，一边保高基数与难例的精度——成立条件与失效条件同样明确。全树附「走完树再做一次自测」的收尾纪律。

学习目标

• 按硬约束到软偏好的顺序走完决策树，得到方案或方案组合。
• 说出四个一票否决项的判断依据：数据出域、延迟预算、高基数线、微调投入意愿。
• 设计 laya 前置过滤加 Jev 兜底的混合架构，说明分界参数怎么定。
• 用「走完树再自测」收尾：留出集数字替树做最终裁决。

一、决策树

场景分流决策树（从上往下走，先硬约束后软偏好）

 [Q1] 数据可以出域（送托管 API）吗？
   ├── 否 ──▶ [Q2] 有训练工程能力与 GPU 预算吗？
   │            ├── 是 ──▶ Kev（自训开源权重，数据不出域）
   │            └── 否 ──▶ laya（CPU 可跑·必须微调，第 5 章投入是前提）
   └── 是 ──▶ [Q3] 单次判断延迟预算卡在几十毫秒以内吗？
                ├── 是 ──▶ laya（官方口径 32.8ms；线上高频多语言场景的主场）
                └── 否 ──▶ [Q4] 选项规模常超过约 20 个（高基数）吗？
                             ├── 是 ──▶ Jev（官方口径高基数更强）
                             │          或 混合架构（laya 粗筛 + Jev 决胜）
                             └── 否 ──▶ [Q5] 精度要求苛刻且愿意自建吗？
                                          ├── 是 ──▶ Kev（0.851 对 0.857，官方口径最近）
                                          └── 否 ──▶ [Q6] 追求省事与零运维吗？
                                                       ├── 是 ──▶ Jev（托管）
                                                       └── 否 ──▶ laya（成本与微调门槛最优）
​

树的排序逻辑说明：Q1 与 Q3 是硬约束（合规与延迟物理上不可商量），放最前避免走完一整树被一票否决；Q4 是能力边界（官方口径）；Q5、Q6 是偏好题——精度优先还是省事优先，两题的答案分别通向 Kev 与 Jev，都否的话 laya 以综合成本胜出。任何一个叶子都不是「最好」，是「在这些约束下最不坏」——选型的成熟度体现在接受这一点。

二、四个一票否决项

数据出域（Q1）。 敏感数据不能送托管 API 时 Jev 出局——这不是成本问题，是合规红线。注意两条易混判断：脱敏后能不能出域要法务拍板，不要工程自查了事；Kev 与 laya 都能数据不出域，但 Kev 出的是「训练在自家 GPU」，laya 出的是「推理在自家 CPU」——出域概念相同，算力门槛不同（第 9.1 节算力轴）。

延迟预算（Q3）。 预算 50 毫秒以内：Jev 的官方口径 236~276 毫秒物理出线，Kev 要小尺寸加好卡才可能挤进线内，laya 直接合格——这是 laya 最硬的一张牌。注意预算要算链路全程：你的业务链路若已有 200 毫秒的其他开销，决策这跳给 50 毫秒是合理的；若链路总共只有 80 毫秒，谁都要掂量（量级示意）。

高基数线（Q4）。 选项常态超过约 20 个（官方口径 Jev 更强）：直接走 Jev，或走第 6.3 节两段式补偿后把「进入决赛圈」这步交给 laya——混合架构的入口之一。注意判据是「常态」：偶发超线的请求可以靠预算截断兜住，常态超线才是路线问题。

微调投入意愿（Q2 的隐含项）。 laya 的每个叶子都以第 5 章投入为前提——没有攒偏好数据、跑微调、做校准的意愿与人力，laya 的叶子全部作废（zero-shot 近随机，官方口径）。树上的 laya 应读作「laya 加你的数据投入」。

三、混合架构：laya 前置过滤加 Jev 兜底

第四条路不在树的叶子上，长在树缝里：高频流量走 laya，难例与高基数走 Jev。架构（示意）：

混合架构（示意）

  全量请求
     │
     ▼
┌─────────────────┐   高置信·选项规模小      ┌──────────────┐
│ laya 前置过滤     │ ─────────────────────▶ │ 自动执行      │
│ （毫秒级·微调后） │                         └──────────────┘
└────────┬────────┘   低置信 / 高基数 / 域外
         │            ┌──────────────┐
         └──────────▶ │ Jev 兜底      │ ──▶ 自动执行或人工
                      └──────────────┘
  分界参数：min_confidence 阈值（第 7.3 节代价矩阵定）
            选项规模线（约 20 个，官方口径）
  成本结构：laya 边际免费扛量，Jev 只接漏下来的难例
​

成立条件三条：laya 侧已微调且校准（第 5、7 章做完，前置过滤的置信才可信）；Jev 侧协议直连已通（第 4.1 节改 baseUrl，兜底通道零成本常备）；分界参数有监控（laya 的弃权率就是 Jev 的调用量——弃权率漂移直接变成 Jev 账单漂移，要报警）。失效条件对应三条：laya 未微调就上前置（随机过滤器，兜底被冲垮）；分界参数拍脑袋（阈值过高 Jev 账单爆炸，过低错例漏网）；流量分布漂移没人盯（第 10.3 节的漂移监控在这里同时护着两个后端）。

混合架构的收益上限取决于「laya 能独扛多大比例」：常见形态下前置过滤能独扛多数流量（示意判断：弃权率两三成以内属健康，具体以你的门控数据为准）——Jev 只为难例付费，账单与「全走 Jev」相比差出一个量级（定性）。

四、走完树之后：自测收尾

树给方向，数字定案。走完树得到候选方案后，最后一道工序是拿自己的留出集跑一次三向自测（如果候选不止一个）：同一批业务样本、同样的题面，各方案跑一遍，比准确率、延迟（第 3.2 节的基准纪律：中位数不报最好值）、以及在你业务上的失败形态——失败样本是不是同一批（失败形态互补的组合方案，比单项冠军更值得上）。这一步的成本不过几小时，却能把「树上的推理」换成「自己数据上的证据」；第 9.1 节的对照表是地图，自测才是你的地形。

五、两个场景走查（示例）

树的用法看两个案例。走树时每个节点都写判定依据——写不出依据的节点就是你要补调研的地方。

案例 A：客服工单一线分类。 全球站工单先分「退款/技术/物流/投诉」四类再进队列，日均 80 万条，英语葡语混杂，预算 50 毫秒，数据可出域。走树：Q1 可以出域；Q3 预算 50 毫秒——Jev 官方口径 236~276 毫秒出线，小尺寸 Kev 勉强但团队无 GPU 运维；Q4 选项四个，远离高基数线；Q5 精度要求高（分错队列伤体验）但无自建能力；Q6 有一名算法人力愿意做微调。判定：laya（延迟与语言双硬约束命中），微调投入由 Q6 确认。落地形态选纯 laya 而非混合：四类封闭任务微调后弃权率预期低（示意判断），兜底通道可先建不用。

案例 B：研发任务自动分派。 每周约 2000 条新任务要分给 40 个候选负责人，延迟不敏感（小时级即可），数据含未公开代码描述——不能出域。走树：Q1 不能出域，Jev 直接出局；Q2 团队无训练工程能力；由此到 laya 叶子——但 Q4 反向亮灯：40 个候选常态超线（约 20 个以上，官方口径），第 6.3 节两段式成了必选项。判定：laya 加 shortlist/tournament 组合，短名单用团队历史分派记录训练的召回器（规则加特征排序即可，示意方案）。这个案例的关键提醒：树的叶子不是终点，叶子附带的补偿工程（第 6.3 节）与投入前提（第 5 章）都在账上。

两个案例合起来的教训：同一棵树，先硬后软的顺序保证了「物理上不可能」的方案先被砍掉，剩下的分歧才交给偏好与成本——所以走树时对每个一票否决项的判定依据要有书面记录，它就是将来复盘选型时的审计线。

最后补一种树不回答的情况：三个叶子都不合适。典型信号有两个——其一，任务根本不是「决策」：要的是开放生成或长链推理（写文案、做多步规划），决策引擎整个类目出局，回生成式模型；其二，决策没有任何可验证的对错（审美偏好、主观打分），没有对错就没有留出集，没有留出集就没有第 9.1 节的任何一轴——这类问题要么不上模型，要么改造成有对错的代理任务（例如「偏好 A 还是 B」的配对比较）再回来走树。树的作用恰恰包括诚实地告诉你：这里没有它的叶子。

给团队落地的建议是把这个走树流程固化成半页纸的表单，新需求半小时走完：

• 表单左侧：六问（Q1 到 Q6）各配一栏「判定依据」，写不出依据的节点先补调研。
• 表单右侧：结论、投入估算（微调数据量、算力、人力）、条件变化触发器。
• 触发器清单：调用量级、语言数、延迟预算、合规口径——任一变化即重走树。

比每次重新开讨论会便宜得多，也让选型决策从「谁嗓门大」变成「谁依据硬」。

本节要点回顾

• 决策树按硬约束到软偏好排序：出域、延迟、高基数、精度自建、省事偏好，六个问题四条出路。
• 四个一票否决项：数据出域红线、延迟物理上限、高基数能力线、微调投入意愿。
• 混合架构 laya 前置加 Jev 兜底：成立靠微调校准、协议直连、分界监控三件套，失效于它们的缺席。
• 弃权率即兜底调用量：混合架构的成本阀门就是第 7.3 节的阈值。
• 树给方向、自测定案：留出集三向自测（准确率、延迟、失败形态）是选型的最后一道工序。
• 走树写依据：每个否决项的判定记录就是选型复盘的审计线。

方向有了。对已经在 Jev 上跑着的系统，还有一条更具体的路：协议已兼容，怎么安全地把流量迁到开源侧——下一章给迁移三步与回退预案。