> 评测集失效有两个方向，只盯"样本量"会漏掉另一个

结论先行¶

一个检索评测集只有 50 条，直觉是"太少了，要扩"。 扩之前先给它做了一次体检，量的是一个此前没量过的东西—— 每道题的标签在语料里匹配到多少个小节：

最松的两条各匹配 821 / 751 个小节 —— 标签正则写的是 [Mm]emory|CUDA|[Gg]lobal，在锁定的那本书里几乎命中任意一节。

那已经不是"找对小节"，是"找对书"。

所以之前那个 Recall@10 = 1.000 有相当一部分是标签松出来的。 这解释了为什么那张消融表后来分辨不出任何配置差异：题目本身不判错。

另一个方向同时存在。新题集第一轮跑完，10 条未命中里8 条其实是标签太窄：

两种失效都会让人去调一个没坏的东西。

为什么¶

指标是"检索结果"和"标签"的函数，所以标签错了，指标测的就不是检索器：

"样本量不足"只是第三种失效（方差大）。它最容易想到，因为它有个 现成的名字和一个现成的修法。而前两种需要你去量一个 关于标签自身的统计量 —— 每条标签匹配多少候选 —— 而这个量 在任何标准评测框架里都不会自动打出来。

还有第三种混淆要拆开："答案薄"和"检索差"不是一回事。 这个库里有 15 道题的正确答案只占 1~3 个块（18.4 万块里的 3 块）。 这类题检索不到，首先该怀疑的是索引缺口，不是检索器。

怎么用¶

出题顺序不能反。 先抽真实小节 → 再据其写题 → 标签取该小节自身的元数据。 这样标签是构造出来的真值，天然独立于检索结果。 反过来"先写题、跑检索、照着结果定标签"，得到的分数没有意义 —— 那是在用待测系统给自己出题。

给评测集本身写一个体检脚本，两头都查。 这个项目的 p6b_validate.py 有 --tight / --thin 两个开关： 一头查标签匹配数过多（太松），一头查正确答案块数过少（答案薄）。 体检先跑，消融后跑。一个没有被体检过的评测集， 它给出的配置排序是不可引用的。

标签太窄的修法是 pooling，但必须承认它的偏差。 IR 里处理 incomplete qrels 的标准做法：把各配置返回的前 k 条摊开， 逐条按"这一节是否正面回答了这个问题"判定，判据只看小节内容、 不看它排第几，理由写进修订记录。

诚实声明是这样写的：

pooling 只对 miss 做，所以绝对分数偏乐观。但四格用的是同一次 修订后的标签，配置之间的相对高低不受影响。

这两句话必须跟着那张表一起走。少了它，读者会把一个偏乐观的 绝对值当成能力上界 —— 同 核验报告必须先报自己的覆盖率，再报结论——否则一次失败的核验看起来像核过了。

字符串匹配的标签要先做归一化。 那条 CLRS 的 miss 纯粹是 - 4th 对 _3e 没匹配上。标签用正则匹配书名/小节名时， 版次、连字符、空格、大小写都要先归一 —— 同 会产生"指控"的工具，误报代价不对称——先归一化再开口， 那里是一个句末句号造出了 12 条假指控。

n 小的时候就把 n 小写在结论旁边，然后真的去扩。 "仍然是 n=50，要把默认值当定论得先扩到 150~200 条" ——写下这句话之后真的扩了，并且推翻了自己当时一半的结论。 声明局限的价值不在声明，在它后来被消掉。

出处¶

~/Tools/booksearch/docs/RAG_PLAN.md §15「把 golden set 从 50 条扩到 160 条」：15.1（两个题集的匹配小节数、821/751 那两条）、 15.4（pooling 的三个典型例与偏差声明）、15.6（沉下来的三条方法论、 --tight / --thin、15 道答案薄的题）。