北京
RAG（检索增强生成）系统能生成流利的回答，却可能在多个独立环节上出错：检索到错误证据、遗漏必要文档、误读正确上下文、答非所问，或者编造一个从未出现在任何来源中的数值。单一的"准确率"分数无法解释这些失败，更无法指明需要调整的组件。
可靠的评测应把RAG视为一条流水线。检索与生成分别获得独立指标。精确数值用确定性代码校验，开放式回答则依据明确标准评判。每个模型、提示词、分块策略和排序调整，在发布前都必须在同一数据集上完成评测。
目标不是产出一个好看的仪表盘数字，而是建立一套可重复的决策系统，回答三个运营问题：检索层是否把正确证据送进了上下文？生成层是否忠实地使用了这些证据？如果答案错了，应该改检索还是改生成？
RAG至少有两条主要的故障面。
检索层负责选择上下文。它可能返回无关片段、遗漏必要段落，或检索到过期版本。生成层负责解读上下文。它可能无视证据、错误合并事实，或添加无依据的断言。
两类故障需要不同的修复手段。如果正确的发票行从未进入上下文，修改回答提示词无法修复检索；如果正确行已在上下文中、但模型报错了单价，调大向量top-k也无法修复生成。
因此，评测必须保留这两个阶段之间的边界。
上下文精确率衡量检索到的内容中与问题相关的比例。精确率低意味着提示词中混入了噪声——无关片段既浪费token，又可能分散生成器的注意力，即使正确证据就在其中。
精确率还应当考虑排序权重。相关片段被埋在第八位、而前七位全是无关片段，比起原始相关比例所暗示的，检索器的实际能力要弱得多。
以产品PRD-482的退货条件查询为例，如果检索返回的十个片段中，仅第三个片段包含真实退货条款，其余九个均为其他产品的说明，那么精确率仅为0.1，且排序权重进一步暴露了检索器的问题——相关证据位置靠后，生成器需要穿过大量噪声才能找到它。反之，如果相关片段排在第一、第二位，即便精确率相同，生成器也更可能输出正确回答。这正是为什么评测必须同时关注"检索到了什么"和"检索结果的排序质量"。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
