考察点
「怎么量化你的回答效果，检索效果、回答效果」是 2026 面经 RAG 部分的原题。这题直接筛掉「改参数靠感觉」的候选人。面试官想看你有分层评测的意识：检索错了怪生成是没意义的，先定位错在哪一层。追问常走「评测集怎么来」「没有标注怎么办」。
参考答案
核心思路：拆开评测，先定位错在哪一层
RAG 的错误有三个来源：检索没召回正确文档、召回了但模型没用对、模型自由发挥幻觉。用一个大而化之的「答案准确率」评测，永远不知道优化该打在哪。所以评测必须分层。
检索层指标
需要一个带标注的评测集：N 条真实 query，每条人工标出「正确文档/chunk 是哪些」。
- Recall@K：正确 chunk 出现在召回 Top-K 中的比例。这是最重要的检索指标，K 取你实际进 Rerank 的条数（如 20）。调切分、换 Embedding、加混合召回，所有召回侧优化都看它。
- MRR（Mean Reciprocal Rank）：正确结果排第几的倒数均值。衡量精排质量，Rerank 优化的目标。
- Top-K 命中率：Rerank 后 Top 3-5 里是否含正确片段，直接决定生成层有没有好原料。
我的项目里这个评测集有 300 条，来自客服真实咨询日志脱敏后人工标注。每次改召回链路，跑一遍五分钟出分，比拍脑袋强太多。
生成层指标
检索对了，答案还可能错。生成层看两个核心指标：
- 忠实度（Faithfulness）：答案里的每个论断能不能在检索到的上下文里找到依据。这是幻觉的直接度量。
- 答案相关性（Answer Relevancy）：答案有没有正面回答用户问题（而不是答非所问）。
自动化评测用 RAGAS 这类框架：让 GPT-4 级别的强模型当裁判，把答案拆成原子论断逐条核对上下文，给出忠实度得分。LLM-as-Judge 不是银弹——裁判模型自己也会错，所以关键决策（上线、大改版）前还要人工抽检：随机抽 50-100 条线上问答，人工标「答案是否正确可用」，这个数是最终的业务指标。
线上指标闭环
离线评测之外，线上要有持续信号：
- 显式反馈：答案下方的赞/踩按钮。踩率高的问题类型聚类分析，优先补知识库或修检索。
- 隐式信号：客服场景看转人工率、追问率（用户换个说法再问一遍，八成是上一轮没答好）。
- Bad Case 流水线：低分样本自动进待分析队列，每周人工归因——检索丢、Rerank 丢、生成错、知识库缺内容，四类分别计数，优化按占比排优先级。
一个容易忽略的点：知识库覆盖率
评测集里要留一类「知识库根本没有答案」的 query，看系统的表现是「正确拒答」还是「硬编」。忠实度高不代表诚实——如果模型拿不相关的检索结果硬凑答案，忠实度指标可能不差，但业务上是事故。这类「拒答准确率」要单独统计。
可能的追问
Q：没有历史数据，冷启动怎么建评测集？ 让领域专家/运营手写 50-100 条典型问题，再用 LLM 对每条做同义改写扩到 200 条，人工确认标注。冷启动集宁可小也要准，后续用线上日志滚动扩充。
Q：LLM-as-Judge 可信吗？ 先校准再使用：抽 100 条让人类和裁判模型同时打分，算一致率（比如 85% 以上才可用）。裁判要用比生成模型更强的模型，且 Prompt 里要求逐条论断核对，别让它凭感觉打个总分。
Q：两个版本的系统怎么比？ A/B 评测集离线跑双盲对比 + 线上灰度。离线分高 3 个点以内别急着下结论，人工抽检确认；线上灰度看转人工率和踩率这些业务信号，技术指标和业务指标冲突时信业务指标。