How do you evaluate the best LLM model for your use case
1️⃣ 考察意图
面试官想考察你系统化评估 LLM 的工程方法论，而非背几个 benchmark 分数。刁钻点在于：候选人常陷入“只看 MMLU 分数”或“只跑一个 demo”的陷阱，而实际业务需要权衡任务性能、成本、延迟、安全性四个维度。答好了能展示你从“模型评测”到“模型选型”的完整决策能力，包括如何设计自定义测试集、如何做 A/B 测试、如何应对部署约束。这是区分“调 API 选手”和“工程落地选手”的关键题。
2️⃣ 标准答
评估 LLM 选型，我按四步法走：明确业务目标、设计评估维度、选择评估方法、迭代验证。
第一步：明确业务目标与约束
- 任务类型：是问答（客服）、摘要（文档）、代码生成（IDE 插件）还是对话（聊天机器人）？不同任务对模型能力要求不同。例如客服场景更看重指令遵循和安全性，代码场景更看重语法正确性和上下文长度。
- 部署约束：延迟（<500ms 还是可接受 2s？）、吞吐量（QPS 要求？）、硬件（A100 还是 T4？）、成本（每百万 token 预算？）。这些直接决定模型大小和量化方案。
第二步：设计评估维度（至少 4 个）
- 任务性能：用自定义测试集（100-500 条业务样本）替代纯公开 benchmark。例如客服场景，构造包含“多轮对话”、“歧义问题”、“敏感内容”的测试集。指标用准确率（分类任务）、ROUGE-L（摘要）、BLEU（翻译），但注意这些自动指标与人类判断相关性低（【通用知识】ROUGE 对同义词不敏感）。
- 安全性：用红队测试（Red Teaming）和有害内容检测（如 OpenAI Moderation API）。记录模型拒绝率（refusal rate）和有害输出比例。例如金融场景，模型不能给出投资建议。
- 效率：测量首 token 延迟（TTFT）、生成吞吐量（tokens/s）、峰值显存。用 vLLM 或 TensorRT-LLM 做推理优化后对比。例如 Llama-2-7B 在 T4 上 FP16 推理，TTFT 约 200ms，吞吐量约 50 tokens/s。
- 成本：计算每千次请求成本（API 调用费 + 硬件折旧）。例如 GPT-4 比 Llama-3-70B 贵 10 倍，但性能可能只高 5%。
第三步：选择评估方法
- 公开基准：MMLU（知识）、HellaSwag（常识推理）、GSM8K（数学）、HumanEval（代码）。但必须结合自定义测试集，因为公开基准可能过拟合（【通用知识】某些模型在 MMLU 上刷分但业务场景表现差）。
- 自动评估：用 LLM-as-a-Judge（如 GPT-4 打分）或 BLEURT（语义相似度）。注意 LLM-as-a-Judge 有位置偏差（更喜欢第一个答案）和长度偏差（更喜欢长答案），需做校准（如用 pairwise 对比替代打分）。
- 人工评估：对关键场景（如客服回复质量）做盲测 A/B 测试，让标注员按 1-5 分打分。样本量至少 100 条，计算Cohen’s Kappa 确保标注一致性。
第四步：迭代验证
- 离线评估：在测试集上跑完所有指标，输出综合评分表（加权平均，例如性能 50%、安全性 20%、效率 20%、成本 10%）。
- 在线评估：用 A/B 测试（如 10% 流量切到新模型）监控用户满意度（点赞/点踩率）、任务完成率、错误率。例如客服场景，对比 GPT-4 和 Llama-3-70B 的首次解决率。
- 实际落地的坑：模型在测试集上表现好，但上线后因分布偏移（用户输入风格不同）导致性能下降。解法：持续监控并定期用新数据微调模型，或做在线学习（如用用户反馈做 RLHF）。
总结一句：评估 LLM 不是跑一个 benchmark，而是设计一套可复现的评估 pipeline，覆盖性能、安全、效率、成本，并用离线+在线验证确保业务价值。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从四个层面回答：第一，明确业务目标与部署约束，比如客服场景要求延迟<500ms；第二，设计评估维度，包括任务性能（用自定义测试集）、安全性（红队测试）、效率（TTFT/吞吐量）、成本；第三，选择评估方法，结合公开基准（MMLU）和 LLM-as-a-Judge，但必须校准偏差；第四，迭代验证，用离线测试+在线 A/B 测试。总结一句：评估 LLM 是系统工程，不是单一指标能决定的。”
4️⃣ 高频追问 & 应对
追问 1：你如何设计自定义测试集？样本量多少？
按业务场景分层抽样。例如客服场景：正常问题 60%、歧义问题 20%（如“退款流程”）、敏感问题 10%（如“如何逃税”）、多轮对话 10%。样本量至少 100 条，但建议 300-500 条以保证统计显著性。用主动学习（Active Learning）从线上日志中挑选低置信度样本，减少标注成本。注意测试集要定期更新（如每月一次）以对抗分布偏移。
追问 2：LLM-as-a-Judge 有偏差，你怎么处理？
用pairwise 对比替代打分，让 Judge 模型选“哪个更好”，减少长度偏差。同时做位置随机化（交换 A/B 顺序）并取平均。如果 Judge 模型本身有偏好（如 GPT-4 更喜欢自己的输出），用校准集（人工标注的 50 条对比数据）调整 Judge 的权重。最后，对关键场景（如客服回复）必须辅以人工评估，不能完全依赖自动 Judge。
追问 3：如果预算有限，只能选一个开源模型，你怎么选？
先做轻量级筛选：在 50 条样本上跑所有候选模型（如 Llama-3-8B、Mistral-7B、Qwen-7B），用自动指标（ROUGE、BLEU）快速过滤掉明显差的。然后对 top-3 模型做全量评估（300 条样本 + 人工评估）。最后考虑部署约束：如果硬件是 T4，选量化后的 7B 模型（如 Llama-3-8B 4-bit），牺牲 5% 性能换 2 倍吞吐量。如果预算允许，用模型蒸馏（Distillation）从大模型（如 GPT-4）生成训练数据，微调小模型。
5️⃣ 避坑 · 常见错误答法
- ❌ “我只看 MMLU 分数，分数高的模型就是最好的。” → ✅ “MMLU 只是知识基准，不能反映业务场景的指令遵循和安全性。必须结合自定义测试集，例如客服场景需要测试多轮对话和敏感内容处理。”
- ❌ “我跑一个 demo 觉得不错就上线了。” → ✅ “Demo 表现好不代表线上稳定。必须做离线评估（自定义测试集）和在线 A/B 测试（监控用户满意度），并考虑分布偏移问题。”
- ❌ “我用 GPT-4 做 Judge 打分，结果很准。” → ✅ “LLM-as-a-Judge 有位置偏差和长度偏差，必须做校准（pairwise 对比 + 位置随机化），且对关键场景辅以人工评估。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索质量 vs 生成质量”角度切入，说明如何评估 RAG 管道的整体效果（如用 Correctness、Faithfulness 指标），并对比不同 LLM 作为生成器的表现。
- 如果你只做过传统 NLP：用“分类模型评估”类比，说明从准确率/召回率到 LLM 评估的迁移（如用 BLEU 替代 F1），并强调 LLM 评估需要额外关注安全性和成本。
- 如果你是校招无项目：聚焦“公开基准 + 自定义测试集”的论文复现，例如复现 MMLU 评测代码，并设计一个简单的客服测试集（10 条样本），展示你对评估 pipeline 的理解。
- 《Evaluating Large Language Models: A Survey》（2023）
- 《MMLU: Measuring Massive Multitask Language Understanding》（2020）
- 《LLM-as-a-Judge: A Survey of Evaluation Methods》（2024）
- 《Red Teaming Language Models with Language Models》（2022）
- 《A/B Testing for LLM-based Systems: Best Practices》（2024）