您的RAG流程在首次嵌入之前就开始了

搜索系统可能会从本不应被纳入其证据库的文档中返回流畅的答案。标题可能属于某一页，而URL却指向另一页；已保存的页面可能仅包含预览内容；表格在提取后可能会变成没有标签的数字列表。

将这些内容嵌入其中虽可使其具备搜索功能，但并不能保证其可靠性。

对于知识应用而言，我建议首先建立来源清单：记录已收集的内容、实际提取的内容以及能够可靠支撑答案的信息。这样的清单还能让基于文章的发布流程更易于审核，因为每份草稿都可以对应到其证据的具体版本。

将发现过程与证据分开

标题、作者和简短描述是很有用的检索元数据。它们能帮助你决定接下来阅读哪篇文章。但仅凭这些信息不足以还原文章的论点、核查其中的例子，或了解作者得出的结论。

应明确标注内容的可用性。可行的状态包括仅包含元数据、完整性未知的提取文本、已验证的完整文本以及身份冲突情况。避免使用单一的indexed: true标志来掩盖这四种情况。

最简化的记录可能如下所示：

{
  "source_id": "article-42",
  "canonical_url": "https://example.com/article-42",
  "content_status": "extracted_text",
  "completeness": "unverified",
  "content_hash": "sha256-of-extracted-text",
  "retrieved_at": "2026-09-17T12:00:00Z"
}

哈希值用于标识文本版本，但它并非真实性的衡量标准。同样，较长的提取内容只能说明有可用文本，无法证明不存在付费墙、解析器故障或导航限制对其造成的改动。

保留具有意义的内容关联

文档解析与分块解决的是不同的问题。解析的目的是恢复文档结构，而分块则是决定如何划分该结构。如果提取过程将表格中的数值与其列标题分开，后续的分割工具就无法可靠地重建这种缺失的关联。

以一份维护指南为例，其中会列出某个组件、其检查间隔以及改变间隔的条件。仅保存检查间隔虽然能给出看似合理的答案，但却不完整。在考虑向量相似性之前，应先将标签和异常情况一起保留下来。

正因如此，分块边界需要明确设计。分割工具无法弥补那些早已丢失的信息。

在不丢弃数据的前提下让故障显现

为便于维护，应保留有问题的记录以便检索，但不得将其纳入用于撰写答案或出版物的证据集中。需记录原因：标识符不匹配、内容缺失、语言不确定或提取失败。

这种区分支持两种不同的工作流程。维护检索旨在找出需要修复的内容，而答案检索则用于确定哪些来源能够为某项论点提供支持。二者不应默默返回相同的数据集。

在用于出版时，还需进行另一项检查：通读你打算使用的段落。某个来源可能与主题相关，但却无法支持你草稿中的特定结论。

将检测来源质量作为产品的一部分

刻意准备一些格式尴尬的测试数据：文章预览、重定向后的URL、双栏页面、带脚注的表格，以及同一文档的两个版本。在衡量搜索相关性之前，先检查提取的结果。

更广泛的评估工作流程应当能够区分“证据缺失”“排名不佳”与“生成内容无依据”这三种情况。否则，检索问题可能会让你重新回到原始提示中，而真正的缺陷却依然存在于数据源中。

第一个有用的里程碑其实很简单：每条记录都要说明现有内容是什么以及其来源。一旦做到这一点，后续的改进就更容易理解了。