一、项目背景

这个项目里我们当时面对的第一个麻烦，不是模型效果不够好，而是"好"这件事根本没法对话。多个业务线各自接入了不同的模型实例——有走我们采用的 X 技术平台（基于 vLLM/TGI 的模型服务化层）部署的开源权重，有在私有云上做 LoRA/QLoRA 微调后的业务专用模型，还有推理一体机上跑的闭源模型。每个团队都在说"我们这条线的模型效果最好"，但谁也说不清好在哪、差在哪。

最直接的问题发生在一次版本回归上。客服业务线把底座里的对话模型从 A 版本切到 B 版本，上线当天没收到明显投诉，结果三天后运营发现核单准确率悄悄掉了接近一个百分点——因为 B 版本在长上下文下的拒答率变高了，而客服场景恰恰需要模型在长对话里稳定抽取订单要素。这件事之前没有任何一道关卡能拦住它，因为当时根本没有统一的评测基准，版本对比全靠人工抽测几十条样本，覆盖不到这类长尾退化。我们意识到，再这么各自为战，模型越多，风险敞口越大。

二、落地场景

于是我们在这个项目里搭了一套覆盖"构建—执行—观测"的评测体系，核心落在三个场景。

第一是业务基准集构建。我们按业务线梳理出高频真实请求脱敏后的典型样本，覆盖智能客服、商品生图文案、辅助采购等场景，沉淀成结构化评测集。每条样本带业务标签、难度分级、预期能力维度，并按版本快照冻结，避免评测集被"偷偷改答案"。

第二是自动化评测流水线。我们把评测集接入 CI 风格的执行链路：每次模型版本变更、Prompt 模板调整、RAG 切片-向量化-重排参数改动，都会触发一轮自动评测。流水线调用我们采用的 X 技术平台的统一推理接口，批量产出响应，再交给多维度自动评分模块打分。

第三是能力雷达与回归看板。评测结果落库后，用能力雷达图把每个模型在"准确性、稳定性、拒答率、长上下文、抗干扰"等维度上的得分画出来，并通过 Prometheus+Grafana 把回归趋势做成看板，基线漂移超出阈值就自动告警。

三、关键技术挑战与解决思路

挑战一：评测集构建与防泄漏。 我们最开始直接拿线上日志做评测集，结果很快发现分数虚高——因为模型训练或微调时很可能"见过"这些线上样本，属于典型的评测泄漏。解决思路是双管齐下：一是对评测样本做严格的去标识与改写，剔除可被记忆的具体实体和字段；二是建立"版本隔离"规则，评测集只使用晚于任一训练数据截止时间之后采集的真实请求脱敏样本，并定期轮换。同时我们在评测脚本里加了一道相似度筛查，用向量库（Milvus）对候选样本和训练语料做近邻比对，疑似泄漏的直接剔除。

挑战二：多维度自动评分。 人工评分无法支撑每天几十轮回归，但纯规则匹配又太脆。我们采用"LLM-as-Judge + 规则校验"的混合评分：对事实性、格式类题目用确定性规则核对（如核单字段是否齐全、JSON 是否可解析）；对开放性回答用我们采用的 X 技术平台上一个轻量判别模型按维度打分，judge 本身也纳入评测防止其漂移。为降低成本，评测批量走连续批处理与 KV 缓存，把评分吞吐拉了上来。

挑战三：回归基线与告警。 难点在于"什么叫退化"。不同维度对业务的重要性不同，不能简单看平均分。我们为每个业务线定义权重化的综合基线，并支持维度级基线：比如客服线把"拒答率"权重拉高。当某维度相对基线的回退超过预设百分比，或 bad case 新增数超过阈值，流水线就标记该版本"不可上线"并推送到看板与即时消息。

挑战四：评测与生产的偏差控制。 评测环境用统一推理接口，但生产开了张量并行与弹性扩缩容，偶发批处理差异。我们让评测链路尽可能复用生产同款推理配置，并在看板里标注"评测配置快照"，减少环境漂移带来的误报。

四、效果数据

上线这套体系约半年后，我们在脱敏示意口径下统计了几项核心指标，下面是上线前（以人工抽测阶段为基线）与上线后的对比：

从我们的看板数据看，模型版本回归导致的线上质量事故数量从一个季度多次，降到一个季度个位数。评测流水线日均自动执行约 40 轮，把人力从反复抽测里解放出来。

案例片段（已脱敏）： 评测流水线触发配置（YAML，节选）：yaml pipeline:  trigger:    - model_version_change    - prompt_template_change    - rag_reindex  dataset:    frozen_snapshot: "v2025q2_core"    leak_scan:      vector_store: milvus      similarity_threshold: 0.82  scoring:    rule_check: ["json_parse", "field_completeness"]    llm_judge:      model: "x-platform-discriminator"      dimensions: [accuracy, stability, refusal_rate, long_ctx]  baseline:    weighted: true    alert_on_dim_drop_pct: 5

评分片段（Python，节选）：python def score(sample, resp):    rule = rule_check(resp, sample.expect_fields)   # 确定性字段校验    judge = llm_judge(resp, dims=sample.dimensions)  # 判别模型多维度打分    if rule.failed or judge.refusal_rate > sample.ceil:        return BadCase(sample.id, reason=rule.msg or "refusal_high")    return Pass(sample.id, score=judge.weighted())

五、可复用经验总结

回头看，这条线最大的教训有两个，也正好对应选题 lesson：先有基准再谈优化，评测集防泄漏是关键。

第一，基准集是一切优化的前提。没有基准，模型迭代就是蒙眼开车，所谓"效果更好"只是各业务线的主观感受。我们建议任何团队在动模型、动 Prompt、动 RAG 参数之前，先把核心场景的脱敏基准集冻结下来，哪怕一开始只有几百条，也比零基准强。

第二，防泄漏要当成工程纪律。评测集一旦被训练数据污染，所有分数都会失真，甚至给退化版本开出绿灯。把"版本隔离 + 相似度筛查 + 定期轮换"做成评测流水线的强制步骤，而不是事后抽查。

第三，评分要混合、要可解释。纯规则太脆，纯 LLM 太玄，混合方案兼顾确定性与泛化，且 judge 自身也要被评测。维度级基线比单一平均分更能反映业务真实诉求，告警才有意义。

第四，把评测嵌进变更流程而不是做成月度汇报。只有每次变更自动触发、自动拦截，评测体系才真正产生约束力。我们后来把它和底座的弹性扩缩容、网关的限流信号联动，形成了"算力—流量—质量"的小闭环，这也是我们采用的 X 技术平台设计上比较顺手的地方。