大模型 LLM 评估指标全解析：召回率、准确率、F1 及其在 RAG / Skills 场景下的实战应用

评估是 LLM 应用落地的"最后一公里"。没有度量就没有优化，没有指标就没有信心。

---

一、为什么 LLM 评估这么难？

传统 NLP 任务的评估相对直接：分类看准确率，翻译看 BLEU，摘要看 ROUGE。但 LLM 时代，一切都不一样了：

• 生成是开放的：同一个问题可以有很多"正确"的回答方式
• 任务是混合的：一次调用可能同时涉及检索、推理、工具调用、格式化输出
• 用户满意度是主观的：一段代码能跑但风格不好，算对吗？

因此，我们需要回到最本质的评估框架，结合 LLM 的具体场景去重新理解每一个指标。

---

二、四个核心基础指标

所有评估都建立在一个 混淆矩阵 之上：

	预测为正 (Positive)	预测为负 (Negative)
实际为正 (Positive)	TP (True Positive)	FN (False Negative)
实际为负 (Negative)	FP (False Positive)	TN (True Negative)

2.1 准确率 (Accuracy)

$$\text{Accuracy}=\frac{TP+TN}{TP+TN+FP+FN}$$

直觉理解：所有预测中，对了多少？

适用场景：类别均衡的分类任务（垃圾邮件检测、情感分析）。

局限：类别不均衡时非常具有欺骗性。99% 的正常邮件，模型全部预测为"正常"，准确率也是 99%——但一个垃圾邮件也抓不住。

---

2.2 精确率 / 查准率 (Precision)

$$\text{Precision}=\frac{TP}{TP+FP}$$

直觉理解：模型说"Yes"的东西里，有多少是真的 “Yes”？

一句话记忆：宁可放过，不可错杀——高 Precision 意味着模型很"谨慎"。

典型场景：

• 搜索引擎返回的结果相关性
• 代码审查工具标记的可疑代码
• RAG 检索到的文档中有多少真正相关

---

2.3 召回率 / 查全率 (Recall)

$$\text{Recall}=\frac{TP}{TP+FN}$$

直觉理解：所有真的 “Yes” 里面，模型找到了多少？

一句话记忆：宁可错杀，不可放过——高 Recall 意味着模型很"全面"。

典型场景：

• 病历筛查：漏掉一个病灶的代价远大于多查几项
• 合规审计：遗漏一个违规记录影响严重
• RAG 检索：相关文档被成功捞出多少

---

2.4 F1 Score

$$F1=2\times \frac{\text{Precision}\times \text{Recall}}{\text{Precision}+\text{Recall}}$$

直觉理解：Precision 和 Recall 的调和平均数（而非算术平均）。调和平均数对较小的值更敏感——你必须在两方面都做好，F1 才会高。

举例：
Precision = 0.9,  Recall = 0.1  →  算术平均 = 0.50,  F1 ≈ 0.18
Precision = 0.5,  Recall = 0.5  →  算术平均 = 0.50,  F1 = 0.50

关键洞察：F1 惩罚"一头沉"。如果一个系统 Precision 极高但 Recall 极低，F1 会把这个问题暴露出来。

---

2.5 F-beta（带权重的 F 值）

$$F_{\beta }=(1+{\beta }^2)\times \frac{\text{Precision}\times \text{Recall}}{({\beta }^2\times \text{Precision})+\text{Recall}}$$

β 值	含义	典型场景
β = 1	Precision 和 Recall 同等重要（即 F1）	通用评估
β = 0.5	Precision 权重更高（更关注准确性）	法律文书生成、金融报告
β = 2	Recall 权重更高（更关注全面性）	病历筛查、安全漏洞检测

---

三、各场景下的指标选择与应用

3.1 RAG（检索增强生成）

RAG 管道有两个关键环节，每一环节都需要不同的指标：

环节一：检索阶段

指标	计算方式	关注点
Recall@K	相关文档在 Top-K 结果中的比例	相关文档有没有被捞到？K 取 5/10/20
Precision@K	Top-K 结果中相关文档的比例	捞上来的东西有多少是有用的？
MRR (Mean Reciprocal Rank)	第一个相关文档排在第几位？	最好的那个文档排得够不够靠前？
NDCG (Normalized DCG)	考虑排序位置的加权命中率	既有"对不对"也有"位置好不好"
Hit Rate	是否至少命中一个相关文档？	最宽松的指标

RAG 检索的典型矛盾

• 高 Recall 低 Precision：检索了 50 篇文档回来，5 篇相关，45 篇噪声。结果：LLM 被无关上下文干扰，生成质量下降。
• 低 Recall 高 Precision：检索了 3 篇文档，篇篇相关，但遗漏了 7 篇关键信息。结果：回答不完整，出现幻觉。

最佳实践：

1. 先用 Recall@K 确定 K 至少取多大——确保关键文档不会丢
2. 再用 Precision@K 确定 K 最大取多大——确保噪声不会太多
3. 用 NDCG 微调排序模型——确保最相关的排最前面
4. 最终用端到端的生成质量评估——检索指标≠用户体验

环节二：生成阶段

指标	衡量什么	局限性
Faithfulness (忠实度)	生成内容是否基于检索到的文档？	需要人工标注或用 LLM-as-Judge
Answer Relevance	回答是否回答了用户的问题？	主观性强
Context Relevance	检索到的文档是否与问题相关？	只衡量检索，不衡量生成
Hallucination Rate	生成内容中有多少是编造的？	定义和检测本身就很困难

---

3.2 Function Calling / Tool Use / Skills

当 LLM 不只是生成文本，而是需要选择正确的工具、传递正确的参数、解释返回结果时，评估维度更加复杂：

场景：多工具选择

用户: "帮我把上周五的会议纪要发给张三"
系统: 应选择 [文件搜索] + [邮件发送] 两个工具

指标	含义	示例
Tool Selection Precision	选中的工具中有多少是正确的？	选了 3 个工具，2 个正确 → 0.67
Tool Selection Recall	应该选的工具选了多少？	应该选 2 个，选了 2 个 → 1.0
Tool Selection F1	工具选择的综合质量	调和平均

场景：参数提取

用户: "帮我订一张明天下午从北京到上海的机票"
系统: 应提取 {出发地: 北京, 目的地: 上海, 时间: 明天下午, 类型: 机票}

指标	含义
Slot Precision	提取的槽位中有多少是正确的？
Slot Recall	应该提取的槽位提取了多少？
Slot F1	槽位填充的综合质量
Exact Match Accuracy	所有槽位全部正确才算对（最严格）

场景：端到端任务成功率

指标	定义	适用场景
Task Success Rate	用户意图是否被完整满足？	最终衡量标准
Tool Call Correctness	工具调用（名称+参数）是否完全正确？	中间步骤衡量
Error Recovery Rate	工具返回错误后能否纠正？	鲁棒性衡量

---

3.3 文本生成质量评估

这是 LLM 最核心也最难评估的场景。

传统指标（参考对比）

指标	原理	局限
BLEU	N-gram 与参考文本的重合度	只看表面匹配，不懂语义
ROUGE-L	最长公共子序列的召回率	依然是表面匹配
BERTScore	用 BERT Embedding 算语义相似度	需要参考文本
METEOR	考虑同义词和词形变化的匹配	覆盖有限

LLM-as-Judge（模型评分）

用另一个更强的 LLM 来评估输出质量：

维度	评估方式	关键 Prompt 设计
相关性	1-5 分打分	“回答是否直接且完整地回应了用户的问题？”
准确性	逐句核查	“逐句核查回答中每一句事实陈述是否与参考材料一致”
流畅度	1-5 分打分	“回答的语言表达是否自然、流畅、无语法错误？”
有用性	对比排序	“两个回答中，哪个对用户更有帮助？为什么？”

LLM-as-Judge 的注意事项：

• 存在位置偏差（position bias）：倾向于认为排前面的回答更好
• 存在长度偏差（verbosity bias）：倾向于认为更长的回答更好
• 解决方案：双向评估、长度控制、多次采样取平均

---

3.4 安全与对齐评估

指标	含义
拒绝率 (Refusal Rate)	对有害请求的拒绝比例（越高越好）
过度拒绝率 (Over-Refusal Rate)	对无害请求的错误拒绝（越低越好）
有害输出率	对有害请求的违规响应比例（越低越好）
毒性分数	生成内容的毒性水平

这里的评估涉及 Precision-Recall 权衡的经典困境：

高 Precision 低 Recall → 很多有害请求被拒绝，但也误拒了无害请求（过度审查）
低 Precision 高 Recall → 有害请求几乎全被拦住，但过于宽松的定义导致大量误报

---

四、一个完整的评估体系设计

以 RAG + Function Calling 的客服机器人 为例，完整的评估体系应该是分层的：

关键设计原则：

1. 从下往上建设：先确保检索准了，再确保工具调用对了，再评估对话体验
2. 离线和在线结合：离线跑 Benchmark 看指标趋势，在线抽检看真实用户体验
3. 单一数字原则：每个维度有一个主指标（通常是 F1 或 Success Rate），辅助指标用于诊断
4. 红线指标：某些指标低于阈值直接阻止上线（如幻觉率 > 5%、有害输出率 > 0.1%）

---

五、常见误区

误区一：只看一个指标

“我们的模型准确率 95%！”

但 Recall 可能只有 30%——意味着模型对大多数正例选择了沉默。这不是好模型，这是懒惰模型。

误区二：不知道指标的业务含义

“F1 提高了 2 个百分点”

这个提升对你的用户意味着什么？如果一个 RAG 系统的 Recall@10 从 0.85 提升到 0.87，意味着每 100 个问题中多找到了 2 个相关文档，这可能意味着少发生 2 次幻觉——这个影响可能很大也可能微乎其微，取决于业务场景。

误区三：过度依赖 LLM-as-Judge

LLM 法官也有偏见。关键在于：

• 用多个独立的 Judge 交叉验证
• 与人工标注定期校准
• 看的是相对比较（A vs B）而不是绝对分数

误区四：测试集与线上分布不一致

你精心构造的 1000 条测试用例，可能和真实用户的提问方式完全不同。线上用户会说"那个啥，就是上次那个"，而你的测试集是"请查询 2024 年 3 月 15 日的订单状态"。

解决方案：定期从线上日志中抽样、标注，保持测试集的"新鲜度"。

---

六、实战工具箱

RAG 评估

工具	特点
RAGAS	专为 RAG 设计，支持 faithfulness、answer relevancy、context precision/recall
TruLens	可观测性 + 评估一体化，支持 RAG 三元组评估
LangSmith	LangChain 生态的评估平台，适合链路追踪 + 人工标注
DeepEval	开源、指标丰富、支持 CI/CD 集成

通用 LLM 评估

工具 / 框架	特点
lm-evaluation-harness (EleutherAI)	学术界标准 Benchmark 框架
HELM (Stanford)	多维度的标准化评估
Chatbot Arena (LMSYS)	众包 + Elo 排名的真实人类偏好
Promptfoo	开发者友好的 Prompt 评估工具，适合快速 A/B 测试

---

七、总结

你想知道什么？	用什么指标？
模型说"Yes"的东西靠不靠谱？	Precision
该找的东西找全了吗？	Recall
两者都要平衡？	F1 (F-beta)
检索结果的排序好不好？	NDCG / MRR
RAG 生成的东西有没有编？	Faithfulness
工具选对了吗？	Tool Selection F1
用户最终满意吗？	Task Success Rate / NPS