在开始构建大模型评估体系之前，有必要先澄清一个常见的认知误区。很多团队一上来就急于搭建 LLM 评估框架，但连最基本的“评估对象”都没想透彻。

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

这绝非一句空话。绝大多数团队踩坑的根源，就在于把一个概率系统当作确定性系统来评估。传统软件测试有一个核心假设：相同输入，必然得到相同输出。但这个假设在 LLM（大语言模型）这里彻底失效了。同一条 prompt，温度参数设为 0.7，跑十次，你会收获十个截然不同的回答，质量分布可能从 0.6 跨度到 0.95。因此，你评估的重点不是“这个输出对不对”，而是“这个系统在什么样的概率分布下稳定运作”。

这个认知转变是整套 LLM 质量评估体系的地基。没有这个前提，后面的一切努力都如同在沙子上建造楼阁。

二、大模型评估体系的四个核心层次

如上图所示的架构，一套完整的 LLM 评估体系由四个不可或缺的层级构成。下面逐层深入剖析，把每一层的核心设计逻辑讲清楚。

第一层：测试用例设计

大多数团队的测试用例设计，往往只覆盖了“正常路径”——给模型一个标准输入，期望它返回一个标准输出。这远远不足以保障 LLM 系统的可靠性。

大模型评估用例需要覆盖以下三类场景：

功能用例（Happy Path）：系统应该能完成哪些核心任务？将关键能力拆解为最小可测单元。例如，对于一个 RAG 问答系统，功能用例应覆盖：单文档检索、多文档综合、时序推理、数字计算类问题等。每个能力点独立建用例，切勿将多个能力揉进同一条用例——否则出问题后你难以精准定位故障点。

鲁棒性用例（Edge Case）：系统在哪些边缘情况下可能翻车？这部分常被忽视，但对 LLM 评估而言至关重要。包括：格式异常的输入（全大写、无标点、混合语言）、语义模糊的提问、超长上下文、包含矛盾信息的文档、越权指令注入等。鲁棒性用例至少应占总用例数量的 30%。

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

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

第二层：执行控制与参数管理

用例设计好之后，如何规范执行？这一层的核心原则是：控制变量，留存完整证据链。

关于运行次数：这是最容易被省略、但代价最高的设计决策。

为什么需要这么多轮次？因为你需要的不是一个孤立的点，而是一条完整的分布曲线。单次结果告诉你的只是“今天这一次的运气”，而多次运行揭示的是“这个系统的真实能力区间与稳定性”。

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

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

第三层：评估打分与质量度量

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

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

规则评分（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 系统已经在你的生产环境里运行了，它每天都在产生不确定的输出。你是否拥有一套体系，能够持续感知这种不确定性、有效管理它、并在它恶化之前及时预警——这才是最值得投入的工程能力。