How do you evaluate the performance of a fine-tuned LLM
1️⃣ 考察意图
面试官想看你是否具备“整条链路评估思维”，而非只盯着单一指标。这道题考察类型是系统设计 + 工程取舍，刁钻点在于：微调后模型可能“偏科”——任务指标涨了，但通用能力崩了（灾难性遗忘），或推理变慢、鲁棒性下降。答好了能展示你对评估体系设计的硬实力：能平衡任务性能、通用保持、成本与部署风险，并给出可落地的量化方案。
2️⃣ 标准答
评估微调后的 LLM 必须从 5 个维度 构建体系，缺一不可：
- 任务特定指标（Task-Specific Metrics）
- 分类/抽取任务：用准确率、F1、精确率/召回率。例如微调一个情感分类模型，在 SST-2 上算 F1，注意类别不平衡时用 macro-F1 而非 micro。
- 生成任务：用 ROUGE（摘要）、BLEU（翻译）、METEOR（语义匹配）。但坑：这些指标与人类判断相关性低（ROUGE 对同义词不敏感）。解法：同时用 BERTScore（基于 embedding 的语义相似度）或 COMET（翻译质量）作为辅助。
- 对话/指令跟随：用 GPT-4 作为评判器（LLM-as-Judge），对响应进行 1-5 分打分（参考 MT-Bench 协议）。工程取舍：GPT-4 评判有偏见（偏好长回答），需做位置偏差校正——交换候选顺序取平均分。
- 通用能力保持（Catastrophic Forgetting Check）
- 微调后必须跑通用基准：MMLU（知识推理）、HellaSwag（常识）、GSM8K（数学）、HumanEval（代码）。关键：对比微调前后的分数差，若下降 >5% 则需调整训练策略（如混合通用数据或加 LoRA 约束）。
- 实际坑：MMLU 有 57 个子任务，微调后可能某些子任务崩了（如法律知识）。解法：按子任务粒度分析，而非只看总分。
- 人工评估（Human Evaluation）
- A/B 测试：让标注员盲评微调前后模型的输出（偏好率）。样本量：至少 100 条，每条由 3 人标注，计算 Fleiss‘s Kappa 确保一致性 >0.6。
- 评分标准：用 Likert 5 分制（准确性、流畅性、安全性）。坑：标注员疲劳导致评分漂移。解法：每 20 条插入黄金标准样本（已知正确输出），剔除评分偏差 >1 分的标注员。
- 鲁棒性与安全性（Robustness & Safety）
- 对抗样本：对输入做微小扰动（如同义词替换、拼写错误），看输出是否稳定。例如用 TextAttack 库生成对抗样本，计算准确率下降幅度。
- 分布外（OOD）测试：用与训练集不同分布的测试集（如医疗模型用法律文本）。工程取舍：OOD 测试成本高，优先覆盖高风险的边缘场景（如敏感词、长尾实体）。
- 安全评估：用 Toxicity（Detoxify 模型）和 Bias（WinoBias）检测微调后是否引入偏见。实际案例：微调客服模型后，发现对“退款”类请求回复变长但更易激怒用户，需加安全护栏。
- 效率与成本（Efficiency & Cost）
- 推理速度：测量 tokens/s（吞吐量）和首 token 延迟（TTFT）。微调后若模型变大（如全量微调 vs LoRA），速度可能下降 30-50%。
- 显存占用：用
torch.cuda.max_memory_allocated记录峰值。取舍：若用 LoRA，显存节省 70%，但任务性能可能差 1-2%。 - 成本：计算每 1000 次推理的 API 成本（若部署）或 GPU 小时数。建议：设定一个“性价比阈值”——性能提升 <5% 但成本翻倍，则放弃微调。
总结：评估不是跑一个指标，而是设计一个多维度矩阵，每个维度有阈值（如 MMLU 下降 <3%、人工偏好率 >60%、推理速度 >50 tokens/s），任何一项不达标则回滚或调整。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，任务指标，用 ROUGE/BERTScore 评估生成质量，用 GPT-4 做 LLM-as-Judge 并校正位置偏差；第二，通用保持，跑 MMLU 和 HellaSwag 检测灾难性遗忘，按子任务粒度分析；第三，鲁棒性与成本，用对抗样本和 OOD 测试，同时监控推理速度和显存。总结一句：评估体系必须包含任务性能、通用能力、人工偏好、安全性和效率，任何一项短板都可能导致上线失败。”
4️⃣ 高频追问 & 应对
追问 1：如果人工评估和自动指标（如 ROUGE）结果冲突，你信哪个？
信人工评估，但需要分析冲突原因。首先，检查 ROUGE 是否对同义词不敏感（例如“购买”vs“买”），此时用 BERTScore 或 BLEURT 做二次验证。其次，看人工评分的一致性（Fleiss’s Kappa），若 <0.4 则标注员不可靠，需重新培训。最后，若人工偏好微调后模型但 ROUGE 下降，说明微调改变了输出风格（如更简洁），此时应接受人工结果，但需补充安全性测试。
追问 2：微调后 MMLU 下降了 8%，但任务指标涨了 15%，你怎么决策？
优先解决灾难性遗忘。方案：1）混合训练：在微调数据中混入 20% 通用数据（如 MMLU 训练集），用 LoRA 约束参数更新幅度（rank=8）。2）知识蒸馏：用原始模型作为教师，微调模型作为学生，在通用数据上做 KL 散度损失。3）回滚阈值：若 MMLU 下降 >5% 且任务提升 <20%，则放弃微调，改用 prompt engineering 或 RAG。实际案例：微调代码模型时，HumanEval 涨 10% 但 MMLU 掉 6%，最终用 LoRA + 10% 通用数据混合，MMLU 只掉 2%。
追问 3：如何设计一个低成本的评估流程，避免每次都跑全量基准？
用分层抽样和代理指标。1）分层抽样：从 MMLU 的 57 个子任务中随机选 10 个（覆盖知识、推理、数学），每个子任务抽 20 条，总样本 200 条，误差控制在 ±3%。2）代理指标：用 Perplexity 作为通用能力代理——若微调后 perplexity 在通用语料上上升 >10%，则大概率有遗忘，再跑全量 MMLU。3）增量评估：每次微调只跑与上次差异最大的子任务（如上次法律子任务掉 10%，这次优先测它）。成本可降低 80%。
5️⃣ 避坑 · 常见错误答法
- ❌ “我只看 BLEU 和 ROUGE，够了。” → ✅ “BLEU/ROUGE 是基础，但必须配合 BERTScore 或人工评估，因为生成任务中语义等价但词汇不同时，这些指标会误判。”
- ❌ “微调后跑一次 MMLU 就行。” → ✅ “MMLU 要按子任务粒度分析，并对比微调前后分数差；同时需要跑 HellaSwag 和 GSM8K 覆盖不同能力维度。”
- ❌ “人工评估找 5 个人随便打分。” → ✅ “人工评估需要标准化流程：黄金样本校准、Fleiss’s Kappa 一致性检验、至少 100 条样本，否则结果不可信。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“评估检索增强 vs 微调”切入，强调微调后模型在 OOD 数据上的鲁棒性测试（如用不同来源的文档做 RAG 评估）。
- 如果你只做过传统 NLP：用“分类任务 F1 与生成任务 ROUGE 的差异”类比，说明评估体系需要从单一指标扩展到多维度（如传统模型只测准确率，LLM 需加安全与效率）。
- 如果你是校招无项目：聚焦“论文复现”——描述如何用 MT-Bench 和 AlpacaEval 评估微调后的 LLaMA 模型，并手动分析 50 条输出中的错误模式（如幻觉、重复）。
- 《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》（Zheng et al., 2023）
- 《LoRA: Low-Rank Adaptation of Large Language Models》（Hu et al., 2021）
- 《BERTScore: Evaluating Text Generation with BERT》（Zhang et al., 2020）
- 《MMLU: Measuring Massive Multitask Language Understanding》（Hendrycks et al., 2021）
- 《Evaluating Large Language Models: A Comprehensive Survey》（Chang et al., 2024）