跳到主要内容

RAG 系统概览

1. 一句话结论​

RAG（Retrieval-Augmented Generation，检索增强生成）先从受控知识源中找到与问题相关的证据，再把证据连同问题交给模型生成回答；它的可靠性主要取决于知识质量、切块、检索、过滤、引用和评估，而不只是向量数据库或语言模型。

2. RAG 解决什么问题​

模型参数中包含训练时学习到的统计知识，但这些知识难以及时更新，也不天然带有可核验来源。RAG 把外部知识作为可更新的非参数记忆，使系统能够：

  • 使用组织内部或专业领域资料回答问题。
  • 在不重新训练模型的情况下更新知识。
  • 将回答连接到具体文档和段落。
  • 根据权限、领域、语言或版本限制检索范围。
  • 把通用模型能力与 CBL 的专业知识组合起来。

RAG 不会自动保证答案正确。错误资料、失败检索、不当切块或模型对证据的误读，仍然会产生错误回答。

3. 完整流程​

RAG 包含离线索引和在线问答两条流程。

离线索引​

知识原件
  ↓
解析正文与元数据
  ↓
按语义结构切块
  ↓
生成关键词索引与 Embedding
  ↓
写入搜索索引并保留来源映射

在线问答​

用户问题
  ↓
理解查询与确定检索范围
  ↓
关键词 / 向量 / 混合检索
  ↓
元数据过滤与结果重排
  ↓
组织证据上下文
  ↓
模型生成带引用回答
  ↓
质量检查、反馈与评估记录

索引是知识原件的派生物。模型、Embedding 或切块策略改变时，应能够从 Markdown 和资产源重新生成索引。

4. CBL 的知识源​

CBL 建议保留以下来源层次：

  • Git Markdown：公开知识正文、front matter 和修订历史，是主要知识原件。
  • R2 资产：未来用于 PDF、数据表、原始图片、数据集和较大附件。
  • 结构化数据：未来可能存放产品参数、文档索引、评估结果和任务日志。
  • 外部来源：论文、标准、厂商资料和官方网页，只在授权与引用边界内使用。

公开网站本身也可以作为托管搜索服务的数据源，但 Git 中的 Markdown 仍应是内容治理和版本控制的中心。

5. 文档解析与切块​

切块的目标不是把所有文档机械切成相同长度，而是让每个检索单元表达一个能够独立理解的问题或结论。

CBL 建议：

  • 优先沿 H2/H3 标题边界切块。
  • 在每个块中保留文档标题和标题路径。
  • 一句话结论、参数表、误区和参考资料使用不同的处理策略。
  • 避免把表头与表格内容拆开。
  • 过短相邻段落可以合并，过长章节再按段落细分。
  • 为块保留少量上下文重叠，但不重复大段内容。
  • 不把导航、footer 和页面模板噪声写入知识索引。

不存在适合所有文档的固定 Token 数。最终大小应通过检索评估决定，而不是只看行业常用数值。

6. 最小元数据模型​

每个检索块至少应保留：

字段作用
canonical_id识别原始文档，即使标题或 URL 变化仍能保持关联
chunk_id唯一识别文档中的具体检索块
title文档标题
heading_path当前块所在的 H2/H3 层级
source_url回到公开页面或授权来源
domain限定 Photonics、AI 等主要领域
visibility区分 public、internal、private 和 restricted
status排除 archived，或降低 draft 内容的权重
language支持中文、英文和未来多语言检索
last_reviewed判断内容时效性
content_hash检测内容是否变化并支持增量重建

向量元数据适合存储检索和过滤所需的短字段。完整正文和大附件仍应保留在原始知识源中。

7. 关键词、向量与混合检索​

关键词检索​

适合精确术语、型号、公式、标准编号和缩写。例如 G15978-0020P 或 canonical_id 不应只依赖语义相似度。

向量检索​

适合自然语言问题、同义表达和概念相似性。例如“APD 为什么需要温度补偿”可以匹配没有完全相同措辞的相关章节。

混合检索​

混合检索结合关键词和向量结果，再进行融合或重排。对于同时包含中文、英文术语、产品型号和专业概念的 CBL，混合检索通常比单一路径更合理。

8. 元数据过滤与排序​

在计算语义相似度之外，应先确定哪些内容有资格参与回答。公开 CBL 可以使用：

  • visibility = public
  • status 不等于 archived
  • 与用户问题匹配的 domain
  • 当前语言或允许的多语言范围

排序还可以考虑：

  • 与查询的关键词和语义相关度。
  • stable、review、draft 的内容成熟度。
  • 最近复核时间。
  • 是否来自原始资料、标准或官方文档。
  • 多个结果是否只是同一段内容的重复版本。

过滤字段需要在建立索引前规划。向量数据库通常只对明确建立索引的元数据字段提供高效过滤。

9. 回答与引用​

检索结果进入模型前，应组织成带编号的证据块，并保留标题、URL 和章节。回答阶段要求模型：

  • 优先依据检索内容回答。
  • 对没有证据支持的部分说明不确定性。
  • 把事实来源和模型推断区分开。
  • 在关键结论附近给出引用，而不是只列文末资料。
  • 当资料冲突时展示冲突，不强行合并成单一结论。
  • 找不到足够材料时拒绝编造，并建议需要补充的资料。

引用存在不等于引用正确。系统仍需要验证引用是否真正支持对应句子。

10. 评估体系​

RAG 至少需要分别评估四个层次：

内容质量​

  • 来源是否可靠、可公开和仍然有效。
  • 文档是否有清晰边界和最近复核日期。

检索质量​

  • 正确证据是否出现在前若干结果中。
  • 结果是否被错误领域、重复内容或旧版本占据。

回答质量​

  • 结论是否受到检索材料支持。
  • 是否遗漏关键条件或夸大证据。
  • 引用是否指向正确文档和章节。

系统质量​

  • 延迟、成本和失败率是否可接受。
  • 内容更新后索引是否及时刷新。
  • 权限过滤是否在后端可靠执行。

测试集应来自真实问题，例如“为什么 APD 不能使用固定 40 V 偏压”，并包含期望证据、关键结论和不可接受回答。

11. 公开与私有隔离​

公开与私有知识不能只依赖提示词或前端按钮隔离。建议：

  • 使用独立数据源、索引和访问凭证。
  • 私有检索在后端验证身份和权限。
  • 不把 private 或 restricted 内容发送到公开模型或日志。
  • 对每个回答记录使用了哪些文档和权限范围。
  • 禁止公开回答通过跨索引检索接触私有内容。

即使向量本身不易被人直接阅读，也应把 Embedding 和元数据视为派生敏感数据。

12. Cloudflare 上的两条实施路线​

Cloudflare AI Search 可以连接自有网站、R2 或上传文件，自动处理索引，并支持关键词、向量、混合检索和元数据过滤。

适合 CBL 的公开试点，因为：

  • 可以直接从已部署网站开始。
  • 运维和索引管道较少。
  • 适合先验证真实问题和搜索体验。

需要验证它对 CBL 自定义 front matter、章节引用、中文切块和刷新时效的支持是否满足要求。

自定义 Workers + Vectorize​

自建流程可以使用 Worker 负责解析和查询，Vectorize 保存向量与检索元数据，R2 或其他存储保存原文与附件。

适合以下情况：

  • 需要完全控制切块和增量更新。
  • 需要自定义混合检索、重排与引用格式。
  • 需要复杂权限或公开、私有多套索引。
  • 需要独立评估、日志和模型路由。

代价是需要自己维护摄取、去重、重建、错误恢复和监控。

CBL 初期应优先验证托管路线，确认不足后再决定是否自建，不需要现在同时实现两套系统。

13. 分阶段实施​

当前：元数据准备​

  • 继续补齐 canonical_id、domain、visibility、status 和 last_reviewed。
  • 保持 Markdown 标题层级和参考资料规范。
  • 建立真实问题清单，作为未来评估集。

约 15 至 20 篇文档：搜索试点​

  • 先上线站内关键词搜索。
  • 试验 Cloudflare AI Search 对公开网站的索引效果。
  • 比较中文术语、英文缩写和型号的检索质量。

约 30 篇稳定文档：公开 RAG​

  • 建立带引用的问答入口。
  • 加入 domain、status 和语言过滤。
  • 用真实问题集测试检索与回答。
  • 明确无法回答和资料不足时的行为。

私有知识形成规模后：独立私有 RAG​

  • 使用独立存储、索引、身份验证和日志策略。
  • 先解决访问控制和数据生命周期，再增加 Agent 能力。

14. 常见误区​

  • “有向量数据库就有 RAG”：向量库只是检索组件之一。
  • “块越小越容易命中”：过小会丢失条件和上下文，过大则引入无关信息。
  • “相似度最高就是正确证据”：语义相似不等于事实支持，需要过滤、重排和评估。
  • “RAG 可以消除幻觉”：它能提供证据，但模型仍可能忽略、误解或超出证据。
  • “私有内容加一个 visibility 字段就安全”：安全边界必须落实在存储、索引和后端权限中。
  • “先接聊天界面，再补评估”：没有真实问题集就无法判断系统是否真的改进。

15. 与其他主题的关系​

16. 参考资料​

  1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，Lewis 等，2020。RAG 的代表性原始论文。
  2. Cloudflare AI Search，Cloudflare，访问日期 2026-08-27。用于核对托管索引、自然语言搜索和持续同步能力。
  3. Cloudflare AI Search configuration，Cloudflare，访问日期 2026-08-27。用于核对关键词、向量、混合检索、切块和元数据配置。
  4. Build a Retrieval Augmented Generation AI，Cloudflare，访问日期 2026-08-27。用于核对 Workers、Vectorize、D1 和模型组成的自定义 RAG 路线。
  5. Cloudflare Vectorize metadata filtering，Cloudflare，访问日期 2026-08-27。用于核对向量元数据过滤机制。

17. 修订记录​

  • 2026-08-27：建立 CBL 的 RAG 概念、元数据、检索、引用、评估和实施路线。