RAG 效果评估

RAG 评估不要从“答案好不好”开始。答案只是最后的表现，真正要拆的是证据有没有找对、有没有排到前面、有没有按权限和版本过滤、模型有没有忠实使用证据。

先分问题层

第一层是召回。它回答“正确证据有没有进候选集”。这里优先看 Recall@K、HitRate，也要抽查 query rewrite、稀疏召回、dense retrieval 和 metadata filter 是否把正确材料漏掉。召回层出问题时，先别调 prompt。

第二层是排序。它回答“正确证据有没有排到模型能看见的位置”。这里优先看 MRR、nDCG、Precision@K。如果正确 chunk 在 Top-50 里，却没进最终上下文，问题通常在 rerank、cutoff、去重或 chunk 合并策略。

第三层是上下文装配。它回答“送给模型的材料是否干净”。同一条制度的旧版本、新版本、草稿版混在一起，模型很容易写出看似合理的错答案。权限过滤、版本状态、引用字段和 chunk 边界都应该在这里检查。

第四层才是生成。它回答“模型有没有忠实使用证据”。Ragas 里的 Faithfulness、Answer Relevance、Context Precision 可以作为起点，但不要把框架分数当结论。低 faithfulness 要回看引用和上下文装配，低 answer relevance 要回看问题理解和任务定义，低 context precision 要回看召回和 rerank。

默认排查顺序

线上效果变差时，先抽 20 到 50 条失败样本分桶。把问题分成无召回、召回错、排序错、上下文混杂、生成未遵循、引用错误、权限/版本错误。分桶后再动参数。直接同时改 embedding、rerank、prompt 和 chunk size，只会让你不知道是哪一步生效。

默认优化路线是先保证关键证据能进候选集，再压噪声，再收紧最终上下文，最后改生成提示。召回层目标是别漏，最终上下文目标是别乱。把两个目标混成一个分数，是很多 RAG 系统调不稳的根因。

面试表达

可以这样答：我不会只用“回答像不像”评估 RAG。我会把链路拆成召回、排序、上下文装配和生成四层。召回看 Recall@K 和命中率，排序看 MRR 或 nDCG，上下文看权限、版本、去重和引用字段，生成再看 faithfulness 和 answer relevance。失败样本先分桶，再决定是补 query rewrite、调 rerank、改 chunk，还是收紧生成约束。