基于TREC与K池化的相对召回率计算技术问询

好问题！这两个点其实是TREC-style评估里很关键的细节，我来逐一拆解：

1. 总相关文档的定义 #

在TREC的K池化（Pooled Relevance Assessment）流程中，总相关文档是按单个查询维度来定义的：

• 针对每个查询，我们会收集所有参与评估的系统提交的前K篇文档（比如常见的K=100），把这些文档合并、去重，形成一个「池化文档集合」。
• 然后人工标注这个集合里哪些是相关文档，最终这个查询下的总相关文档数就是该池化集合中被标注为相关的文档总数。
• 注意：不是所有查询的相关文档总和——召回率是先针对每个查询单独计算，之后再通过平均、中位数等方式聚合出系统的整体性能指标。

2. 这种方法会导致召回率计算失效吗？ #

你的例子戳中了K池化的一个固有特性，但这不叫「计算失效」，而是要明确它的评估边界：

• 你提到的场景：两个系统的前50篇文档合并后共有75篇相关文档，那这个查询的总相关文档数就是75。单个系统最多能在自己的前50篇里召回50篇相关，所以它的相对召回率最高是50/75 ≈ 66.7%，确实到不了100%。
• 但这是合理的：K池化的核心目的是高效比较多个系统的相对性能，而不是测量「绝对召回率」（即找到所有存在的相关文档）。它基于一个假设：真正的相关文档大概率会被至少一个参与系统排在前K位，所以通过合并这些文档来构建评估用的相关集合，能在成本可控的前提下有效区分系统性能。
• 如果你追求的是绝对召回率，那K池化确实不适用，但TREC这类评估本来就聚焦系统间的相对优劣，这种相对召回率的计算是完全有效的——它能准确反映一个系统在「所有参与系统能覆盖到的相关文档」里的召回能力。
• 补充一点：如果后续有新系统找出了池化集合外的相关文档，说明初始池化集合有遗漏，这时通常会扩展池化集合（加入新系统的前K篇）重新标注，这是评估流程的迭代，而非计算逻辑的问题。

内容的提问来源于stack exchange，提问作者Josh