什么是检索管道？

Scrapeless Agent Browser 支持基于浏览器的网页内容采集。

检索流水线是一系列处理阶段，用于查找和整理与请求相关的信息。它可以摄取文档、构建索引、解释查询、检索候选结果、对其进行排序并返回选定的证据。生成过程可以在检索之后进行，但检索流水线也可以在没有语言模型的情况下直接提供搜索结果。

对于一个 AI 应用，流水线的工作是提供能够支撑所请求答案的信息。相似文本并不总是足够的证据。围绕下一阶段的需求来设计每个阶段，并保留足够的源信息，以便检查为何选择了某个文档。

离线路径和请求时路径

一个检索管道通常包含一个用于准备可搜索内容的摄取路径，以及一个在请求时为查询选择信息的请求路径。摄取过程可以包括收集、文本抽取、规范化、切分和索引。在请求阶段的工作可以包括查询处理、访问过滤、候选检索、排序以及上下文组装。

这种区分很重要，因为每个路径中会出现不同的失败情况。如果文档从未进入索引，那么仅靠更好的排序也无法找回缺失的文档。而已被索引的相关文档，仍然可能因为查询较弱或过滤条件过于严格而被排除。保留分阶段的观察，这样这些情况就不会混淆成诸如“RAG 效果差”之类含糊的标签。

原文 检索增强生成研究 将生成器与检索到的信息结合起来。在一个应用中，这种关系创建了一个清晰的约定：检索阶段提供候选证据，而生成阶段利用这些证据来产生回答。需要对这两个阶段都进行评估，因为即便是功能强大的生成器，也无法可靠地弥补源材料的缺失。

摄取始于源记录

文档摄取应在文本被转换之前保留每个来源的标识和来源信息。为每条信息保留一个规范标识符、来源位置、收集时间以及相关的版本信息。将这些字段与提取出的文本关联起来，而不是仅仅将它们嵌入到在处理过程中可能丢失的文件名中。

Web 源可能需要在其相关内容可用之前进行浏览器交互。 代理浏览器工作流 属于该收集阶段。收集完成后，你的应用程序仍然需要决定哪些文本是有用的、数据来源是否在范围之内，以及该记录应如何建立索引。

对于一个假设的产品支持语料库，将每个配置页面作为一个带有其产品版本的来源进行存储。删除重复的导航内容，但不要删除警告或适用条件。如果一张表格中包含答案，要保留其行标签与对应值之间的关联关系。将每个单元格全部扁平化为一个无结构的文本流，即使所有词语仍然存在，也可能在后续检索时造成误导。

分块应保留可回答单元

分块将文档划分为检索器可以选择、下游阅读器可以理解的单元。合适的单元取决于文档结构以及用户提出的问题。一个简短的定义可能只需要一个段落；一个操作性答案则可能需要若干步骤以及相关的警告说明。

避免仅仅因为某个分块大小在示例中常见就选择它。应当检查具有代表性的文档，并衡量检索到的分块是否包含完整的支撑内容。保留标题、来源标识符以及偏移量或其他可用于在原始文档中定位段落的方式。如果一个分块从某个条件的中间开始，答案生成器可能会忽略该指令适用的内容。

重叠的分块可以保持连贯性，但重叠也可能产生重复的证据。在上下文组装过程中去重，并保留指向完整来源的链接。一次检索结果应该告诉下一阶段这段内容的含义以及其来源，而不仅仅是提供一个高相似度分数。

候选检索与排序解决的是不同的问题

候选检索会找到一组数量可控的潜在相关记录，而排序则决定这些记录中哪些最能满足请求。关键词检索有助于处理精确的名称和标识符。稠密检索使用学习到的表示来比较查询与文段。当任务同时受益于二者时，混合式设计可以结合多种信号。

The 稠密段落检索架构 演示了使用分别编码的问题和段落进行检索。该机制并未将语义相似性等同于事实支持。关于某产品先前版本的段落，可能与当前版本的问题相似，却回答的是错误的版本。

根据任务中包含的来源范围、访问权限、版本或时间等约束条件应用过滤。然后在该有效集合内评估相关性。不要将被禁止的内容提取到模型上下文中，再指望生成器在事后修复访问控制错误。权限检查应当在披露证据之前完成。

在不丢失来源的情况下组装上下文

上下文组装会为下一个使用者选择并组织检索到的证据。在 RAG 应用中，这个使用者通常是一个模型。加入来源标识和相关限定条件，以便答案保持可追溯性。移除重复和无关内容，但不要丢弃使某个陈述成立所必需的条件。

包含数字的段落可能需要它的单位、表格标题和适用日期。如果压缩移除了这些细节，一个较短的上下文反而可能比一个较长的上下文更无用。关于……的研究 长上下文中的信息放置 也说明了仅有容量是不够的。评估模型实际接收到的上下文，而不是只看检索器的原始候选列表。

“ 具备代理能力的实时网页检索工作流 ”还需要决定何时需要进行进一步搜索或检查。当这些决策是可预测的时，一个固定的流水线可能更合适。无论采用哪种方式，上下文组装都应记录选用了哪些来源，以及哪些所需论断仍然缺乏证据。

在评判答案前先评估检索

检索评估要判断流水线是否返回了一个为定义好的问题集提供所需证据的结果。构建带有已知相关来源或经审查的相关性标签的示例。检查缺失支持到底源自接入、候选检索、过滤、排序还是上下文组装。

分别衡量相关性与覆盖率。结果列表大部分可以是相关的，但仍然遗漏回答某个必需子问题所需的那一段。流水线也可能检索到了正确的来源，却只暴露了不完整的片段。在答案步骤实际消费的粒度上进行评估，包括最终组装好的证据包。

保持答案评估独立。生成模型可能忽略有用证据，或引用一个并不支持其句子的来源。端到端测试应评估论断支撑情况、完整性以及是否恰当地表达不确定性。避免用答案的流畅度来替代检索质量的评估；精雕细琢的文字可能掩盖缺失的文档或过期的来源。

时效性依赖更新策略

检索流水线需要一个用于刷新、替换和删除已索引来源的策略。采集时间戳表示你的系统观察到某页面的时间；它并不必然说明该页面的发布时间，或其中描述事件发生的时间。尽可能保留并区分这些信息。

以一个假设的版本发布文档语料库为例，新页面版本可能使旧的配置建议失效。根据版本策略更新来源记录，并从激活检索中移除过时片段。在没有清晰元数据的情况下同时保留二者，会导致系统把互相矛盾的指令当作同样最新的内容呈现。

删除同样需要谨慎。如果来源文件被删除，而它的片段仍然留在索引或缓存的证据包中，那么删除就是不完整的。跟踪依赖关系，以便更新会影响到可搜索的表示以及存储。预先定义：当先前引用的证据不再可用时，应用将如何响应，而不是悄悄用不相关的来源替换。

用边界检查诊断流水线

边界检查测试的是在检索各阶段之间交换的工件。抽取之后，检查相关内容是否存在。切分之后，检查完整单元是否保留下来。检索之后，检查相关单元是否在候选集合中。组装之后，检查它是否带着必要的限定条件一并传达到模型。

在优化吞吐量之前，先从一个小语料库和一组经审查的问题开始。将处理配置和语料库版本与评估结果关联起来。如果你之后更换了嵌入模型或抽取规则，用相同案例运行，观察哪些边界发生了变化。一个小而可追溯的评估，比一个无法还原其来源的大分数更有价值。

将采集基础设施与索引和推理成本分开。 Scrapeless 定价选项 涉及你设计中所使用的采集服务。索引存储、排序和模型调用有各自的计费。保留这些分类有助于更容易改进真正主导成本或延迟的阶段。

要点回顾

检索流水线通过一系列明确的处理阶段，把请求转化为选定证据。保留来源身份，在有效范围内进行检索，并评估确实被向下游传递的那些段落。当答案失败时，先检查各阶段边界，再考虑模型是否需要不同的提示。