最近看自己项目里的 RAG 评测，我发现一个挺值得警惕的现象。 一套系统在已有测试集上表现非常不错，几十道问题里只错了少数几道，看起来已经可以放心使用。 结… · @UPing123zzz · TwKit

@UPing123zzz

最近看自己项目里的 RAG 评测，我发现一个挺值得警惕的现象。 一套系统在已有测试集上表现非常不错，几十道问题里只错了少数几道，看起来已经可以放心使用。 结果把问题换一种表达方式，之前能够检索到的资料，突然就找不到了。 这件事让我意识到，RAG 的评测不能只关注答对了多少道固定题。 因为真实用户根本不会按照我们提前准备好的问题模板来提问。 比如知识库里有一份差旅制度，标准测试问题可能是员工住宿报销上限是多少。 可真实用户可能会问，我明天去外地出差，酒店最多能订多少钱。 两句话在业务上很接近，但关键词、句子结构和问题表达已经发生变化。 再进一步，用户可能根本不提差旅制度，只问某个城市、某种职级对应的住宿标准。 如果检索系统过度依赖固定关键词，或者查询改写环节没有正确保留业务条件，就可能出现明显的召回问题。 这也是为什么我现在觉得RAG 测试集应该加入更多语义变化。 同一个事实可以用不同说法提问，问题里可以包含无关信息，也可以故意省略某些条件，检查系统会不会乱猜。 但这里也不能简单地认为，只要换几种问法，就能证明系统足够可靠。 因为资料解析、权限控制、版本有效性、检索排序和最终答案生成，都可能引入不同错误。 如果一套 RAG 已经在某个测试集上反复优化，还要特别注意它有没有逐渐适应这些固定样本，却没有真正提高对新问题的处理能力。 所以我更希望测试集有一部分在开发过程中不被反复用于调参。 每次换 Embedding、Reranker 或查询改写策略以后，都拿相同的独立标准检查，看看提升到底能不能延续到没有见过的问题。 我觉得企业 RAG 真正难的地方，就是让它面对真实用户千奇百怪的表达，仍然能找到正确证据。 固定测试题答得特别漂亮当然是好事。但如果客户只是换了一种正常说法，系统就开始找错文件，那这个知识库距离稳定交付，可能还差很远。

曝光 116 · 评论 1 · 点赞 0 · 书签 0