考察点
这道题筛掉的是「凭感觉调 RAG」的人。面试官想看你有没有建立过分层评估体系：检索层和生成层分别用什么指标、评测集从哪来、改动怎么归因、LLM-as-judge 靠不靠谱。能讲清 baseline 和消融实验的，说明真的做过迭代，而不是搭了个 demo。
参考答案
分层评估：先把问题定位到层
RAG 的效果要拆成两层分别度量，混在一起看端到端指标，出了问题根本不知道该修哪。
检索层指标：Recall@K（或叫 hit rate，标准答案所在文档是否进了召回 top-K）是最核心的，召回漏了后面全白搭；MRR（第一个相关文档排第几的倒数均值）和 nDCG 衡量排序质量，主要用来评 rerank。这层指标全自动可算，不需要 LLM 参与。
生成层指标：忠实度（faithfulness，答案是否严格基于检索到的资料，有没有幻觉）、答案相关性（answer relevance，有没有答非所问）、答案正确性（和标准答案比对）。前两个可以让 GPT-4 级别的模型做 judge 自动评，正确性涉及事实比对，自动评的噪声大，重要场景要人工抽检。RAGAS、TruLens 这类框架把这几项都封装好了，但指标定义要自己看懂，别当黑盒用。
评测集怎么构造
质量排序非常明确：真实用户日志 > 人工出题 > LLM 生成。
最有价值的是线上日志里用户真实问过的问题，分布就是真实分布。没上线之前，让业务方或自己模拟用户视角出几十上百个问题。LLM 批量生成问题可以补量，但有两个坑要防：一是生成的问题偏简单、偏「文章里直接写着答案」的类型，测不出系统真实短板；二是问题分布会偏向生成模型的偏好，和真实用户差距大。LLM 生成的题目必须人工筛一遍。
规模上，几十到几百条精标远比几千条噪声标注有用。每条样本标三样东西：问题、相关文档（用来算检索指标）、标准答案或答案必须覆盖的关键要点（用来评生成）。标注时顺手给问题打个类型标签（事实型、多文档推理型、拒答型），后面分析 badcase 好用。别忘了加一批「知识库里没有答案」的问题，专门测拒答能力，幻觉问题一大半在这类 query 上暴露。
Baseline 是什么
Baseline 至少三条线。第一条是不挂 RAG 直接问 LLM，回答「RAG 到底带来了多少增益」，这条线在老板面前尤其有用。第二条是最简实现：单一向量召回加默认 prompt，作为一切优化的起点。第三条是逐级消融：加混合召回涨多少、加 rerank 涨多少、换 embedding 涨多少——每次只动一个变量，指标变化才能归因。没有消融，改了三处发现效果好了，你不知道是哪处起的作用，下次回退都不知道回退什么。
LLM-as-judge 的可信度
自动评分是规模化评估的唯一办法，但要管理它的偏差：judge 模型偏爱长答案、偏爱自己风格的表达（用 GPT-4 评 GPT-4 生成的答案会系统性偏高）。工程对策：评分 prompt 里给明确的打分 rubric 和 few-shot；定期用人工标注和 judge 打分算一致率，一致率低就先修 judge 再信指标；对比实验用同一个 judge，绝对值不准没关系，相对排序稳定就够用。
闭环：评测集是活的
上线后把 badcase（用户点踩、人工抽检发现的错误）持续回流进评测集，每次改动跑回归防止顾此失彼。评测集只增不改，改了就无法纵向对比。同时要警惕对评测集过拟合：调参全在这几百条上试，时间长了就是在 hack 评测集，定期换一批新样本校准。
可能的追问
- 检索指标好但端到端答案差，怎么定位？答：这正是分层评估的价值——Recall@K 高说明检索没问题，去看生成层：抽查上下文里相关 chunk 是否被正确引用，是 prompt 约束问题、上下文组装问题（lost in the middle）还是模型能力问题，逐个排查。
- 评测集多大够用？答：看你要检测多小的效果差异。50 条能发现大的翻车，要区分 3-5 个点的指标差异通常需要两三百条以上，统计显著性要有概念。
- 没有标准答案的开放问题怎么评？答：退而求其次评忠实度和相关性，加上人工抽样评有用性；也可以让 judge 模型对比两个版本的答案做 pairwise 排序，pairwise 比绝对打分稳定。