从 JD 到施工图：公司级大模型路由与评测系统的完整落地方案

一份好 JD 是一份被压缩的架构文档。米哈游这份「大模型路由与评测工程师」JD 的六条工作内容，按顺序读就是一条数据流：建路由（条 1）→ 让路由可解释可回滚（条 2）→ 建评测（条 3）→ 用评测对比路由和基线（条 4）→ 评测出问题时归因（条 5）→ 把线上信号回灌给路由（条 6）。这篇文章把这六条解压成可施工的方案：十个模块、六层架构、三张时序图、每个模块的开源选型与自研分界。先把全文唯一的主线摆在最前面：这套系统的本体不是路由器，而是「请求 → 路由 → Trace → 评测 → 策略更新 → 回到路由」这条闭环；模块划分就是给闭环的每一段配一个组件，施工顺序必须沿数据依赖方向走——先有评测信号，才有路由标签。

在决策地图系列·评测路由篇里我已经把这个领域的六个决策点（信号源、学习目标、路由时机、成本旋钮、验收、闭环）和「路由器是评测器的蒸馏」定律讲完了——那篇回答选什么。这篇是它的施工图姊妹篇，回答怎么搭：模块怎么切、接口长什么样、哪些直接抄开源、哪些必须自研、按什么顺序上线。它同时也是工种全景图里「路由与评测工程师」这一格的完整展开。

一、先读懂需求：JD 六条 = 六个子系统

把 JD 的工作内容逐条翻译成系统语言，模块编号（M1–M10）在后文逐个展开：

JD 工作内容	系统语言翻译	对应模块
1. 规则路由、Embedding 语义路由、模型驱动路由	三级路由决策引擎，按成本递增、覆盖率递减排布	M3（执行面在 M1）
2. 能力标签、任务分类、策略版本、灰度实验，可解释可回滚	模型元数据管理 + 策略配置中心 + 实验平台	M2、M4
3. 评测数据集、评分器、回归测试，覆盖代码/工具/长程/业务	离线评测子系统三件套	M6、M7、M8
4. 对比固定强模型、固定低成本模型、智能路由	三臂基线实验 + 统一指标口径	M9
5. 区分模型能力变化/数据问题/评分问题/基础设施问题	异常归因流程（一棵决策树）	M10
6. 离线评测 + 线上 Trace + 用户反馈 + 生产指标 → 迭代	数据闭环（整套系统存在的理由）	M5 + M10

注意 JD 条目顺序和施工顺序不同：JD 按「路由→评测」写（因为路由是业务可见的交付物），但施工必须按「评测→路由」建（因为路由器的训练标签只能来自评测）。这是全文反复出现的一条约束，路线图一节会展开。

二、总体架构：六层十模块

2.1 分层架构图

flowchart TB
    subgraph L6["L6 策略与实验治理层"]
        M4["M4 路由策略中心与灰度实验"]
        M9["M9 基线对比与实验分析"]
        M10["M10 异常归因与闭环迭代"]
    end
    subgraph L5["L5 评测层（离线）"]
        M6["M6 评测数据集管理"]
        M7["M7 评分器体系"]
        M8["M8 评测执行引擎与回归门禁"]
    end
    subgraph L4["L4 观测数据层"]
        M5["M5 Trace 与观测"]
    end
    subgraph L2["L2 路由决策层"]
        M3["M3 路由决策引擎（规则→语义→模型驱动）"]
        M2["M2 模型注册表与能力标签"]
    end
    subgraph L1["L1 接入层（在线）"]
        M1["M1 统一 LLM 网关"]
    end
    subgraph L3["L3 模型供给层"]
        MA["自部署模型（vLLM 等）"]
        MB["外部 API（多厂商）"]
    end

    APP["业务方 / Agent 应用"] --> M1
    M1 --> M3
    M3 --> M2
    M3 --> M4
    M1 --> MA
    M1 --> MB
    M1 --> M5
    M5 --> M6
    M6 --> M8
    M7 --> M8
    M8 --> M9
    M9 --> M10
    M10 --> M4
    M10 --> M2
    M4 --> M3

读图要点：左下角顺时针转一圈就是闭环——业务请求进网关（M1），路由引擎（M3）查能力标签（M2）和当前策略（M4）做决定，请求发往模型层（L3），全过程落 Trace（M5）；Trace 被挖掘成评测样本进数据集（M6），评测引擎（M8）用评分器（M7）跑出结果，实验分析（M9）和异常归因（M10）消化结果，最终更新能力标签（M2）和路由策略（M4）——回到起点。任何一段断了，闭环退化成单行道，路由器就会停在它上线那天的水平。

2.2 十模块总表

模块	职责一句话	在线/离线	开源可覆盖度
M1 统一 LLM 网关	所有模型调用的唯一入口：协议统一、fallback、限流、预算	在线	✅ 几乎全覆盖
M2 模型注册表与能力标签	每个模型一张结构化「能力履历」	在线（读）	⚠️ 载体开源、内容自研
M3 路由决策引擎	三级瀑布：规则 → 语义 → 模型驱动	在线	⚠️ 框架开源、策略自研
M4 策略中心与灰度实验	策略版本化、灰度分流、自动回滚	在线	✅ 复用通用实验平台
M5 Trace 与观测	每次请求的完整链路证据	在线（异步）	✅ 几乎全覆盖
M6 评测数据集管理	公开基准 + 内部业务集 + Trace 挖掘	离线	⚠️ 基准开源、业务集自研
M7 评分器体系	ground truth / 规则 / LLM 裁判 / 人工四类	离线	⚠️ 框架开源、rubric 自研
M8 评测执行引擎与回归门禁	版本钉死、可重复执行、CI 拦截	离线	✅ 几乎全覆盖
M9 基线对比与实验分析	三臂对比 + 统一指标口径	离线	⚠️ 工具开源、口径自研
M10 异常归因与闭环迭代	四类归因决策树 + 数据飞轮	离线	❌ 纯自研流程

三、模块详解

M1 统一 LLM 网关——没有它，后面全是空中楼阁

职责：公司内所有 LLM 调用（不管调的是自部署 vLLM 还是外部 API）走同一个入口，对外暴露 OpenAI 兼容协议。它做四件事：协议归一、多副本负载均衡、失败 fallback、按团队/项目的用量与预算管控。

为什么它是第一块砖：路由的执行面在这里（路由引擎只输出决定，网关执行）；Trace 的采集点在这里（唯一入口=唯一埋点）；成本账本在这里（预算与计费按 key/团队归集）。没有统一网关，路由和评测系统就要在 N 个业务方各自的调用代码里做 N 次埋点。

开源选型：LiteLLM，直接用，基本不用自研。 按其官方文档，它自带的能力几乎就是按这个岗位需求清单长的：

• 多策略负载均衡：simple-shuffle / least-busy / usage-based / latency-based / cost-based 路由策略；
• 三类 fallback：通用失败 fallback、内容策略 fallback、上下文超长 fallback，配合部署级 cooldown（不健康副本临时摘除、冷却后自动恢复）；
• 预算与限流：按 key / 团队 / 组织 / 模型设硬预算，日/月重置，超限即拒；
• 多实例部署用 Redis 共享冷却与限流状态。

一个值得注意的动向：LiteLLM 在 2026 年推出了 Auto Routing（用启发式/关键词/LLM 分类器把请求分档再路由）。我的建议是网关内建路由只用它的负载均衡与 fallback，语义级路由决定放到 M3 独立做——因为 JD 条 2 要求路由「可解释、可回滚」，独立的路由引擎 + 策略中心才能做版本化，嵌在网关配置里的路由规则很难灰度。这是观点，不是事实。

M2 模型注册表与能力标签——模型的结构化履历

职责：回答「公司现在有哪些模型可用、各自什么水平、什么价、什么限制」。每个模型一条记录，示意 schema：

model_id: qwen3-32b-sft-0801
provider: self-hosted-vllm        # 或 external-api
endpoint_group: gpu-pool-a
capability_tags:                  # 能力标签：全部来自 M8 的评测结果，禁止手填
  code: 0.71                      # 内部代码评测集 pass rate
  tool_use: 0.64                  # 内部工具调用集
  long_horizon: 0.38              # 长程任务集
  zh_writing: 0.82
capability_eval_run: run-2026-08-01-nightly   # 标签的出处，可追溯
price_per_mtok_in: 0.4            # 元/百万 token
price_per_mtok_out: 1.2
context_window: 131072
latency_p95_ms: 2100              # 来自 M5 生产观测，滚动更新
status: active                    # active / canary / deprecated

关键设计只有一条：能力标签必须由评测流水线写入，人不许手填。 标签带 capability_eval_run 字段指向产生它的评测运行，这样 JD 条 2 的「可解释」就落了地——任何一次路由决定都能沿着「决定 → 策略版本 → 能力标签 → 评测运行」追溯到底。

开源选型：载体不值得引重型系统，一张数据库表 + 网关的 model_list 配置即可；内容（标签体系怎么定、用哪些评测集算）是自研核心资产。

M3 路由决策引擎——三级瀑布，按成本递增排布

职责：输入一条请求（+可选的业务方 hint），输出一个 RoutingDecision。JD 条 1 的三种路由不是三选一，而是一条瀑布，按「决策成本递增、覆盖率递减」排：

1. L1 规则路由（微秒级）：白名单命中即返回。典型规则：业务方指定模型、合规要求（某类数据只许走自部署模型）、超长上下文直接给大窗口模型、特定 task_type 的硬绑定。规则路由永远保留最高优先级——它同时是紧急逃生通道（出事时一条规则把流量钉死到某个模型）。
2. L2 语义路由（毫秒级）：规则不命中时，用 embedding 把请求分到任务类目（代码/工具调用/闲聊/长程规划/业务场景 X…），再按类目查 M2 的能力标签选「够用的最便宜模型」。开源直接用 semantic-router：为每个类目写一组示例话术（utterances），预先算好 embedding，请求进来做向量近邻分类——决策是一次向量检索而不是一次生成，所以快；支持 dense+sparse（BM25）混合编码提精度，向量库可接 Qdrant 等。类目体系本身是自研核心：类目就是公司的任务分布画像，没有任何开源项目替你定义。
3. L3 模型驱动路由（几十毫秒级）：语义路由只回答「这是什么任务」，不回答「这条具体请求有多难」。第三级用一个轻量预测器直接预测各模型在这条请求上的表现，典型形态是 RouteLLM 式的胜率预测器 $P(\text{strong wins}\mid q)$ 配成本阈值（论文报告质量不降成本降 2 倍以上；开源实现 lm-sys/RouteLLM，我在源码深读篇逐行拆过），或 Hybrid LLM 式的难度分类器（BERT 量级，论文报告大模型调用量减 40%）。训练标签来自 M6–M8 的评测产出——这就是「先评测后路由」的数据依赖。

每次决定必须落一条结构化记录（进 M5 的 Trace）：

{
  "request_id": "r-8f3a",
  "policy_version": "routing-policy-v13",
  "decision_level": "L2-semantic",
  "task_class": "code_gen",
  "candidates": [
    {"model": "qwen3-32b", "score": 0.71, "est_cost": 0.003},
    {"model": "strong-api-x", "score": 0.88, "est_cost": 0.041}
  ],
  "chosen": "qwen3-32b",
  "reason": "cheapest model with score >= class threshold 0.65",
  "fallback_chain": ["strong-api-x"]
}

有了这条记录，「可解释」是查询问题而不是考古问题；「错路由率」（M9）也才有了可测量的对象。

M4 路由策略中心与灰度实验——把策略当代码发布

职责：路由策略（规则表、类目阈值、预测器版本、成本旋钮）是一个版本化的配置对象，发布流程照抄软件工程：离线回归 → shadow → 小流量灰度 → 全量，每一步可自动回滚。

关键设计：

• 策略即配置：一个策略版本 = 规则集 + 类目阈值表 + 预测器模型 hash + 全局成本参数，整体打版本号。M3 只认版本号加载，不接受散装修改。
• Shadow routing（影子路由）：新策略上线前，对线上真实流量并行计算「如果用新策略会选谁」，只记录不生效。零风险拿到新旧策略的决策差异分布——差异大的那部分请求，正是要重点离线评测的样本。
• 灰度与自动回滚：按流量百分比放量，盯 guardrail 指标（成功率、成本、延迟、fallback 率），越界自动切回上一版本。

开源选型：灰度分流与实验分析不要自己写，复用通用实验平台——GrowthBook（MIT 开源核心，warehouse-native，实验分析内建）或 Unleash（特性开关控制面强，但实验分析要自己搭）。选型判据：要内建实验分析选 GrowthBook，只要开关和放量控制选 Unleash。策略对象的 schema 与 shadow 回放逻辑自研（很薄，本质是配置管理）。

M5 Trace 与观测——闭环的原材料仓库

职责：每次请求留下完整证据链：输入输出、路由决定（M3 那条 JSON）、实际走到的模型与 fallback 路径、token 用量、成本、TTFT/端到端延迟、用户反馈信号（点踩、重新生成、人工接管）。

开源选型：Langfuse，直接用。 开源可自部署（Docker，ClickHouse 做底座），trace/评分/数据集/prompt 管理一体，SDK 异步批量上报不挡在线请求，和 LiteLLM 有现成集成——网关侧配一个 callback，全公司流量自动落库。它的 datasets 功能正好承接 M6 的「从 trace 挑样本进评测集」动作，scores 功能承接线上 LLM-as-judge 抽样打分。

埋点标准：尽量贴 OpenTelemetry GenAI 语义约定（LLM span、agent span、事件与指标的标准属性名），避免供应商锁定。一个诚实的提醒：截至 2026 年中，GenAI semconv 仍处于 Development/experimental 状态，属性名可能在版本间变化——贴标准的同时在自己这层留一次字段映射，别把标准属性名直接刻进下游表结构。

两个自研点：（1）路由决策记录是自定义字段，要设计进 trace schema；（2）采样策略——全量存决策元数据（便宜），按比例存完整输入输出（贵），对触发 fallback / 用户点踩 / 高成本的请求强制全量存。

M6 评测数据集管理——公司最值钱的自研资产

职责：管理三层数据集，JD 条 3 的「覆盖代码、工具使用、长程任务及内部业务场景」正好对应「公开基准打底 + 业务集为主」的结构：

层	内容	规模	更新频率	用途
冒烟集	每能力 5–10 条代表题	~50 条	稳定	每次策略变更前快跑（分钟级）
回归金集	内部业务场景为主，人工审核过答案标准	200–1000 条	每周吸新	nightly 回归、能力标签计算
全量集	公开基准 + 大规模业务集	数千条+	月度	新模型准入评测、季度盘点

公开基准直接装载，不自己造（对应 JD 加分项 2）：代码用 SWE-bench（2294 个真实 GitHub issue，ICLR 2024，我的拆解笔记）；工具+多轮对话用 τ-bench（模拟用户对话 + API 工具 + 政策约束，用数据库终态判分，pass^k 度量稳定性——这个指标对 Agent 路由特别有用：路由到便宜模型省的钱，可能被 pass^k 的坍塌吃回去）；通用助手用 GAIA（466 题，人类 92% vs 当年 GPT-4 带插件 15%）；终端任务用 Terminal-Bench（2.0 版 89 个 docker 化任务，前沿模型 <65%）。Inspect Evals 已经把其中多数打包成可直接运行的实现。

业务集的采集管道是自研重点：来源=Trace 挖掘（fallback 请求、点踩请求、shadow 差异请求、高成本请求优先入池）+ 业务方提报；每条样本要有 ground truth 或 rubric，版本化管理（数据集也要有版本号，否则「上周 85% 这周 82%」无法归因是模型退了还是题变了——这正是 JD 条 5 要区分的「数据问题」）。

M7 评分器体系——评分器也要被评测

职责：四类评分器分层使用，判据是「答案可验证程度」（呼应测试篇的 Oracle 梯度定律）：

1. 可执行验证（最硬）：代码跑测试、工具调用比对终态数据库、结构化输出 schema 校验。能用这档绝不用下一档。
2. 规则/精确匹配：有标准答案的分类、抽取、数值题。
3. LLM-as-judge：开放生成任务。地基论文 MT-Bench/Chatbot Arena（arXiv 2306.05685）给出 GPT-4 裁判与人类 85% 一致率（超过人与人的 81%），同时钉死三种偏差：位置偏差、冗长偏差、自我增强偏差（详见我的逐节笔记）。工程上的三条纪律：裁判模型版本钉死；成对比较时交换位置跑两次；裁判模型不评自家产出的答案。
4. 人工评审：只用于金集建设和裁判校准，不进日常回归。

自研重点是 meta-eval（评评分器）：维护一个 100–200 条的「裁判校准集」（人工标好期望判分），每次更换裁判模型或修改 rubric，先在校准集上测裁判与人工的一致率，达标才能上岗。没有这一步，JD 条 5 的「评分问题」这一归因分支就永远查无实据。

M8 评测执行引擎与回归门禁——可重复是底线

职责：给定（模型版本 × prompt 版本 × 数据集版本 × 评分器版本）四元组，可重复地跑出结果并存档。四个版本号缺一个，异常归因（M10）就少一个可排除项。

开源选型（对应 JD 加分项 1，四个工具各占一个生态位，不互斥）：

• Inspect AI（英国 AISI）：主评测引擎首选。Task/Solver/Scorer 三段式抽象，内建 Docker 沙箱（跑 SWE-bench/Terminal-Bench 这类要执行代码的评测必需），自带 200+ 预置评测，透明的 transcript 日志查看器。
• Promptfoo：CI 回归门禁首选。声明式 YAML 测试配置、缓存、CI/CD 集成顺手——冒烟集挂进 CI，路由策略/prompt 改动不过评测不许合并。这一格的深层逻辑我在门禁篇和《Eval 是新的 PRD》写过：回归集就是行为规格。
• EvalScope（ModelScope）：两个独特用途——中文基准齐全（C-Eval/CMMLU 内置），以及模型服务压测（TTFT/TPOT 指标）：M2 里的延迟字段、路由到自部署模型前的容量验证，用它测。它还能把 OpenCompass 当后端封装调用。
• OpenCompass（上海 AI Lab）：100+ 学术基准的标准化跑分，新模型准入时拉通用能力基线用。

组合建议（观点）：Inspect AI 做主引擎跑 Agent 与沙箱评测，Promptfoo 做 CI 门禁跑冒烟/回归，EvalScope 做压测与中文基准，OpenCompass 按需做学术基线。不要试图用一个工具覆盖全部——它们的抽象各有偏向，强扭的代价是评测代码比业务代码还难维护。

M9 基线对比与实验分析——JD 条 4 的实验设计

三臂设计：同一份评测集、同一套评分器，跑三个策略臂——A 固定最强模型、B 固定最低成本模型、C 智能路由。A 是质量上界兼成本上界，B 是成本下界兼质量下界，C 的价值 = 离 A 的质量差距 × 离 A 的成本节省。统一指标口径表（每个指标注明分母和测量点，否则跨团队没法对话）：

指标	定义口径	数据来源
成功率	评分器判 pass 的任务数 / 总任务数（按任务类目分层报告）	M8
成本	每千次请求总成本；每成功任务成本（后者才反映真实性价比）	M1 计费
延迟	TTFT 与端到端 P50/P95（路由决策耗时单独列——语义路由和预测器的开销要摊在明处）	M5
Fallback 率	触发 fallback 链的请求占比	M1/M5
错路由率	见下	反事实回放

错路由的测量（设计建议，行业无统一标准）：错路由分两个方向，都用离线反事实回放测——从 trace 抽样，把请求交给「路由器没选的那个模型」重答一次再评分。向上错路由：路由给了贵模型，但便宜模型的回答也能过评分 → 纯浪费；向下错路由：路由给了便宜模型且失败，但强模型能过 → 质量损失。两个率加上三臂对比，就是向管理层汇报路由系统价值的完整语言。

M10 异常归因与闭环迭代——JD 条 5、6 的流程化

归因决策树（JD 条 5 的四类，按排查成本从低到高排）：

flowchart TD
    A["nightly 回归指标异动"] --> B{"基础设施问题?<br/>超时率/错误码/压测指标异常?"}
    B -- 是 --> B1["修基础设施，重跑评测"]
    B -- 否 --> C{"数据问题?<br/>数据集版本变了? 新样本有脏数据?"}
    C -- 是 --> C1["回滚/修数据集版本，重跑"]
    C -- 否 --> D{"评分问题?<br/>裁判在校准集上一致率还达标吗?"}
    D -- 否 --> D1["修评分器，历史结果标记不可比"]
    D -- 是 --> E["确认为模型能力变化<br/>更新 M2 能力标签 → 触发 M4 策略调整"]

树的排查顺序有讲究：前三类是「假异动」，只有排除它们，第四类「真异动」才可信。这棵树能跑起来的前提，是 M8 的四元组版本钉死和 M7 的裁判校准集——归因不是分析技巧，是前置埋点的收获。

闭环迭代（JD 条 6）四条回流通道：① trace 困难样本 → M6 评测集扩充；② 生产成功率/成本 → M9 与离线评测交叉验证（离线在涨线上在跌 = 评测集已经不代表真实分布）；③ 用户反馈 → LLM-judge 抽样标注 → 路由器增量训练数据；④ 新模型上架 → 全量集准入评测 → M2 标签 → M4 策略纳入。

四、三张关键时序图

4.1 在线请求：三级路由 + fallback

sequenceDiagram
    participant App as 业务方
    participant GW as M1 网关
    participant RT as M3 路由引擎
    participant REG as M2 注册表
    participant MB as 模型B(便宜)
    participant MA as 模型A(强)
    participant LF as M5 Trace

    App->>GW: /chat/completions (api-key, task_hint)
    GW->>RT: route(query, hint, policy_v13)
    RT->>RT: L1 规则: 未命中
    RT->>RT: L2 语义: task_class=code_gen
    RT->>REG: 查 code 能力标签+价格
    REG-->>RT: 候选打分表
    RT-->>GW: decision{chosen: 模型B, fallback:[模型A], reason}
    GW->>MB: 转发请求
    MB--xGW: 超时/5xx
    GW->>MA: fallback 链下一跳
    MA-->>GW: 响应
    GW-->>App: 响应(+路由元数据头)
    GW--)LF: 异步落 trace(决策JSON+fallback+成本+延迟)

两个设计细节：路由决策在转发前一次算完（含 fallback 链），失败时网关直接走链、不回头重新问路由引擎——把路由引擎保持为无状态纯函数；响应头带回路由元数据，业务方可自查「这次是谁答的、为什么」。

4.2 新路由策略灰度发布

sequenceDiagram
    participant Eng as 工程师
    participant EV as M8 评测引擎
    participant PC as M4 策略中心
    participant GW as M1/M3 在线侧
    participant EXP as 实验平台

    Eng->>EV: 新策略 v14 离线回归(回归金集+回放集)
    EV-->>Eng: 报告: 质量/成本/错路由 vs v13
    Eng->>PC: 注册 v14, 状态=shadow
    PC->>GW: 下发 shadow 配置
    Note over GW: 真实流量并行计算 v14 决策<br/>只记录不生效
    GW--)PC: 决策差异样本回流
    Eng->>EV: 差异样本定向离线评测
    EV-->>Eng: 差异部分质量确认
    Eng->>EXP: 开 5% 灰度
    EXP->>GW: 分流规则生效
    Note over EXP: guardrail: 成功率/成本/延迟/fallback率
    alt guardrail 越界
        EXP->>PC: 自动回滚至 v13
    else 观察期达标
        Eng->>EXP: 放量 25% → 100%
        PC->>PC: v14 转正, v13 归档可回滚
    end

4.3 评测→策略迭代闭环（每夜例行）

sequenceDiagram
    participant CRON as 调度器
    participant EV as M8 评测引擎
    participant AT as M10 归因
    participant REG as M2 注册表
    participant TR as M5 Trace
    participant DS as M6 数据集

    CRON->>EV: nightly 回归(全模型池 x 回归金集)
    EV-->>AT: 结果+四元组版本号
    alt 指标异动
        AT->>AT: 归因树: 基础设施→数据→评分→模型
        AT->>REG: (确认模型变化) 更新能力标签
        REG--)AT: 触发策略调整建议
    end
    TR->>DS: 周度: 困难样本挖掘入池(人工审核后)
    DS->>EV: 数据集版本+1, 下夜生效
    Note over EV,DS: 累积的(请求,各模型得分)对<br/>= 模型驱动路由器的再训练数据

五、开源 vs 自研分界总表

判据一句话：开源承包「所有公司都长一样的管道」，自研沉淀「只有你公司知道的三样东西」——任务分布（分类体系）、质量定义（评测集+rubric）、成本约束（路由策略）。 这三样是竞争壁垒，也是这个岗位真正的产出物；其余全是管道，管道抄最快的。

模块	直接用开源	必须自研
M1 网关	LiteLLM（负载均衡/fallback/预算全内建）	仅配置
M2 注册表	一张表而已	能力标签体系 + 标签生产流水线
M3 路由引擎	semantic-router（L2）、RouteLLM（L3 起步）	任务类目体系、类目阈值、L3 训练数据
M4 策略/灰度	GrowthBook 或 Unleash	策略 schema、shadow 回放（薄层）
M5 Trace	Langfuse + OTel GenAI 约定	路由决策字段、采样策略
M6 数据集	SWE-bench/τ-bench/GAIA/Terminal-Bench（经 Inspect Evals 装载）	内部业务金集 + Trace 挖掘管道
M7 评分器	judge 模板/评分框架（各评测工具内建）	业务 rubric + 裁判校准集（meta-eval）
M8 执行引擎	Inspect AI + Promptfoo + EvalScope + OpenCompass	四元组版本管理的胶水层
M9 实验分析	GrowthBook 分析 / notebook	指标口径定义、反事实回放脚本
M10 归因/闭环	无	归因决策树 + 四条回流通道（纯流程资产）

加粗项就是简历上应该写的东西——开源装配不构成壁垒，三样自研资产才构成。

六、四阶段落地路线图

施工顺序定律（本文元规律）：建设顺序必须沿数据依赖方向走——网关产 trace，trace 产评测集，评测产标签，标签产路由器。任何跳步，都等于在没有训练数据的情况下训练模型。 JD 把路由写在评测前面，是因为路由是老板看得见的交付物；但你心里的施工图必须是反过来的。

阶段 0（第 1–2 周）：网关 + Trace。 LiteLLM 部署，2–3 个模型上架，一个业务方接入；Langfuse 落 trace。此阶段没有任何「智能」，交付物是统一入口和成本可见性——第一次有人能回答「公司每天在 LLM 上花多少钱、花在什么任务上」。

阶段 1（第 3–6 周）：评测地基。 从 trace 里挑 + 业务方提报，建 200 条以内的回归金集（带人工审核的判分标准）；评分器 v1（能执行验证的用执行验证，开放题用钉版本的 judge）；Promptfoo 冒烟集进 CI；用金集跑第一次三臂对比（固定强/固定便宜/最朴素的规则路由）。交付物是第一张成本-质量报告——这张报告就是向公司要后续投入的依据。

阶段 2（第 2–3 月）：规则 + 语义路由上线。 任务类目体系 v1（5–10 类）、semantic-router 分类、按能力标签选模型；策略中心 + GrowthBook 灰度 + 自动回滚跑通一次完整发布（4.2 的时序图走一遍）。交付物是第一次真实降本，且每个决定可解释、可回滚。

阶段 3（第 3 个月起）：模型驱动路由 + 闭环。 用累积的（请求 × 各模型评分）数据训 L3 预测器（从复现 RouteLLM 开始，别急着自创结构）；nightly 回归 + 归因树例行化；四条回流通道逐条打通。到这一步，4.3 的时序图每天自动转一圈，系统开始自我改进。

诚实的提醒

按本站惯例声明证据边界：文中所有论文数字（RouteLLM 的 2 倍成本节省、Hybrid LLM 的 40%、judge 的 85% 一致率、GAIA 的 92% vs 15%、Terminal-Bench 的 <65% 等）和工具特性描述（LiteLLM/Langfuse/Inspect 等）均来自当场核实过的论文与官方文档（正文带链接），但我没有亲手复现其中任何一个数字；「错路由的反事实回放测量法」和「三工具组合建议」是我的设计观点，未见行业统一标准；十模块的划分本身也是设计方案而非行业规范——模块边界可以按团队规模合并（两人团队可以把 M2/M4 合成一个配置服务）。

成本最低的亲手验证实验（半天可完成，恰好也是工种全景图里这个岗位的最小 rollout 项目）：LiteLLM 挂两个价差 10 倍以上的模型 → 从自己的真实使用记录里挑 30 条任务写成 Promptfoo 测试集 → 跑三臂对比（全走强模型/全走便宜模型/一条「代码类走强模型、其余走便宜模型」的规则路由）→ 手算三臂的成功率与总成本。跑完你会亲手摸到本文的全部关键概念：口径、错路由、成本-质量前沿——以及最重要的：你的 30 条评测集比任何开源组件都更接近这套系统的本体。

参考来源

工程实践 / 官方文档

• LiteLLM — Router 与负载均衡文档 / GitHub
• semantic-router（aurelio-labs）
• RouteLLM 开源实现（lm-sys）
• Langfuse — 开源 LLM 工程平台 / Observability 文档
• OpenTelemetry GenAI Observability（官方博客，2026-05）
• Inspect AI（UK AISI） / Inspect Evals
• Promptfoo
• EvalScope（ModelScope）
• OpenCompass（上海 AI Lab）
• GrowthBook / Unleash
• Terminal-Bench 官网

arXiv 论文

• RouteLLM: Learning to Route LLMs with Preference Data（arXiv 2406.18665，ICLR 2025）
• Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing（arXiv 2404.14618，ICLR 2024）
• FrugalGPT（arXiv 2305.05176）
• AutoMix（arXiv 2310.12963，NeurIPS 2024）
• Prompt-to-Leaderboard（arXiv 2502.14855）
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（arXiv 2306.05685，NeurIPS 2023）
• SWE-bench（arXiv 2310.06770，ICLR 2024）
• τ-bench（arXiv 2406.12045）
• GAIA（arXiv 2311.12983）
• Terminal-Bench（arXiv 2601.11868）

本站相关旧文

• 评测路由篇决策地图：六个决策点与「蒸馏」定律（本篇的「选什么」姊妹篇）
• RouteLLM 源码深读 ・ 用真实 Session 找最便宜够用的模型
• 测试篇：Oracle 梯度定律 ・ 门禁篇：不可逆边界定律
• Eval 是新的 PRD ・ 大模型行业工种全景图