Llama-Factory的eval模块详解：准确率、困惑度等指标一览
Llama-Factory的eval模块详解：准确率、困惑度等指标一览
在大语言模型（LLM）快速迭代的今天，微调已不再是少数研究团队的专属技术。越来越多的企业和开发者希望基于开源模型定制自己的智能应用——从金融客服到医疗问答，从教育辅导到内容生成。然而，一个常被忽视的问题是：我们如何科学地判断一个微调后的模型真的“变好了”？
答案并不总是显而易见。你可能训练了几十个epoch，loss曲线一路下降，但最终生成的回答却越来越模板化；或者准确率高达90%，但在真实场景中仍然频繁出错。这些问题的背后，是对评估环节的轻视。
正是在这样的背景下，Llama-Factory 的 eval 模块显得尤为关键。它不仅仅是一个“跑个测试集出个分数”的工具，而是将模型评估系统化、标准化、自动化的关键组件。通过统一接口支持多种任务与指标，它让不同模型、不同训练策略之间的比较成为可能，也让实验结果更具可复现性。
准确率：简单却不容小觑的基础指标
说到评估，最直观的指标莫过于准确率（Accuracy）。它的定义极其朴素：预测正确的样本数占总样本的比例。公式也简洁明了：
$$
\text{Accuracy} = \frac{\text{Number of Correct Predictions}}{\text{Total Number of Samples}}
$$
这使得它成为分类任务中的首选指标，尤其是在指令微调或选择题类任务中表现突出。比如在 MMLU 或 C-Eval 这类基准测试中，准确率几乎是衡量模型知识掌握程度的“硬通货”。
但在实际使用中，有几个细节值得特别注意：
- 标签格式一致性：模型输出可能是
" A "，而真实标签是"A"，一个空格就能导致误判。因此，在计算前必须做标准化处理。 - 结构化提取问题：对于开放式生成，模型可能会回答：“根据选项，我认为正确答案是 B。” 此时需要借助正则表达式或其他规则从中抽取出
"B"才能参与比对。 - 类别不平衡陷阱：如果数据集中80%的答案都是“A”，那么即使模型只会答“A”，也能获得80%的准确率。这时候高分反而具有误导性。
Llama-Factory 的 eval 模块通过内置的 Evaluator 类封装了这些逻辑。你可以直接传入测试集路径和模型 checkpoint，框架会自动完成数据加载、推理、解码、匹配和统计全过程。
from sklearn.metrics import accuracy_score true_labels = ["A", "B", "C", "A", "D"] pred_labels = ["A", "B", "B", "A", "C"] acc = accuracy_score(true_labels, pred_labels) print(f"Accuracy: {acc:.4f}") # 输出: Accuracy: 0.6000 这段代码虽短，却是整个评估流程的核心缩影。在 Llama-Factory 内部，类似的逻辑被进一步增强以支持批量处理、多GPU推理以及异常值过滤。
⚠️ 实践建议：
对于意图识别、多项选择等任务，准确率足够有效；但对于开放生成任务（如摘要、对话），应结合其他指标综合判断。
困惑度：无监督下的语言质量探针
如果说准确率是“看得见”的评估，那困惑度（Perplexity, PPL） 就更像是模型内部语言能力的“体检报告”。它不需要人工标注，仅凭原始文本即可评估模型对语言分布的拟合程度。
其数学本质来源于交叉熵损失：
$$
\text{PPL} = \exp\left(\frac{1}{N}\sum_{i=1}^{N} -\log P(w_i | w_{<i})\right)
$$
简单来说，困惑度衡量的是模型在给定上下文下预测下一个词的“不确定性”。数值越低，说明模型越自信、越流畅。一般情况下，预训练模型在标准语料（如 WikiText）上的 PPL 在 10~20 之间；若微调后上升至 30 以上，则很可能出现了过拟合或灾难性遗忘。
在 Llama-Factory 中，eval 模块利用 DataLoader 加载纯文本数据，逐 token 计算负对数似然，并最终取指数得到 PPL 值。整个过程无需修改模型结构，也不依赖任何外部标签。
import torch import torch.nn as nn def calculate_perplexity(model, dataloader, device): model.eval() total_loss = 0 total_tokens = 0 criterion = nn.CrossEntropyLoss() with torch.no_grad(): for batch in dataloader: input_ids = batch['input_ids'].to(device) labels = batch['labels'].to(device) outputs = model(input_ids=input_ids, labels=labels) loss = outputs.loss total_loss += loss.item() * input_ids.size(0) total_tokens += input_ids.numel() avg_nll = total_loss / len(dataloader.dataset) perplexity = torch.exp(torch.tensor(avg_nll)) return perplexity.item() 这个函数虽然模拟的是基础逻辑，但在实际框架中还会加入更多工程优化：
- 支持长序列分块处理，避免 OOM；
- 使用 KV Cache 缓存注意力键值，提升推理效率；
- 自动对齐 input_ids 与 labels（通常 labels 是 input_ids 向左移动一位）；
值得注意的是，PPL 对局部错误非常敏感。哪怕只有一个词被赋予极低概率，整体得分也可能大幅上升。因此，建议在目标任务相关语料上单独测试，而非通用语料。
⚠️ 实践建议：
- 推荐用于预训练阶段监控或 QLoRA 微调后的语言流畅性验证；
- 不适用于指令遵循能力评估，因其不涉及任务理解。
BLEU 与 ROUGE：生成任务的双面镜像
当进入真正的文本生成领域——比如机器翻译、摘要生成、指令响应——我们就不能再依赖简单的匹配或概率指标了。这时，BLEU 和 ROUGE 成为了行业标配。
BLEU：精确率导向的翻译评价者
BLEU 最初为机器翻译设计，核心思想是通过 n-gram 精确率来衡量生成文本与参考译文的相似度。它计算 1~4 gram 的加权几何平均，并引入短句惩罚因子（Brevity Penalty, BP） 防止模型通过输出极短句子刷分。
$$
\text{BLEU} = BP \cdot \exp\left(\sum_{n=1}^N w_n \log p_n\right)
$$
尽管近年来受到一些批评（例如无法捕捉语义等价但词汇不同的情况），但由于其实现简单、计算高效，仍是许多自动化流水线中的首选。
ROUGE：召回率驱动的内容覆盖检测器
相比之下，ROUGE 更关注“有没有说全”，即生成文本是否覆盖了参考文本的关键信息。常见的有：
- ROUGE-N：基于 n-gram 共现次数；
- ROUGE-L：基于最长公共子序列（LCS），更能反映句子级语义连贯性。
$$
\text{ROUGE-L} = \frac{(1+\beta^2)R_lP_l}{\beta^2R_l + P_l}
$$
其中 $ R_l $ 是 LCS 的召回率，$ P_l $ 是精确率，$ \beta $ 控制两者权重。
两者各有侧重：
| 特性 | BLEU | ROUGE |
|------|------|--------|
| 侧重点 | 精确率为主 | 召回率为主 |
| 适用任务 | 翻译、指令响应 | 摘要、归纳 |
| 是否需多个参考 | 推荐 | 否 |
在 Llama-Factory 中，这两个指标都通过集成 nltk 和 py-rouge 实现，并支持批量输入与多参考答案处理。
from nltk.translate.bleu_score import sentence_bleu, SmoothingFunction from rouge import Rouge # BLEU 示例 reference = [["the", "cat", "is", "on", "the", "mat"]] candidate = ["the", "cat", "is", "on", "the", "mat"] smoothie = SmoothingFunction().method4 bleu_score = sentence_bleu(reference, candidate, smoothing_function=smoothie) print(f"BLEU Score: {bleu_score:.4f}") # ROUGE 示例 rouge = Rouge() hyp = "China launched a new space mission yesterday." ref = "Yesterday, China sent a spacecraft into orbit." scores = rouge.get_scores(hyp, ref) print("ROUGE Scores:", scores[0]) 这套组合拳能有效替代部分人工评审工作，尤其适合集成进 CI/CD 流程进行持续评估。
⚠️ 实践建议：
- BLEU 对词序敏感，不适合创意写作类任务；
- ROUGE-L 能反映语义连贯性，但仍难以识别事实错误；
- 强烈建议结合多个指标 + 人工抽查，形成闭环反馈。
从流程到架构：eval模块如何嵌入真实项目
在 Llama-Factory 的整体架构中，eval 模块位于训练流水线末端，处于“模型训练 → 模型评估 → 模型部署”链条的关键节点。其系统位置如下：
[数据预处理] → [模型训练] → [eval模块] → [模型部署] ↑ ↓ [配置文件] [评估报告] 它的工作流程可以分为三个阶段：
- 准备阶段
用户指定模型路径（如output/lora-qwen-7b-chat/epoch-3）、测试数据集（支持 JSONL、CSV）及评估参数（任务类型、batch size、max length 等）。 - 执行阶段
- 自动加载模型与 tokenizer；
- 根据任务类型选择评估模式（分类 or 生成）；
- 并行处理样本，调用模型生成输出；
- 解析输出并与参考答案比对；
- 计算各项指标并缓存中间结果。 - 输出阶段
- 生成结构化评估报告（JSON/TXT）；
- 可选导出详细预测结果供人工抽查；
- WebUI 实时更新图表（如 epoch-wise 准确率曲线）。
这一整套机制解决了多个现实痛点：
| 痛点 | 解决方案 |
|---|---|
| 缺乏统一评估标准 | 提供标准化接口，确保结果可比性 |
| 不同模型脚本不兼容 | 自动适配各类 tokenizer 与模型结构 |
| 手动评估效率低下 | 支持批量处理与 GPU 加速推理 |
| 结果难以追溯 | 输出完整日志与配置快照，保障可复现 |
举个例子，在某金融客服机器人项目中，团队使用 LoRA 微调 Baichuan-13B 模型后，通过 eval 模块在内部 FAQ 测试集上测得准确率达 92.3%，同时困惑度低于 8.5。这不仅确认了模型具备良好的判别能力，也验证了其语言流畅性未因微调受损，从而顺利进入上线阶段。
设计背后的考量：不只是“跑个分”
真正优秀的评估系统，从来不是简单地输出几个数字。Llama-Factory 的 eval 模块在设计时充分考虑了实用性与扩展性：
- 数据划分合理性：强调测试集独立于训练集，推荐按领域或时间切分，防止信息泄露；
- 评估频率控制：大型模型不必每轮都评估，可在最后几轮集中测试，节省资源；
- 多指标联合分析：单一指标容易产生偏差，应结合 Acc + PPL + ROUGE 综合判断；
- 硬件资源优化：支持多 GPU 分布式评估（通过
device_map设置），启用 KV Cache 提升推理速度； - 半精度推理支持：可通过
half_precision=True减少显存占用，加快评估速度。
这些细节决定了该模块能否真正服务于大规模生产环境，而不是停留在实验室演示阶段。
这种高度集成的设计思路，正引领着大模型应用向更可靠、更高效的方向演进。未来随着更多细粒度评估方法（如事实一致性检测、毒性识别、偏见分析）的引入，eval 模块有望成长为一个真正的“模型质量守护者”，帮助我们从“能用”走向“好用”。
