TL;DR
- RAG 网络数据层将允许的网页转换为可追溯、可刷新文档,然后才进行检索。
- 爬虫成功并不建立文档质量;需要单独验证范围、内容、来源、重复性和新鲜度。
- Nstdata Crawl 是一个为 LLM 准备的数据的网络爬虫 API,能够发现网站、在范围内递归、渲染 JavaScript,并生成 Markdown 和其他人造物,内置代理编排。
- 保持爬虫状态和索引状态分开,以便失败的更新不会默默地在答案路径中留下过时的块。
- 数据层必须支持更正和删除,以及新页面的添加。
什么是 RAG 的专用网络数据层?
专用网络数据层是外部页面和检索器可以引用的文档之间的受控管道。它定义了哪些内容可以被收集、如何发现 URL、接受哪个版本的页面、保留什么内容以及何时刷新或删除索引块。Nstdata Crawl 可以提供网络获取阶段。向量数据库存储嵌入;它本身并不决定检索到的段落是否为当前或是否来自预期页面。
Azure RAG 设计指南 将摄取、块划分、索引、检索和评估描述为不同的决策。这种分离很有用,因为一个完美的检索器可能会返回一个处理不当的文档。如果爬虫捕获了导航菜单而不是政策,模型可能会非常自信地引用错误的文本。
为什么直接的 URL 到向量的摄取是脆弱的?
直接的 URL 到向量的摄取是脆弱的,因为源网页独立于索引发生变化。重定向、规范路径、客户端渲染的内容、地区切换、已删除页面和模板更改都可以改变 URL 的含义。一次性的快照也遗漏了更正和删除。
考虑一个公共文档页面,其特性可用性发生变化。如果夜间爬虫失败,但索引保留了上个月的块,则应用程序可能会从过时的文本中回答,同时仍显示出一个合理的引用。如果页面移动,简单的摄取可能会添加其新 URL,而未删除旧向量,从而产生矛盾的证据。AWS 的 知识库同步文档 明确将添加、修改和删除文档视为摄取事件。
数据层需要一个稳定的文档身份、内容哈希、爬虫时间戳、接受结果,以及从源文档到所有派生块 ID 的映射。这些字段使得更新作业可以精确替换或删除受影响的块。
架构中属于哪些阶段?
生产 RAG 网络管道有六个阶段,具有不同的失败边界。
| 阶段 | 输入 | 输出 | 接受规则 |
|---|---|---|---|
| 源政策 | 域名、目的、条款 | 批准范围 | 使用是被授权的 |
| 发现 | 种子、网站地图、链接 | URL 清单 | URL 保持在范围内 |
| 获取 | URL 和渲染选项 | 页面人造物 | 预期内容存在 |
| 规范化 | HTML、Markdown、元数据 | 规范文档 | 主要内容和源身份保持 |
| 索引 | 已接受文档 | 块、嵌入、索引条目 | 块 ID 映射回文档版本 |
| 刷新 | 先前清单和新爬虫 |





