这篇文章探讨了如何构建能真正测试搜索代理能力的复杂查询，避免简单堆砌信息，而是聚焦于暴露搜索系统的能力短板。
核心内容：
剖析真实线上查询的局限性，提出构建评测集的三个核心问题
从真实查询出发，通过六种方法（如多跳、时间约束）构造有价值的复杂查询
强调复杂查询的核心是加入真实搜索过程中会出现的有效约束
最近技术群的老哥问了一个非常贴合实际的问题：
给大家分享一下小逸的经验~
在搜索场景下怎么样去构造评测数据？
首先我们思考一下，我们在测评 Search Agent / DeepSearch的时候，需要怎么构建测试集？
一个简单的想法就是：直接拿线上的Query日志不就好了吗？
但问题是，真实用户大部分问题都是简单查事实，并且口语化严重，真正能暴露 Agent 搜索能力的问题，比例并不高。
所以构建评测集时，不能只依赖线上原始 Query。
我们需要思考这三个问题：
除了真实 Query，还能怎么构造复杂 Query？
困难样本里的“困难约束”应该怎么挖掘？
简单样本和困难样本的比例应该怎么配？
复杂 Query 不能只靠写长
很多人在构造复杂 Query 时，很容易走到一个误区：
把问题写得很长、加很多限定词、塞很多实体，就觉得它是 Hard Query。
但在搜索场景里，复杂不等于长。
真正有价值的复杂 Query，应该能让系统在搜索过程中暴露能力短板。
比如：
能不能搜到真正相关的信息
搜偏之后会不会改写 Query
不同来源冲突时会不会判断证据
搜索中途发现方向错了，会不会重新规划
多步搜索后，会不会忘记最初目标
信息过期时，会不会意识到时间变化
所以构造复杂 Query 的核心，是给 Query 加入真实搜索过程中会出现的约束。
那么这些约束从哪里来？最稳妥的来源，还是线上真实的用户问题。
从真实 Query 出发，避免完全凭空造
首先我建议，先把线上困难的真实Query作为种子数据，再围绕它扩增复杂版本。
比如原始 Query 是：
OpenAI 收购 Windsurf
它本身只是一个简单事实查询。
但可以扩展成：
OpenAI 收购 Windsurf 之后，对 Cursor 的产品定位和商业化会有什么影响？
这样就从一个单点事实问题，变成了需要搜索事件、产品能力、竞品关系、市场影响的复杂问题。
种子有了，下一步的问题是：从一个简单 Query 出发，具体可以往哪些方向扩？下面这 6 种方法是我常用的几条路径。
构造复杂 Query 的 6 种方法
增加 Multi-hop 约束
Multi-hop 可以理解为：回答这个问题不能只看一个网页或一个事实点，需要跨多个信息源做整合。
原始 Query：
Windsurf 是什么？
复杂版本：
Windsurf 和 Cursor 在产品能力、目标用户、商业化路径上有什么差异？
这个问题至少需要搜索：
Windsurf 的产品定位
Cursor 的产品定位
两者功能差异
两者面向的用户群
可能的商业模式
这种复杂度是有意义的，因为它测的是信息整合能力。
增加时间约束
搜索场景里，时间非常关键。
很多答案只在某个时间点正确，过一段时间就可能失效。
可以把普通 Query 改造成带时间约束的 Query。
比如：
2024 年大家对某个 AI Coding 产品的评价是什么？
可以扩展成：
2024 年到 2026 年，这个 AI Coding 产品的定位发生了哪些变化？
这样就要求系统区分不同时间点的信息，不能拿旧资料回答新问题。
这类 Query 适合测试 Temporal Drift，也就是时间漂移问题。
增加证据冲突约束
真实搜索里，不同来源经常说法不一样。
比如：
官方公告说得很谨慎
媒体报道会更激进
博客文章会加入主观分析
社交平台会有很多未经验证的信息
可以构造这类 Query：
关于某公司收购某产品，不同媒体说法不一致，哪些信息是确定的，哪些只是推测？
这种问题的价值在于，它要求系统判断证据可靠性，而不只是给出一个结论。
它适合测试 Grounding，也就是回答是否真的建立在证据上。
增加检索陷阱
有些 Query 看起来很简单，但搜索结果很容易跑偏。
常见原因包括：
实体名有歧义
缩写有多个含义
产品名和普通词重名
中英文叫法不一致
比如：
Agent 可能是 AI Agent，也可能是代理人
Memory 可能是大模型记忆，也可能是计算机内存
Rust 可能是编程语言，也可能是铁锈
Apple 可能是公司，也可能是水果
这类 Query 可以测试系统能不能识别语境，避免看到高相关搜索结果就直接相信。
增加 Rewrite 约束
真实用户根本不会输入非常有逻辑且严谨的Query。
很多线上 Query 是这样的：
那个最近很火的 coding agent 是什么？
这种问题原句直接搜，可能很难搜到准确答案。
系统需要自己改写 Query，比如补充关键词、换英文表达、加入产品名或事件名。
而构造这类复杂 Query 的方法是：
把标准表达改成用户表达。
标准表达：
OpenAI 收购 Windsurf 与 Cursor的影响是什么？
用户表达：
那个 coding agent 收购案会不会影响 Cursor？
这类样本可以专门测试 Query Rewrite 能力。
增加 Long-horizon 约束
Long-horizon 的关键不在于搜索步骤变多。
它真正的含义是：
后面的判断依赖前面很多步的信息。
比如：
请比较 OpenAI 收购 Windsurf 前后，AI Coding 工具市场里 Cursor、Windsurf、GitHub Copilot 的定位变化。
这个问题里，系统需要一直记住几个对象、几个时间点和几个比较维度。
很容易出现的问题是：
搜着搜着只讲 Cursor
忘记 Windsurf 被收购前后的变化
把 GitHub Copilot 的旧资料当成新资料
最后没有回到“定位变化”这个核心问题
这类 Query 可以测试长链路搜索中的目标保持能力。
困难样本的约束应该怎么挖掘？
复杂 Query 需要从失败模式里挖掘约束。
可以把线上失败 Case 拆开看：搜索到底是在哪里失败的？
这里，我个人先总结一下常见的失败模式
| 失败模式 | 可以转化成的困难约束 |
| — | — |
| 搜索结果跑偏 | 增加歧义词、缩写、同名实体 |
| 第一次搜不到 | 使用口语表达、别名、非标准术语 |
| 答案引用了过期信息 | 增加时间范围、最新状态、前后变化 |
| 不同来源说法冲突 | 增加官方/媒体/博客多来源对比 |
| 多步后目标漂移 | 增加多个对象、多个维度、前后比较 |
| 回答没有证据 | 要求区分事实、推测和观点 |
| 搜索次数过多 | 设计已经有充分证据即可停止的问题 |
那么这些问题，该如何解决？
一个比较有效的流程是：
收集线上失败 Query
标注失败原因
把失败原因抽象成约束类型
围绕同一约束扩增相似 Query
人工过滤掉无意义的复杂问题
这里人工过滤很重要（这里人工可以标一些数据，尝试下自动化）
因为 LLM 很容易生成两类有问题的样本：
fake hard：看起来复杂，但其实搜索一下就能回答
meaningless hard：问题本身不清楚，人类也不知道怎么答
好的困难样本应该满足一个标准：
人类能理解，但 Agent 容易在搜索过程中犯错。
把复杂 Query 拆成几个能力维度
为了让评测集更可控，不要只用 Easy / Hard 这种粗粒度标签，需要给每个 Query 更加细粒度的分类。
这里举个例子：
| 能力维度 | 说明 |
| — | — |
| Retrieval | 能不能搜到正确信息 |
| Rewrite | 搜不到时会不会改写 Query |
| Multi-hop | 能不能跨多个信息点整合 |
| Grounding | 能不能基于可靠证据回答 |
| Replanning | 搜偏后会不会重新规划 |
| Temporal | 会不会处理时间变化 |
| Long-horizon | 多步搜索后是否还能保持目标 |
| Stopping | 证据足够时能不能停止 |
这样做的好处是：
评测结果会从一个总分，进一步拆到系统具体弱在哪里。
比如：一个模型总分还可以，但 Rewrite 分很低，就说明它可能只适合标准表达的 Query，不适合真实用户口语表达。
Easy / Medium / Hard 应该怎么定义？
Easy：单点事实查询
特点：
单次搜索基本能解决
不需要改写 Query
不需要多来源整合
不存在明显时间冲突
例子：
OpenAI 的 CEO 是谁？
这类样本用于测试基础检索和事实回答。
Medium：需要简单整合
特点：
需要 2 到 3 个信息点
可能需要简单 Query Expansion
需要比较、总结或归纳
但不一定有明显陷阱
例子：
Cursor 和 Windsurf 的主要区别是什么？
这类样本更接近用户真实的研究型问题。
Hard：带有明确困难约束
特点：
有歧义或检索陷阱
需要 Query Rewrite
需要跨来源整合
有时间变化
有证据冲突
多步搜索后容易目标漂移
例子：
OpenAI 收购 Windsurf 后，对 Cursor、GitHub Copilot 这类 AI Coding 工具的产品定位和商业化可能有什么影响？哪些结论有公开证据支持，哪些只是推测？
这个问题的难点来自它同时包含：
多对象比较
时间变化
证据判断
市场影响分析
事实和推测区分
简单、中等、困难样本怎么配比？
这里要区分训练集和评测集。
训练集的目标是，稳定的学到能力，所以不能一上来全是困难样本。
评测集的目标是暴露问题，所以困难样本比例可以更高。
训练集我这里给一个大概的比例
| 难度 | 比例 |
| — | — |
| Easy | 60% |
| Medium | 30% |
| Hard | 10% |
这里这样给的原因是 Hard Query 往往搜索链路更长，reward 更稀疏，训练波动也更大。
如果 Hard 样本太多，RL 训练很容易不稳定。
评测集的话
| 难度 | 比例 |
| — | — |
| Easy | 30% |
| Medium | 35% |
| Hard | 35% |
评测集里可以提高 Hard 的比例。
因为线上真实 Query 里 Easy 本来就很多，如果评测集也以 Easy 为主，分数会很好看，但很难看出系统在复杂搜索场景下的上限。
一个小小的经验是：
用 Easy 样本看基础能力有没有退化
用 Medium 样本看真实用户场景表现
用 Hard 样本专门压测搜索链路的薄弱点
评测时不要只看最终答案
Search Agent 的评测不能只看 final answer。
因为很多错误早在搜索过程中就已经发生，最后一步只是把问题暴露出来。
这里需要记录下过程的指标，例如：
| 指标 | 说明 |
| — | — |
| search_count | 搜索了几次 |
| rewrite_count | 改写 Query 的次数 |
| replan_count | 重新规划的次数 |
| retrieval_hit | 是否搜到关键证据 |
| trajectory_length | 搜索链路长度 |
| evidence_support | 回答是否被证据支持 |
| source_quality | 来源是否可靠 |
| stop_efficiency | 是否在合适时机停止 |
这样才能知道模型到底是：
没搜到
搜到了但没看懂
看懂了但整合错
中途目标漂移
被低质量证据带偏
这比只看最终正确率更有价值。
[登录查看剩余 70% 内容](javascript:void (0);)
提示词技巧AI提示词技巧prompt提示词技巧
分享：
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
53AI，企业落地大模型首选服务商
产品：场景落地咨询+大模型应用平台+行业解决方案
承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业
上一篇：codex官方推荐的10个实用技巧，用完效率翻倍下一篇：Playwright 1.59 新特性：3 个 API 帮你告别 F12 手动找定位
返回列表
相关资讯
2026-07-02 Claude团队：别再逐条喂Prompt，学会给Agent设计循环2026-07-02 Agent 怎么沉淀技能:把一个好 prompt 变成全队资产2026-07-01 从 Prompt 到 Skill：专业工作流的结构升级2026-07-01 别让 AI 写的文档误导用户：从单次 Prompt 到高可信文档工程化实践2026-06-30 网传 Karpathy 的 CLAUDE.md 曝光，10条铁律管住Claude Code！2026-06-29 AI Coding 的底层框架：一切优化都是在对抗熵增2026-06-29 给模型写方法论：拆解一个跨法域隐私审计Skill2026-06-28 别再手工调 prompt 了，让 Agent 自己改自己的"操作系统"
联系获取
联系获取
160+中大型企业正在使用53AI
[立即咨询](javascript:void(0))[预约演示](javascript:void(0))
把握AI发展的机遇，共同探索、共同进步 2025-01-22如何打造基于GenAI的员工服务机器人 2025-01-22
