从写用例到守护评测流水线：测试运维转型实录

过去两年，我所在团队里变化最剧烈的不是算法岗，而是测试与运维。曾经围绕需求文档写用例、围绕发布窗口盯监控的同事，被突然推到一条全新的流水线前：上游是每天迭代多次的大模型与 Prompt，下游是要求「答得准、不胡说、风格稳」的业务方。中间那道「质量闸门」谁来守？答案落到了测试和运维身上。

这篇文章记录这段转型：旧能力哪些直接作废、哪些意外升值，以及如何用三个月左右，把自己从「写用例的人」改造成「维护 AI 评测流水线的人」。

一、问题背景：当被测对象变成一个概率系统

传统测试的底层假设是确定性的：给定输入，软件应返回确定输出，断言可以写成 assert response.code == 200。传统运维的底层假设也是确定性的：指标超阈值就告警，回滚到上一个版本即可恢复。

但大模型把这两个假设都打碎了。同一个问题问两次，答案可能不同；你无法用一条等值断言判断一段开放文本「对不对」；模型版本升级后，旧的黄金集可能整体失效；而所谓「回滚」，在 Prompt、检索库、模型权重三者耦合时，往往根本回不到当初那个现场。

这意味着质量保障从「判断对错」变成「度量分布」。测试同学擅长的边界值、等价类依然有用，但要作用在数据集设计上；运维同学擅长的稳定性、可观测、灰度同样有用，但监控对象从 CPU、错误率扩展到了答案质量分、幻觉率、单轮成本与 Token 消耗。

二、方案对比：三种转型路径的取舍

转型不是单点学个工具，常见路径有三条，适合不同底色的人。

路径一：评测集工程师（偏测试）。 核心是构建与维护数据集、标注规范、黄金答案与回归集。优点是最贴近原有用例设计能力，上手快；风险是如果只懂标注、不懂评分原理，容易沦为「高级标注员」，价值随数据稳定而见顶。

路径二：AI 平台 / 评测流水线工程师（偏运维）。 核心是把评测、采样、打分、看板、门禁做成稳定可复用的平台能力，关注调度、并发、成本、缓存与可观测。优点是技术壁垒高、复用性强；风险是离业务太远时，搭出的平台分数漂亮却拦不住真实事故。

路径三：评测算法应用工程师（偏跨域）。 需要理解 RAG、Agent、各类评分器（规则、模型当裁判、人工抽检）的偏差，能设计指标并做 Badcase 归因。门槛最高，但也最难被替代。

我的建议是：以路径二立身、用路径一建立业务信任、逐步向路径三延伸。先用「把流水线跑稳」证明不可替代，再用「懂数据、懂归因」扩大话语权。

三、实操步骤：搭一条最小可用的评测流水线

转型最忌只看概念不动手。下面用一个可直接运行的最小示例，说明评测流水线的骨架。它做三件事：准备数据、调用模型、用「规则 + 模型裁判」混合打分并汇总。

# eval_pipeline.py  最小 AI 评测流水线骨架（可直接运行）
import json

# 1) 评测数据集：每条含输入、期望要点、场景标签
DATASET = [
    {

<!-- 内容间隙推广位：正文之后内联渲染，不遮挡阅读；变现开关关闭时零渲染零占位 -->
<MonetizeSlot position="inline" domain="essays" />

<!-- 免责声明：文字与 data/site.config.yaml 的 disclaimer 保持完全一致，不得删改 -->
::: warning 免责声明
本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。
:::