如何构建可落地的 LLM 测试评估体系

开始之前，有必要先澄清一个认知误区。很多人一上来就急着搭建评估体系，但连最基本的“评估对象”都没想透。

你的系统输出，是确定性的还是概率性的？

这不是一句废话。大多数团队踩坑的根源，就在于把一个概率系统当确定性系统来评估。传统软件测试有个核心假设：相同输入，相同输出。这个假设在 LLM 这儿，彻底不灵了。同一条 prompt，温度参数设成 0.7，跑十次，你会得到十个不同的回答，质量分布可能从 0.6 到 0.95 都有。所以，你评估的不是“这个输出对不对”，而是“这个系统在什么样的概率分布下工作”。

这个认知是整套体系的地基。没有这个认知，后面的一切都是在沙子上建房子。

---

二、体系的四个层次

如上面架构图所示，一套完整的 LLM 评估体系由四层构成，缺一不可。下面逐层展开，把每一层的核心设计决策讲清楚。

---

第一层：用例设计

大多数团队的用例设计，都只覆盖了“正常路径”——给模型一个标准输入，期望它给一个标准输出。这远远不够。

LLM 评估用例需要覆盖三类场景：

：系统应该能做什么？把核心能力拆成最小可测单元。比如一个 RAG 问答系统，功能用例应覆盖：单文档检索、多文档综合、时序推理、数字计算类问题等。每个能力点独立建用例，不要把多个能力揉进一条用例里——出问题了你不知道是哪里坏了。

：系统在什么情况下会翻车？这部分往往被忽视，但对于 LLM 来说更重要。包括：格式异常的输入（全大写、无标点、混合语言）、语义模糊的提问、超长 context、包含矛盾信息的文档、越权指令注入等。鲁棒性用例至少要占总用例数量的 30%。

：历史上出过的 bug，必须转化为永久性测试用例。每次新版本上线，先跑回归。这是防止“修了东墙、塌了西墙”的最低成本手段。

用例的质量比数量重要。100 条高质量、边界清晰的用例，远胜过 500 条互相重叠的水题。

---

第二层：执行控制

用例设计好了，怎么跑？这一层的核心原则是：控制变量，留存证据。

：这是最容易被省略、代价又最高的设计决策。

场景类型	建议运行次数
普通功能验证	5 次
核心对话链路	10 次
安全 / 合规相关	20 次
上线前全量回归	每条用例 ≥ 5 次

为什么这么多？因为你需要的不是一个点，而是一条分布。单次结果告诉你的是“今天这一次的运气”，多次运行告诉你的是“这个系统的真实能力区间”。

：开发阶段，建议固定 temperature=0（或你生产环境的实际值）来做对比基准测试，排除随机性干扰。评估生产行为时，使用与生产环境完全相同的参数配置，不要在测试里悄悄调低温度。这是最常见的“测试环境比生产环境好”的原因之一。如果 API 支持固定 seed，每次回归测试时对同一批用例使用相同 seed，可以精确追踪版本变化带来的质量差异。

：每次测试运行，必须记录：模型版本、API 参数、系统 prompt 版本、测试时间戳。这四个字段缺一个，事后复盘都可能变成悬案。“上周还是好的，这周怎么就差了”——如果没有这些记录，你永远不知道变量在哪里。

---

第三层：评估打分

这一层是整套体系最复杂、分歧最大的部分。核心问题是：谁来判断输出质量？

评估方法从低成本到高成本，大致有三类：

：适用于输出格式明确、有标准答案的场景。比如：输出必须是 JSON、必须包含某个关键词、必须在某个字符数以内。规则评分成本低、可复现，应该尽量优先用。实现方式：写断言函数，对模型输出做结构化校验。json.loads()不报错算一分，包含目标字段再加一分。累积分数归一化到 0-1 区间。

：适用于开放式输出，比如摘要质量、回答完整性、语气是否合适等。用一个评估模型（通常比被测模型更强或同级）对输出打分。这里有几个设计要点：评估 prompt 要固定。每次版本迭代，评估 prompt 不能变，否则你不知道分数变化是模型变了还是评估标准变了。打分要多维度。不要只打一个“总分”。拆分成：准确性、完整性、格式合规、安全性等维度，分别打分。这样出问题时才能定位是哪个维度退化了。LLM-as-Judge 的局限要清楚。它本身是个概率系统，评分也会抖动。因此，对同一条输出，LLM Judge 也要跑多次，取均值。不要把单次 Judge 结果当作最终结论。

：成本最高，但不可替代。所有进入黄区（需要关注）的用例，都需要人工翻看失败样本。所有红区（不可上线）的用例，建议全量人工审核，理解失败模式，再决定是修 prompt、换模型还是降低任务复杂度。

：不管用哪种评估方式，每条用例的测试报告必须包含：

{"case_id": "...","runs": 10,"mean_score": 0.82,"std_dev": 0.09,"min_score": 0.61,"max_score": 0.94,"pass_rate": 0.8,"failure_types": ["格式错误×1", "事实偏差×1"]}

只写 result: pass 的报告，等于没写报告。

---

第四层：分层决策

评估结果出来了，如何做决策？这一层把所有信息汇聚成行动。

。条件：mean_score ≥ 0.85 且 std_dev ≤ 0.05，连续多版本均值无显著下滑。动作：自动通过，进入下一个流程节点。不需要人工介入。这一档要设计得足够严格——放宽阈值换来的“通过率提升”是虚假的安全感。

。条件：mean_score 在 0.70–0.84 之间，或 std_dev > 0.10。动作：进入人工复核队列。复核时区分两种失败模式：失败集中在某类输入格式 → 是 prompt 工程问题，修 system prompt 或 few-shot 示例；失败随机分布、无规律 → 可能是模型能力边界，考虑任务拆分或升级模型。

。条件：mean_score < 0.70，或任意一次出现灾难性输出（严重事实错误、有害内容、逻辑完全崩塌）。动作：一票否决，无论均值多好。灾难性失败不能被平均值稀释。打回后进入修复流程，修复完成后重新进入评估体系。红区的失败分析同样要做分治：如果失败原因是模型本身能力不足 → 评估升级模型或缩小任务范围；如果失败原因是测试用例设计有缺陷 → 修用例，不是修系统。

---

三、五个容易踩的坑

体系搭起来之后，运行过程中有几个高频陷阱，提前说清楚。

。测试时 temperature=0，生产时 temperature=0.8。测试时 context 只有 500 tokens，生产时动辄 4000 tokens。这种环境差异会导致测试通过率虚高 20%-40%。解决方式：测试参数必须与生产完全对齐，用生产环境的真实流量做 shadow testing。

。每次迭代只跑新功能的用例，不跑回归。结果新功能上了，老功能悄悄退化了，用户先发现，你后知道。解决方式：每次版本变更，全量回归必跑，时间不够就减少用例数量而不是跳过回归。

。只有一个总分，出问题了不知道是哪里坏了。是准确性下降了，还是格式变差了，还是新功能引入了安全风险？解决方式：至少拆分成 3-4 个维度独立打分，每个维度都有独立趋势图。

。LLM Judge 本身会漂移，会对格式有偏好，会受评估 prompt 措辞影响。把它当成唯一标准，最终结果就是“用模型的偏好来评估模型”，循环自洽。解决方式：LLM Judge 只是辅助，高分用例定期人工抽检 10%，低分用例必须人工确认。

。评估体系建好了，但产品每次改 prompt 时不跑评估，直接上线。几次之后，评估体系变成了摆设。解决方式：把评估跑通作为 CI/CD 流程的强制卡点，不通过评估，merge request 不能合并。

---

四、最小可行版本

如果你的团队现在什么都没有，从零开始，应该先做哪些？按优先级排序：

：建立 20-30 条核心功能用例，覆盖主链路；每条用例跑 5 次，记录均值和最低分；写最简单的报告格式（哪怕是 CSV）。

：补充边界用例，总量拉到 80-100 条；接入 LLM-as-Judge，实现自动打分；建立三档决策规则，黄区用例开始人工复核。

：历史失败用例转化为回归集；评估跑通作为 CI 卡点；建立版本间质量趋势的对比报告。

不要等体系“完整了”再开始。20 条用例 × 多次运行 × 分布统计，已经比单次红绿灯强十倍。

---

五、最后

LLM 评估体系的核心不是技术难度，是认知转变。

从“这次对了”到“它在什么概率区间下稳定”。从“给一个答案”到“把不确定性显式地写进报告”。从“测试是上线前的检查关”到“评估是持续运行的质量雷达”。

这个转变需要时间，也需要一些说服工作。但 LLM 系统已经在你的生产环境里跑了。它每天在产生不确定的输出。你有没有一套体系，能持续感知这种不确定性、管理它、并在它恶化之前发现它——这才是最值得投入的工程能力。