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

一、先想清楚：你在评估的是什么

构建 LLM 评估体系之前，有一个问题必须先回答清楚：你的系统输出，是确定性的还是概率性的？

这不是废话。大多数团队踩坑的根源，就在于把一个概率系统当确定性系统来评估。传统软件测试的核心假设是“相同输入，相同输出”。这个假设在 LLM 上完全不成立。同一条 prompt，温度参数 0.7，跑十次，你会得到十个不同的回答，质量分布可能从 0.6 到 0.95 都有。

所以，你评估的不是“这个输出对不对”，而是“这个系统在什么样的概率分布下工作”。

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

二、体系的四个层次

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

第一层：用例设计

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

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

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

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

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

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

第二层：执行控制

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

关于运行次数

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

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

关于温度参数与 seed

开发阶段，建议固定 temperature=0（或你生产环境的实际值）来做对比基准测试，排除随机性干扰。评估生产行为时，使用与生产环境完全相同的参数配置，不要在测试里悄悄调低温度。这是最常见的“测试环境比生产环境好”的原因之一。

如果 API 支持固定 seed，每次回归测试时对同一批用例使用相同 seed，可以精确追踪版本变化带来的质量差异。

关于版本锁定与日志

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

第三层：评估打分

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

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

规则评分（Deterministic Scoring）

适用于输出格式明确、有标准答案的场景。比如：输出必须是 JSON、必须包含某个关键词、必须在某个字符数以内。规则评分成本低、可复现，应该尽量优先用。

实现方式：写断言函数，对模型输出做结构化校验。json.loads()不报错算一分，包含目标字段再加一分。累积分数归一化到 0-1 区间。

模型打分（LLM-as-Judge）

适用于开放式输出，比如摘要质量、回答完整性、语气是否合适等。用一个评估模型（通常比被测模型更强或同级）对输出打分。

这里有几个设计要点：

• 评估 prompt 要固定。每次版本迭代，评估 prompt 不能变，否则你不知道分数变化是模型变了还是评估标准变了。
• 打分要多维度。不要只打一个“总分”。拆分成：准确性、完整性、格式合规、安全性等维度，分别打分。这样出问题时才能定位是哪个维度退化了。
• LLM-as-Judge 的局限要清楚。它本身是个概率系统，评分也会抖动。因此，对同一条输出，LLM Judge 也要跑多次，取均值。不要把单次 Judge 结果当作最终结论。

人工审核（Human Review）

成本最高，但不可替代。所有进入黄区（需要关注）的用例，都需要人工翻看失败样本。所有红区（不可上线）的用例，建议全量人工审核，理解失败模式，再决定是修 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，或任意一次出现灾难性输出（严重事实错误、有害内容、逻辑完全崩塌）。

动作：一票否决，无论均值多好。灾难性失败不能被平均值稀释。打回后进入修复流程，修复完成后重新进入评估体系。

红区的失败分析同样要做分治：

• 如果失败原因是模型本身能力不足 → 评估升级模型或缩小任务范围
• 如果失败原因是测试用例设计有缺陷 → 修用例，不是修系统

三、五个容易踩的坑

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

坑1：用测试环境的好结果代表生产环境

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

坑2：只测新功能，不测老功能

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

坑3：评估维度不够细，定位不了问题

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

坑4：把 LLM Judge 当作客观标准

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

坑5：评估体系和产品迭代脱钩

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

四、最小可行版本

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

第1步（一周内可完成）

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

第2步（一个月内）

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

第3步（稳定运行后）

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

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

五、最后

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

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

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