基于实时网络数据构建 RAG 管道（无需过期索引）
All Posts

基于实时网络数据构建 RAG 管道（无需过期索引）

Ryan Turner
Ryan Turner · Head of Growth

实时网络 RAG 管道在查询时直接从开放网络中检索数据，而非读取预先爬取的向量索引。这能确保答案的时效性，因为数据是在用户提问时即时获取的，而非在数周前进行爬取时获取的。 这种取舍非常直接：实时检索会增加延迟和每次查询的成本，而缓存索引虽然速度快，但数据会过时。我们看到的大多数生产系统都采取了混合方案，即对时间敏感的查询进行实时检索，并在有效期（TTL）内复用缓存的数据块。

要点
  • 经典的RAG系统从静态索引中获取结果，因此其数据新鲜度的上限就是上次抓取的日期。
  • Live-web RAG 通过搜索 API 发现信息来源，在查询时获取并清理网页内容，随后通过引用为答案提供依据。
  • 难点不在于数据检索，而在于决定何时获取实时数据、何时复用缓存数据块，这取决于每个主题的时效性TTL。
  • Gartner预测，到2025年底，40%的企业应用程序将配备针对特定任务的人工智能代理，而这一比例此前不足5%；这些代理需要实时数据。
  • 在数据摄入阶段，规范的 Markdown 格式优于原始 HTML，因为它能降低分词成本，并在分块处理前移除导航栏、广告和冗余代码。

当数据集还是更新缓慢的知识库（如文档、政策、工单）时，经典的RAG模式还算合理。但一旦将其应用于开放网络，模型就会失效。 价格波动、新闻频发、排名更迭，而上周二构建的向量索引却自信满满地返回着上周二的现实。解决之道并非构建更大的索引或加快重新抓取的频率，而是将实际会变化的数据的获取操作移至查询时执行。RAG 即检索增强生成（RAG）：模型的回答基于您检索并输入的文档，而不仅仅依赖其训练权重。本文将分阶段介绍该架构，随后探讨区分实时网络 RAG 与经典版本的“时效性”逻辑。若想了解向智能体提供实时数据的更广泛背景，请从关于如何为 AI 代理提供实时网页访问权限.

为什么经典的RAG在处理网络数据时会失效？

经典的RAG会过时，因为它基于快照来提供答案。你先进行爬取、分块、嵌入和存储，然后每次查询都会读取那个静态副本，直到下一次爬取。对于稳定的语料库来说，这没问题。 然而，对于开放网络而言，这反而是个弊端，对实时数据代理的需求正在攀升。Gartner预测，到2025年，到2026年底，40%的企业应用将配备针对特定任务的人工智能助手，较2025年的不足5%有所上升。负责回答真实问题的智能代理不能仅依赖过时的数据快照。

过时问题主要分为两部分。首先是覆盖范围：上个月索引的网页中缺少当时尚未存在的页面，因此无论采用多么巧妙的检索方法都无法恢复这些页面。 其次是内容漂移：你已收录的页面在你的索引更新前发生了变化，而你的嵌入向量仍指向旧文本。缩短爬网周期虽能缩短时间窗口，却无法彻底消除这一问题，同时还会浪费计算资源在无人查询的页面上。

实时网络RAG则颠倒了这一顺序。它不再预先抓取所有内容并寄希望于索引中包含正确页面，而是在查询发生的那一刻发现并获取来源。因此，计算成本从“持续爬取整个网络”转变为“仅获取该查询所需的少量页面”。 关于“锚定”为何重要以及它如何减少幻觉的背景信息，请参阅我们的指南利用实时网络数据对大型语言模型进行微调.

实时网络 RAG 架构是什么样的？

一个实时网络RAG管道包含七个阶段：查询理解、实时来源发现、数据提取与清理、分块与嵌入、提取前K项、通过引用验证生成内容，最后以有效期（TTL）进行缓存。前六个阶段共同生成答案。 第七个阶段决定保留哪些内容，以便后续类似查询可以跳过实时检索。每个阶段都是具体的，实际上大多数失败都可以追溯到源发现或检索步骤的薄弱环节。

以下是该流程的步骤列表：

1. 查询理解 -> 将用户问题重写为搜索意图
2. 来源发现 -> 搜索 API 返回候选 URL
3. 获取 + 清理 -> 将每个 URL 渲染为干净的 Markdown 格式
4. 分块 + 嵌入 -> 分割 Markdown，并在查询时将块嵌入
5. 检索前 k 项 -> 根据查询嵌入向量对片段进行排序
6. 锚定 + 引用 -> 大语言模型仅使用检索到的片段并附带来源链接进行回答
7. 缓存 + TTL -> 存储片段并设置有效期以便重复使用

以下各阶段描述了每个步骤。其中任何一个步骤都不需要预先构建的庞大索引。此处的“向量存储”体积小且存续时间短，通常仅限于单个查询或会话。

第一阶段：查询理解

在检索网页内容之前，先将原始用户问题转化为搜索意图。 剔除对话中的冗余内容，展开缩写词，并提取实体信息和时间敏感性。例如，“X收购案的最新进展如何”暗示了时效性；而定义性问题则不具备这一特征。这一阶段决定了后续处理流程在多大程度上优先采用新鲜数据而非缓存数据。该步骤运行成本低廉，却能显著提升数据质量。

第二阶段：实时源发现

数据探索阶段是大多数数据管道悄然失败的地方，因为模型无法基于它从未找到的页面进行训练。源头追踪 这一步是将查询意图转换为候选 URL 集合的过程，通常通过搜索 API 实现，而非猜测域名。在此过程中，支持地理定位的搜索结果页面 (SERP) 接口至关重要：针对“附近最好的 X”或价格查询的结果会因国家/地区和城市而异，您需要获取用户实际能看到的来源。有关各项选项的对比，请参阅面向代理的网络搜索 API.

这是 Massive 的 Web Render API 发挥作用的第一阶段。搜索端点 (/搜索) 可从各大搜索引擎获取搜索结果页面（SERP）数据，并支持按国家、地区或城市进行地理定位。对于那些根据AI摘要内容进行决策的查询，等待=ai 等待长达一分钟以获取 AI 概览，并且等待=答案 调用“People-Also-Ask”功能。您将获得一组候选 URL，其排序方式与该地区真实用户所见一致。

第三阶段：取回并清理

在检索候选页面这一环节，实时RAG（检索辅助生成）技术将面临现代网络的防御机制，而现代网络对机器人并不友好。2025年，Imperva报告称2024年，自动化机器人占所有网络流量的51%，这是十年来机器人流量首次超过人类流量，其中恶意机器人占比达37%。网站为此采取了激进的封锁措施，导致数据中心的简单抓取请求遭到拦截，或被返回虚假内容。

此阶段有两个要求。首先，你的请求必须能通过该页面的反机器人防护层，否则就会跳转到错误页面。住宅代理 将请求路由至真实的终端用户设备，因此流量源自家庭IP地址，而非已被标记的数据中心IP范围。Massive的Web Render API通过覆盖195多个国家、拥有约130万日活跃设备的真实终端用户设备网络来执行数据抓取。 在我们的测试中，使用住宅IP访问受保护网站的成功率通常远高于数据中心IP（粗略范围：住宅IP约85%-99%，数据中心IP约20%-40%）；请将此数据视为供应商基准，而非独立研究结果。

其次，你需要的是纯文本，而不是原始 HTML。浏览端点（/浏览器) 支持格式=markdown 作为一级输出，返回经过处理的、适用于大型语言模型（LLM）的 Markdown 格式，其中已去除导航栏、广告和冗余代码。这一点在分块处理前尤为重要：与原始 HTML 相比，Markdown 能大幅减少令牌数量，从而降低嵌入和生成成本，并确保分块内容具有实质意义，而非充斥着菜单链接。业界实践者也已记录了这一效果（dev.to,AI 代理的浏览器工具 第 4 部分：跳过浏览器（2026年）。

第四阶段：分块与内化

将处理过的 Markdown 内容拆分为多个片段，并在查询时将其嵌入。由于语料库仅包含该查询提取的几页内容，因此这种方式既快速又经济；您嵌入的只是几千字节的数据，而非整个网络的爬取结果。 确保各片段与 Markdown 结构保持一致，按标题和段落划分，使每个片段自成一体。Markdown 的标题提供了天然的边界，这是原始 HTML 所不具备的。

第5阶段：提取前k项

将新嵌入的片段与查询嵌入进行排序，并保留排名前 k 个。对于每个查询的语料库规模较小时，检索过程较为简单，因此可以采用较大的 k 值，随后由生成模型进行筛选。此处的关键在于仅保留通过相关性阈值的片段，从而避免质量较差的来源稀释上下文窗口。

第6步：通过引用为论述提供依据

仅向模型提供检索到的片段，并要求它基于这些片段进行回答，同时为每个论点提供来源链接。接地 这是一种将模型的回答限定在检索到的证据范围内，而非其参数化记忆中的做法，因此这就是“锚定”协议：没有信息块，就没有论断。由于每个信息块都包含来自第二阶段的来源URL，因此引用信息无需额外处理，读者（或下游验证程序）可以直接对照实时页面来验证答案。 基于“即时检索文本”进行锚定，正是实现实时更新的核心意义所在。

第 7 阶段：带有效期 TTL 的缓存

将检索到的数据块与有效期一同存储，以便后续类似的查询能够复用这些数据，而无需重新检索。这正是实时 RAG 能够在大规模场景下保持经济性的关键。缓存机制将第二次相同的查询从全量实时检索转变为简单查找，而 TTL 则确保了这种查找的准确性。下一节将介绍如何设置 TTL。

如何利用有效期 (TTL) 机制避免索引过时？

您可以通过为每个缓存块设置有效期（TTL），并在过期后重新获取最新数据，从而避免使用过期的索引。一个新鲜度 TTL 这是一个按数据块计算的生存时间（TTL），用于标记缓存数据在必须刷新之前仍可被信赖的时间长度。TTL是按主题设置的，而非全局的：股价可能仅在几秒内有效，产品规格可能有效几天，而百科全书的定义则可能有效数周。 当查询到达时，应先检查缓存，返回仍在 TTL 有效期内的数据块，并对已过期或缺失的数据触发实时获取。这就是混合型中间层：在可加速时保持高效，在必须保证新鲜度时确保数据最新。

在查询解析阶段设置 TTL。如果第 1 阶段将问题标记为“时效敏感型”，则应缩短或绕过 TTL，并强制进行实时获取。 相比之下，如果是稳定的定义性问题，较长的 TTL 即可，此时可直接从缓存中提供结果。这就是控制延迟和成本的关键：实时获取次数越多，答案越新鲜，但每次查询的成本也越高；缓存命中率越高，则情况相反。

失效机制与过期机制同样重要。TTL 用于处理基于时间的过时问题，但某些事件需要立即失效：例如你引用的页面返回 404 错误、你信任的来源发布了更正声明，或者查询中出现了已知易变的实体（如实时比分、突发新闻）。 对于这些情况，应构建明确的失效处理路径，而非被动等待超时。简而言之，主题级 TTL 与事件驱动失效机制的结合，正是实时网络管道与仅通过定时任务重新抓取的传统索引之间的根本区别。

2025年，实时数据往往优于静态索引的另一个原因在于：开放网络正在积极限制批量爬虫的访问。Cloudflare 报告称，在2025年7月1日，该平台开始默认在约20%的网络内容中屏蔽AI爬虫 并推出了按爬取次数付费的市场。因此，维护一个现成的开放网络索引变得越来越困难，成本也逐季攀升。 通过真实设备网络在查询时进行抓取可以规避批量抓取的问题，因为你抓取的是真实用户可能访问的几页内容，而不是按计划抓取整个网络。如果你想将这条管道作为可调用的工具提供给代理，请参阅如何构建一个用于网页数据提取的MCP服务器.

何时应获取实时数据，何时应复用缓存的片段？

当查询对时效性敏感，或匹配的缓存条目已过期时，应实时获取数据；当缓存块仍处于有效期内且查询内容稳定时，则应重复使用该缓存块。 该决策针对每个查询单独执行，参考第一阶段的时间敏感性信号以及数据块剩余的TTL。正确制定这条规则是决定延迟和成本预算的关键，因此应根据实际流量进行调优，而非凭空猜测。

一个实用的默认策略：将缓存视为快速路径，将实时获取视为正确性保障。 当缓存中存在有效期内的数据块且满足相关性阈值时，直接从缓存提供服务。但在以下情况下则转为实时获取：缓存未命中、数据块已过期、查询具有时效性需求，或缓存源已被失效。这种机制既能确保常见且重复的查询保持低成本，又能保证易变的查询结果始终是最新的。

通过观察两种故障模式来调整阈值。过期的结果（即缓存 TTL 对于该主题设置得过长）会促使您缩短 TTL 并增加实时获取的频率。 而成本和延迟的突增（稳定查询上过多的实时获取）则会促使您朝相反方向调整。根据我们在各代理工作负载中的观察，并不存在单一的正确设置；恰当的平衡取决于您的流量构成以及数据源实际变化的速度。

来源

Frequently Asked Questions

实时网络RAG会取代向量数据库吗？

不，它的作用发生了变化。它不再是覆盖整个网络的庞大持久化索引，而是维护一个范围仅限于某个查询或会话的小型、短暂存储，通常仅包含你检索到的页面片段。对于稳定的内部内容，你仍可保留一个持久化存储。与此同时，“实时层”则负责处理答案中那些动态变化的部分。

在查询时进行数据检索，对于生产环境来说是不是太慢了？

虽然这会增加延迟，但“新鲜度TTL”机制能有效缓解这一问题。重复且稳定的查询会命中缓存并快速返回，而只有对时效性敏感或未命中缓存的查询才会产生实时获取的开销。在渲染阶段采用高速层级，并设置严格的Top-K阈值，能确保实时路径保持足够精简，以满足交互式使用需求。

为什么不使用普通的HTTP客户端，而要通过真实设备的网络进行数据获取？

因为现代网络对机器人采取了强力封锁措施。 Imperva 报告称，2024 年自动化机器人占网络流量的 51%，而网站则通过对数据中心请求进行验证来应对。通过真实的消费者设备网络进行抓取意味着请求源自家庭网络，因此受保护的页面会返回真实内容，而非阻挡页面或诱饵页面。

如何选择一个新鲜的TTL？

应根据数据变化的频率按主题分别设置，而非采用一个全局值。易变数据（价格、分数、突发新闻）的TTL应设置为几秒到几分钟；稳定的参考内容则应设置为几小时到几周。 当查询解析阶段检测到用户有获取最新信息的需求时，应缩短或跳过 TTL 时效，并针对更正内容和失效链接添加基于事件的失效处理机制。