设想一家有几十个检测模型的食品企业（场景为示意，不对应任何真实企业）：苹果分选的视觉模型有三个版本，其中两个还在不同产线上运行；农残筛查有苹果和番茄两个光谱模型，番茄那个被人拿去筛了葡萄；风险预测模型上个季度重训过，质检部门却没有收到通知；新同事想查某个添加剂的适用要求，不知道该问哪个系统。每个模型单独看都“准确”，放在一起却没有人能说清：这个请求该由谁处理，处理它的是哪一版，结果可不可信。
这是模型数量越过某个临界点之后的典型症状。继续训练新模型，只会让混乱里多一个角色。纵横国际 AI 的做法，是在模型之前先加一层路由器（Router），由它决定请求去哪里。
路由规则：先看任务，再看数据
路由器主要看三个信号：任务类型、数据类型和置信度。前两个信号决定候选模型，第三个信号决定结果要不要放行。最基础的规则可以写成一张表：
| 任务类型 | 目标模型 | 路由依据 | 不满足时的处理 |
|---|---|---|---|
| Image Task：产线图像、缺陷、异物 | Vision Model（视觉模型） | 输入是图像帧，品类与产线已登记 | 置信度低则保留样品复检 |
| Residue Task：光谱农残筛查 | Spectral Model（光谱模型） | 输入是光谱，作物基质在模型适用范围内 | 基质超出范围，拒绝路由，转实验室送检 |
| Risk Prediction：批次风险排序 | XGBoost | 输入是供应商、品类、季节、抽检历史等字段 | 缺失字段过多，输出“不确定”，转人工 |
| Knowledge Query：标准与历史记录问答 | LLM + RAG | 输入是自然语言问题 | 检索不到出处则不作答，提示查阅原文 |
表里最容易被忽略的是最后一列。路由不只是把请求送出去，还包括判断“这个输入不该送给它”。每个模型都要登记适用范围：品类、季节、设备、产线；路由之前先核对输入是否落在范围之内。番茄的农残模型被拿去筛葡萄，就是范围没登记、没核对的后果，背后的原理见同一种农药换一种水果以后模型为什么失效。至于任务类型和数据类型，尽量用格式校验来判断，是图像、光谱还是表格，别让模型去猜。
置信度不足时：回退链
模型给出的结果并不总要被接受。一条常见的回退链是这样的：
- 先看输出的概率或置信度是否落在放行区间。落进“不确定区”的结果不直接使用，做法可以参考农残 AI 为什么要输出概率。
- 退到更保守的备选：上一版已经验证过的稳定模型，或一条简单的阈值规则。
- 仍然没有把握时，转人工复核，或者按法定方法送实验室检测。
- 无论走到哪一步，都记录下来，包括是谁在什么时候推翻了模型。
大语言模型这一支的回退最简单：检索不到出处就不作答。
版本管理与效果监控
每一次推理至少要记下四样东西：模型版本、输入对应的批次 ID、输出与置信度、是否被人工推翻。有了这些记录，监控才有依据：输入分布有没有漂移（换季、换供应商、换灯管之后最容易发生），人工推翻率是不是在上升，误剔率与漏检率有没有偏离验收线。新版本上线前先以“影子模式”并行运行，只记录、不执行，与旧版对比一段时间再切换，并保留一键回滚的能力。这与实验室到工厂以后准确率为什么变化里讲的漂移监控和再校准是同一套做法，只是对象从一个模型变成了一批模型。
与“继续堆模型”对比
继续堆模型，每多一个模型，就多一份维护负担和一种新的出错方式；模型路由把适用范围、回退规则和监控集中到同一处，新增模型时只需补一条登记。前者的信息散落在各个团队的文档与记忆里，后者让“谁负责、跑哪一版、出了错怎么退”都有据可查。
路由也有边界。它不会提高任何单个模型的精度：某个专用模型如果没有用独立批次、独立季节、独立产线验证过，路由只会把它的错误分发得更整齐。路由器也只能处理已经对齐的数据：输入若没有按数据对齐的要求挂到正确的批次上，请求会被送到正确的模型，却带着错误的上下文。最后，路由规则本身会随新品类、新产线变化，谁来审这些规则、多久审一次，是路由上线之前就该回答的问题。