Search Agent 复杂查询构建实战指南

在评估Search Agent或DeepSearch类系统的能力时，一个核心挑战在于：如何构建真正能够暴露搜索系统能力短板的测试查询？很多开发者习惯性地直接使用线上用户Query作为测试集，但实际效果往往不尽如人意——真实用户的提问大多属于简单的事实查询，口语化严重，真正能够考验搜索系统综合能力的问题占比并不高。因此，构建高质量的评测数据集需要系统性的方法论指导。

为什么简单照搬线上Query不够用

真实搜索场景中的用户Query通常具有以下特点：问题简短、信息量有限、以单点事实查询为主。然而，优秀的搜索代理需要具备的能力远不止于此——它需要处理多跳推理、时间敏感信息、证据冲突判断、Query改写、目标漂移纠正等复杂场景。如果评测集仅由线上原始Query组成，很难全面评估系统的真实能力水平。 这就引出了一个关键问题：如何科学地构造能够真正测试搜索代理能力的复杂Query？

从失败案例中挖掘困难约束

很多人在构造复杂Query时容易陷入一个误区：认为把问题写得很长、加入大量限定词和实体名词，就是「困难样本」。但在搜索场景下，复杂绝不等于冗长。 真正有价值的复杂Query，应该能够在搜索过程中暴露系统的能力短板。具体来说，它应该能够测试以下几个维度：能否检索到真正相关的信息、搜索偏离后是否会进行Query改写、不同来源信息冲突时如何判断证据可靠性、发现搜索方向错误后是否会重新规划、多步搜索后是否仍能保持初始目标、信息过期时是否能意识到时间因素的重要性。 因此，构造复杂Query的核心思路是：加入真实搜索过程中会出现的各类约束条件。

能力维度拆分与难度分级

为了使评测集更加精细化，建议将Query按照能力维度进行分类，而不是简单使用Easy/Hard二分法。主要能力维度包括： - Retrieval：能否搜到正确信息 - Rewrite：搜不到时会不会改写Query - Multi-hop：能否跨多个信息点整合 - Grounding：能否基于可靠证据回答 - Replanning：搜偏后会不会重新规划 - Temporal：会不会处理时间变化 - Long-horizon：多步搜索后是否还能保持目标 - Stopping：证据足够时能不能停止 这样拆分后，评测结果会从一个总分细化到具体能力项，帮助开发者精准定位系统的薄弱环节。 关于难度分级，建议如下： Easy级别为单点事实查询，单次搜索基本能解决，不需要改写Query，不需要多来源整合，不存在时间冲突，如「OpenAI的CEO是谁？」 Medium级别需要简单整合，需要2到3个信息点，可能需要简单Query Expansion、比较、总结或归纳，如「Cursor和Windsurf的主要区别是什么？」 Hard级别带有明确困难约束，包括

样本配比与过程指标监控

关于训练集和评测集的样本配比，需要区分两者的不同目标。训练集的目标是稳定学习能力，因此不能一上来全是困难样本，建议配比为Easy 60%、Medium 30%、Hard 10%。原因是Hard Query的搜索链路更长，reward更稀疏，训练波动也更大，如果Hard样本过多，RL训练很容易不稳定。 评测集的目标是暴露问题，因此困难样本比例可以更高，建议配比为Easy 30%、Medium 35%、Hard 35%。因为线上真实Query中Easy本来就很多，如果评测集也以Easy为主，分数会很好看，但很难看出系统在复杂搜索场景下的真实上限。 一个小经验是：用Easy样本看基础能力有没有退化，用Medium样本看真实用户场景表现，用Hard样本专门压测搜索链路的薄弱点。 最后，Search Agent的评测不能只看最终答案，因为很多错误早在搜索过程中就已经发生。建议记录以下过程指标：search_count（搜索次数）、rewrite_count（改写Query次数）、replan_count（重新规划次数）、retrieval_hit（是否搜到关键证据）、traje

如有侵权，请联系删除。