2.3 默认路由的取舍

2.3 默认路由的取舍

本节摘要：把请求交给 Router 自动分，换来的省心，代价是把语言判断交给了脚本检测。本节讨论这笔交换什么时候划算、什么时候不划算：先厘清默认策略的行为边界（按脚本检测分流，具体规则以官方实现为准）；再分析错误路由的代价——多语言文本误送英语检查点比反向误送的伤害更大，因为英语检查点没有为其他语言训练过；然后给三条兜底策略：单语流量显式钉死、不确定时覆盖优先（走多语言检查点）、抽样复核错配率；最后专门处理混合语言输入——官方口径是按脚本检测分流，工程建议是以主脚本定位辖区、拿真实样本实测，不要凭直觉预判路由行为。

学习目标

• 说出默认路由（交给 Router）的行为边界与适用前提。
• 分析两类错误路由（英语误送多语言、多语言误送英语）的代价差异。
• 落地三条兜底策略：显式钉死、覆盖优先、抽样复核。
• 给混合语言输入设计一套实测驱动的处理方案。

一、默认策略的行为与边界

默认策略一句话：不指定检查点，Router 对输入做文字脚本检测，按检测结果分流（官方口径；具体判定规则以官方实现为准）。

它的适用前提是「检测可判、辖区正确」八个字。检测可判：文本的书写系统单一且清晰——纯英语、纯中文、纯俄语都满足。辖区正确：检测结果对应的检查点确实覆盖该语言——拉丁字母方向的英语辖区、100+ 语言的多语言辖区。

边界之外的典型输入：多脚本混排（一句里既有汉字又有英文单词）；语言与脚本错位（用拉丁字母写的越南语、用西里尔字母写的蒙古语）；超短输入（一个词、一个标点，检测特征太少）。这些输入上，默认策略的行为要靠实测确认，不能靠脑补——这正是本节后半的主线。

二、错误路由的代价

路由错误分两个方向，代价不对称：

第二行是真正的风险来源：它不一定报错——模型总会吐出一个概率分布——而是安静地给出低质量答案。分布看起来与好答案无异（第 1.2 节的形态完全一样），置信度字段也不会替你标红。所以错误路由的隐蔽性大于破坏性的瞬间，危害在于长期悄悄拉低质量而不触发任何告警。

对应动作有两个。监控侧：把 checkpoint 字段的分布当质量信号用（2.2 节的看数姿势），多语言流量占比突然漂移就查检测。防御侧：宁可走多语言检查点，也别让非英语流量落到英语检查点——覆盖优先原则，见下。

三、三条兜底策略

策略一：单语流量显式钉死。 流量构成已知且稳定（内部系统、单一市场产品），直接 preload 对应检查点（2.1 节写法），把「检测」这层不确定性整个拆掉。这是成本最低、收益最确定的优化。

策略二：不确定时覆盖优先。 流量构成拿不准、或明知混杂，显式走 laya-multilingual：它牺牲一点单语精度（方向性结论），换「任何脚本都接得住」。判断标准很简单：错送多语言检查点的代价（略降质）远小于错送英语检查点的代价（可能失效），两害相权取覆盖。

策略三：抽样复核错配率。 定期抽一批线上样本，人工标注真实语言，与 checkpoint 字段比对，得到路由错配率的直接估计。错配率低，默认策略就放心用；高就启动策略一或二。这一步是「默认路由值不值得信任」的最终裁决，数据说了算。

# audit_route.py —— 错配率最小实验（写法示意）
from laya import Router

# 样本与人工标注：标注该样本「应当」由哪个辖区作答
samples = [
    ("退货地址填错了怎么改？", "multilingual"),
    ("Payment failed for order 8837.", "english"),
    (" Quotation 已批准，合同今日寄出。", "multilingual"),
]

router = Router()
mismatch = 0
for text, expected in samples:
    r = router.predict(context=text, questions=[{
        "id": "ping", "type": "noul", "question": "这条需要处理吗？",
    }])
    used = r.get("checkpoint", "unknown")
    ok = (used == "laya") == (expected == "english")
    mismatch += 0 if ok else 1
    print(("OK " if ok else "MISMATCH "), text[:16], "→", used)

print("错配率:", mismatch, "/", len(samples))
​

百条量级的抽样就够出结论；标注只需要「英语辖区 / 多语言辖区」的二分，一分钟几十条。把这份脚本放进周期任务，错配率就成了路由健康度的常设指标。

四、混合语言输入怎么办

混合语言是最常见的边界输入：中文邮件里夹英文产品名、英文工单里贴中文报错。官方口径是 Router 按脚本检测分流，混合输入的具体判定（以主脚本为准、逐段判定、还是按首字符）以官方实现为准。工程上给三条建议，全部以实测为前提：

1. 以主脚本定位辖区。 判断文本的主体脚本（按字符占比即可），主体是汉字就按多语言流量对待，主体是拉丁字母再细看是不是英语。这是最接近 Router 设计意图的预处理思路。
2. 拿真实样本实测，不要凭直觉预判。 取一百条线上真实混合样本，跑一遍默认 Router，记录 checkpoint 字段与作答质量（有没有人工可辨的明显错判）。实测十分钟的收获，超过读十段猜测。
3. 拆或不拆，按质量差距决定。 若混合样本整体质量明显差于纯语样本，考虑预处理拆分（按脚本切段分别送检再合并结果）；若差距可忽略，别拆——拆分引入的复杂度（切段、合并、对账）通常高于收益。

三种处理选项的完整对照：

# mixed_lang_probe.py —— 混合语言实测探针（写法示意）
from laya import Router

router = Router()
samples = [
    "客户反馈：checkout 页面在 Safari 上白屏，请尽快处理。",
    "工单：the printer 报错 paper jam，重启后依然存在。",
    "Quotation for Q3 has been approved by finance，合同下周寄出。",
]
for text in samples:
    r = router.predict(context=text, questions=[{
        "id": "lang_route", "type": "noul", "question": "这段文本需要中文客服处理吗？",
    }])
    # 关注两件事：checkpoint 字段（送进了哪个辖区）、
    # 以及作答质量是否与纯语样本一致——不一致再考虑预处理拆分。
    print(text[:20], "->", r.get("checkpoint", "unknown"))
​

五、路由决策速查表

六、路由决策树：一图收束

 开始：你的流量语言构成
   │
   ├─ 纯英语且稳定 ──────────▶ 显式预载 laya
   │
   ├─ 单一非英语且稳定 ──────▶ 显式预载 laya-multilingual
   │
   ├─ 混杂或未知
   │    ├─ 能接受略降质 ─────▶ 默认 Router 自动分
   │    └─ 覆盖优先 ─────────▶ 显式走 laya-multilingual
   │
   └─ 混合语言占比高
        ├─ 实测质量可接受 ───▶ 不处理，默认路由
        └─ 实测质量折损 ─────▶ 主脚本归类或切段拆分
                                 （先跑 audit_route.py 拿错配率）
​

本节要点回顾

• 默认路由的适用前提是「检测可判、辖区正确」；混合语言、语言脚本错位、超短输入是三类边界。
• 代价不对称：英语误送多语言略降质，非英语误送英语可能整体失效且不报错。
• 三条兜底：单语钉死、覆盖优先、抽样复核——错配率是最终裁决。
• 混合语言：主脚本定位辖区、实测不脑补、拆分与否按质量差距决定。

至此，laya 的结构层（三个检查点加 Router）与它的取舍都讲完了。概念齐备，下一章正式动手：安装 SDK、发出第一次 predict、把批量与 decide 用起来，最后用 CLI 把决策能力接进 shell 管道。