RAG 网络搜索 API：定义来源准入契约

Emily Chen

Advanced Data Extraction Specialist

27-Oct-2026

摘要：

RAG 网络搜索 API 需要一个下游“准入契约”。 只有在评估了来源内容及其适用性之后，被发现的 URL 才能成为证据。
发现、获取和准入应是独立记录。 保持这些关系可检视，以便审阅者能解释为何某段内容会进入答案上下文。
缺失值需要显式含义。 未知的发布时间、不可访问的内容以及被拒绝的证据都不应被折叠成一个空白字段。
在宣称答案质量前先衡量证据漏斗。 准入率描述的是检索过程；它本身并不能证明生成的回答是正确的。

引言：一个 URL 是一条证据记录的起点

一个来源列表看起来可能很完整，但其中却没有任何段落适合用来回答用户的问题。URL 也许能成功解析，标题也许听起来相关，摘要也许也包含期望的术语。但这些事实本身都不足以证明应用为最终结论获取并评估了所需的证据。

因此，RAG 网络搜索 API 需要在“发现”与“答案生成”之间建立一个准入契约。该契约定义候选结果必须携带哪些信息、必须通过哪些检查，以及当结果无法被使用时，它的状态如何保持可见。这是一种应用层的数据设计，而不是声称搜索提供方会自动返回所有分析字段。

Google Search API 在一个搜索数据方案中提供结构化的发现上下文。构建证据驱动助手的团队可以通过 AI 模型和 RAG 场景来评估这一角色。这里提出的记录和示例是设计建议，并不包含任何实际执行的 API 调用或虚构的响应负载。

让每个阶段拥有自己的身份

发现、文档获取和证据准入应该拥有各自的标识符，并通过显式关系连接在一起。

发现记录描述候选目标是如何被找到的。获取记录描述从该目标尝试获取内容的过程。准入记录描述允许某个特定表示或段落进入答案上下文的决策。多个获取记录可以指向同一个候选目标，多个被准入的段落也可以来自同一份文档。

避免把 URL 当作每个阶段唯一的标识符。目标位置可用的内容会变化，不同问题也可能基于不同原因指向同一页面。一个稳定的内部身份可以让应用在不覆盖早期证据的前提下保留这些差异，而不是假装每次访问都获得了完全相同的文档。

在必要时对终端用户隐藏这些标识符，但要让运营人员可以检视这些关系。审阅者应当能够从一个答案断言追溯到被准入的段落，再追溯到获取的文档和最初的发现上下文。比起一个与产出决策脱节的来源列表，这条链条更加有用。

在不“虚构”提供方字段的前提下保留发现上下文

发现记录应保留所选产品实际提供的搜索信息，并将应用自有的上下文单独添加。

保存已批准的查询语句、目标市场或语言环境、观察时间以及所选目标。尽可能以原始形式保留相关的结果信息。如果应用为问题添加了类别、业务优先级或来源偏好，应将这些标注为内部注解，而不要暗示它们源自提供方的响应。

在实现过程中记录从提供方输出到内部记录的映射。数据契约应说明哪些值是被直接复制的、哪些是转换得到的、哪些是推断出的、以及哪些缺失。这样的区分有助于后续对变更进行排查。某个内部字段的缺失可能反映了提供方不支持相关能力，也可能是映射错误，或者是刻意延后的分类决策。
在确认可用字段时，请使用当前的产品和文档界面。Scrapeless API 架构提供了更广泛的采集上下文，但仍需要根据正在评估的具体搜索产品，确认一个可用的工作契约。不要在未核对实际支持的表示形式时，将一个规划阶段的字段名称当作已经承诺的 API 标识符。

将原始与解析后的目标地址放在一起

目标记录应同时保留发现到的 URL 和在获取过程中得到的最终位置。

重定向可能是合法的，但也可能改变应用实际接收到的文档。指向已废止政策的链接，可能会被解析到一个不再包含相关材料的通用落地页。保留这两个位置有助于操作人员判断抓取到的内容是否与发现阶段看上去承诺的来源相匹配。

仅在有文档说明的规则下做规范化处理。移除跟踪参数可能有利于归组，而删除选择文档版本的参数则可能改变资源本身。保留原始值，这样在调整归组方式时不会丢失关于实际发现内容的证据。

URI 通用语法标准定义了资源标识符的各个组成部分。在设计规范化时，要谨慎应用这种结构性理解。通用的字符串清理规则不应悄悄抹去用于标识支撑答案材料所需的有效路径、查询或片段信息。

定义什么算作已获取的内容

“已获取的内容”应意味着应用拥有了预期源材料的可用表示。

仅有 HTTP 成功响应并不能建立这一条件。响应体可能只是导航外壳、通用的不可用页面，或与所选结果无关的文本。获取阶段需要对内容进行检查，这个检查要针对预期来源和问题本身，而不能只把状态码为成功就当作完成。

记录下游处理实际接收的表示。如果流水线从文档中抽取文本，应保留足够的信息，用来标识源版本和抽取过程。后续审查者需要知道，一个缺失的限定条件究竟是原始内容中就不存在，还是在转换过程中丢失的。

HTTP 语义标准描述了协议响应的含义。你的接纳契约会在此之上增加应用层要求：已获取的表示必须真正包含合适的证据。将这些层次区分开来，可以避免把传输层的成功误认为是对证据是否完整的评估。

让接纳成为一个带有理由的决策

证据接纳应记录清楚，为什么某个来源片段适合作为当前论断的支撑。

一个务实的决策可以综合考虑主题相关性、来源权威性、生效期间、适用司法辖区，以及该片段是否直接支持拟议的陈述。这些维度不需要被压缩成不透明的综合评分。与缺乏稳定释义的数值置信度相比，一个明确的理由往往对调试和审查更有用。

在设计契约时使用假设性的接纳案例。当前的官方规范可以满足关于某个协议要求的陈述。过时的地区政策，可能会被拒绝用于当前的全球性主张。讨论相关产品的来源，可能需要缩窄答案范围，而不是在原问题下直接接纳该片段。

在需要解释未解决的答案或改进来源选择时，应保留被拒绝的候选。被拒绝并不一定意味着页面质量低劣，只可能意味着这些材料不支持这个问题、这个时间段或这个论断。要在“理由”词汇中保留这种区分。

用 Scrapeless 开始抓取

通过 Scrapeless 强化你的网页抓取与自动化工作流！
立即注册即可获得 $5 免费额度 —— 无需信用卡。

现在就前往 Scrapeless 控制台领取你的免费额度。

为缺失值赋予具体含义

缺失值应对不确定性或缺席情形进行足够精确的刻画，以便为下一步决策提供指引。
未知的发布时间不同于已确认的“无日期”页面。不可用内容不同于已获取但不包含相关段落的内容。未审核的来源不同于被拒绝的来源。用一个空白字段来同时表示所有这些状态，会让后续的报告和产品行为变得不可靠。

为各个阶段状态选择一个小而受控的词汇表，并用日常语言加以解释。当额外背景重要时，把原因与状态放在一起。当运营人员不需要阅读每一份候选文档的完整处理历史时，也应该能够识别出当前哪个阶段需要关注。

数据质量词汇提供了用于描述质量评估和相关元数据的概念。利用这一原则，让数据质量在证据记录中保持可见。不要把缺失的信息默默转换为“该来源是最新的、权威的或不相关的”这样的断言。

记录时间而不将其等同于“新鲜度”

观测时间和来源新鲜度回答的是不同的问题，应当保持区分。

搜索观测时间记录发现发生的时间。获取时间记录应用何时获得了一份表征。来源的发布日期、修订日期或生效日期在可用时描述的是材料本身。新抓取的文档仍然可能描述一个已经过时的产品版本，或者一项已不再适用的政策。

为交换记录选择一个一致的时区约定并将其文档化。互联网时间戳规范为交换的时间值提供了标准格式。当解释存在不确定性时，保留原始来源的日期表达。一个页面声称“最近已更新”，并不一定能确定相关段落何时发生了变化，因此避免仅凭页面的通用标签就声称某个段落是“最新的”。

让新鲜度要求依赖于问题类别。历史研究可以有意使用较旧的文献，而当前资格认定问题则可能需要一个包含用户情形的有效期。纳入规则应当解释这种要求，而不是把“内容更新”视为普遍更优。

用稳定的分母来衡量证据漏斗

证据漏斗度量应当描述各个阶段实际发生了什么，而不过度夸大它们所能证明的内容。

发现计数描述候选目的地；获取计数描述获得的表征；纳入计数描述在某条规则下被接受为证据的内容。应当将这些度量分开。较高的纳入比例可能反映的是问题集较窄或者策略较宽松，而不是更优的搜索质量。

在计算比例之前，先定义比较人群。重复的目的地、重复的查询、被排除的问题类别以及不完整的获取过程，都可以改变分母。报告应当解释哪些记录符合条件，并让未解决的案例保持可见。否则，处理规则的改变可能会被误认为是检索效果的提升。

要单独评估最终答案。已被纳入的证据仍然可能被不准确地引用、被应用到其语境之外，或被组合成一个缺乏支持的结论。漏斗度量有助于定位流程问题；它们不能替代对用户实际收到的回答在“论断层面”的评估。

保留会影响含义的变换

当某个变换改变了哪些证据能够进入回答语境时，应当保持其可追溯性。

去重、文档分段、语言处理以及来源偏好规则，都可能影响生成器接收到的内容。应当把适用的规则版本与纳入决定关联起来。如果一次分段变更从某个段落中移除了限定条件，运营人员需要能够区分：这是分段问题，而不是原始来源本身的薄弱之处。

来源追踪模型家族为连接来源实体、处理活动和生成的证据提供了概念基础。轻量级的实现也可以在不采用复杂本体的前提下，保留这些关键关系。重要的要求是：审阅者能够重建那些有意义的决策。

当一条规则发生变化时，要决定是否需要重新评估较早的证据。被修正的目的地规范化规则可能会影响分组，但不会改变来源内容本身；被修订的纳入标准则可能改变哪些历史段落符合条件。解释重算的范围，这样接收方就不会把“修订后的解读”误认为是一次新的观测。

按照发现契约评估无抓取（Scrapeless）

无抓取（Scrapeless）的评估应当明确搜索输出是如何进入你拥有的证据记录中的。
将拟议的发现字段和代表性问题类别纳入评估中。确认由 Google Search API 产品提供的结构化结果信息和上下文控制。将文档获取、来源资质评估、段落准入和答案评估保持为明确的下游职责，而不是假定为搜索响应自带的特性。

使用 Scrapeless 定价来在当前商业条款下讨论预期的发现工作负载。将发现成本与获取和评估源文档所需的运营投入区分开来。在没有真实评估之前，不要凭空发明“每个被支持答案的计量成本”；有用的采购审查应同时考虑这两者。

要求可检查的交接过程。产品负责人应该能够解释为何选择了某个目的地、是否获得了预期内容，以及适用了哪条准入规则。这个要求使搜索提供方的选择变得具体，同时让应用本身对其随后构建的证据链负责。