怎么考「RAGAS 这类框架评的是什么？faithfulness 和 answer relevancy 有何区别？」
谁在问：用过评测框架的面试官；简历提到 RAGAS 必被追问指标区别
开场怎么问
你们用 RAGAS 吗？主要看哪几个指标？
换个问法
- faithfulness 和 answer relevancy 有什么区别？
- faithfulness 高是不是就说明系统没问题？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
faithfulness 是怎么算出来的？
- 期望
- 判官模型把答案拆成一条条独立声明（claim），逐条检查能否由检索到的上下文直接推出；faithfulness = 被支持的声明数 / 总声明数。理解这个机制就知道它为什么对「材料残缺但答得自洽」无能为力。
- 信号
- 能说出「拆成 claim 逐条核验」的，是真看过实现；只说「判断答案忠不忠实」的是复述定义。
用 LLM 当判官，它自己不会出错吗？
- 期望
- 会。已知偏差包括位置偏差、自我偏好（倾向于给同源模型的输出打高分）、长度偏好、分数分布集中。缓解手段：用比被测模型更强的判官、固定 prompt 模板、抽样人工校准判官（先用一批人工标注反过来验证判官准不准）、多次采样取一致性。详见 Q5-03。
- 信号
- 完全没意识到判官本身有偏差的，是把工具当真理。
这些指标你们线上跑吗？成本怎么样？
- 期望
- 每条样本都要调若干次 LLM，全量线上跑成本很高。实践是：离线在评测集上全量跑（回归）；线上做抽样评测（如 1% 流量）+ 廉价代理指标（点踩率、追问率、检索分数分布）监控。
- 信号
- 说「线上每条都跑 RAGAS」的，没算过账。
只用这四个指标够吗？
- 期望
- 不够。补充维度：端到端任务成功率（尤其 Agentic RAG，答案忠实但动作做错了也是失败）、延迟 P95、答案相似度（有标准答案时）、噪声敏感度（无关 chunk 混进来会不会带偏）。还有一个常被忽略的盲区：这些指标都假设索引本身是可信的——如果源数据本身过期、无人维护、和权威源不一致，指标再高答案也是错的。
- 信号
- 能提出「索引可信度是评测的盲区」这一层的，思考很深。
faithfulness 0.91 但用户说答得不对，你怎么查？
- 期望
- 这就是开头的故障——先看检索侧指标（context recall / precision），大概率是材料残缺而生成自洽；同时做「手工塞正确文档」的归因（见 Q2-17）确认是检索的锅；再看评测集是否覆盖了这类多跳问题（很可能没覆盖，所以离线发现不了）。修完把这类 case 加进评测集分桶。
- 信号
- 第一反应是「去调 prompt 提高忠实度」的，方向完全错了——这题的病根在检索。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 能说出四个核心指标并正确归类到检索侧/生成侧
- 能清晰辨析 faithfulness（有没有编）与 answer relevancy（有没有答到点）的正交关系
- 知道只测生成测不出检索的病
- 知道 RAGAS 底层是 LLM-as-Judge
- 加分：知道 faithfulness/relevancy 免参考、context recall 需要标注
- 加分：意识到判官模型自身有偏差
- 加分：知道四个指标不够，能补充端到端成功率、延迟、索引可信度
参考答案与考察意图面试中途别看这一段
考察意图
第三问是埋伏。 faithfulness 高完全可能掩盖严重的检索缺陷——这正是最经典的 RAG 评测事故形态。面试官想看你是「知道有这几个指标」还是「知道每个指标盯的是哪种病、以及它盯不住什么」。能主动说出「reference-free 与需要标注」这个区别的，基本可以判定真跑过。
参考答案
60 分答案（及格线）
RAGAS 是最常用的 RAG 评测框架，核心用 LLM-as-Judge 打分。四个核心指标分属两侧：
生成侧——Faithfulness（忠实度）：答案里的每条声明能否由检索到的上下文推出，管「有没有编」；Answer Relevancy（答案相关性）：答案是否切中提问，管「有没有答到点上」。
检索侧——Context Precision（上下文精确度）：检索内容里相关的比例及是否排在前面；Context Recall（上下文召回率）：该检索到的信息是否都检索到了。
faithfulness 和 answer relevancy 是正交的：照抄材料但答非所问 → faithfulness 高、relevancy 低；答到点上但添油加醋 → relevancy 高、faithfulness 低。
90 分答案（有生产经验的回答）
补三层：
讲一个真实事故形态（最有说服力）：一个法律检索 RAG 上线，离线 faithfulness 0.91，团队很满意。三周后客户投诉大约六分之一的回答漏掉关键法条。回去看仪表盘——faithfulness 还是 0.91 纹丝不动，再查 context recall 只有 0.62。真相是检索器在多跳问题上漏了第二条法条，而生成器基于残缺的上下文把答案编圆了——它说的每句话都能在（残缺的）上下文里找到依据，所以忠实度反而很高。
结论：只测生成，测不出检索的病。 仪表盘上必须同时有检索侧指标，否则这类回退无声无息。
说清 reference-free 的差别（专业细节）：faithfulness 和 answer relevancy 是免参考答案的——用检索到的上下文和问题本身作为判据，不需要人工写标准答案，所以能大规模跑。而 context recall 需要标准答案或标注的 gold chunk 才能算准。这也正是开头那个团队仪表盘上没有它的原因：它是唯一「贵」的那个指标，最容易被省掉，偏偏又最不该省。
给阈值参考：社区常用经验线是 faithfulness > 0.8、context precision > 0.75、context recall > 0.8，低于线就知道该修哪一层。注意这是参考不是标准，业务容忍度自己定。
再补一个 2026 年的变化：RAGAS 已不止评 RAG——同样的 reference-free 思路扩展到了 Agent 工具调用轨迹（有没有调对工具、顺序合不合理）、text-to-SQL（生成的 SQL 语义是否正确而非字符串相似）、多模态（对图像内容的声明是否被支持）。