Keenable AI Open-Sources NEEDLE: A Live Search Benchmark That Rebuilds Its Query Set Every Hour

发生了什么

NEEDLE 这个名称本身是一组首字母缩写，分别对应 News、Everyday、Expert、Deep-tail、Legal Evaluation 五个垂直方向，覆盖新闻、专家知识、长尾稀有实体与法律等检索场景。

基准的另一项关键设计是查询集会持续滚动重建。新闻与日常类查询每小时由 RSS 订阅源与 Google Trends 重新生成，金融、学术、法律与稀有实体类查询则每天从 SEC XBRL、arXiv、Europe PMC、CourtListener、Wikidata、GLEIF 等来源拉取重新组装。这意味着每条查询在被检索时仍是真实存在的网页或记录，避免了离线基准常见的答案陈旧问题。

在协议层面，NEEDLE 对 15 个搜索 API 在同一调用协议下进行评测，仓库以 MIT 协议开源，可在笔记本或持续集成流水线中直接运行，评判环节通过 OpenRouter 调用大模型。

针对不同类型的查询，评测采用差异化打分：新闻与稀有实体类没有单一正确答案，由大模型评委按 0 到 4 分逐项打分，再以加入重复 URL 惩罚的 nDCG@5 汇总；金融类按 answer-recall@5 评分；学术与法律类则通过标识符匹配打分。每条证据截取长度上限为 2000 字符，评委看不到引擎名称，不抓取页面也不重排，并发固定为 1，以减少工程差异干扰。

基准还内置一个被称为 ultimate 的池化神谕引擎。它把同一窗口内所有被测引擎的结果合并去重，用来衡量在该垂直方向上行业整体理论上能达到的上限。各引擎得分与 ultimate 的差距，用于区分召回不足与排序不准这两类常见问题。

在 2026 年 8 月 28 日截止的 7 天均值窗口中，金融类的 answer-recall@5 排名靠前者依次为 Exa 0.910、Keenable 0.872、Perplexity 0.871、Google 0.847，同期神谕引擎得分为 0.965。同一窗口的延迟中位数显示 Keenable-realtime 为 193 毫秒，Exa 为 1876 毫秒，Bing 为 2767 毫秒，差距来自是否实时抓取与并发上限设置。深度稀有实体类中 Exa 0.557、Keenable 0.470、Bing 0.199；学术类 Keenable 0.774、Tavily 0.310，对应神谕引擎为 0.869。

时间线与证据

报道发布于 2026 年 8 月 31 日晚，所引用的排行榜数据来自此前一周的滚动均值窗口，窗口结束日为 2026 年 8 月 28 日。这意味着上述数字反映的是基准上线初期的快照，而非全年走势。

支撑这一时点的是 NEEDLE 自身的查询重建机制。新闻与日常类每小时由 RSS 与 Google Trends 重新生成，金融、学术、法律与稀有实体类每日从 SEC XBRL、arXiv、Europe PMC、CourtListener 等重新组装。也就是说，窗口内的每条查询在被检索时都对应真实存在的网页或记录，金融类查询直接绑定到当天仍在生效的 SEC 申报条目，学术与法律类则关联到当天刚上线的 arXiv 预印本或法院文书。由于查询每小时或每天滚动，7 天均值实际上由 168 组新闻类小时窗口与 7 组其余垂直的日窗口拼合而成。

评测口径与证据处理也对应到具体可观察的指标。金融类按 answer-recall@5 评分，0.910 与 0.847 的差距意味着同一组 SEC XBRL 文档中，Exa 平均多召回约六个百分点的高价值答案。新闻与稀有实体类由大模型评委按 0 到 4 评分后再以加入重复 URL 惩罚的 nDCG@5 汇总，因此深度稀有实体类中 Exa 0.557、Bing 0.199 的差距同时包含召回与排序两层差异。每条证据截取长度上限为 2000 字符，评委看不到引擎名称，不抓取页面也不重排，并发固定为 1，由此排除了抓取策略与并发差异对评分的干扰，使 193 毫秒与 2767 毫秒的延迟差距能够被单独归因到实时性差异。

需要注意的是，报道仅披露了 Exa、Keenable、Perplexity、Google、Tavily、Bing 等部分引擎的数字，15 家 API 的完整名单与其余得分未在文中给出，新闻类与法律类的窗口均值也未列出，因此横向比较只能限定在已公开的子集之内。

具体变化

相较于传统一次性基准，NEEDLE 把数据生命周期从发布那一刻延伸到了评测运行当下。新闻与日常类查询由 RSS 订阅源与 Google Trends 每小时重新生成，旧的链接退出，新的链接进入，查询池的构成每小时都在变化；金融、学术、法律与稀有实体类查询每日从 SEC XBRL、arXiv、Europe PMC、CourtListener、Wikidata、GLEIF 等来源重新拉取装配，金融题面绑定到当日生效的申报条目，学术与法律题面关联到当日新上线的预印本或法院文书。

来源的多样性决定了各垂直的更新节奏不同。新闻依赖 RSS 与 Google Trends 抓取热度变化，刷新频率最高；金融、学术、法律与稀有实体分别依赖结构化数据库的官方更新，节奏被锁定在每日一次。稀有实体类额外引入 Wikidata 与 GLEIF 作为标识来源，使得同一类实体可以在不同维度被检索到。

打分口径随垂直类型变化。新闻与稀有实体类无单一正确答案，由通过 OpenRouter 调用的大模型评委按 0 到 4 分逐项打分，再以加入重复 URL 惩罚的 nDCG@5 汇总；金融类按 answer-recall@5 评分；学术与法律类则通过标识符匹配打分。每条证据截取长度上限 2000 字符，评委看不到引擎名称，不抓取页面也不重排，并发固定为 1。

评测协议同时控制工程变量。统一的调用协议、固定的并发与截断长度、隐藏引擎名称的盲评方式，使不同搜索 API 之间的差距主要反映在检索与排序能力上，而不是抓取策略或重排实现上。神谕引擎把同一窗口内所有被测结果合并去重，得到该垂直方向上行业整体理论上限，各引擎得分与该上限的差值由此可被拆分为召回差距与排序差距两类。

对使用者的影响

对使用者的影响

对需要选型的工程团队而言，NEEDLE 提供了一个可以本地复现的对照环境。仓库以 MIT 协议开源，统一的调用协议使 15 个搜索 API 接入同一评测流程，开发者既能在笔记本上跑完整套垂直，也能把同一段逻辑接入持续集成流水线，对候选引擎做回归比对。由于并发固定为 1、每条证据截取长度上限 2000 字符、评委看不到引擎名称，差距主要落在检索与排序本身，而不是抓取或重排策略。对于实时性敏感的场景，193 毫秒与 2767 毫秒的延迟中位数差距直接来自是否实时抓取与并发上限设置，可作为接入成本的参考。

对研究者而言，ultimate 池化神谕引擎把同一窗口内所有被测结果合并去重，给出该垂直方向上行业整体理论上能达到的上限。在金融类 0.965、学术类 0.869 这一参照下，Exa 0.910、Keenable 0.774 等公开数字与上限之间的距离，可被进一步拆解为召回差距与排序差距，从而区分检索能力不足与排序不准这两类问题。

但使用者也面对公开数据的边界。报道仅披露 Exa、Keenable、Perplexity、Google、Tavily、Bing 等部分引擎的数字，15 家 API 的完整名单与剩余得分未在文中列出，新闻类与法律类的窗口均值同样缺席，横向比较只能限定在已公开子集内。OpenRouter 评判所用的具体模型与提示词未披露，ultimate 方法在金融、学术、稀有实体之外的垂直上是否同样适用也未说明，MIT 协议对 Hugging Face 数据集等附属资产是否一并覆盖同样未明确。

限制与未知

首先是被测引擎覆盖范围的缺口。报道仅披露 Exa、Keenable、Perplexity、Google、Tavily、Bing 这几家数字，15 家 API 的完整名单及其余得分未在文中给出，新闻类与法律类的窗口均值同样缺席，横向比较只能限定在已公开子集之内，无法对全部 15 家做完整排序。

其次是评判流程的不透明。OpenRouter 评判所用的具体模型与提示词未披露，新闻与稀有实体类 0 到 4 分的逐项打分标准、加入重复 URL 惩罚后 nDCG@5 的具体惩罚权重也未给出，外部研究者难以复现同口径评分。

再者是神谕引擎的适用范围存疑。ultimate 池化方法在金融、学术、稀有实体三个垂直上用于衡量行业上限，但在其他垂直上是否同样适用，报道未作说明，神谕与单引擎差距在新闻、法律等类别中的解释力尚未验证。

最后是协议覆盖范围未完全明确。MIT 协议覆盖了仓库代码，但 Hugging Face 数据集等附属资产是否一并适用同样开源协议，报道未明确说明，使用者在二次分发相关数据时存在边界模糊。

如何核对

要对齐到 NEEDLE 的口径，第一步是把查询重建机制落到具体来源。新闻与日常类查询每小时由 RSS 订阅源与 Google Trends 重新生成，金融、学术、法律与稀有实体类每日从 SEC XBRL、arXiv、Europe PMC、CourtListener 等数据库重新装配，稀有实体类还引入 Wikidata 与 GLEIF 作为标识来源。在核对榜单上的某一类均值时，应先确认该均值对应的小时或日窗口与题目来源一致，再与原始 RSS 链接、SEC 申报条目、arXiv 预印本或法院文书逐条比对，排除掉因链接过期或撤稿而失效的样本。

第二步是把评分口径对齐到具体指标。金融类使用 answer-recall@5，可直接以 SEC XBRL 标识符对召回的前五条做计数核查；学术与法律类走标识符匹配，可用 arXiv 编号与法院案号在返回结果中检索；新闻与稀有实体类需要复现 OpenRouter 评委的 0 到 4 分打分，并按加入重复 URL 惩罚的 nDCG@5 汇总，由于提示词与惩罚权重未披露，核对结果会有偏差。每条证据截取长度上限 2000 字符、评委看不到引擎名称、不抓取页面也不重排、并发固定为 1，这些约束要在复现脚本里逐项落地，否则同一组查询得到的得分会偏离原榜单。

第三步是核对延迟数字。报道给出的 193 毫秒、1876 毫秒、2767 毫秒都是同一窗口内的中位数，复现时应保持并发为 1，并显式记录是否开启实时抓取，因为延迟差距主要由这一开关决定，而非网络状况。Keenable-realtime 的低延迟与 Bing 的高延迟并列出现，正是用于区分实时与缓存两条接入路径。

最后是与神谕上限做差距分解。神谕引擎把同一窗口内所有被测结果合并去重，给出该垂直方向上的理论上限，金融类 0.965、学术类 0.869 这两个数字应作为召回上限的参照。核对时把单引擎得分与上限逐项相减，差额可被拆分为召回差距与排序差距两类，从而判断问题出在覆盖范围还是在排序质量。

读者能做什么

拿到这份基准的开发者可以把仓库拉到笔记本或 CI 环境里直接复现 15 个搜索 API 的对照评测。统一的调用协议把各家引擎接入同一流程，固定并发为 1、每条证据截取长度上限 2000 字符、评委看不到引擎名称，这些约束在脚本里逐项落地后，候选引擎的回归比对就能在本地完成，而不必依赖外部榜单。对于关心接入成本的团队，193 毫秒、1876 毫秒、2767 毫秒这一组同一窗口延迟中位数可以直接拿来估算实时与缓存两条路径的开销差距。

选型时可以把公开数字与神谕上限并列阅读。神谕引擎把同一窗口内所有被测结果合并去重，得到金融类 0.965、学术类 0.869 这类理论上限。把 Exa 0.910、Keenable 0.872、Perplexity 0.871、Google 0.847 这几个金融类数字与 0.965 相减，差额可以拆成召回差距与排序差距两部分，进而判断某家引擎的短板落在覆盖范围还是在结果排序。深度稀有实体类 Exa 0.557 与神谕上限之间、学术类 Keenable 0.774 与 Tavily 0.310 之间，同样可以照此分析。

使用过程中应核对查询重建机制与自身需求是否匹配。新闻与日常类依赖 RSS 与 Google Trends 每小时刷新，适合评估突发热点的抓取能力；金融、学术、法律与稀有实体类从 SEC XBRL、arXiv、Europe PMC、CourtListener、Wikidata、GLEIF 等每日重新装配，更贴近结构化数据的核对场景。把自身业务的刷新节奏与基准的更新窗口对齐，才能让本地复现的得分与公开榜单口径一致。

最后要注意公开数据的边界。报道仅披露了 Exa、Keenable、Perplexity、Google、Tavily、Bing 等部分引擎的数字，15 家 API 的完整名单与剩余得分未在文中给出，新闻类与法律类的窗口均值同样缺席，横向比较只能限定在已公开子集之内。OpenRouter 评委所用的具体模型与提示词未披露，ultimate 池化方法在金融、学术、稀有实体之外的垂直上是否同样适用未作说明，MIT 协议是否一并覆盖 Hugging Face 数据集等附属资产也未明确，二次分发与跨垂直复用前需要先确认这些边界。

后续观察

围绕 NEEDLE 后续走向，可以从几条线索继续跟进。

数据再发布节奏值得跟踪。报道引用的排行榜截至 2026-08-28，对应一个 7 天均值窗口，文章本身发表于 2026-08-31。新闻与日常类查询每小时重建，金融、学术、法律与稀有实体类每日重建，因此下一个窗口的均值会随 RSS 订阅源、Google Trends、SEC XBRL、arXiv、Europe PMC、CourtListener、Wikidata、GLEIF 的更新而漂移，原本不在披露名单中的引擎如果进入新窗口，有可能改变 Exa 0.910、Keenable 0.872、Perplexity 0.871、Google 0.847 在金融类的相对位次。

被测引擎覆盖范围有望补全。报道只给出 Exa、Keenable、Perplexity、Google、Tavily、Bing 的数字，剩余引擎的具体得分未披露。随着仓库以 MIT 协议开源并在 Hugging Face 等平台发布，完整 15 家 API 名单与各垂直得分很可能在后续更新中陆续公布，新闻类与法律类窗口均值也有望补齐，这会直接影响横向比较的完整性。

评判流程的透明度需要等待进一步披露。OpenRouter 担任评委接口，但具体调用的模型与提示词未给出，新闻与稀有实体类 0 到 4 分的逐项打分标准以及 nDCG@5 中重复 URL 惩罚的权重也未公开。如果后续仓库或评测报告补充这些参数，外部研究者就能在统一口径下复现同一窗口的得分，否则核对只能停留在指标定义层面。

神谕引擎的适用范围有待验证。ultimate 池化方法在金融类 0.965、学术类 0.869、稀有实体类 0.869 上用于衡量行业上限，在其余垂直上是否同样适用尚未说明。随着覆盖范围扩大，神谕上限与单引擎差距在新闻、法律等类别的解释力值得进一步观察。

延迟口径也需要留意后续披露。193 毫秒、1876 毫秒、2767 毫秒均为同一窗口中位数，并发固定为 1，并显式区分实时抓取与缓存路径。在新的窗口里，这一组数字是否会随被测引擎调整或网络条件变化，是判断实时与缓存两条接入路径成本差距的关键参考。