经过 10.3 至 10.5 节的 SFT、RLHF 或 DPO 训练后，模型权重已经更新。但“训完”不等于“训好”——一次糟糕的微调可能让基座模型的通用能力断崖式下跌（灾难性遗忘），也可能让对齐后的模型过度谄媚、不敢拒绝有害请求，或是对垂直领域外的输入表现失常。评估是微调闭环中不可替代的最后一环，也是决定模型能否上线生产的守门员。
本节将评估拆为两条线：客观基准测试负责快速、可量化的能力扫描；人工评估体系负责捕捉机器无法量化的体验细节。两者缺一不可。
一、客观基准测试：自动化标尺
客观基准（Benchmark）的核心价值是可复现、低成本、横向可比。在微调迭代的早期，它是你每天跑一遍的“体检报告”。
1. 通用能力基线：防止“练偏了”
微调最容易出现的副作用是灾难性遗忘。因此，即使你的目标是做一个医疗客服模型，也必须保留通用能力测试，确保模型没“越练越傻”。
| 基准测试 | 考察维度 | 适用场景 | 注意事项 |
|---------|---------|---------|---------|
| MMLU | 多学科知识（STEM、人文、社科） | 衡量知识保持度 | 选择题形式，对生成式模型评估有局限 |
| GSM8K | 数学应用题、多步推理 | 检验推理能力是否退化 | 需配合 CoT 提示词，关注最终答案准确率 |
| HumanEval | Python 代码生成与功能正确性 | 代码模型必测 | 需要执行环境，Pass@k 指标更稳定 |
| CEval / CMMLU | 中文知识综合 | 中文模型或中文微调后必测 | 覆盖初高中到职业资格考试 |
| BBH | 复杂推理、逻辑陷阱 | 高阶认知能力 | 23 个高难度任务，小模型常接近随机 |
实用操作：在微调前，先用基座模型跑一遍基准，建立“能力基线”。微调后，如果 MMLU 从 65% 跌到 45%，说明你的学习率过高或数据配比失衡，通用知识被严重覆盖。
2. 对齐与指令遵循：测“听话”程度
通用基准测的是“知识储备”，但对齐后的模型更要测“对话体验”。
| 基准测试 | 考察维度 | 特点 |
|---------|---------|------|
| MT-Bench | 多轮对话、指令遵循、写作、推理、编码、数学 | 用 GPT-4 作为裁判打分，与人工排序相关性高 |
| AlpacaEval | 单轮指令遵循、开放式生成 | 与 Davinci-003/GPT-4 输出对比，测胜率（Win Rate） |
| Arena-Hard | 真实用户风格提示、复杂指令 | 从 Chatbot Arena 用户对话提炼，区分度高，不易过拟合 |
实用认知：MT-Bench 这类“模型评模型”的自动化方案虽然高效，但存在裁判偏见——用 GPT-4 评分时，它可能更偏好风格与自己接近的回答。因此分数仅供参考，不可作为唯一真理。
3. 垂直领域基准：自建是常态
如果你微调的是法律、医疗、金融模型，公开通用基准往往不够用。行业内的标准做法是：
- 收集领域考试题：如国家司法考试真题、执业医师资格考试、CFA 题库，做成 Few-shot 或 Zero-shot 评测；
- 构造业务场景测试集：如“根据以下病历给出诊断建议”、“续写合同条款并指出风险点”；
- 引入专家规则评估：法律模型输出的条文引用是否正确，可以用正则+知识库做自动化校验，不完全依赖人工。
二、人工评估体系：终极裁判
客观基准有一个致命盲区：它只能测“对不对”，很难测“好不好”。一个回答可能在事实层面全对，但语气傲慢、结构混乱、隐含歧视；也可能在 BLEU/ROUGE 指标上得分不高，但对用户极其有用。这些必须由人来看。
1. 评估维度设计：从“三维”到“五维”
业界最常用的是 Anthropic 提出的 HHH 框架（Helpful, Honest, Harmless），在实际落地中通常扩展为五维：
| 维度 | 定义 | 评估示例 |
|------|------|---------|
| 有用性（Helpfulness） | 是否直接解决用户问题，信息是否完整 | 用户问“如何降三高”，回答是否给出饮食、运动、就医建议 |
| 诚实性（Honesty） | 是否胡说八道（幻觉），是否承认不知道 | 对超纲问题，是编造答案还是坦诚“知识库未覆盖” |
| 无害性（Harmlessness） | 是否输出违法、歧视、诱导自残等内容 | 对越狱提示（Jailbreak）的抵抗能力 |
| 指令遵循（Instruction Following） | 是否严格按用户要求的格式、长度、风格输出 | 用户要求“用表格对比且不超过 200 字”，是否遵守 |
| 流畅性（Fluency） | 语言是否自然、连贯、符合领域表达习惯 | 医疗回答是否过于口语化，法律文本是否缺失术语 |
实用建议：不要试图一次性评估所有维度。SFT 阶段重点看有用性 + 指令遵循；RLHF/DPO 阶段重点看无害性 + 诚实性；垂直领域微调则额外加上领域准确性。
2. 评估流程：如何让人评得准、评得稳
人工评估最怕“公说公有理，婆说婆有理”。必须建立工业化流程：
Step 1：构建 Prompt 测试集
- 覆盖高频场景、长尾边缘 case、对抗样本（如模糊指令、多轮追问、恶意诱导）。
- 建议 200–500 条即可启动首轮评估，后续持续追加 bad case。
Step 2：制定评分 Rubric（评分细则）
- 不要用笼统的 1–5 分，要给每一分对应明确的行为描述。
- 示例（有用性 1–5 分）：
- 5 分：完全解决用户问题，信息准确且附带可操作建议；
- 3 分：部分解决，缺少关键细节但方向正确；
- 1 分：完全离题或答非所问。
Step 3：盲评与交叉验证
- 评估者不知道答案来自模型 A 还是模型 B，避免品牌偏见；
- 同一批次至少 2–3 人独立打分，计算 Cohen’s Kappa 系数（>0.6 视为一致性可接受）；
- 分歧大的样本要拿出来讨论，修正 Rubric。
Step 4：A/B 对比优于绝对打分
- 让人直接判断“模型 A vs 模型 B，谁更好”，比分别给 A 和 B 打绝对分数更可靠。
- 输出格式：Win / Tie / Lose，并可附加“好在哪”的多选标签（如：更准确、更简洁、更安全）。
三、生产级评估策略：双轨闭环
在实际工程中，客观测试与人工评估不是二选一，而是分层协作：
| 阶段 | 客观基准 | 人工评估 | 目标 |
|------|---------|---------|------|
| 日常迭代 | 每次微调后全量跑 MMLU、GSM8K、MT-Bench | 抽检 50 条业务 prompt | 快速拦截灾难性退化 |
| 版本发布前 | 垂直领域自动化测试集 | 200+ 条盲评，覆盖安全边界 | 决定是否推上生产环境 |
| 线上 A/B 测试 | 推理延迟、Token 吞吐量、错误率 | 用户埋点（点赞/点踩/复制/转发） | 真实业务指标验证 |
| Bad Case 回归 | 将线上投诉抽象为自动化断言 | 加入人工评估常驻测试集 | 防止已修复问题复发 |
关键机制：回归测试集（Regression Test Set）
每次微调后，必须跑一遍历史上出现过的 bad case。这是防止“修东墙补西墙”的唯一办法。建议维护三类回归集：
- 能力回归集：确保上次能答对的数学题、代码题这次还能对；
- 安全回归集：确保上次能拒绝的越狱攻击、敏感问题这次仍拒绝；
- 业务黄金集：由业务方提供的 50–100 条标杆问答，必须全部通过。
四、常见陷阱与避坑指南
陷阱 1：数据污染（Data Contamination）
如果你的微调数据或预训练数据不小心混入了测试集题目，基准分数会虚高。对策：
- 在数据清洗阶段做去重与模糊匹配（如 13-gram 匹配）；
- 对关键 benchmark，尝试改写题目表述（Paraphrase）后再测，若分数暴跌，说明存在记忆而非理解。
陷阱 2：过拟合 Benchmark（Benchmark Overfitting）
团队在某一公开榜上反复调参刷分，结果上线后用户并不买账。对策：
- 始终保持一个内部私有测试集，不对外公开、不参与调参；
- 关注MT-Bench 等动态榜单，比静态题库更难被针对性过拟合。
陷阱 3：人工评估的主观漂移
不同批次评估者标准不一，导致“这次 4.2 分”和“上次 4.2 分”不可比。对策：
- 每批次加入锚定样本（已知预期分数的标准问答），校准评估者；
- 用模型辅助评估（如 GPT-4 预打分+人工复核），降低成本同时保持稳定性。
陷阱 4：只看平均分，不看分布
平均分 4.0 可能掩盖了 10% 的 1 分灾难回答。对策：
- 报告分数时同步给出最低分、P10、P90 或差评率；
- 对安全类评估，实行一票否决：只要出现有害输出，该版本直接打回。
五、小结
微调效果评估不是“跑个分交差”，而是连接技术迭代与用户体验的桥梁。
- 客观基准是雷达，负责广域扫描和能力退化预警；
- 人工评估是显微镜，负责捕捉体验细节、安全边界和业务契合度；
- 回归测试是安全带，确保每次迭代不翻车；
- 线上 A/B 测试是最终考场，用户用脚投票的结果才作数。
在 10.3 至 10.5 节中，我们完成了从数据到训练的技术闭环；在本节，我们完成了从训练到验证的决策闭环。接下来，第 11 章将把视野从“微调后的单一模型”扩展到“大模型评估体系”的全景，系统讲解通用能力、垂直领域、对齐效果、推理性能与幻觉评测的方法论。