这道题问的是[[RAG]]系统怎么评估和迭代,其实本质是问你怎么把检索和生成两件事拆开来看,再合起来调优。因为RAG的坑往往藏在中间,检索准了但生成没用对,或者生成对了但检索根本没把正确答案找出来。
先说评估。我会把评估拆成三层:检索层、生成层、端到端。但关键不是列指标,而是看它们之间的联动。
检索层,核心看召回率,比如Recall@K,正确答案在不在前K个里?这是底线。再一个看排序质量,比如MRR,毕竟就算召回了,排到第10条和排到第1条对生成层的影响差很多。生成层,我重点盯事实性,就是答案有没有忠实于检索内容。这个可以用NLI模型自动判,但人工抽检也跑不掉。流畅性反而不是大问题,LLM天然流畅。端到端就是最终答案对不对,但这里有个坑:如果检索召回很低,但生成答案居然对了,那很可能是模型靠参数记忆作弊,这种场景下你的RAG其实没生效。所以三层指标要一起看,才能定位到具体瓶颈。
迭代优化,我遵循先诊断后动手。举个例子,客服退款场景,用户问“我买了件衣服尺码不对怎么退”,如果检索没召回退款政策文档,那就是召回不足。我会用[[混合检索]],[[BM25]]加向量,再加[[重排]],把关键词匹配和语义匹配结合起来。如果召回够但生成还是瞎编,那就强制引用,让模型必须标注来源,甚至把检索内容直接前置到prompt里。还有一个常见失败场景:用户问题太模糊,比如问“满减怎么算”,这时候我会做查询扩展,比如HyDE,先生成一个假设答案再拿去检索。
落地时我特别关注一个前提:离线指标提升不一定等于线上好用。比如召回率高了,但引入的噪声文档反而让生成更不稳定。所以上线前我会建一个回归测试集,覆盖高频query和边界case,比如用户问“订单号输错了怎么办”,这种容易跟“订单状态查询”混淆。上线后小流量验证,看用户有没有二次提问或者直接离开。
其实现在还有一个方向是[[Self-RAG]],让模型自己判断什么时候需要检索、什么时候靠自身知识就够了。这个在混合场景里特别有意思,比如用户问的是常识性政策,模型直接答就行,不用每次都去库里翻。
所以整体上,我会把RAG评估看成一套诊断工具,而不是打分清单。先拆开看检索和生成各自的问题,再合起来调,最后用线上行为验证。