效果怎么评估的
P0 · evaluation · 🏢 字节
1️⃣ 考察意图
面试官真正想看的是：候选人是否真正落地过RAG系统，而非停留在“跑通demo”阶段。这道题看似基础，但“还不错”三个字是雷区——它暴露了缺乏量化评估的工程习惯。考察类型是工程取舍+debug，刁钻点在于：面试官会追问“你用了哪些指标？为什么选这个？数据怎么来的？有没有发现过指标和实际体验不一致？”答好了能展示：你懂离线/在线评估体系、能设计评估数据集、会权衡指标成本与效果，这是大厂做搜索/问答系统的硬实力。
2️⃣ 标准答
评估RAG效果不能只靠“感觉”，必须分层量化。我从三个层面回答：检索质量、生成质量、端到端效果，每个层面都有具体指标和落地坑。
1. 检索质量评估
核心指标是召回率和排序精度。我常用：
- Recall@K：前K个检索结果中命中正确答案的比例。K通常取5或10，取决于下游生成模型能处理多少上下文。例如，用BGE-large-zh做embedding，在自建QA数据集上Recall@10达到85%是及格线。
- MRR (Mean Reciprocal Rank)：衡量第一个正确答案的排名。MRR对“第一个结果就正确”的场景敏感，适合知识库问答。我踩过坑：MRR高但Recall低，说明模型只擅长找热门答案，冷门知识全漏了。解法是同时监控两个指标，不能只看一个。
- NDCG@K：考虑排序位置和相关性等级（如0/1/2分），比Recall更精细。但标注成本高，我通常只在A/B测试阶段用。
实际落地的坑：离线指标和线上体验可能背离。比如Recall@10很高，但用户反馈“搜不到”。排查发现：用户query是口语化表达（如“怎么调模型参数”），而知识库是书面语（如“超参数优化方法”）。解法是构建同义query池，用人工改写+LLM生成扩充评估集，覆盖口语化变体。
2. 生成质量评估
生成部分不能只看“通顺”，要关注忠实度和有用性。
- 忠实度 (Faithfulness)：用LLM-as-judge打分，检查生成内容是否基于检索结果，有无幻觉。我常用GPT-4或Qwen2.5-72B做裁判，prompt里明确要求“只根据给定上下文判断，忽略模型自身知识”。坑：裁判模型本身有偏见，比如偏好长回答。解法是人工抽样验证，每100条抽10条人工标注，校准裁判模型。
- 有用性 (Helpfulness)：用BLEU/Rouge-L不合适，因为答案可以多样。我改用Answer Relevance：让裁判模型判断答案是否直接回答用户问题，打分1-5。同时监控冗余度，避免模型重复检索结果。
工程取舍：忠实度和有用性有时冲突。比如用户问“苹果公司市值”，检索结果只有2023年数据，模型若忠实回答“2.8万亿美元”，但用户期望最新值（2024年可能变了）。我选择优先忠实度，并在答案末尾加时间戳和免责声明，避免误导。
3. 端到端效果评估
最终看用户是否满意。线上指标：
- A/B测试：对比有/无RAG的版本，看用户停留时间、点击率、会话轮数。例如，接入RAG后，用户平均会话轮数从2.3提升到3.8，说明用户更愿意追问。
- 人工标注：对线上日志抽样，标注“答案是否解决用户问题”。我按“完全解决/部分解决/未解决”三级标注，每周抽500条，标注一致性用Cohen's Kappa控制>0.7。
实际落地的坑：线上指标提升但用户满意度下降。排查发现：RAG答案太长，用户需要滚动才能看完。解法是答案长度限制+摘要前置，把核心答案放在前50字。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从检索质量、生成质量、端到端效果三个层面回答。检索层用Recall@K和MRR，注意构建同义query池避免口语化漏检；生成层用LLM-as-judge评估忠实度和有用性，人工抽样校准；端到端做A/B测试和人工标注，监控用户停留时间和答案长度。总结一句：评估要分层、指标要互补、数据要覆盖真实场景。”
4️⃣ 高频追问 & 应对
追问 1：你用的评估数据集怎么来的？有没有标注偏差？
评估集来自线上日志+人工构造。线上日志随机采样1000条用户query，人工标注正确答案（从知识库中找）。构造部分：用LLM生成同义query（如“怎么调参”->“如何优化超参数”），再人工校验。标注偏差主要来自标注员主观性，我采用双人标注+仲裁，一致性>0.8。另外，评估集要覆盖长尾query（如拼写错误、中英文混写），否则指标虚高。
追问 2：如果离线指标好但线上效果差，你怎么排查？
先看数据分布差异：离线评估集是否偏向高频query？线上长尾query占比高，但离线没覆盖。解法是线上日志回流，定期更新评估集。再看指标定义：Recall@K只关心命中，不关心排序位置，但线上用户只看前3条。我会加Precision@3作为辅助指标。最后检查生成模型：离线用标准答案评估，但线上用户可能接受不同表述。我会做人工抽样对比，看模型是否过度依赖检索结果。
追问 3：LLM-as-judge的准确率怎么保证？有没有替代方案？
准确率靠prompt工程+人工校准。prompt里给评分标准（如“1分：完全无关；5分：直接回答”），并加few-shot示例。人工校准：每100条抽10条，计算裁判模型和人工标注的Spearman相关系数，低于0.7就调prompt或换裁判模型。替代方案：用BERTScore或BARTScore做无参考评估，但不如LLM-as-judge灵活。如果成本敏感，可以用小模型（如Qwen2.5-7B）蒸馏大模型打分结果。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“效果还不错，用户反馈挺好” → ✅ 必须给出具体指标（如Recall@10=85%，MRR=0.72）和评估方法（离线/在线/人工）。
- ❌ 只提一个指标（如“我用Recall”） → ✅ 至少覆盖检索和生成两个层面，并说明指标互补性（如Recall+MRR避免漏检和排序差）。
- ❌ 忽略评估数据来源，说“用公开数据集” → ✅ 强调自建评估集覆盖真实场景，并说明如何处理标注偏差和长尾query。
6️⃣ 简历呼应
- 如果你有RAG项目：从“我负责搭建评估体系”切入，具体说明用了哪些指标（Recall@K、MRR、忠实度），以及如何发现并解决离线/线上不一致问题（如构建同义query池）。
- 如果你只做过传统NLP：用“搜索排序”类比，说“RAG评估类似信息检索的NDCG，但多了生成质量维度”，并展示你如何迁移BERTScore或BLEU到生成评估。
- 如果你是校招无项目：聚焦论文复现，说“我复现了KILT benchmark的评估流程，用FAISS做检索、BART做生成，计算了Recall@5和F1”，并提到你发现指标和人工判断的差异。
- 《RAGAS: Automated Evaluation of Retrieval Augmented Generation》
- 《Evaluating RAG Systems: A Practical Guide》 (Towards Data Science)
- 《KILT: a Benchmark for Knowledge Intensive Language Tasks》
- 《LLM-as-Judge: A Survey of Large Language Model Evaluation Methods》
- 《BGE Embedding: A Comprehensive Evaluation on Chinese Retrieval Tasks》