模型质量与评估

模型质量评估是判断一个大语言模型是否“真的好用”的过程。它不只是跑几个公开 benchmark，也不只是人工看几条回答，而是要围绕真实任务，系统评估模型的准确性、稳定性、安全性、成本和可控性。

对 LLM 来说，“质量”不是单一指标。一个模型可能数学能力很强，但中文客服体验一般；也可能对话很自然，但 JSON 格式经常出错；还可能公开榜单分数高，但在企业私有知识问答里表现不稳定。

因此，模型质量评估的核心问题是：

在目标场景里，这个模型是否可靠、可控、可上线？

1. 为什么需要模型评估

模型评估用于回答这些问题：

• 哪个模型更适合当前业务？
• 微调、量化、蒸馏后质量有没有下降？
• RAG、提示词、工具调用改动是否真的带来提升？
• 新版本是否可以替换旧版本？
• 模型是否存在安全、幻觉、格式错误或拒答问题？
• 上线后如何监控质量退化？

如果没有稳定评估集，模型迭代很容易变成“感觉更好了”。这会导致不同版本难以比较，也很难定位问题来自模型、提示词、检索、工具还是推理参数。

2. 模型质量的主要维度

LLM 质量可以拆成多个维度。

维度	含义	典型问题
准确性	回答是否事实正确、推理正确	答案错、计算错、引用错
相关性	是否回答了用户真正的问题	答非所问、跑题
完整性	是否覆盖必要信息	漏掉关键步骤或字段
简洁性	是否避免无意义冗长	啰嗦、重复、废话多
稳定性	相似输入是否得到稳定输出	同类问题表现波动大
格式遵循	是否遵循 JSON、表格、schema 等要求	格式不可解析、字段缺失
指令遵循	是否遵守 system prompt 和任务要求	忽略约束、擅自扩展
安全性	是否避免有害内容和越权信息	不当回答、泄露敏感信息
鲁棒性	面对噪声、错别字、长输入是否稳定	输入稍变就失败
可解释性	是否能给出合理依据或过程	只给结论，没有依据

不同业务权重不同。客服机器人可能更关注准确性、拒答和语气；代码模型更关注测试通过率；结构化抽取更关注字段准确率和 JSON 可解析率。

3. 通用 Benchmark

公开 benchmark 可以快速了解模型的通用能力。

常见评估方向包括：

方向	常见任务
通识知识	MMLU、C-Eval、CMMLU
数学推理	GSM8K、MATH、AIME 类题目
代码能力	HumanEval、MBPP、LiveCodeBench
阅读理解	RACE、DROP、QuAC 等
多语言	FLORES、XNLI、多语言问答
长上下文	Needle in a Haystack、LongBench
安全对齐	Jailbreak、拒答、安全分类测试

公开 benchmark 的价值：

• 快速横向比较模型。
• 判断模型大致能力边界。
• 观察模型在标准任务上的趋势。

局限：

• 可能和真实业务任务不一致。
• 可能存在数据污染。
• 分数高不代表上线效果好。
• 很多主观体验和工具调用能力难以覆盖。

因此，公开 benchmark 适合做第一层筛选，不适合替代业务评估。

4. 业务评估集

真正决定模型是否可用的，是业务评估集。

业务评估集应该来自真实使用场景，例如：

• 历史用户问题。
• 客服工单。
• 内部知识库问答。
• 合同、财报、论文、代码等真实文档。
• 工具调用日志。
• 线上失败案例。
• 专家整理的边界样本。

一个好的业务评估集应该具备：

• 覆盖核心任务。
• 覆盖高频问题。
• 覆盖高风险问题。
• 覆盖边界和异常输入。
• 有明确评分标准。
• 与训练集隔离。
• 版本可追踪。

不要只放简单样本。评估集里必须有模型容易失败的样本，否则无法区分模型质量。

5. 评估集切分

建议把评估数据分成几类。

类型	用途
Smoke Test	少量样本，快速检查服务是否正常
Regression Set	固定回归集，用于比较版本变化
Challenge Set	困难样本，专门暴露模型短板
Safety Set	安全、隐私、越权、拒答测试
Format Set	JSON、工具调用、表格等格式测试
Golden Set	专家高质量标注集，用于关键决策
Online Sample	线上采样数据，用于持续监控

回归集应该相对稳定，不能频繁修改。挑战集可以持续扩充，用来推动模型迭代。

6. 自动评估

自动评估适合有明确标准答案或规则的任务。

常见指标包括：

任务	指标
分类	Accuracy、Precision、Recall、F1
多选题	Accuracy
信息抽取	字段准确率、严格匹配、部分匹配
JSON 输出	可解析率、schema 通过率、字段完整率
代码生成	编译通过率、单元测试通过率
数学题	最终答案准确率
检索任务	Recall@k、MRR、NDCG
摘要	ROUGE、BERTScore、人工评分

自动评估的优点：

• 成本低。
• 可重复。
• 适合 CI / 回归测试。
• 便于量化比较。

缺点：

• 难以覆盖开放式回答质量。
• 指标可能和用户体验不一致。
• 标准答案不唯一时容易误判。

自动指标适合“能明确判对错”的任务。开放式对话仍需要人工或模型裁判辅助。

7. 人工评估

人工评估适合主观质量较强的任务，例如：

• 对话体验。
• 解释是否清楚。
• 语气是否合适。
• 回答是否有帮助。
• 是否符合业务规范。
• 引用是否可靠。

常见评分维度：

维度	评分问题
Helpfulness	回答是否真正解决问题
Correctness	内容是否正确
Completeness	是否完整覆盖需求
Clarity	表达是否清晰
Conciseness	是否简洁
Safety	是否安全合规
Tone	语气是否符合场景

人工评估要注意：

• 提供明确评分 rubric。
• 多人标注时计算一致性。
• 样本顺序随机化。
• 隐藏模型名称，避免偏见。
• 保留原始标注和理由。

人工评估成本高，通常用于关键版本发布、复杂开放任务和自动评估无法覆盖的场景。

8. LLM-as-a-Judge

LLM-as-a-Judge 是用另一个模型作为评审，对回答进行打分或比较。

常见形式：

• 单答案打分：给一个回答打 1-5 分。
• 成对比较：判断回答 A 和回答 B 哪个更好。
• 多维评分：分别评分准确性、完整性、简洁性、安全性。
• 规则检查：判断是否违反某些约束。

成对比较通常比绝对打分更稳定：

同一个问题下，回答 A 和回答 B 哪个更好？为什么？

LLM-as-a-Judge 的优点：

• 成本低于人工。
• 速度快。
• 可覆盖开放式任务。
• 适合大规模初筛。

风险：

• judge 模型本身有偏见。
• 容易偏好更长、更自信的回答。
• 对事实正确性判断可能出错。
• 可能偏向和自己风格相似的回答。
• 如果被评模型和 judge 同源，可能存在偏置。

建议把 LLM-as-a-Judge 当作辅助评估，不要完全替代人工和客观指标。

9. Win Rate

Win Rate 是评估两个模型或两个方案时常用的指标。

流程：

1. 对同一批问题，分别让模型 A 和模型 B 回答。
2. 由人工或 judge 判断哪个回答更好。
3. 统计 A 胜、B 胜、平局比例。

示例：

结果	比例
A 胜	48%
B 胜	35%
平局	17%

Win Rate 适合比较：

• 新旧模型。
• 不同提示词。
• 微调前后。
• 量化前后。
• RAG 策略改动前后。

注意：Win Rate 需要看样本来源和评分标准。只报告“胜率提升”但不说明评估集，很难判断可信度。

10. RAG 质量评估

RAG 系统的质量不只取决于生成模型，还取决于检索和上下文拼接。

评估时建议拆开看：

模块	指标
文档解析	文本是否完整、表格是否丢失、段落是否乱序
Chunk	切块是否保留语义、是否过长或过短
Embedding	相似问题是否能召回相关内容
检索	Recall@k、命中率、MRR
Rerank	排序后相关文档是否靠前
生成	答案是否基于引用、是否幻觉
引用	citation 是否真实、是否支持结论

RAG 常见失败类型：

• 没召回正确文档。
• 召回了但排序靠后。
• 上下文太长，模型忽略关键片段。
• 引用了文档，但答案和文档不一致。
• 文档本身过期或冲突。

RAG 评估要区分“检索失败”和“生成失败”。否则容易误以为是模型不好。

11. 工具调用评估

工具调用模型要评估的不只是最终回答，还包括调用过程。

关键指标：

指标	含义
Tool Selection Accuracy	是否选择了正确工具
Argument Accuracy	参数是否正确
Schema Validity	工具调用 JSON 是否符合 schema
Execution Success Rate	工具是否成功执行
Multi-step Success Rate	多步工具链是否完成目标
Recovery Ability	工具失败后是否能恢复或解释
Permission Safety	是否越权调用敏感工具

工具调用评估要记录完整轨迹：

用户请求
  -> 模型选择工具
  -> 工具参数
  -> 工具执行结果
  -> 模型最终回答

只看最终回答，可能掩盖中间工具调用错误。

12. 安全评估

安全评估用于检查模型是否遵循边界。

常见方向：

• 暴力、自残、违法内容。
• 隐私和个人信息泄露。
• 内部系统提示泄露。
• 越权访问和工具滥用。
• 医疗、法律、金融等高风险建议。
• Jailbreak 和 prompt injection。
• 版权和敏感内容。

安全评估要同时看两类错误：

错误类型	含义
False Negative	应该拒绝但没有拒绝
False Positive	不该拒绝但过度拒绝

过度拒答也是质量问题。一个安全模型不应该对正常请求也大量拒绝。

13. 幻觉评估

幻觉是指模型生成了看似合理但不真实或无依据的内容。

常见类型：

• 编造事实。
• 编造引用。
• 错误归因。
• 把不确定内容说得很肯定。
• RAG 场景中回答超出文档依据。
• 数字、日期、实体名称错误。

评估方式：

• 与标准答案比对。
• 使用可验证事实库。
• 检查引用是否支持结论。
• 人工事实核查。
• 让模型标注“不确定”并评估校准程度。

幻觉评估不能只看语言是否流畅。越流畅的错误越危险。

14. 格式与结构化输出评估

很多生产任务更关心格式稳定性，而不只是自然语言质量。

常见指标：

• JSON 可解析率。
• Schema 通过率。
• 必填字段完整率。
• 字段类型正确率。
• 枚举值合法率。
• 多余字段比例。
• Markdown 表格格式正确率。
• XML / YAML 可解析率。

结构化输出建议使用程序自动验证。例如：

模型输出
  -> JSON parse
  -> schema validate
  -> 字段级准确率检查

如果格式错误，后续业务系统可能直接失败。因此格式评估应进入回归测试。

15. 长上下文评估

长上下文模型需要单独评估。

不能只看模型标称支持 32K、128K 或 1M tokens。更重要的是：

• 长输入下是否能找到关键信息。
• 多个相似片段中是否能区分正确片段。
• 开头、中间、结尾的信息是否都能关注。
• 是否受无关内容干扰。
• 长上下文下延迟和显存是否可接受。

常见测试：

• Needle in a Haystack。
• 长文档问答。
• 多文档综合。
• 长对话记忆。
• 长代码仓库定位。

长上下文评估要同时看质量和性能。能处理长输入不代表线上可承受。

16. 多模态评估

多模态模型需要评估图像、文本和跨模态理解。

常见维度：

• OCR 能力。
• 图表理解。
• 物体识别。
• 空间关系。
• 多图对比。
• 视频时间顺序理解。
• 图文混合推理。
• 幻觉和过度猜测。

多模态评估要注意输入预处理：

• 图片分辨率。
• 裁剪方式。
• 多图顺序。
• 图像占位 token。
• OCR 文本是否额外提供。

同一个模型在不同推理框架或图片预处理方式下，表现可能差异明显。

17. 评估报告应该记录什么

一份可复现的评估报告至少记录：

类别	内容
模型	名称、版本、revision、量化方式
推理配置	temperature、top_p、max_tokens、stop、seed
Prompt	system prompt、chat template、工具定义
数据	评估集名称、来源、版本、样本数
方法	自动评估、人工评估、judge 模型
指标	accuracy、win rate、格式通过率、安全指标等
环境	推理框架、硬件、服务参数
结果	总分、分任务结果、置信区间
案例	典型成功、失败和边界样本

如果没有记录 prompt、采样参数和评估集版本，评估结果很难复现。

18. 线上质量监控

离线评估不能覆盖所有线上情况。上线后还需要持续监控。

可以监控：

• 用户点赞 / 点踩。
• 人工质检结果。
• 投诉和转人工率。
• 工具调用失败率。
• JSON 解析失败率。
• RAG 无引用回答比例。
• 拒答率。
• 平均回答长度。
• 安全拦截率。
• 线上抽样 judge 分数。

线上数据还能反哺评估集：

线上失败案例
  -> 清洗和标注
  -> 加入回归集 / 挑战集
  -> 指导下一轮模型或系统优化

评估集应该随着真实问题演化，但核心回归集要保持稳定。

19. 常见误区

19.1 只看公开榜单

公开榜单不能代表业务表现。模型选择应该结合业务评估集。

19.2 只看平均分

平均分可能掩盖关键失败。例如整体 95 分，但安全样本大量失败，仍然不能上线。

19.3 用训练集做评估

训练集评估会虚高，不能代表泛化能力。评估集必须和训练集隔离。

19.4 只看最终答案

RAG、工具调用、Agent 场景要看中间过程。最终答案正确不代表链路可靠。

19.5 评估时参数不固定

temperature、top_p、max_tokens、prompt、chat template 变化都会影响结果。评估时必须固定配置。

19.6 忽略失败案例

只看总分无法指导优化。失败案例分类比单一分数更有价值。

20. 实践建议

建议按这个顺序建设模型质量评估体系：

1. 明确业务目标：模型要解决什么任务。
2. 定义质量维度：准确性、格式、安全、体验等哪个最重要。
3. 建立小型 golden set：先用几十到几百条高质量样本。
4. 加入自动评估：能程序判断的尽量程序判断。
5. 加入人工或 judge 评估：覆盖开放式质量。
6. 建立回归集：每次模型、prompt、RAG、量化改动都跑。
7. 记录完整配置：模型版本、prompt、参数、数据版本。
8. 分析失败案例：按原因分类，而不是只看分数。
9. 上线后持续采样：把真实失败样本补回评估集。

评估体系不需要一开始很大，但必须可复现、可迭代、能暴露真实问题。

21. 总结

模型质量评估的本质是：用稳定、可复现、贴近真实任务的方法，判断模型是否满足目标场景。

可以抓住四条主线：

• 通用 benchmark 用来做初筛。
• 业务评估集决定模型是否真的可用。
• 自动评估、人工评估和 LLM-as-a-Judge 各有适用边界。
• RAG、工具调用、安全、格式输出和长上下文都需要专项评估。

对生产系统来说，评估不是上线前的一次性动作，而是贯穿模型选择、提示词优化、微调、量化、部署和线上监控的持续流程。

参考

• EleutherAI's lm-evaluation-harness