被忽略的一个前提：谁在写搜索词
检索增强生成的教程里，流程通常被描述成：用户输入一个问题，这个字符串被送进向量库，返回若干文档。但真实的智能体系统并不这么工作。
在 agentic RAG 里，检索是流水线的粗排环节，执行者是 Agent 而不是人。Agent 会读对话历史、参考前序工具输出，把用户的原话重写成一条或多条更适合检索的查询，有时还会把一个问题拆成主查询加若干支持查询。这些重写后的查询通常更长、更具体、塞满了实体名称，与人类搜索行为有明显差异。
这带来一个评测上的空档。研究里提到，即使重写保持了原意，也会让检索流水线的 nDCG@10 平均下降约 20%。既然分布不同、效果差异显著，评测就应该用机器写的查询。但现有公开基准大多评的是人写的查询。
Perplexity 在 9 月 10 日发布 Q2D-Web（Query2Doc-Web），并公开排行榜，正是冲着这个空档去的。相关论文提交于 9 月 8 日，编号 2609.08887。
它为什么非要做得这么大
论文对现有基准的批评很具体：大规模语料通常只配少量评测查询；查询数量多的基准，语料规模往往停在百万级；而且绝大多数用人类撰写的查询。
这三个维度各有各的作用。语料规模决定难负例的数量——文档越多，语义相近但实际不相关的页面就越多，检索器必须在这些「看起来像」的干扰项里挑出真正有用的。查询数量决定结果的可信度——查询集太小，模型之间的分数差异可能只是采样运气。标注密度决定假阴性——如果每条查询只标一个正例，检索器返回了另一个同样好的页面就会被算成错误。
论文引用了一组很有说服力的数字：在 MS MARCO 上，人工抽查那些被检索出来但未标注的段落，其中约 70% 实际上是相关的。也就是说，稀疏标注会系统性地低估检索器的真实能力。
Q2D-Web 的规模是这样：1.9 亿网页文档、69,721 条 Agent 重写查询、覆盖 10 种语言（其中英语占 65.8%），联合标注集里平均每条查询有 99.6 条正例。作为对照，被它称为最接近的公开基准 MS MARCO Web Search 包含 1.009 亿文档、9,374 条测试查询，以及每条查询约 1 条由点击推导的正例。
查询与语料是怎么造出来的
查询侧不是实验室里的合成改写。团队从九个月的生产流量中抽样了 23,000 条去除个人信息后的真实搜索，再展开成 69,721 条 Agent 重写查询。这里的「一次搜索」指的是 Agent 为回应用户消息所执行的全部检索工具调用，其中包含一条主查询（重述用户信息需求）以及零到多条支持查询（探索替代表述、背景信息或相关实体）。虽然它们服务于同一个请求，但可能需要不同文档，因此每条查询都独立评测、各自拥有标注。
语料侧的构造方式值得注意。文档池不是随机采样的网页，而是对每条查询，从其检索系统中取回排名前 5,000 的结果，再做近似页面去重。这种构造方式正是「难负例」的来源——那些与查询在语言或主题上匹配，却缺少它真正要求的日期、实体或数值的页面。一个在宽松测试里表现良好的检索器，可能在这里丢分。
标注侧采用三套独立判断，而不是选一个当作标准答案。一套是 Agent 实际引用了哪些文档，一套是内部排序栈检索出了哪些文档，第三套是联合集——把前两者合并，并对池中此前未被标注的文档补充大模型判断以降低假阴性。团队的说法是，多来源能限制单一标注流程带来的偏差；这同时也承认了一件事：在这么大的规模上，没有任何单一信号能干净地代表相关性。
结果里最有意思的地方：排序会随指标翻转
论文对 13 个检索器做了评测，涵盖词法、稠密向量与后期交互三类模型。
结果呈现出两个层次。一个层次是，模型的相对排序对标注集的选择不太敏感——换成引用集、线上排序集还是联合集，大体顺序稳定。另一个层次是，绝对性能在不同主题领域、不同语言与不同查询类型之间差异显著。
具体数字上有一个值得记住的对比。在联合标注集上，Perplexity 自己的 pplx-embed-v1-4b 在 Recall@1000 上以 69.11 领先，Nemotron-3-Embed-8B 为 68.58。但换成联合集的 nDCG@10——这个指标衡量的是排序质量而非覆盖广度——Nemotron-3-Embed-8B 以 47.44 反超 pplx-embed-v1-4b 的 45.84。
没有任何模型在所有标注集与所有指标上都领先。这组翻转本身就是结论：检索质量是多维的，「哪个检索器更好」这个问题必须附带指标与场景才能回答。
工程取舍：为什么要先做一份小考卷
全库跑一次评测的成本很高，即使中等规模的模型也需要数千 GPU 小时。团队的做法是先做子语料采样：用互逆秩融合从各检索器的联合运行结果中选出约三分之一语料，先在这个缩小版上评测。
论文给出的结论是，保留三分之一语料，能在联合标注下基本复现全库的模型排序，而 Recall@1000 的绝对值只抬高 3 到 7 个百分点，增幅可控。只有在这个小考卷上进入各自参数量级前十的模型，才获得全库评测资格。
这个设计对做检索工程的人有直接参考价值。企业内部做模型选型时，同样可以先在抽样语料上做粗筛，再对少数候选做全量验证。需要注意的是，子采样会移除干扰项，从而抬高召回率——所以小考卷适合比排序，不适合用来估算上线后的真实召回水平。
中立思辨
这份基准的价值与它的边界同样明显，官方在说明中也做了部分披露。
其一，语料是私有的，榜单由 Perplexity 运营，而任何与 Perplexity 模型相关的数字，都是 Perplexity 在自己的数据上测出来的。官方承认自家模型「可能受益于分布内优势」，尽管用于评测的具体查询与文档未参与训练。这个披露是诚实的，但它不改变控制权归属。
其二，标注集的选择会改变结论。官方给出的建议是：把引用集的结果看得比联合集更重，因为引用反映的是 Agent 实际选择据以行动的证据，而联合集包含标注模型的判断。这是一个技术判断，同时也意味着「用哪套标注」本身就是一个需要读者自己决策的变量。
其三，难负例的构造方式依赖 Perplexity 自己的检索栈——文档池来自其系统的前 5,000 结果。这既是难度来源，也是偏差来源：语料分布带着这家公司检索栈的特征，未必等同于其他系统的检索场景。
其四，多语言覆盖以英语为主，占比 65.8%。对中文检索场景的团队来说，直接套用榜单结论的参考价值有限。
其五，把 Q2D-Web 当成方向性信号比当成裁决更稳妥。选择嵌入模型做检索的团队，仍然应该在自己真实的查询分布上做一轮实测——尤其是当查询同样由 Agent 重写时，自家分布与公开语料的差异可能比模型之间的差距更大。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给检索工程团队的四条做法
把这份基准背后的方法论拆出来，有四条可以直接用。
用真实重写查询做评测集。如果线上检索由 Agent 发起，评测就不该用人手写的短查询。可以从生产日志里抽样去敏，把 Agent 的重写结果连同上下文一起留下来，作为长期复用的评测资产。
提高标注密度。每条查询只标一个正例会让评测失真，而增加正例数量的边际成本，往往低于因为评测失真带来的错误选型成本。论文给出的 70% 这个数字说明，稀疏标注带来的偏差并不小。
分开看覆盖与排序。Recall@1000 高不代表排序好，nDCG@10 高不代表召回全。选型时把两类指标并置，并明确自己的场景更怕漏还是更怕乱——召回型任务与问答型任务的取向并不相同。
记录指标会翻转的可能。当两个模型在不同指标上互有胜负时，不要急着取平均分。更实用的做法是回到业务：在这个具体场景里，漏掉一条相关文档和多排错两条文档，哪个代价更高。