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

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

Ryan Turner
Ryan Turner · Head of Innovation

实时网络 RAG 管道在查询时从开放网络中检索信息，而不是从预先爬取的向量索引中读取。这能确保答案的时效性，因为数据是在用户提出查询时才获取的，而不是在数周前进行爬取时获取的。 其中的权衡关系很直接：实时获取会增加延迟和每次查询的成本，而缓存索引虽然速度快，但数据会过时。我们看到的大多数生产系统都采取了混合方案，即对时间敏感的查询进行实时获取，而对符合新鲜度TTL要求的查询则复用缓存数据块。

要点总结
  • 经典 RAG 系统从静态索引中获取答案，因此其信息时效性的上限就是您上次抓取的日期。
  • Live-web RAG 通过 Web Search API 发现信息来源，在查询时获取并清理网页内容，然后通过引用为答案提供依据。
  • 难点不在于数据检索，而在于决定何时获取实时数据、何时复用缓存数据块——这由每个主题的新鲜度TTL决定。
  • Gartner预测，到2025年，到2026年底，40%的企业应用将配备针对特定任务的AI代理，而这一比例此前还不到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”或价格查询的结果会因国家和城市而异，您需要获取用户实际能看到的来源。有关各种选项的比较，请参阅面向代理的 Web Search API.

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

第三阶段：取回并清理

在检索候选页面时，实时RAG会遭遇现代网络的防御机制，而现代网络对机器人持敌视态度。2025年，Imperva报告称，2024年，自动化机器人占所有网络流量的51%，这是十年来机器人流量首次超过人类流量，其中恶意机器人占比达37%。网站为此采取了激进的封锁措施，因此数据中心进行的简单抓取请求会遭到拦截，或被返回虚假内容。

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

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

第4阶段：分块与嵌入

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

第5阶段：提取前k项

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

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

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

第7阶段：具有有效期（TTL）的缓存

将检索到的数据块与有效期一起存储，以便下一次类似的查询可以复用这些数据块，而无需重新检索。这正是实时 RAG 能够在大规模部署下保持经济可行性的关键。缓存将第二次相同的查询从完整的实时检索转变为查找操作，而 TTL 则确保了该查找操作的准确性。下一节将介绍如何设置 TTL。

如何利用有效期（TTL）来避免索引过期？

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

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

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

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

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

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

一个实用的默认策略：将缓存视为快速路径，将实时获取视为正确性的保障。 当缓存中存在有效期（TTL）内且满足相关性阈值的片段时，直接从缓存中返回结果。但在以下情况下则转而进行实时获取：缓存未命中、片段已过期、查询具有时效性需求，或者缓存源已被失效。这样既能降低常见重复查询的开销，又能保证易变查询的结果是最新的。

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

来源

常见问题解答

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

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

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

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

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

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

如何选择有效期（TTL）？+

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