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区别于普通对话系统的根本。