大家好，我是刘聪NLP。
最近技术群的老哥问了一个非常贴合实际的问题：
给大家分享一下小逸的经验~
在搜索场景下怎么样去构造评测数据？
首先我们思考一下，我们在测评 Search Agent / DeepSearch的时候，需要怎么构建测试集？
一个简单的想法就是：直接拿线上的Query日志不就好了吗？
但问题是，真实用户大部分问题都是简单查事实，并且口语化严重，真正能暴露 Agent 搜索能力的问题，比例并不高。
所以构建评测集时，不能只依赖线上原始 Query。
我们需要思考这三个问题：
- 除了真实 Query，还能怎么构造复杂 Query？
复杂 Query 不能只靠写长
很多人在构造复杂 Query 时，很容易走到一个误区：
把问题写得很长、加很多限定词、塞很多实体，就觉得它是 Hard Query。
但在搜索场景里，复杂不等于长。
真正有价值的复杂 Query，应该能让系统在搜索过程中暴露能力短板。
比如：
所以构造复杂 Query 的核心，是给 Query 加入真实搜索过程中会出现的约束。
那么这些约束从哪里来？最稳妥的来源，还是线上真实的用户问题。
从真实 Query 出发，避免完全凭空造
首先我建议，先把线上困难的真实Query作为种子数据，再围绕它扩增复杂版本。
比如原始 Query 是：
OpenAI 收购 Windsurf
它本身只是一个简单事实查询。
但可以扩展成：
OpenAI 收购 Windsurf 之后，对 Cursor 的产品定位和商业化会有什么影响？
这样就从一个单点事实问题，变成了需要搜索事件、产品能力、竞品关系、市场影响的复杂问题。
种子有了，下一步的问题是：从一个简单 Query 出发，具体可以往哪些方向扩？下面这 6 种方法是我常用的几条路径。
构造复杂 Query 的 6 种方法
增加 Multi-hop 约束
Multi-hop 可以理解为：回答这个问题不能只看一个网页或一个事实点，需要跨多个信息源做整合。
原始 Query：
Windsurf 是什么？
复杂版本：
Windsurf 和 Cursor 在产品能力、目标用户、商业化路径上有什么差异？
这个问题至少需要搜索：
这种复杂度是有意义的，因为它测的是信息整合能力。
增加时间约束
搜索场景里，时间非常关键。
很多答案只在某个时间点正确，过一段时间就可能失效。
可以把普通 Query 改造成带时间约束的 Query。
比如：
2024 年大家对某个 AI Coding 产品的评价是什么？
可以扩展成：
2024 年到 2026 年，这个 AI Coding 产品的定位发生了哪些变化？
这样就要求系统区分不同时间点的信息，不能拿旧资料回答新问题。
这类 Query 适合测试 Temporal Drift，也就是时间漂移问题。
增加证据冲突约束
真实搜索里，不同来源经常说法不一样。
比如：
可以构造这类 Query：
关于某公司收购某产品，不同媒体说法不一致，哪些信息是确定的，哪些只是推测？
这种问题的价值在于，它要求系统判断证据可靠性，而不只是给出一个结论。
它适合测试 Grounding，也就是回答是否真的建立在证据上。
增加检索陷阱
有些 Query 看起来很简单，但搜索结果很容易跑偏。
常见原因包括：
比如：
- Agent 可能是 AI Agent，也可能是代理人
- Memory 可能是大模型记忆，也可能是计算机内存
这类 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 的定位变化。
这个问题里，系统需要一直记住几个对象、几个时间点和几个比较维度。
很容易出现的问题是：
- 把 GitHub Copilot 的旧资料当成新资料
这类 Query 可以测试长链路搜索中的目标保持能力。
困难样本的约束应该怎么挖掘？
复杂 Query 需要从失败模式里挖掘约束。
可以把线上失败 Case 拆开看：搜索到底是在哪里失败的？
这里，我个人先总结一下常见的失败模式
那么这些问题，该如何解决？
一个比较有效的流程是：
这里人工过滤很重要（这里人工可以标一些数据，尝试下自动化）
因为 LLM 很容易生成两类有问题的样本：
- fake hard：看起来复杂，但其实搜索一下就能回答
- meaningless hard：问题本身不清楚，人类也不知道怎么答
好的困难样本应该满足一个标准：
人类能理解，但 Agent 容易在搜索过程中犯错。
把复杂 Query 拆成几个能力维度
为了让评测集更可控，不要只用 Easy / Hard 这种粗粒度标签，需要给每个 Query 更加细粒度的分类。
这里举个例子：
这样做的好处是：
评测结果会从一个总分，进一步拆到系统具体弱在哪里。
比如：一个模型总分还可以，但 Rewrite 分很低，就说明它可能只适合标准表达的 Query，不适合真实用户口语表达。
Easy / Medium / Hard 应该怎么定义？
Easy：单点事实查询
特点：
例子：
OpenAI 的 CEO 是谁？
这类样本用于测试基础检索和事实回答。
Medium：需要简单整合
特点：
例子：
Cursor 和 Windsurf 的主要区别是什么？
这类样本更接近用户真实的研究型问题。
Hard：带有明确困难约束
特点：
例子：
OpenAI 收购 Windsurf 后，对 Cursor、GitHub Copilot 这类 AI Coding 工具的产品定位和商业化可能有什么影响？哪些结论有公开证据支持，哪些只是推测？
这个问题的难点来自它同时包含：
简单、中等、困难样本怎么配比？
这里要区分训练集和评测集。
训练集的目标是，稳定的学到能力，所以不能一上来全是困难样本。
评测集的目标是暴露问题，所以困难样本比例可以更高。
训练集我这里给一个大概的比例
这里这样给的原因是 Hard Query 往往搜索链路更长，reward 更稀疏，训练波动也更大。
如果 Hard 样本太多，RL 训练很容易不稳定。
评测集的话
评测集里可以提高 Hard 的比例。
因为线上真实 Query 里 Easy 本来就很多，如果评测集也以 Easy 为主，分数会很好看，但很难看出系统在复杂搜索场景下的上限。
一个小小的经验是：
评测时不要只看最终答案
Search Agent 的评测不能只看 final answer。
因为很多错误早在搜索过程中就已经发生，最后一步只是把问题暴露出来。
这里需要记录下过程的指标，例如：
这样才能知道模型到底是：
这比只看最终正确率更有价值。
PS：都看到这里，来个点赞、在看、关注吧。
欢迎评论区多多讨论，说出你的想法，
也欢迎交个朋友，一起学习，一起进步！
当然想第一时间收到推送，也可以给我个星标⭐~
您的支持是我坚持的最大动力！
粤ICP备14082021号
免费POC，
零成本试错
