实时搜索基准 NEEDLE：用每小时重建的评测集解决 RAG 与 AI 搜索的时效性难题

如果你正在做 AI 搜索、RAG 问答或者 Agent 工具，那么最近开源社区出现的一个方向值得关注：把“评测基准”本身做成一套实时更新的系统。以前大家评测大模型检索能力，用的是几个月甚至一年前固定的问答集；现在 Keenable AI 团队开源的 NEEDLE 项目给出了一种新思路——查询集每小时重建，让基准测试始终贴着当前最新、最热的信息走。

这篇文章会从 NEEDLE 要解决的痛点讲起，拆解“实时搜索基准”背后的设计逻辑，说明它为什么在 AI 搜索和 RAG 场景中比传统静态评测集更有参考价值。同时我也会以工程化视角，给出一个团队如果想自建类似实时评测流水线的参考设计与部署示例，并对常见误区和落地建议做系统梳理。

1. 为什么需要“每小时重建”的搜索基准

先从一个真实场景说起。假设你负责一个企业知识库问答系统，底层接入了大模型和向量数据库。上线前，你用一批包含 500 条标准问答的测试集做了评测：准确率 88%，看起来不错。但上线两周后，用户开始反馈“回答过时了”“新政策查不到”“最近发生的热点事件完全不理解”。你再跑一遍评测集，发现准确率依然是 88%。问题出在哪？出在评测集本身是静态的。

这个现象不是个例。当前大量 RAG 应用和 AI 搜索产品的评测方式，本质上仍停留在“用历史问题检验历史知识”的阶段。测试集里的问题来自过去某段时间的文档、新闻或知识库快照，评测得到的结论只能说明系统在“那个时间点”的检索和生成能力，无法反映它在面对今天新出现的新闻、版本发布、政策变更、突发技术事件时的真实表现。

NEEDLE 这类“实时搜索基准”项目，正是对准了这个缺口。它在设计上不再把查询集当作固定的 Excel 表或 JSON 文件，而是通过自动化流水线，让查询集、对应的上下文语料和参考答案随着真实世界的信息更新而滚动刷新。以 Keenable AI 开源版本披露的设计目标来看，NEEDLE 追求的是“查询集每小时重建”的实时性——这意味着评测的不仅是搜索系统的历史记忆能力，更是它在最新信息环境下的发现能力、时效性判断能力和抗幻觉能力。

对开发者来说，这个转变的理解可以更直白：

• 传统基准评测的是“系统记住了多少”。
• 实时搜索基准评测的是“系统能不能快速找到最近一小时真正重要的事”。

从 AI 搜索产品评估的演进趋势看，这种“评测集实时化”会成为继 benchmark 扩大参数量、引入人类偏好之后的下一个关键方向。因为用户实际使用 AI 搜索时，提问的往往是当天的事情、最新的公告、刚发布的论文，而不是三个月前被反复筛选过的语料。评测体系如果不能覆盖这一类需求，测出来的分数和用户真实体感之间就一定存在偏差。

2. NEEDLE 核心概念与适用场景

2.1 NEEDLE 是什么

NEEDLE 是 Keenable AI 团队开源的一个面向实时搜索场景的评测基准项目。我需要先说明一点：由于目前公开材料有限，下面我基于标题信息和开源项目通用结构做一个体系化解读，你可以把它理解为“NEEDLE 这类实时搜索基准应该具备的完整技术画像”。

从名称和项目定位来看，NEEDLE 最核心的关键词有三个：实时（Real-time）、搜索（Search）、基准（Benchmark）。这与传统信息检索基准（如 MS MARCO、BEIR）的最大差异不在评测方法本身，而在于评测数据的生命周期管理。

传统基准通常是静态的：先确定一批文档集，再人工或半自动生成查询，人工标注相关性，之后整个评测集基本不再变化。NEEDLE 则把数据生命周期纳入设计目标：不断从实时信息源采集新文档，基于新文档自动生成查询和评估标准，再每隔固定时间重新构建评测集。这种设计方式让基准测试不再是“一次性用品”，而是可以持续运行的“评测监控系统”。

2.2 “实时”到底指什么

很多读者可能会问：实时搜索基准，是基准测试本身实时打分吗？这并不是 NEEDLE 强调的重点。从项目描述中的“实时搜索基准”来理解，“实时”首先指评测数据的新鲜度——文档、查询、对应答案都需要来自一个不断流动的语料来源。查询集每小时重建，意味着上午你在评测系统对科技新闻的检索能力，中午可能就换成了新的问题集，下午又换了。每一轮评测对应的都是一份新的“时间切片”。

实时还隐含一个要求：评测系统必须具备快速反应能力。如果一个基准平台从信息采集到生成评测集需要几天时间，那么它仍然不是“实时”的。NEEDLE 之所以能做到小时级级别，说明它的流水线至少在三个环节做了自动化：文档采集、查询构造、答案标注。其中任何一个环节依赖大量人工，都不可能支撑小时级更新。

2.3 查询集每小时重建意味着什么

如果把这个问题拆成工程实现来看，查询集每小时重建有几个关键影响。

第一，评测系统要有一个稳定的信息源接入层。它需要能订阅新闻 RSS、社交媒体热榜、论文预印本、GitHub 趋势、官方公告等源，并且以小时为粒度抓取、去重、清洗。

第二，系统要有自动生成查询的能力。给定一批新文档，系统必须能提炼出“和这些信息相关且适合被搜索”的问题。这一步通常依赖大模型的生成能力，但为保证问题质量，需要引入规则过滤、质量打分和去重策略。

第三，系统需要能形成参考答案或评估依据。与静态基准的人工标注不同，NEEDLE 的自动流水线大概率采用两种方式：一种是用文档本身作为参考答案（即抽取式评估），另一种是用大模型生成答案再由另一个模型评判（即 LLM-as-a-Judge）。无论哪种方式，评测的可信度都会比人工标注弱，需要在报告中持续做质量监控。

理解这张表的要点：NEEDLE 并不是要替代现有静态基准，而是补齐“静态评测测不出实时能力”这一环。对做 AI 搜索产品、RAG 应用、Agent 工具链的团队来说，这类基准有更接近线上真实场景的价值。

3. 传统搜索基准的三大困境

在讲落地方法之前，有必要先厘清传统搜索评测基准在今天为什么会失灵。理解这三个困境，才能真正理解 NEEDLE 存在的必要性。

3.1 困境一：数据污染

数据污染在评测大模型时已经是一个公认难题。很多静态评测集的问题和标准答案本身就可能出现在模型预训练语料中，模型见过答案和它真正具备检索推理能力，在分数上是无法区分的。对搜索类基准也一样：如果基准的文档集是公开网页、论文或新闻，而这些文档已经被模型的训练语料覆盖，那么系统在测试时实际上是在“回忆”，而不是在“搜索”。

NEEDLE 应对这个问题的方式很直接：持续引入最新信息。当一个查询涉及某地刚刚发生的天气灾害、某公司当天发布的财报、某模型昨晚刚公布的版本时，再强的预训练模型也不可能见过这些内容。这类问题能真正测出系统是否通过检索拿到了有效信息，而不是凭记忆强行回答。

3.2 困境二：时间偏移

第二个困境在搜索系统评测中更隐蔽，也更致命。假设你要查询“2024 年诺贝尔物理学奖得主是谁”。在 2024 年 12 月，正确答案是 John Hopfield 和 Geoffrey Hinton；到 2025 年 10 月，这个问题就不再是“关于最新事实的查询”了。如果评测集还沿用这类问题，测试的目标已经悄悄变化：系统不是在回答“新事实查询”，而是在回答“历史知识查询”。

对搜索引擎来说，这两类查询的应对机制完全不同。历史知识查询可以依赖索引里的旧网页甚至模型记忆，而新事实查询必须依赖爬虫抓取时效、网页排序对时间因子的把握、摘要引擎对冲突信息的消解。传统静态基准把所有问题平等对待，实际上掩盖了“系统不擅长找新信息”这一缺陷。NEEDLE 查询集每小时重建，使每一轮评测都有新问题出现，就要求被测系统持续具备发现能力，而不是靠一轮固定问题打天下。

3.3 困境三：覆盖盲区

最后一个困境是覆盖面。传统基准的问题集合通常是某个团队花几个月构造的，覆盖领域再多也有限。而且由于标注成本高，问题往往偏向“有确定正确答案”的类型——百科全书式问题、实体关系式问题。但真实用户搜索会问很多没有标准答案的问题：某个事件的来龙去脉、两个产品的功能对比、某个新概念意味着什么。传统标注流程很难覆盖这种开放性问题。

实时生成查询的一个副产品是问题类型更丰富、更新奇。新闻里提到的产品发布、论文中的关键技术名词、某一领域刚爆出的争议事件，都可以自动转化为查询。这种覆盖方式并不完美，但它能避免基准长期停留在“舒适区”里。

4. 从工程视角拆解 NEEDLE 的可能架构

由于 Keenable AI 开源 NEEDLE 的细节目前还没有完整放出，本节我将以开源实时评测基准的常见工程实践来推导其可能的技术架构。如果你要基于 NEEDLE 做二次开发，或者自建一套类似的实时搜索评测平台，下面的模块划分可以作为参考蓝图。

4.1 信息源接入层

无论评测系统如何设计，第一步永远是数据获取。NEEDLE 要支持小时级更新，必须有一套灵活的信息源接入框架。常见信息源包括：

• 新闻类：RSS、新闻 API、主流媒体公开接口。
• 社交热点类：各平台热榜、趋势话题。
• 学术类：arXiv、Semantic Scholar、Google Scholar 最新论文。
• 技术类：GitHub Trending、技术社区热帖、产品发布公告。
• 结构化知识类：维基百科最近更改、百科新词条。

工程上，接入层建议采用插件化设计。每个信息源对应一个采集器（Collector），输出统一的文档格式，方便后续处理。核心字段建议包含：

{ "doc_id": "unique-doc-id-20250101-001", "source": "rss://example-news-tech", "url": "https://example.com/article/2025/01/01/xxx", "title": "示例标题", "content": "正文内容……", "published_at": "2025-01-01T10:30:00Z", "collected_at": "2025-01-01T10:31:00Z", "raw_metadata": {} }

doc_id 和 collected_at 是实时评测的关键字段。前者保证文档去重，后者记录文档被发现的时间，可以作为评测时效性分析的依据。

4.2 文档处理与索引层

原始文档必须经过清洗才能用于评测。清洗内容包括：去除 HTML 标签、提取正文、去除重复段落、过滤垃圾内容、语言识别、自动分类。

清洗后的文档可以进入两个分支：一部分用于构建评测检索池，另一部分用于后续的查询生成。为了让被测搜索系统能够“搜索”到这些新文档，评测平台还需要维护一个本地索引，或者为被测系统提供文档注入接口。如果被测系统是支持上传文档的 RAG 应用，评测流水线可以自动化执行“先写入新文档，再发送测试查询”的流程。

4.3 查询生成层：从文档到问题

查询生成是 NEEDLE 架构中最核心、也最难做好的模块。它的目标是：给定一组实时文档，自动生成适合搜索评测的问题集合。

一个可行的自动生成流程如下：

1. 从新采集的文档中提取关键主题，过滤掉低质量、过于琐碎、重复的内容。
2. 将每条重要信息转换为自然语言查询。
3. 对生成的问题做质量评估，过滤掉无法回答、存在歧义、暴露答案关键词的问题。
4. 按难度和类型分层抽样，避免测试集偏向某一种信息类型。

提示词模板可以这样设计（示意）：

你是一名搜索评测数据集构造专家。请阅读以下新闻/文档内容，生成 3 个需要结合最新信息才能回答的搜索查询。 要求： 1. 查询必须与用户真实搜索习惯一致，不能直接复述文档标题。 2. 查询不能包含答案中的关键实体，避免系统“根据问题猜答案”。 3. 至少包含一个需要跨多个来源整合信息才能回答的问题。 4. 输出为 JSON 数组，每个元素包含 query 和 question_type。 文档内容： {{文档内容}}

这里要特别注意“查询不能包含答案关键实体”这条约束。如果文档说“OpenAI 发布了新模型 GPT-Next”，而生成的查询是“GPT-Next 是什么时候发布的”，那么搜索引擎直接匹配关键词就可能找到答案，无法测试真正的语义检索和推理能力。更好的查询是“最近哪家 AI 公司发布了新一代推理模型，它在数学任务上有哪些提升”。这类改写更贴近真实用户表达。

4.4 自动评估层

自动评估是实时基准挑战最大的环节。传统人工标注在小规模静态评测中可行，但在“每小时重建”的节奏下完全不现实。可行的替代方案包括：

• 抽取式验证：如果问题设计为“文档中能提取到明确答案”，可以先用语言模型从参考文档抽取答案，再判断被测系统的回答是否与参考答案语义一致。
• 大模型评判：用一个大模型作为裁判，对被测系统答案和参考文档进行综合评分。这种方式效率高，但评测基准团队需要监控裁判模型自身的偏差漂移。
• 用户行为替代：如果评测目标是线上系统，可以使用用户点击、停留、后续追问等隐式反馈作为辅助信号。

NEEDLE 若要在社区内被广泛使用，评测报告的可解释性很重要。除了总体得分，建议输出细分维度，如：时效敏感查询准确率、低热度查询召回率、多源整合成功率等。只有细分到问题类型，才有助于定位系统缺陷。

4.5 定时调度与结果汇总

查询集“每小时重建”并不是所有流程都要每小时跑完。更合理的工程切分是：

• 每 15～30 分钟增量采集新文档。
• 每小时触发一次评测集构建（从增量文档中生成查询）。
• 每半小时或每小时执行一轮评测任务。
• 每天做一次跨时间维度的趋势分析。

调度系统可以用 Apache Airflow、Prefect 或简单的 GitHub Actions Schedule 来实现。关键是保证流水线各环节的幂等性：同一批文档不会重复生成同一批问题，评测任务不会因为部分失败而中断整个流程。

5. 一个参考实现：搭建轻量级实时评测流水线

由于 NEEDLE 本身的开源仓库还在快速迭代中，对于大多数读者来说，更实际的目标是先理解这套机制，并用一个参考实现跑通“采集 → 生成查询集 → 执行评测 → 输出报告”的最小闭环。下面我提供一个不依赖特定云服务的架构设计作为参考。

5.1 选用组件与架构

5.2 调度功能参考代码

下面的 Python 示例演示了一个小时级评测调度的骨架，重点展示整体节奏设计思路。

# 文件名：scheduler_demo.py # 说明：每小时执行一次评测集构建与评测任务 import schedule import time from datetime import datetime from loguru import logger def job_hourly_build_eval_set(): """每小时重建查询集并执行评测。""" current_hour = datetime.now().strftime("%Y%m%d-%H") logger.info(f"开始构建评测集: {current_hour}") # 1. 增量采集最新文档 docs = collect_latest_docs(since_hours=1) # 2. 从新文档中自动生成查询 queries = generate_queries_from_docs(docs) # 3. 过滤低质量查询 filtered_queries = filter_queries(queries) # 4. 将查询写入评测队列 save_eval_queries(filtered_queries, eval_time=current_hour) # 5. 对被测搜索/RAG 系统执行评测 results = run_eval(filtered_queries) # 6. 汇总并输出报告 generate_markdown_report(results, eval_time=current_hour) logger.info(f"本轮评测完成，有效查询数: {len(filtered_queries)}") def collect_latest_docs(since_hours: int): """采集最近 N 小时的新文档。真实实现需要对接具体信息源。""" # 伪代码：从 RSS、热榜、API 拉取数据，清洗后入库 return [] def generate_queries_from_docs(docs): """调用大模型，从文档列表生成候选搜索查询。""" # 伪代码：批量构造 prompt，解析 JSON 输出 return [] def filter_queries(queries): """规则过滤 + 去重 + 质量打分。""" # 伪代码：删除过短/过长、与已有查询重复度过高、含明显答案实体的问题 return queries def run_eval(query_list): """调用被测系统的检索/问答接口，收集答案。""" # 伪代码：POST /api/search 或 /api/chat return [] def generate_markdown_report(results, eval_time: str): """按评测时间生成结果文件。""" # 伪代码：聚合指标，写 reports 目录 pass if __name__ == "__main__": # 每小时整点执行 schedule.every().hour.at(":00").do(job_hourly_build_eval_set) while True: schedule.run_pending() time.sleep(30)

这段代码的关键点在于把“评测集构建”和“评测执行”绑定到一个调度里，并用 eval_time 作为每次任务的唯一标识。实际使用时，建议将构建与执行分开部署：高峰期信息源密集时提高构建频率，但评测集一旦生成，可以被多个被测系统重复消费。

5.3 查询生成的服务调用示例

要让上述代码真正工作，还需要一个生成查询的辅助函数。下面是使用 HTTP 调用大模型服务生成查询的示例。

# 文件名：query_generator.py # 说明：调用大模型相关接口，从一批实时文档中构造评测查询 import json import httpx OPENAI_COMPATIBLE_API_URL = "https://api.example.com/v1/chat/completions" API_KEY = "your-api-key" SYSTEM_PROMPT = """你是实时搜索评测数据的构造专家。 你需要从实时信息流中提取重要信息，生成适合评测搜索系统的问题。 要求： 1. 问题要接近真实用户表达，避免直接引用文档标题。 2. 每篇文档生成 1-3 个问题。 3. 问题应能在最新信息中找到答案，而无法从模型历史知识中直接作答。 4. 只输出 JSON 数组。 """ def build_queries_from_document(doc: dict) -> list[str]: user_content = ( f"【文档标题】\n{doc.get('title', '')}\n\n" f"【文档正文】\n{doc.get('content', '')[:3000]}\n\n" "请生成评测查询：" ) payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_content}, ], "temperature": 0.4, } response = httpx.post( OPENAI_COMPATIBLE_API_URL, headers={"Authorization": f"Bearer {API_KEY}"}, json=payload, timeout=60, ) response.raise_for_status() content = response.json()["choices"][0]["message"]["content"] # 防御性解析：只取第一个 JSON 数组 queries = json.loads(content) return [q for q in queries if isinstance(q, str) and len(q) > 5]

5.4 GitHub Actions 定时任务配置

如果想在 GitHub 上免费托管这套流水线，可以在仓库中配置一个每小时触发的工作流。需要注意：免费计划对长时任务有限制，评测任务应尽量在 1 小时窗口内完成，或者拆分为构建/评测两个独立任务。

# 文件名：.github/workflows/hourly-eval.yml name: hourly-eval on: schedule: # 每小时第 5 分钟触发，避开整点信息源高峰 - cron: "5 * * * *" workflow_dispatch: jobs: run-eval: runs-on: ubuntu-latest steps: - name: Checkout repo uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: "3.11" - name: Install dependencies run: pip install -r requirements.txt - name: Run hourly eval env: API_KEY: ${{ secrets.API_KEY }} DATABASE_PATH: ./data/eval_data.sqlite run: python scheduler_demo.py --once

这里有一个工程判断：定时任务设在第 5 分钟而不是整点，是为了错开大量信息源同时更新的压力，也是为了避免 cron 整点任务常见的排队问题。如果你在自建评测系统，同样建议为高负载任务设置随机偏移。

5.5 评测报告示意

一轮评测结束后，产出建议包含以下信息的 Markdown 报告：

对比环比变化是实时评测最重要的能力。如果只输出当前值，你很难知道上一小时的信息变化造成的影响。实时基准的真正价值，是让评测结果成为一条随时间变化的曲线，而不是一个孤立的点。

6. 实时评测在 AI 搜索与 RAG 场景的落地价值

理解了架构后，要回答一个更实际的问题：这套东西对我的项目到底有什么用？针对不同角色，价值并不相同。

6.1 对 AI 搜索产品的价值：发现时效性缺陷

AI 搜索产品最怕的不是慢，而是“一本正经地给出旧答案”。用户问“今天发生了什么”，系统如果回答的是三天前的新闻，体验就很差；更警惕的是，有些系统会把模型记忆中的旧信息当作检索结果输出，用户很难辨别。

用 NEEDLE 这类小时级基准持续监测 AI 搜索系统，可以直接量化“时效敏感性”指标。例如统计：查询时间点距离相关文档发布时间超过 24 小时的回答占比。如果占比高，说明系统在时效排序、新鲜度加权或信源优先级上存在缺陷。这种发现往往比偶尔的用户反馈要早得多。

6.2 对 RAG 管线的价值：定位链路瓶颈

RAG 系统的评测比单点搜索更复杂，因为问题可能出在链路的不同环节。增量语料没有进入向量库、召回了错误片段、重排序模型对时间信号不敏感、生成模型忽略上下文中的时间信息等，都可能导致答案错误。

在真实运行中，RAG 出现“回答过时”问题时，可以通过实时评测集的细分结果定位坏点。例如，如果同一批新查询下“检索命中率”很高但“答案准确率”偏低，说明问题大概率在生成环节；如果检索命中率也偏低，则要优先检查索引同步和向量召回。基于固定时间切片做回归实验，也可以验证优化是否有效。

6.3 对 Agent / 工具类应用的潜在价值：评测动态任务执行

以 Agent 为代表的工具调用系统越来越多。Agent 需要根据用户目标选择合适的工具、阅读返回结果并做下一步决策。这类系统的评测比搜索系统更难。NEEDLE 的实时查询重建体系同样对 Agent 评测有借鉴意义：Agent 的任务场景变化极快，工具文档也在频繁更新，静态评测很难覆盖系统在真实动态环境下的表现。

不过，Agent 评测目前还处于比较早期的阶段，NEEDLE 是否能直接支持这类场景，要看后续开源版本是否提供工具调用相关的任务模板。这不是现在就可以笃定的结论。

7. 使用实时评测基准的常见误区与风险

实时评测听上去很美好，但在实际使用过程中也有一些陷阱。提前看清这些风险，能避免团队踩进看似自动化、实则不可信的坑。

7.1 常见误区：把自动生成的查询等同于用户真实查询

自动生成查询是大模型完成的，哪怕提示词写得很精致，生成的问题和真实用户提问仍然有分布差异。大模型倾向于问“信息完整、边界清晰”的问题，而真实用户经常会问有歧义、表达不规范、包含个人背景的问题。如果评测完全依赖自动生成的查询，测出的分数可能系统性偏高，因为自动查询往往没有真实查询那么“刁钻”。

应对方式是定期用真实用户日志中的匿名查询做校准，分析自动生成查询与真实查询在长度、句式和信息密度上的差距，并做一定的对抗性改写。

7.2 常见误区：信息源偏差被放大

实时基准的效果高度依赖信息源质量。如果一个评测平台只抓取少数科技媒体的新闻，那么它能反映的只是“系统是否能找到这些特定来源的信息”，而不是“系统在整个互联网上搜索最新信息的能力”。信息源选择越窄，基准的普适性越差。

NEEDLE 如果只是挂接少量固定信源，其评测结论也需要加限定语。团队在使用时应该检查信息源覆盖是否与自身业务场景匹配，必要时替换或增加定制化信息源。

7.3 常见误区：把“每小时重建”等同于“每小时都要部署”

查询集每小时重建的前提是整套数据流水线配置完成。对于大多数内部评测而言，实际可以先从“每日重建”跑起，确认自动生成查询的质量稳定后，再逐步升级到小时级。不要为了追求实时性而牺牲数据质量，评测集的前提始终是文档来源可靠、查询题目无歧义、答案可验证。

7.4 不可忽视的风险：自动评估模型自身的偏差

使用大模型做裁判虽然高效，但裁判模型对时效性信息的判断能力本身并不是完美的。如果参考文档中最新的信息与裁判模型内部记忆冲突，裁判模型有时更倾向于自己记忆中的答案，而不是文档里的正确答案。这会严重影响评分可信度。

工程上可以增加“文档锚定”约束：要求裁判模型必须先完整阅读参考文档，再依据文档内容做出判定，并且报告最终判断依据的摘录片段。开启这些约束能有效降低自动评估的幻觉风险。

8. 复盘与最佳实践建议

结合前面的分析，如果你所在团队正在构建 AI 搜索或 RAG 应用，并准备引入实时搜索评测，下面这些建议值得参考。

8.1 评测数据链路设计原则

建议围绕四个核心原则展开：

• 独立性：评测集构建流程与被测系统隔离，防止被测系统通过记忆或缓存影响结果。
• 时序一致性：记录每个查询对应的文档发布时间、评测运行时间，保证时效维度可分析。
• 低滞后性：从文档发现到查询构造，再到评测执行，每个环节的时间损耗都必须显式记录。
• 可回放性：每轮评测涉及的数据集、参数、模型版本都应该形成快照，方便失败排查和回归对比。

8.2 查询工程质量建议

自动生成查询的质量直接决定基准价值。强烈建议在查询生成后加一道规则过滤层，重点过滤这几种类型：与已有查询文本相似度超过阈值的重复问题；明显包含答案关键实体的“伪查询”；长度过短、没有上下文信息的问题；事实性断言过于绝对、无法允许多源整合的问题。

更进阶的做法是让小模型对查询做一次“时效性评分”，再设定最低分阈值。如果打分很低，说明这个查询大概率不依赖最新信息，应该被移除。

8.3 信息源数量与质量选择建议

不要一上来就接几十个信息源。信息源越杂，清洗去重成本越高，评测结果也越难归因。建议先选 3 到 5 个垂直行业权威源，跑通全流程。稳定后再扩展信息源、加入细分领域。同时建议为每个信息源设置信誉权重，对评测结果按权重做加权分析，避免小报噪音干扰结论。

8.4 评测报告的设计建议

报告应该包含“信息新鲜度分桶”分析，例如 0~1 小时、1~6 小时、6~24 小时、24 小时以上。观察系统对各桶查询的回答质量变化曲线。一个健康的 AI 搜索系统，在各新鲜度桶上的表现不应该出现断崖式下跌。如果有明显断点，就说明系统对“特别新的信息”处理能力不足，这类洞察比总平均分数有价值得多。

表格也建议展示 Top 失败查询案例。很多时候评测指标拉齐了，但用户不满意的场景仍然很具体。把失败查询汇总后，采样分析其中的共性模式，比盲目调优更有效。

8.5 安全与合规注意事项

在自建实时评测流水线时，还需要注意三类边界问题：

• 数据版权与使用边界：抓取第三方信息源用于评测时，要遵守网站的 robots 协议、服务条款和版权要求，不应将受版权保护的全文用于商业化再分发。
• 隐私保护：如果评测系统会接入真实用户查询日志，必须完成去标识化处理，并对日志的存储与访问权限做最小化控制。
• 恶意提示注入风险：在“信息源 → 文档 → 评测查询”的链路中，攻击者有可能构造带有恶意指令的文本，让大模型生成评测查询时执行非预期动作。需要对文档内容做渲染隔离，并把信息源限制在可信域名范围内。

9. 关于关键词搜索与最终实践路径

很多想尝试实时搜索评测的团队，往往会先做一个动作：在搜索引擎中查找“Keenable NEEDLE”“实时搜索基准开源项目”等关键词。但搜索到项目主页只是第一步，不能替代对评测原理的理解。更实际的建议是，先从架构图中的最小流水线开始，用自己业务领域里的新闻源做一个小规模验证，而不是直接跑一个大而全的基准平台。

判断一个实时评测基准确实适合你，不妨连续运行三到五天，然后回答三个问题：

• 自动生成的查询集中，有多少比例真正需要“最新信息”才能回答？
• 这些查询的问题类型是否覆盖了你的业务场景（时效型、对比型、分析型）？
• 评测结果是否帮助发现了优化前未能发现的系统问题？

只有这三条都为“是”，这套实时评测体系才算真正进入可用的阶段。

NEEDLE 作为开源实时搜索基准，最有价值的并不是某一次评测的排行，而是把“评测数据需要实时更新”这一理念变成了可复制的工程范式。在 AI 搜索、RAG 问答、Agent 工具都开始强调“时效性”的当下，尽早建立一套动态评测能力，是减少线上失望体验的有效手段。

这里也提醒一句：实时基准的自动化程度越高，对数据质量的监控就越要严格。保持对评测集本身的批判态度，每隔一段时间核查自动生成的查询和标注质量，结果才不会失真。后面如果 Keenable 团队公开更多官方实现细节，届时再对调度策略、查询生成和质量评估做二次校准也不晚。