本篇定位：为什么要先把离线评测体系搭起来

在《Ai大模型训练教程：从入门到实战落地的系统课程》中，训练与微调并不是“跑起来就算完成”。大模型的真实难点往往在于：你怎么证明它变好了，以及如何防止它在下一次迭代中变差而不自知。这就需要一套可重复、可自动化、可对比的离线评测体系。

离线评测解决三类核心问题：

1. 基准集稳定：每次评估都在同一套题上测，才能形成纵向对比。
2. 自动评分可解释：能持续集成（CI）触发评测，并输出结构化分数/错误样例。
3. 回归对比可追溯：新模型与旧模型差异、退化点、改进点可定位到具体样本。

本文聚焦“离线评测体系搭建：基准集选择、自动评分与回归对比流程”，提供可落地的步骤、示例与建议。

总体架构：离线评测的最小可用闭环

建议把离线评测拆成四层，每层都有清晰的输入输出：

1. 基准集层（Dataset）：任务定义、样本、标准答案/参考、元数据、切分策略。
2. 推理层（Inference Runner）：给定模型版本与prompt模板，批量生成输出。
3. 评分层（Scoring）：规则/模型裁判/多指标融合，产出分数、错误类型、置信度。
4. 对比层（Regression & Report）：与baseline对比，输出差异报告与可回放样本。

落地时先做“最小闭环”：选一小套高价值基准集 + 一种评分方式 + 一种对比报表，跑通后再扩展任务与指标。

基准集选择：从业务目标倒推题型与覆盖面

1）先定义评测对象：能力域与使用场景

不要一上来就收集“看起来很全面”的题。评测集应该围绕你模型的目标能力域。例如：

• 企业知识问答：事实性、引用准确性、拒答策略、来源一致性。
• 客服对话：情绪安抚、流程引导、信息收集完整性、合规表达。
• 代码助手：可运行性、复杂度、边界条件、测试覆盖。
• 多工具/Agent：工具选择正确率、调用参数正确率、计划合理性、终止条件。

把能力域写成可评测的维度（后续用于打标签、做分桶统计）：

• 事实/知识（Factuality）
• 指令遵循（Instruction Following）
• 逻辑推理（Reasoning）
• 安全与合规（Safety/Policy）
• 格式约束（JSON/Markdown/结构化输出）
• 工具调用（Tool-use）

2）基准集来源：公用集 + 私有集的组合策略

推荐组合：公共基准用于横向对标，私有基准用于业务贴合。

• 公共基准：覆盖通用能力，便于对标不同模型（但可能与业务偏差大）。
• 私有基准：来自真实工单、业务QA、内部文档、历史对话（价值最高，但要脱敏与合规）。

实操建议：

• 先用公共集快速建流水线（1~2天跑通），再逐步替换成私有集。
• 私有集务必做脱敏：姓名、电话、地址、订单号、合同号等。

3）样本设计：每条样本至少包含哪些字段

建议你的基准样本采用统一JSON结构，便于扩展和自动化处理：

• id：唯一ID（稳定，不随内容变动）
• task：任务类型（qa/summarize/classify/tool_call等）
• input：用户输入（或多轮对话数组）
• context：可选上下文（检索到的文档片段、知识库段落、工具返回值）
• reference：参考答案（可空，用于无参考的偏好评测）
• rubric：评分细则（关键点、必须包含/禁止包含）
• labels：维度标签（领域、难度、风险等级、是否含敏感意图）

示例（简化）：

• rubric.must_include: ["说明退款流程", "提示预计到账时间"]
• rubric.must_not_include: ["承诺免审核", "泄露内部政策"]

4）切分与泄漏：训练集/评测集隔离的硬规则

离线评测的公信力来自“你没见过”。建议至少做到：

• 按时间切分：用最新一段时间的真实问题做评测，较早的问题可进入训练。
• 按ID去重：对相似问法做近重复检测（MinHash/embedding相似度），避免训练集出现同题改写。
• 按文档版本切分：知识库/政策频繁变更时，评测集要绑定“版本号”和“生效日期”。

5）规模与分布：不要追求大而全，先追求“可解释的覆盖”

经验值（可按资源调整）：

• MVP阶段：100~300条（能快速迭代，每次评测<30分钟）
• 稳定阶段：1000~5000条（分桶统计更可靠）

确保分布合理：

• 每个关键能力维度至少有一定样本量（如每桶≥30）
• 高风险（合规/安全）单独成桶，宁可少也要精

自动评分：从规则到“LLM裁判”的混合方案

自动评分通常分三类，建议按“成本—一致性—覆盖面”取舍，并最终做混合：

1）规则评分（Deterministic）：适合结构化与硬约束

适用场景：

• 输出必须是JSON，字段齐全且类型正确
• 必须包含某些关键词或步骤
• 分类任务有明确标签
• 代码必须通过单元测试

可落地指标举例：

• JSON可解析率（parse success rate）
• Schema校验通过率（required fields）
• 正则/关键点命中率
• 单测通过率

建议：把规则评分作为“门槛指标”，例如：不满足格式直接判0分，避免LLM裁判被格式问题干扰。

2）参考答案对比（Reference-based）：适合有标准答案的任务

适用场景：

• 问答有确定事实
• 摘要有参考摘要

可用方法：

• 文本相似：BLEU/ROUGE（适合摘要，但对问答不鲁棒）
• 语义相似：embedding cosine（对同义改写更友好）
• 关键点打分：把参考答案拆成若干要点，逐项匹配

建议：不要迷信单一相似度分数。更实用的做法是：

• 把参考答案拆成key_points（3~8条），模型回答命中多少条给多少分
• 同时设置“致命错误”检查（如金额/日期/政策结论错误直接扣满）

3）LLM裁判（Model-based Judge）：适合主观质量与复杂指令遵循

当任务难以规则化（如客服话术是否得体、回答是否全面），可用LLM作为裁判。为了可控与复现，需要把裁判流程工程化：

3.1 裁判Prompt要点（强约束输出）

• 明确评分维度与权重（例如：准确性50、完整性30、表达10、合规10）
• 给出评分rubric（1/3/5分分别代表什么）
• 强制输出JSON：{"score":...,"reasons":...,"violations":...}
• 要求引用证据：从context中摘取支持/反对的句子

3.2 抗偏置策略

LLM裁判常见问题：偏向更长回答、被花哨措辞影响、对不同模型风格不公平。

建议措施：

• 双盲：把对比评测中A/B输出随机打乱，不告诉裁判哪个是新模型。
• 长度归一：提示裁判不要因为长度高分；或对超长输出先截断。
• 一致性复评：同样样本用不同seed/不同裁判模型复评，取均值或多数票。
• 校准集：准备一小批人工标注样本，定期验证裁判分数与人工一致性。

3.3 “裁判也要回归”

评测体系的目标是衡量模型变化，不是裁判变化。因此：

• 裁判模型版本要固定（或升级时做一次全量重评并打版本号）
• 裁判prompt与rubric要版本化（存Git），任何改动都要触发基线重建

4）推荐的混合评分落地方案（强可执行）

给出一个在企业里很常用的组合：

1. 门槛：格式/合规规则（不通过则直接Fail）
2. 主分：LLM裁判多维打分（0~5）
3. 辅助：关键点覆盖率、引用命中率（用于定位问题）
4. 最终：按权重合成总分，并输出每维分布

回归对比流程：把“变好/变坏”落到可定位的样本

回归对比的核心不是平均分，而是：

• 哪些桶退化了？（如“安全合规”从4.8降到4.2）
• 退化发生在哪些样本？（Top N worst regression）
• 退化原因是什么类型？（格式错误、拒答过度、事实性错误、指令偏离）

1）基线选择：谁是baseline

常见baseline：

• 线上当前稳定版本（strong baseline）
• 上一个训练checkpoint（用于训练中早停选择）
• 外部对标模型（用于商业竞品对比）

建议：在工程里把baseline写成一个固定的model_id，评测任务中始终带上candidate与baseline。

2）对比粒度：不只看总分

至少输出以下维度：

• 总分均值/中位数/分位数（P10/P50/P90）
• 每个能力桶的均值（domain、difficulty、risk_level）
• 通过率类指标（合规通过率、JSON通过率、单测通过率）
• 显著性：简单可用bootstrap置信区间（资源有限也可先不做）

3）样本级diff：把回归样本“打包可复现”

对每条样本保存以下产物，便于复盘：

• 输入（含context、系统prompt、模板变量）
• baseline输出 / candidate输出
• 评分输出（每维分数、裁判理由、规则触发项）
• 时间戳、模型版本、参数（temperature、top_p、max_tokens）

并生成两类清单：

• Worst Regression Top 50：新模型比旧模型下降最多
• Best Improvement Top 50：新模型提升最多（用于验证训练目标是否达成）

4）失败类型归因：建立“错误码”体系

为了让回归分析可统计，建议从一开始就定义错误码（可多选）：

• FORMAT_INVALID：JSON不可解析/缺字段
• INSTRUCTION_DEVIATION：没有按要求输出、遗漏步骤
• HALLUCINATION：凭空编造、与context冲突
• OVER_REFUSAL：应答却拒答
• SAFETY_VIOLATION：违规建议/敏感信息
• TOOL_CALL_ERROR：工具选择错/参数错/未终止

规则检测能直接打一些错误码；LLM裁判也可以被要求输出error_codes。

工程落地：一次评测跑通的建议目录与流水线

1）推荐目录结构（可直接照抄改造）

• datasets/benchmark_v1/*.jsonl
• prompts/（系统提示词、任务模板、裁判模板）
• configs/（模型列表、推理参数、评测开关）
• runner/（批量推理、并发、重试、缓存）
• scorers/（规则、相似度、裁判）
• reports/（HTML/JSON/CSV输出）
• artifacts/（每次run的输出与日志，按run_id存档）

2）推理Runner关键点：缓存、并发与可复现

• 缓存：同一(model_id, prompt_hash, sample_id)命中则不重复推理，节省成本
• 并发：控制QPS，遇到429/5xx重试（指数退避）
• 可复现：记录推理参数；temperature尽量固定（回归对比建议temperature=0或很低）
• 超时与截断：设置最大tokens，防止异常长输出拖垮批处理

3）持续集成（CI）触发：两层评测策略

• PR级小评测（smoke）：抽样50~100条，10分钟内出结果，用于阻断明显退化
• 夜间全量评测（full）：全量基准 + 多裁判复评 + 完整报表

门禁建议（示例）：

• JSON通过率 < 99%：直接失败
• 合规通过率下降 > 0.5%：直接失败
• 总分下降 > 0.1 且退化样本数 > 30：需要人工审批

实战示例：以“企业知识库问答（带引用）”为例

假设你的目标是让模型在RAG场景下回答并引用依据。

1）基准样本设计

每条样本包含：

• input：用户问题
• context：检索到的3~8段文档
• reference：可选（不一定有）
• rubric：必须包含“结论 + 引用段落编号”，不得编造

2）规则评分

• 检查是否输出了citations: [1,3]
• citations是否在context范围内
• 如果输出包含“根据政策第X条”但context不存在，触发HALLUCINATION

3）LLM裁判评分维度

• 准确性：结论是否与context一致
• 覆盖性：是否回答了问题的所有子点
• 引用质量：引用是否支撑关键结论
• 表达：是否简洁清晰（权重较低）

4）回归对比报告

输出：

• accuracy_mean, citation_precision, hallucination_rate
• Worst Regression中，优先看hallucination_rate上升的样本
• 将退化样本回灌到数据侧：补充训练数据或改检索/重排序

常见坑与规避清单（强烈建议上线前对照）

1. 评测集被训练集污染：相似题未去重，导致离线分数虚高。
2. 裁判版本漂移：换了裁判模型或prompt却没重建基线，前后不可比。
3. 只看均值不看分布：均值持平但P10变差，说明“长尾退化”。
4. 没有样本级产物：只出一个分数表，无法定位退化原因。
5. 高风险桶样本太少：合规问题被均值掩盖，线上出事才发现。
6. temperature过高导致波动：回归对比应尽量稳定，必要时多次采样取均值。

你可以立即执行的落地步骤（1周内跑通）

1. 确定3~5个能力维度（与业务目标一致）并定义标签。
2. 收集200条样本：80%真实问题脱敏 + 20%覆盖边界与高风险。
3. 固化样本JSON结构：加上rubric与labels。
4. 实现推理Runner：并发、重试、缓存、参数记录。
5. 先做规则评分门槛：格式、合规、引用等。
6. 接入LLM裁判：输出强制JSON、打错误码、保存理由。
7. 建立baseline并做第一次全量评测：产出基线报告。
8. 接入CI：PR小评测门禁 + 夜间全量评测。
9. 建立回归看板：每次迭代自动生成Worst/Best样本包，推动数据与训练闭环。

离线评测体系一旦跑通，你的大模型训练迭代就会从“凭感觉调参”升级为“以证据驱动改进”。这也是《Ai大模型训练教程》里从入门走向实战落地的关键一环。