今天在给自研知识库做自动化测试集时，我们撞上了一个极其尴尬又真实的翻车现场：

检索器明明从另一本书里挑出了一个解释得更透彻、更权威的段落，但自动化评测脚本却毫不留情地给它判了 0 分！

原因非常讽刺——因为我们给测试题绑定的预期真值（Ground Truth），是第一本书里的那个特定 chunkId。

做过 RAG 评测的朋友都知道，最常规的思路就是从每本书挑段落出题，让问题死绑定一个 chunkId，然后去测召回率（Hit Rate）和 MRR。
但这套在 Demo 里跑得顺溜的逻辑，一放到真实多图书场景立刻被现实狠狠打脸：
同一个 AI 知识库的核心机制（比如父子切片 Parent-Child、向量与 BM25 的 RRF 混合检索、或者是大模型的上下文迷失 Lost in the Middle），A 书在讲算法原理，B 书在讲落地实战，C 书在做多方案对比。

当知识在不同书籍之间高度重叠时，死绑定单一 chunkId 带来了致命副作用：
1. 误杀优秀检索：模型跨书找到了更透彻的答案，却因 ID 对不上被判“检索失败”；
2. 评价不了综合题：现实读者问的复合架构选型（比如“什么时候用 HyDE 扩展、什么时候上 Rerank”），答案往往分散在多本书里，单 chunk 根本兜不住；
3. 标注成本雪崩：想人工把全库所有等价 chunk 都捞出来打标，在图书规模下根本不可行。

翻遍了目前的行业方案，针对跨文档知识冗余的基准集评测，业界似乎也缺少成熟的标准解法。

各位做 RAG 和大模型落地的朋友，你们在构建测试集时是怎么解决跨书知识冗余难题的？大家有什么好的实战思路可以支招吗？

程序员 大模型落地 AI知识库 RAG架构