搜索系统上线之后开发者最关心的问题往往是排序结果到底变好了没有这个问题看起来简单答案却经常被“评估集是否过时”这件事干扰。你用了三个月前整理的查询集合跑完一轮离线实验发现新模型的 Recall 提升了两个点于是放心发布。但真实世界里的用户早就开始搜索另一批词了。最近我关注到 Keenable AI 团队开源了一个名为 NEEDLE 的实时搜索基准核心特征不是堆测试用例而是把“查询集”变成会定时重建的资源每隔一小时查询集会重新生成一轮。这篇文章会围绕这套思路展开先聊一聊静态搜索基准的局限再拆解实时搜索基准需要考虑的模块最后用 Python 实现一个最小可运行的“小时级查询集重建评估器”帮你理解这类基准是如何工作的。如果你正在做搜索系统、RAG 问答或者要为大模型应用搭建评估体系这篇文章会比较适合。1. 为什么搜索评测开始关注查询集的新鲜度1.1 静态查询集的“时效衰减”很多搜索团队都维护着一份静态评测集里面包含几百到几千条查询并为每条查询标注了相关文档。这份评测集是离线和在线实验的重要参照模型改动后跑一遍同一份查询集对比指标就能判断改动方向是否正确。这套流程本身没有问题问题在于查询和文档之间的相关关系会随时间变化。我举一个很常见的例子假设你维护一个电商搜索系统三个月前评测集里有“无线鼠标 静音”“机械键盘 红轴”这类查询。当时的评测结果能很好地区分不同排序模型。但三个月后用户开始搜索“支持 AI 按键的键盘”“智能办公鼠标”时旧的查询集根本无法暴露新场景下的召回缺失。静态查询集的时效衰减可以拆成两个层面词汇层面某些词不再流行或者新的热词没有覆盖进评测集。语义层面同一个词背后的用户意图可能发生迁移。例如“旗舰机”在一月和三月的真实搜索结果可能对应完全不同的价位段。如果搜索系统一直只用旧查询集做评估团队很容易在“旧查询上稳定提升”的假象中错过真实流量的变化。这也是 NEEDLE 这类实时基准之所以出现的核心背景。1.2 数据集污染与榜单失真除了时效性问题静态基准还有一个长期痛点数据集污染。当某个评测集被广泛使用系统或模型会比较容易被隐性地调优到这份评测集上。公开评测集里的查询可能已经出现在搜索引擎的缓存结果中也可能进入了模型训练语料。结果就是评测指标看起来很高但系统在真实用户查询上的表现并没有同步提升。查询集越固定被“反向适配”的风险就越高。过去缓解方式通常是定期更换一部分测试样例但节奏往往以月或季度为单位。如果把更新粒度压缩到小时系统能“背题”的空间就会小很多。NEEDLE 的思路本质上是通过高频率重建查询集缓解静态数据泄露带来的榜单失真问题。1.3 查询集为什么需要按小时更新按小时更新听起来比较激进但对很多场景是合理的。搜索引擎和内容平台的热点查询生命周期可能很短。一个突发热点出现后用户查询量通常在几小时内快速爬升随后又迅速消退。如果评测集每天只更新一次朝九晚九两个时段的用户意图差异就可能被忽略如果每周更新一次热点事件带来的查询意图变化就几乎无法进入评估视野。尤其现在很多搜索场景开始和大模型结合RAG 系统需要从知识库中检索内容并生成回答。这类系统对“最新问题”的敏感度更高查询集的新鲜度直接影响最终问答质量。当然并不是所有业务都需要小时级评估。对于文档内容稳定、用户查询意图变化很慢的内部知识库搜索周级别或月级别重建查询集可能更合适。NEEDLE 的价值在于把“按小时更新查询集”从工程上变成可能而不是要求所有业务都必须照搬。2. Keenable AI 和 NEEDLE一个实时重建查询集的搜索基准2.1 NEEDLE 要解决什么问题NEEDLE 可以理解为一个面向实时搜索评估的开源基准项目。它的目标不是提供一个固定不变的测试集而是提供一套持续生成新查询、并对搜索系统进行动态评估的机制。项目名 NEEDLE 隐含着一种搜索场景的比喻在大量不断变化的信息中依然要快速找到那根“针”。传统搜索基准给人的感觉像是一张静态地图地图在绘制那一刻是准确的但城市每天都在变化。NEEDLE 的做法更像雷达扫描每隔一小时重新看一次当前环境。因为公开资料有限我们还需要等更多细节。但作为开发者不必等官方仓库把所有代码放出来才行动。NEEDLE 带来的最大启发是把“评测集维护”从一个低频任务变成了高频自动化任务。这背后的工程问题比想象中更多新查询从哪里来相关文档标注如何产生旧的查询集是否完全丢弃指标抖动如何解释2.2 “每小时重建查询集”意味着什么“重建”不只是从查询列表里重新抽样它至少包含三层动作生成新查询在当前时间窗口内构造一系列能够反映用户真实搜索意图的查询。获取或标注结果对每个新查询得到文档集合或候选结果判断哪些文档是相关的。校验与归档确认本次查询集质量后执行评估并保存结果。如果把评测循环看成一套流水线每小时重建查询集就是让流水线以小时为周期快速运转。这种高频运转会和传统的离线评测模式产生明显冲突。过去评测集由人工整理规模大、质量高但成本也高不可能每小时人工做一次。因此 NEEDLE 这类项目必须依靠自动化方法生成查询。自动化生成查询的常见来源包括业务搜索日志中的高频查询尤其是过去一小时内出现的新查询。公开趋势信息或事件化的查询通过合规渠道获取后作为生成素材。基于种子查询改写、组合和扩展生成一批语义相似但有差异的变体。利用大模型生成更接近于真实用户的自然语言查询。真正需要审慎设计的是相关文档标注。一个查询生成出来之后搜索系统需要有一个评判依据否则只能记录候选结果无法计算精确率、召回率。对这个问题业界常见做法是用历史点击数据作为弱标注或者每隔一段时间对部分查询进行人工抽检。2.3 它适合评估哪些现实场景NEEDLE 这种模式不完全适用于所有搜索场景它更适合内容更新速度快、用户查询变化频繁的领域。典型场景包括内容资讯搜索热点事件、突发事件、产品发布都会带来新的查询。电商商品搜索新品上架、季节性促销会快速改变需求分布。RAG 增强问答知识库本身变化后查询集也需要同步观察问答效果。开发者文档检索技术框架更新后开发者会立刻搜索新概念。对这些场景来说评估的核心目的不是“模型在一个固定能力上的绝对分”而是“系统在跟进当前信息变化上的灵敏度”。如果查询集长期不变那么即使系统在真实流量中已经发生明显的召回漂移评估指标也感知不到。3. 实时搜索基准的核心设计拆解3.1 查询集生成不是“随机换一批词”很多人在设计实时基准时会误以为只要把查询集随机换一批词就可以了。实际操作中随机性只会引入噪声让两次评估结果不具备可比性。一个合格的查询集生成器需要具备以下特性可复现性每个小时有确定的时间键例如“2025060214”。同一时间键下生成的查询集必须完全一致。语义规模感查询数量不一定要大但要覆盖多个意图类别例如热点查询、问题型查询、长尾查询。可控新鲜度既要包含当前小时的新增查询也要保留一小部分历史锚点查询以便观察系统长期趋势。去重与清洗避免模板生成大量无意义文本例如重复的标点、无实义的停顿词。NEEDLE 如果把重建粒度定为每小时那么它背后的查询生成器一定是可复现的否则工程上很难回溯问题某小时指标下降了如果查询集本身不可复现就无法判断是系统回归还是查询集噪声。这里我建议在学习阶段先用一个简单时间戳作为随机种子。这样每次跑同一小时的评估查询集完全一致不同小时之间查询集又会发生变化。3.2 相关文档如何确定查询集重建之后下一个难题是相关文档。搜索评测最常见的指标是 PK、RecallK、nDCGK无论哪个指标都需要知道一个查询对应的相关文档集合。自动化实时评测很难保证每条新查询都有完整标注。比较现实的折中方案是分层处理锚点查询层保留一批人工标注好的种子查询长期保留在评测集中用来对比系统不同版本的表现。趋势查询层每小时生成的新查询不要求立即拥有完整标注而是先保存候选结果再通过点击反馈、用户行为或人工抽检补标。延迟标注层对暂无法判断相关性的查询只记录检索结果供后续回溯时使用。看到这里你应该明白真正让实时搜索基准难以落地的不是查询生成服务而是“标注闭环”。如果查询每过一小时就更换一次标注团队必须能够跟上这个节奏。NEEDLE 如果能够在开源生态里解决一部分自动化标注问题那它的价值会比单独发布一份测试集更大。3.3 指标与结果存档层实时基准还需要考虑结果存档。传统静态评测集中一组查询可以用很久指标结果可以长期存放在表格里。但在小时级评测中每一小时都会产生新的查询集、新的文档候选和新的指标如果只记录最终指标而不记录查询集和检索详情后续根本无法排错。推荐的存档结构至少包含当前评估轮次的时间戳例如 datehour。本轮完整查询列表。每条查询生成的检索文档 ID 列表。每条查询的相关文档标注。每条查询的指标明细。本轮聚合指标例如平均 P5、平均 Recall5、用户查询覆盖率。这里要说一个容易被忽略的问题并不是每条查询都需要进入最终指标计算。对于没有相关文档标注的新查询只记录候选结果即可。如果把这类查询硬塞进指标计算就会把“无标注”误判为“零相关”导致指标失真。3.4 实时重建也要关注“连续可比性”高频评测带来的另一个新问题是指标波动。同一系统在相邻两个小时的 P5 可能突然