北京
用户问了一个问题，机器人答得行云流水，语气自然、逻辑通顺。团队准备收工，顺手把提示词再打磨一下。但很少有人回头确认一件事：检索器到底有没有把该找的那份文档捞出来。
一个流畅的答案，常常掩盖了一份缺失的文档。反过来，文档明明被检索到了，模型照样可能给出错误回答。评估一条检索增强生成（RAG）流水线时，这两类失败必须分开看，否则调了半天提示词，修的可能根本不是病根。
这套思路把聊天机器人准确率的话题，改造成了一次离线检索测试。它只依赖文档 ID 和人工标注的相关性判断，不调用任何大模型，不连接向量数据库，也不承诺能自动提升准确率。
测试集该放什么
问题要直接从聊天机器人必须处理的任务里来。针对每个问题，记录哪些文档包含足够证据可以作答，同时把文档版本号和标注一起记下来。比如一个退货政策的测试，如果有人在测试运行中途更新了底层的政策文件，这个测试很快就会失效。
用合成问题，或者经过适当批准的样例。客户对话里可能含有个人信息，把它们粘进测试夹具并不会让这些信息消失。一套能跑的测试可以从很小起步，但要包含那些别扭的措辞，不能只放和章节标题长得一模一样的问句。
Pinecone 的 RAG 评估指南把精确率、召回率这类检索指标和生成质量分开。这些分数衡量的是检索到的证据，并不能为生成的答案背书。
本地怎么给保存的结果打分
下面这段 Python 代码在固定窗口内统计相关文档 ID 的数量。它会拒绝重复 ID，避免重复记录把分数垫高。当期望集合为空时，它返回未评分状态。语料之外的问题需要单独的拒答检查，而不是编一个召回率出来。
- 校验 k 必须是正整数，布尔值也会被拒绝
- 截取前 k 条结果，窗口内出现重复文档 ID 直接报错
- 期望集合为空时返回 unscored_no_relevance_labels
- 否则计算 precision_at_k 和 recall_at_k
这里的精确率除以的是请求的窗口大小。如果系统返回的文档数量少于请求数量，空位按未命中计算。在和其他团队的测试框架对比之前，先把这条约定讲清楚。这个函数期望 ID 可哈希、输入已校验，它不会去清洗脏的入库数据。
这段代码只在本地夹具上验证过，没有和 Pinecone 或线上聊天机器人做过集成。把它当作一次打分逻辑的合理性检查就好。
怎么做一次有用的对比
- 冻结问题集、相关性标注和文档版本。
- 保存当前配置下检索到的 ID，保留排序。
- 只改一个检索设置，然后用完全相同的问题集重跑。
- 在决定保留这次改动前，既看聚合分数，也看每条查询的变化。
不要为了让某个偏爱的参数调整活下来，就去篡改测试标注。如果标注错了，在版本控制里改掉，然后把两次运行都重新跑一遍基准。未回答的问题要留在数字里，把它们剔掉，一个坏掉的索引看起来就过关了。
Pinecone 的 RAG 概览还建议把问题和参考答案配对。单独跑一次生成层评审，确认陈述和检索到的片段一致、引用指向当前版本、证据缺失时能干净地拒答。
检索分高就代表答案更好吗
不能。检索器可能捞对了政策文件，模型却把某个例外条款引错了。生成层要单独测。同样，一个很有说服力的答案，也不是检索做得好的证据。把测试问题、返回的 ID 和输出绑在一起记录，出问题时才能定位断点，而不是靠猜。
每当有没被处理过的客户查询漏过去，就扩充测试集。同时把每一个旧测试都保留在原位，免得今天的补丁悄悄弄坏了昨天的修复。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
