如何建立一套完整的大模型评估体系？

简化版

完整的大模型评估不能只看一个榜单分数，要同时覆盖基础能力、任务效果、事实性、安全性、鲁棒性、系统效率。正确顺序是——先根据业务风险定义成功条件，再选数据和评分器，最后做离线回归 + 线上监控，并为每次模型/Prompt/数据/工具变更做回归。核心认知：公开榜单只回答”模型在哪些题上得分”，代替不了业务验收。

详细版

评估分四层：

模型层：知识、推理、代码、长上下文、指令遵循、多语言；
应用层：任务成功率、引用正确性、工具调用、业务规则；
安全层：有害输出、Prompt Injection、隐私、偏见、过度拒答；
系统层：延迟、吞吐、稳定性、成本、可观测性。

能用代码验证的优先确定性评分；开放式答案再用人工或校准后的 LLM Judge。公开 Benchmark 横向参考，上线决策以私有业务集、长尾失败集、安全红队集为主。

完整版教学

易错点：离线分数衡量的是固定样本与协议；线上还会受到真实流量漂移、工具故障、延迟和用户行为影响，两类证据不能互相替代。

一、从用途和风险开始（不是从榜单开始）

一个高频错误是「先找一组流行 Benchmark，再解释分数」。正确做法反过来——先定用途和风险：

同一个模型，用途不同，成功标准和错误代价完全不同：
  文案生成：错了改改就好（低风险）
  客服：错误答复影响体验（中风险）
  医疗辅助：错误可能致命（高风险，需硬门槛+人工兜底）

评估前先明确：用户、输入分布、允许动作、不可接受的失败、人工兜底。高风险能力要设硬门槛，不能被其他维度的平均高分抵消。

二、能力矩阵：把能力拆成可定位的子项

别用一个总分，把能力拆开，每项配四类样本：

能力子项	样本类型
事实检索、数字计算、格式遵循、拒答、长上下文证据使用、工具参数正确性	正常 + 边界 + 对抗 + 不可回答

HELM 一类整体评估强调同时报告准确性、鲁棒性、公平性、效率等多维度，避免单指标排名掩盖差异。总分相同的两个模型能力结构可能完全不同。

三、评分器选择（能确定就别用 LLM）

内容	评分器
精确答案、JSON Schema、代码测试	确定性程序
多个合法表达	语义匹配或带量规的 Judge
主观质量、高风险内容	训练过的人工评审
安全漏洞	规则 + 分类器 + 人工红队 + 执行层验证组合

关键：评分器本身也要评估——抽样算它和专家的一致性、误报、漏报。

四、数据集设计与防泄漏

测试集要代表真实流量，按场景/语言/长度/用户群/风险分层。关键纪律：

保留【独立开发集】和【最终测试集】分开
  → 持续调 Prompt 时只用开发集，避免把测试集变成"训练信号"（污染）
线上失败 → 脱敏 + 复核 → 进回归集，记录来源、版本、预期行为

五、版本与复现

固定模型版本、系统提示、采样参数、工具、检索库、评分器、随机种子，保存原始输入输出和 Trace——才能解释「分数变化来自模型还是应用链路」。报告除平均值外，还要给分组结果、样本数、不确定性。

开放式生成即使固定随机种子，也可能因推理框架、并行归约或服务端模型更新而变化，因此还要保存端点版本与实际响应。评测集本身也必须版本化：新增、删除或修订样本后生成新版本，禁止用同一个名称覆盖历史结果。

六、如何把离线评测接到线上闭环

离线门禁通过后先做小流量灰度，监控任务成功、用户纠错/转人工、工具错误、拒答、延迟和成本。线上指标容易受流量构成影响，因此要按语言、任务、风险和版本切片，并设置基线与告警窗口。

离线失败 -> 阻断发布并定位
离线通过 -> 小流量灰度 -> 线上异常自动回滚
线上新失败 -> 脱敏复核 -> 候选回归样本 -> 下一轮离线门禁

例如总体成功率仍为 92%，但支付工具切片从 98% 降到 90%，平均值会掩盖关键回归。事故样本进入正式回归集前还要去重、修订真值并记录来源，避免把未经核验的用户反馈直接当标准答案。

七、常见误区与追问

误区：评估就是刷公开榜单分数。 榜单只答”哪些题得分”，代替不了业务验收，要私有业务集+安全集。
误区：一个总分能代表模型好坏。 能力是多维的（HELM 思想），总分相同结构可能天差地别，要分子项看。
误区：高风险能力可以被平均分抵消。 高风险要设独立硬门槛，不被其他维度平均掉。
误区：所有评估都用 LLM Judge。 能确定就用确定性评分（Schema/代码/精确匹配），Judge 只用于开放式且要校准。
误区：用测试集调 Prompt 没关系。 会把测试集变训练信号（污染），要用独立开发集。
追问：评估的正确顺序？ 先定风险和成功条件 → 再选数据和评分器 → 最后离线回归 + 线上监控。
追问：评估分哪几层？ 模型层、应用层、安全层、系统层。
追问：评分器怎么选、要注意什么？ 能确定用确定性、多表达用 Judge、主观/高危用人工；评分器本身要测和专家的一致性。

数字化设计权重：500 道评测中事实性 200、指令遵循 150、安全 100、格式 50。按题数微平均时事实性占 40%；按类别宏平均时四类各占 25%。上线报告必须固定权重，并额外设置安全类零容忍红线。

八、加强记忆

大模型评估记「先定风险和成功条件，再选数据与评分器，最后离线回归 + 线上监控」：四层（模型/应用/安全/系统）、能力拆成可定位子项配四类样本（正常/边界/对抗/不可回答）、能确定就用确定性评分（评分器本身也要和专家校准）。三条纪律钉死：公开榜单代替不了业务验收、高风险能力设独立硬门槛（不被平均分抵消）、用独立开发集调 Prompt（别污染测试集）。固定全部版本 + 保存 Trace，报告要给分组结果和不确定性。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》的效果评测，把「怎么判断好坏」写成了一份常量 METRICS：每个指标一条，写清测什么、属于「找资料」还是「写答案」、给看报告的人的大白话说明、达标线、低于达标线时的建议。

指标	属于哪一段	达标线	低于达标线时的建议
上下文召回	找资料	0.7	该找的资料没找回来，建议开混合检索或查询改写
上下文精度	找资料	0.6	有用的资料排在后面，建议开重排
忠实度	写答案	0.8	答案里有内容找不到出处，建议加强问答模板的约束
答案相关性	写答案	0.7	回答没有针对问题，建议调整生成 Prompt

报告里的东西都从这一份常量来：

自动结论。 遍历 METRICS，把低于达标线的指标拼成一句话，例如「上下文精度偏低，有用的资料排在后面，建议开重排」；都达标时是「四项指标都在合理区间。」
指标卡片。 后端把分数、达标线和是否达标一起算好返回，前端只负责显示：达标只写「达标（≥ 0.6）」，偏低才显示建议，没跑出分数时显示「—」。
逐条明细。 报告下方每条用例一行，标准答案和生成的答案并排两列，后面跟四个分数。

为什么这样取舍

定义只写一份。 结论文案和卡片如果各写一套阈值，迟早会对不上；加一个字段只改常量，接口和页面自动就有。
分数要翻译成动作。 看报告的人不用记住四个指标各自意味着什么，报告直接说「建议开重排」。
达标和偏低分开说。 分数明明达标，卡片上却挂着一句「低了就开重排」，看的人会以为这项现在就是低的。
平均分之外还要看明细。 某一条召回是 0、其余都是 1，平均下来还有 0.8；翻明细才能找出拖后腿的那条，那通常就是知识库该补的地方。

面试官还会追问

四个指标的达标线为什么不一样高？忠实度为什么定得最高，上下文精度为什么最低？
删除一次评测时要删哪几张表？还在评测中的任务为什么不允许删？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。

简化版

详细版