如何评估多向量检索模型的召回覆盖率?

评估多向量检索模型，不能只看一个 Recall@K 数字。真正需要回答的是：与查询相关的文档，尤其是包含关键局部证据的文档，是否进入了候选集合；当查询包含多个条件时，候选结果是否覆盖了全部必要信息。多向量模型保留多个词元级向量，并通过晚期交互完成匹配，优势可能出现在细粒度对应关系上，但这种架构优势必须用业务数据验证。

先定义“覆盖”而不是简单命中

测试集应按查询特征分层，至少区分单一事实查询、多条件查询、带版本或时间限制的查询，以及要求定位局部片段的查询。不同类型的查询，召回难点并不相同。若所有样本都只是短句和单一意图，评测很容易高估模型效果。

对于每条查询，除了记录 Recall@K，还应判断相关文档是否进入前若干名候选、首个相关结果的位置，以及多个必要证据是否全部出现。相关性最好分为“完全满足”“部分满足”和“不相关”。一篇文档主题相近，却只满足查询中的一个条件，不能等同于完整召回。对需要多份证据的问题，还要逐项记录关键证据是否覆盖，以及它们是否排在后续上下文能够使用的位置。

把召回问题与排序问题分开

相关文档没有进入候选集，属于召回失败；已经进入候选集但排名靠后，则属于排序问题。二者必须分开诊断，否则最终的 MRR 或 NDCG 无法说明改进方向。评测记录中应保留候选文档、排名、模型分数和人工判断，必要时比较查询改写或语序调整后的结果稳定性。若轻微改写就导致候选集合大幅变化，说明模型可能仍受到表面表达影响。

负面样本同样重要，包括条件冲突、范围不匹配，或仅有一个条件相似的文档。否则，模型返回大量“部分正确”的结果，表面召回率可能上升，实际可用覆盖却没有改善。

用分组结果支持上线判断

评测应同时保留实验级和查询级信息。前者记录模型类型、文档切分、索引配置、候选规模、硬件、并发条件和数据版本；后者记录查询类别、相关文档、覆盖证据、排名、分数和错误类型。最终按查询类型比较召回覆盖、排序质量、延迟、索引体积及构建和更新成本。

如果多向量模型只改善少量边缘查询，却显著增加存储和计算负担，就不宜仅凭总体分数上线。只有当它稳定改善多条件、局部证据类查询，且新增成本在系统承受范围内，召回覆盖率的提升才具有工程价值。