面试题 · 评估
在RAG系统的评估体系中，您认为哪些是最关键的评价指标？为什么？
RAG评估要分两个层面来看：检索端和生成端，再加上端到端的整体评估。
按学习路线查看教程、项目和面试题。
为什么这些最关键？ RAG的核心价值是用外部知识约束生成，所以"检索准不准"和"生成真不真"是根基。自动化指标解决规模化评测问题，业务指标则锚定实际价值。如果只关注生成流畅度而忽视事实性，RAG就失去了意义。
场景切入
假设你在做一个电商客服RAG，用户问‘订单怎么还没到’，系统检索后生成了回答。你怎么判断这个回答好不好？光看流畅度够吗？
层层追问
RAG系统上线了，你怎么评估它好不好？……如果只看最终答案行不行？……检索和生成你分开看吗？……你觉得最关键的指标是哪个，为什么？
直球架构
聊一下RAG系统的评估体系，你认为哪些是关键评价指标？从检索端和生成端分别说说，再讲一下端到端的指标和业务指标，挑最重要的解释原因。
这道题其实问的是，怎么判断一个[[RAG]]系统到底好不好用。我觉得核心不在于列一堆指标，而是想清楚RAG的价值在哪，它就是用外部知识来约束生成，不让模型乱说。所以评估的立足点一定是：有没有真的约束住，约束得够不够好。
我习惯把评估拆成两个层面：检索和生成，再加一个端到端的整体效果。先说检索，它决定了RAG的天花板。你召回的东西不对，后面模型再强也白搭。我最关注的是 Recall@K，就是相关文档有没有被捞回来。很多系统上线后效果不好，一查，问题出在召回率只有百分之六七十，那后面再怎么调prompt都补不回来。具体到业务场景，比方说电商客服处理退款纠纷，用户的订单号和退款原因五花八门，纯向量检索可能因为拼写差异漏掉关键记录。这时候我会用 [[Hybrid Search]]，把关键词和向量两条路结合起来，先用[[BM25]]兜底高频实体，再靠向量语义召回，这样Recall才能拉上去。
再说生成端，核心指标是 [[Faithfulness]]，也就是答案是不是忠实于检索到的文档。这是RAG的生命线，直接对应[[幻觉]]问题。你不能模型自己脑补出一段看起来流畅但文档里根本没有的话。举个例子，企业内部的合规文档检索，员工问某个条款怎么解读，模型必须严格基于文档回答，不能自由发挥。如果只盯着流畅度或相关性，忽略了事实一致性，那RAG就失去了意义。自动化指标比如[[RAGAS]]，用LLM打分来评估忠实度和相关性，适合大规模快速迭代。但这里有个坑：LLM打分本身不稳定，对边界案例容易误判。所以 人工抽检 不能省，尤其是那些模型表现模棱两可的case，得靠人去仲裁。
落到业务上，我还会特别关注 延迟和成本。检索加生成的总耗时，直接决定用户会不会等得不耐烦走人。成本方面，向量检索和LLM调用的开销，如果一次对话就要好几毛钱，产品根本跑不动。上线前我会先跑一批大样本，覆盖典型场景和异常case，对比Recall和Faithfulness的分数，同时监控延迟的P99。如果召回率低于百分之九十，我宁可牺牲一点延迟，也要加一轮[[重排]]来提高精度。
说到评估，其实有个延伸点：你评估体系搭好了，数据怎么反哺到系统里形成闭环？比如你发现Faithfulness分数低的case，能不能自动标记出来，用来做后续的模型微调或者检索策略优化？这个数据飞轮转不转得起来，往往决定了系统能不能持续变好。
所以整体上，我更愿意把评估看成一套组合拳：检索端抓Recall，生成端抓Faithfulness，业务端抓延迟和成本，再靠人工抽检兜底。如果只能选一个指标，我会选Faithfulness，因为它是RAG区别于普通对话系统的根本。