如何从网络数据构建RAG管道

Scrapeless Web Unlocker 和 Crawl 收集公共网络内容，团队可以在 RAG 管道中对其进行规范化、索引和检索。

为什么这个话题很重要

检索增强生成管道在回答时为语言模型提供对外部知识集合的访问。 原始的增强检索生成论文 正式确定了参数模型知识与检索非参数记忆的结合。对于网络数据，实际架构比嵌入早开始：系统必须发现允许的页面，获取其真实内容，去除无关的装饰，保留来源，并决定何时刷新每个源。

常见的演示上传了几个文档并提出了一个问题。一个生产环境的网络 RAG 系统必须处理规范 URL、重复模板、JavaScript 渲染、重定向、内容更新、已删除页面和相互矛盾的段落。模型仅看到在该管道中存活的块。如果这些块过时或与其源脱节，则更强大的模型无法重建缺失的证据。

网络 RAG 系统的两个部分

离线或异步部分是索引管道。它发现文档，获取内容，解析有意义的文本，分配标识符，将文档拆分为可检索的单元，创建搜索表示，并将其写入索引。离线一词是相对的：一个经常变化的来源可能会在一天内重新处理，但索引仍然与用户的问题分开。

在线部分以查询开始。它可以分类意图，应用访问过滤器，重写问题，运行关键词或向量检索，合并结果，并重新排名候选项。 OpenAI 向量嵌入文档 将嵌入描述为与相关性任务有用的向量表示，但仅凭向量相似性并不能证明某段文字回答了问题。元数据过滤、词汇匹配、重排序和源质量规则通常具有同等的重要性。

生成器接收一个故意有限的证据包。好的提示将源文本与指令区分开，要求引用提供的材料，并允许明确的不足证据回答。应用程序随后验证引用目标并记录使用的段落。这创建了从最终声明到块、文档和规范页面的追踪。

网络数据索引阶段

• 发现来源。 从网站地图、策划的 URL 列表、提要或允许的搜索结果开始；记录每个页面为何属于该语料库。
• 获取内容。 直接获取静态页面，仅在客户端内容更改材料证据时使用呈现获取。
• 规范文档。 规则： 1. 仅输出翻译文本——不做解释，不添加额外的包裹代码框。 2. 精确保留Markdown/HTML结构（标题、列表、链接、表格）。 3. 保持任何占位符标记如@@CODEBLOCK_0@@或@@INLINECODE_0@@完全不变；绝不翻译、重排序、合并或重新格式化它们。 4. 不添加或删除```代码框，且不将普通文本包裹在代码块中。 在保留标题、列表、表格和链接上下文的同时，移除导航重复、cookie面板、脚本和重复模板。
• 带有来源的块。 创建连贯的段落，并附上规范的 URL、标题、标题路径、语言、访问范围、哈希和采集时间。
• 索引和版本。 在稳定的文档标识符下写出词汇和向量表示，以便能够调和修改和删除的材料。

分块和检索决策

最佳设置依赖于文档形状和问题类型。将每个选择视为可测试的假设，而不是普遍常数。

在可验证的阶段构建管道

使用各自的输入、输出和测试装置实现每个阶段。这使得检索错误可以诊断，而不必为每个失败指责模型。

1. 定义语料库合同。 列出已批准的域、页面类型、语言、排除项、所有权、保留规则，以及语料库必须回答的问题。
2. 创建规范文档ID。 仔细标准化URLs，尊重规范信号，并避免合并其地区、产品或版本更改其含义的页面。
3. 保留结构化上下文。 保持标题、表关系、代码边界和附近的链接标签。普通文本的扁平化可能会破坏紧凑技术材料的含义。
4. 建立一个标记的问题集。 撰写代表性问题，并识别应支持每个答案的段落。包括可回答、含糊和无法回答的案例。
5. 添加变更调解。 比较内容哈希，原子性替换更改的块，删除已删除文件，并保留足够的版本历史以解释早期的答案。

在答案质量之前评估检索

流畅的答案可能掩盖检索失误，而措辞较弱的答案仍然可以得到完美的证据。单独评分每个阶段，然后评估完整的用户结果。

• 语料库覆盖率。 索引集合是否包含每个支持问题类别的权威文档？
• 检索召回率。 候选集是否包括支持预期答案的段落？
• 排名精准度。 支持段落是否高于仅相关或重复的文本？
• 引用支持。 每个引用段落是否包含与其相关的具体声明？
• 答案约束。 当语料库缺乏足够证据时，系统是否拒绝或限定答案？

Web特定失败模式

Web内容是不可信的输入，转移至 HTTP语义规范。获取代码应在材料达到解析或模型阶段之前强制执行主机、内容类型、大小和重定向规则。

• 模板污染。 重复的标题和页脚主导相似性搜索，挤出包含答案的段落。
• 重复身份。 跟踪参数和替代路径为一个页面创建多个记录，使证据膨胀而不增加独立支持。
• 指令污染。 一个页面可能包含针对模型的指令。将源文本存储为引用证据，绝不要让其控制检索或系统策略。
• 陈旧的嵌入。 在不更换其向量表示的情况下更新原始文本，会导致索引内部不一致。
• 不支持的合成。 生成器可能会将单独真实的段落组合成一个没有任何来源声明的结论。声明级引用检查会捕捉到这个缺口。

Web RAG 模式

从试点到生产

来自网络数据的 RAG 流水线的有用试点应该小到可以逐条检查记录。开始时 定义语料库合同: 列出经过批准的域名、页面类型、语言、排除项、所有权、保留规则，以及语料库必须回答的问题。然后应用 创建规范文档 IDs: 认真规范化 URLs，尊重规范信号，避免合并那些其语言环境、产品或版本改变其含义的页面。故意将第一个评估集保持为混合状态，包括普通案例、模棱两可的案例、缺失证据，和系统必须拒绝或转交的行动。这揭示了在更高的数量隐藏设计错误之前，工作流程是否理解其边界。

生产准备需要每个度量和文物都有产权人。跟踪 语料库覆盖率 以回答索引集合是否包含每个支持问题类别的权威文档？跟踪 检索召回率 以确定候选集合是否包含支持预期答案的段落？添加 排名精度 以便团队可以看到支持的段落是否高于单纯相关或重复的文本？这些测量应链接到基础记录，而不是仅作为仪表板总量存在。审核者需要从变化的度量移动到产生它的精确查询、来源、观察或行动。

操作控制应针对最有可能改变商业决策的失败模式。第一个审查规则应覆盖 模板污染: 重复的标题和页脚主导相似性搜索，挤压出包含答案的段落。退出审查应覆盖 不支持的综合: 生成器可能会将单独真实的段落组合成一个没有任何来源声明的结论。声明级引用检查会捕捉到这个缺口。分配一个响应负责人，定义什么证据能解决问题，并记录结果是否改变了数据、提示、工具、权限或来源政策。该记录防止相同缺陷被重新发现为无法解释的质量波动。

只有在试点表现可预测后才扩展。团队可以从文档助手开始，工作是索引经过批准的产品和政策页面，并附上版本元数据，以便答案指向当前部分。第二阶段可以增加研究工作区，工作流程必须收集主要来源，保留段落，并让分析师在不丢失页面痕迹的情况下比较证据。原始测试集在范围增长时保持运行。新的来源、市场、工具和权限应一次引入一个边界，以便将回归分配给特定的变化，而不是同时进行平台重写。

结论

当获取、规范化、检索和生成共享一个来源模型时，web RAG 流水线成功。每个答案都应该可追溯到一个块，每个块追溯到一个版本化文档，每个文档追溯到一个被允许的来源。该链条比向量数据库的选择更重要。

构建覆盖真实问题集的最小语料库，在标记示例上评估检索，并在扩展前添加新鲜度规则。当每个新来源遵循相同的身份、证据和删除合同时， web 规模变得可管理。