这道题问的是[[RAG]]评估,但我觉得它真正在问的是:你怎么在检索和生成这两段之间做质量博弈,并且落地时不被指标骗了。
我会把评估拆成两个层面,先检索层,再生成层,最后看端到端,但每个层面都有坑。
先说检索层。Recall@K衡量Top-K覆盖了多少已标注相关文档,分母是相关文档总数;Hit@K衡量至少命中一个相关结果的query比例,不能混为一谈。但这里有个常见误区:很多人上来就追Recall@K到95%以上,其实没必要。比如客服退款场景,用户问“退款到哪了”,若黄金集中有4篇相关文档,Top-3只命中1篇,则Recall@3是25%,该query的Hit@3是1;只有黄金相关集仅1篇时,召回它才是100%。业务是否只需一份证据,须另按问题需求判断。所以我会把Recall@K和MRR搭配看,MRR对第一个相关结果的排名倒数求平均,更偏向首个命中的排序质量。如果MRR低,说明正确答案虽然召回了但排在很后面,生成模型可能压根没用到它,那就需要优化排序。
再就是生成层。传统NLP指标像BLEU、ROUGE,在RAG里参考意义有限,因为答案可以措辞不同但意思对。我更关注[[Faithfulness]],也就是忠实度,说白了就是生成内容有没有被检索文档支持。它与Answer Correctness关注不同问题:忠实于错误资料仍可能不符合现实事实,不能给二者排通用名次。宁可答得少,不能瞎编。比如企业SOP合规场景,员工问“报销流程”,模型如果编一个不存在的审批节点,那就是事故。所以我会用NLI模型或者LLM做裁判,逐句检查生成内容能否从上下文里找到依据。
然后是端到端,主流框架是[[RAGAS]],用LLM当裁判。它有Faithfulness、[[Context Precision]]等指标;Context Precision考虑相关项的排序位置。以v0.1.21的Answer Correctness为例,它组合事实正确性与语义相似度,不是只算embedding相似度,需固定版本。但这里有个前提:裁判LLM本身要靠谱。如果裁判模型能力不够,它可能分不清哪些是忠实哪些是编的。所以我会先用一批人工标注的测试集校准裁判的准确率,按业务错误类型、标注一致性与误判成本决定是否换模型或调整prompt,不预设通用90%门槛。
说到这,其实还有一个更隐蔽的问题:RAGAS的Context Precision指标,它假设检索结果里有用的文档排在前面就好,但现实里,如果检索结果里混入了和问题高度相关但误导性的文档,这个指标反而会骗人。所以落地时,我会额外关注检索结果的“有害相关”比例。
最后说落地策略。没有银弹,我更倾向按场景分层:快速迭代时用RAGAS自动评估加少量人工抽检;上线前必须构建领域测试集,分维度打标;线上监控则靠用户反馈和埋点。检索覆盖、排序、答案支持、事实正确和完整性一起看,再按任务风险定义上线门槛;Recall是质量覆盖指标,不是运行效率指标。
这就是我对RAG评估的理解,核心是分层看、抓底线、用工具但不盲信。