跳到主要内容

RAG与知识系统

核对日期：2026-05-13。

不稳定项：Embedding 模型、向量数据库能力、Rerank 模型、RAG 框架 API、文件检索托管服务和评测工具变化较快；生产项目必须以官方文档和本地评测结果为准。

1. 阶段目标​

本阶段目标是掌握 RAG 从“能搜到一些文本”到“可追溯、可评测、可控权限的知识系统”的完整工程链路。RAG 不是把文档塞进向量库就结束，而是一套数据工程、检索工程、上下文工程、生成控制和质量评测的组合。

学完本阶段，你应该能做到：

  • 解释 RAG 解决什么问题，不解决什么问题。
  • 设计文档导入、清洗、切分、元数据和索引流程。
  • 比较关键词检索、向量检索、混合检索和 rerank 的适用场景。
  • 设计带引用、可追溯、能拒答的问答流程。
  • 在检索前后做权限过滤和租户隔离。
  • 建立 RAG 评测集，评估召回、证据相关性、答案 groundedness、引用覆盖和拒答准确率。
  • 识别 RAG 常见失败模式，并能从数据、检索、Prompt、模型和产品体验层面定位问题。

本阶段的核心产出是：

  • 一个 RAG 系统设计文档。
  • 一套文档 chunk 和元数据规范。
  • 一个 20 条以上的 RAG eval 集。
  • 一个失败样例分析表。

2. 学习前置条件​

建议已完成：

  • 05-Transformer与大模型原理，理解上下文窗口、幻觉和模型边界。
  • 06-Prompt与上下文工程，能设计上下文包和结构化输出。
  • 理解向量、相似度和基本信息检索概念。

不要求：

  • 自研向量数据库。
  • 掌握所有检索算法。
  • 训练 embedding 或 rerank 模型。

3. 核心知识地图​

4. 详细讲义​

4.1 RAG 解决的问题和边界​

RAG 是 Retrieval-Augmented Generation，即检索增强生成。它的核心思想是：在模型生成前，从外部知识库检索相关证据，把证据作为上下文提供给模型。

RAG 适合解决：

  • 模型训练后才出现的新知识。
  • 私有知识库问答。
  • 需要引用来源的回答。
  • 企业制度、产品文档、技术文档、客服知识库。
  • 不适合放进模型参数里的大量事实。

RAG 不适合单独解决：

  • 复杂权限和审计。
  • 数据质量很差的知识库。
  • 需要强事务一致性的查询。
  • 需要精确计算的任务。
  • 没有标准答案的开放创作任务。

工程判断：RAG 是知识接入方式，不是正确性保证。

4.2 RAG 基本链路​

典型 RAG 分为离线索引和在线查询。

离线索引：

数据源 -> 加载 -> 清洗 -> 切分 -> 元数据 -> embedding -> 建索引

在线查询：

用户问题 -> 查询改写 -> 检索召回 -> 权限过滤 -> rerank -> 上下文构造 -> 生成回答 -> 引用/拒答 -> 记录评测

这两条链路都要可观测。只看最终答案无法知道到底是数据错、检索错、排序错、Prompt 错还是模型生成错。

4.3 文档加载和清洗​

文档加载不是简单读取文本。不同来源有不同问题：

数据源常见问题处理建议
PDF页眉页脚、分页、表格错乱保留页码，清理重复页眉
网页导航、广告、脚本提取正文，保留 URL
Markdown标题结构清晰利用标题层级切分
Word / PPT格式复杂转换后人工抽样检查
数据库字段语义强保留主键和更新时间
代码库依赖结构重要保留路径、符号、语言

清洗原则：

  • 不要破坏可引用性。
  • 保留来源、版本、更新时间。
  • 删除明显噪声和重复内容。
  • 对表格、代码、公式做专门处理。

4.4 Chunk 策略​

Chunk 是检索的基本单位。切分过大，召回内容噪声多；切分过小，缺上下文。

常见策略：

策略适用风险
固定长度切分快速 baseline切断语义
标题层级切分Markdown、文档标题不规范时效果差
段落切分普通文本粒度不稳定
语义切分长文档实现复杂
代码符号切分代码库需要语言解析

chunk 元数据至少包含：

  • source_id
  • document_id
  • chunk_id
  • title_path
  • page 或位置范围
  • updated_at
  • access_scope
  • content_hash

工程判断：没有元数据的 chunk 很难做权限、引用、更新和故障排查。

4.5 Embedding 和向量检索​

Embedding 模型把文本映射成向量。向量检索根据相似度找语义接近的 chunk。

优势：

  • 能找同义表达。
  • 用户问题不必和文档关键词完全一致。
  • 适合自然语言问答。

局限：

  • 语义相似不等于事实相关。
  • 数字、代码、专有名词、短查询可能效果差。
  • embedding 模型变更会影响整个索引。
  • 跨语言、领域术语和表格信息需要额外验证。

工程要求：

  • 记录 embedding 模型版本。
  • 索引和查询必须使用兼容模型。
  • 模型变更时要重建索引并回归评测。

4.6 关键词检索、混合检索和 rerank​

关键词检索适合精确匹配专有名词、编号、错误码、API 名称。向量检索适合语义表达差异大的问题。

混合检索通常结合两者：

BM25 / keyword top_k + vector top_k -> 合并去重 -> rerank -> top_n

Rerank 是对候选文档重新排序。它通常比纯向量相似度更关注“问题和文档是否真的能回答”。

组件优点缺点适用
关键词检索精确、快、可解释同义表达弱API、编号、代码
向量检索语义泛化可能召回语义相似但无关内容自然语言问答
混合检索召回更稳参数更多企业知识库
Rerank排序更准增加延迟和成本高质量问答

4.7 查询理解和改写​

用户问题经常不适合直接检索：

  • 指代不明：“这个怎么配置？”
  • 太短：“报销”
  • 复合问题：“试用期报销和转正后有什么区别？”
  • 带错别字或内部简称。

查询改写可以做：

  • 补全上下文。
  • 拆分多问题。
  • 生成关键词和语义查询。
  • 提取实体、时间、产品线、版本。

风险：改写可能改变用户意图。因此要记录原始查询、改写查询和检索结果，便于排查。

4.8 上下文构造和引用​

检索结果不能原样塞给模型，需要构造成可使用的上下文。

推荐证据格式：

[source_id: handbook-2026, chunk_id: c12, page: 8, updated_at: 2026-04-01]
标题：差旅报销 / 住宿标准
内容：...

回答要求：

  • 每个关键结论带引用。
  • 引用必须来自实际证据。
  • 如果证据不足，拒答或说明无法确认。
  • 冲突证据要说明冲突，而不是强行合并。

引用不是装饰。引用必须支持结论，否则会制造“带来源的幻觉”。

4.9 权限过滤和租户隔离​

RAG 系统最容易被低估的是权限。

权限过滤至少要考虑：

  • 用户能否访问该文档。
  • 用户能否访问该文档的该字段或段落。
  • 文档是否属于当前租户。
  • 文档是否已过期、归档或撤回。
  • 检索缓存是否跨用户泄漏。

推荐原则：

  • 索引时写入权限元数据。
  • 检索时做预过滤和后过滤。
  • 生成前再次检查证据权限。
  • 不把无权限证据放入模型上下文。
  • 日志中避免记录敏感原文。

安全判断：不能让模型自己决定“用户有没有权限”。

4.10 RAG 评测指标​

RAG 评测至少分四层：

层级指标说明
检索召回recall@k正确证据是否被召回
排序质量MRR / nDCG正确证据是否排在前面
生成质量正确性、完整性、拒答答案是否符合事实
证据一致性groundedness、引用覆盖结论是否被证据支持

评测样例字段建议：

  • question。
  • expected_answer。
  • required_sources。
  • user_scope。
  • should_refuse。
  • difficulty。
  • tags。

不要只让人看答案“顺不顺眼”。RAG 的关键是证据是否支撑答案。

4.11 RAG 失败定位​

RAG 失败时按链路排查：

现象可能原因检查点
答案不知道文档未导入索引覆盖率
答案编造没强制引用或证据不足Prompt 和拒答策略
引用不相关rerank 或上下文构造错误top_k、rerank 分数
只答一部分复合问题未拆分query decomposition
泄露无权限信息权限过滤缺失access_scope 和日志
更新后仍答旧内容索引未刷新或缓存陈旧content_hash、updated_at

4.12 RAG、微调和 Agentic RAG 的边界​

方案适合不适合
RAG外部事实、私有文档、可追溯问答改变模型行为风格
微调稳定任务格式、风格、专业表达注入大量常变事实
Agentic RAG多源检索、需要动态选择工具低延迟固定 FAQ
传统搜索精确查找、过滤、排序复杂语义生成

经验规则：先做 2-step RAG baseline，再评估是否需要多轮检索、自校验或 Agentic RAG。复杂系统应该来自评测驱动，而不是架构冲动。

5. 关键概念表​

概念含义工程意义常见问题
RAG检索增强生成接入外部知识以为天然正确
Loader数据加载器接入数据源忽略格式噪声
Chunk检索基本单位决定召回粒度太大或太小
Metadata来源、版本、权限等信息支撑引用和治理缺字段无法排查
Embedding文本向量表示支撑语义检索语义相似不等于相关
Vector Store向量索引和查询提供近邻检索当成知识库本体
Hybrid Search关键词 + 向量提高召回稳定性参数复杂
Rerank候选重排序提升证据相关性增加延迟
Groundedness答案被证据支持程度评估幻觉只看答案不看证据
Citation来源引用可追溯和信任引用不支持结论
Refusal证据不足时拒答降低编造拒答过多影响体验

6. 工程案例​

6.1 企业制度问答​

场景：员工询问差旅、报销、休假制度。

关键设计：

  • 文档按制度版本索引。
  • chunk 保留章节、页码和生效日期。
  • 问答必须带引用。
  • 过期制度不能进入上下文。
  • 证据不足时返回“无法从当前制度确认”。

高风险点：制度变更后索引未刷新，会导致旧答案。

6.2 技术文档搜索​

场景：开发者询问框架 API 用法。

关键设计：

  • 混合检索保留函数名、错误码、配置项精确匹配。
  • 代码块和正文分开处理。
  • 回答包含版本号和文档链接。
  • 对“最新 API”类问题标注文档核对时间。

高风险点：向量检索可能错过精确 API 名称。

6.3 合同条款检索​

场景：法务查找违约责任、付款周期、自动续约条款。

关键设计：

  • 保留原文页码和条款编号。
  • 不让模型改写成法律结论。
  • 输出“相关条款 + 风险提示 + 需要人工确认项”。
  • 关键字段用规则或解析器二次提取。

高风险点：摘要不能替代法律审查。

6.4 代码库语义搜索​

场景：问“用户登录 token 在哪里刷新？”

关键设计：

  • 按文件、函数、类、注释和调用关系组织 chunk。
  • 关键词检索匹配函数名和路径。
  • 向量检索匹配意图。
  • 返回文件路径和符号位置。

高风险点：只索引文本不索引依赖关系，容易遗漏关键调用链。

6.5 客服知识库​

场景：客服助手根据产品知识库生成回复草稿。

关键设计：

  • 检索产品、订单状态、用户历史和政策。
  • 答案输出为“草稿”，需要客服确认。
  • 对退款、赔付、封禁等高风险动作走规则和审批。
  • 记录未命中问题反哺知识库。

高风险点：模型不能代表系统执行承诺。

7. 常见误区与反模式​

反模式表现后果修正
文档直接塞上下文不建索引，全量输入成本高、遗漏、污染检索和排序
只做向量检索没有关键词和过滤专有名词召回差hybrid search
无元数据chunk 没来源和版本无法引用和治理建元数据规范
无权限过滤所有文档混在一个库数据泄露租户和权限隔离
引用做装饰答案后随便挂来源带引用的幻觉验证引用支持结论
不评测召回只看最终回答难定位失败分层 eval
top_k 盲目调大一错就加候选数上下文噪声变多rerank 和 query 改写
忽略文档更新索引长期不刷新答旧知识增量索引和版本
不设计拒答任何问题都回答编造事实evidence threshold

8. 阶段练习​

8.1 Chunk 策略比较​

选择一份 20 页以上文档，分别尝试：

  • 固定 500 字切分。
  • 按标题层级切分。
  • 段落 + overlap 切分。

对同一组 10 个问题比较召回效果，并记录错误类型。

8.2 检索对比练习​

为同一知识库实现或模拟：

  • 关键词检索。
  • 向量检索。
  • 混合检索。

记录每个问题的 top 5 结果，判断哪个方法召回正确证据。

8.3 Rerank 练习​

准备 20 个候选 chunk，手工标注和问题的相关性：

  • 3 分：直接回答问题。
  • 2 分：部分相关。
  • 1 分：主题相似但不能回答。
  • 0 分：无关。

比较 rerank 前后 top 5 质量。

8.4 引用验证练习​

让模型生成带引用回答，然后逐条检查：

  • 引用是否存在。
  • 引用是否支持结论。
  • 是否有结论没有引用。
  • 是否有引用被过度解释。

8.5 RAG 拒答练习​

构造 10 个知识库没有答案的问题，设计拒答规则：

  • 没有检索结果。
  • 检索结果低相关。
  • 证据冲突。
  • 用户无权限。
  • 问题要求预测或编造。

9. 项目任务​

9.1 项目要求​

完成一个可追溯知识库问答系统的设计和最小实现。

必须包含：

  • 支持至少一种文档导入。
  • 有 chunk 和元数据规范。
  • 支持检索和带引用回答。
  • 支持证据不足时拒答。
  • 有 20 条以上评测样例。
  • 输出失败样例分析。
  • 记录 token、检索耗时、生成耗时和命中证据。

9.2 设计文档模板​

# RAG 知识系统设计文档

## 1. 业务目标
## 2. 数据源和更新频率
## 3. 文档处理和 chunk 策略
## 4. 元数据与权限模型
## 5. 检索策略
## 6. Rerank 和上下文构造
## 7. Prompt 和输出格式
## 8. 引用和拒答规则
## 9. 评测集和指标
## 10. 已知失败模式
## 11. 成本、延迟和监控

9.3 评分标准​

维度分值标准
数据处理20数据源、清洗、chunk、元数据完整
检索质量20能比较关键词、向量、混合和 rerank
引用与拒答20答案可追溯，证据不足能拒答
权限与治理15有租户、权限、版本和日志策略
评测体系20有分层指标和失败样例分析
工程表达5文档结构清晰，可交接实现

10. 验收题​

  1. RAG 适合解决哪些问题，不适合解决哪些问题？
  2. 离线索引和在线查询分别包含哪些步骤？
  3. Chunk 大小如何影响召回和上下文质量？
  4. 为什么 metadata 是 RAG 系统的关键组成？
  5. 向量检索和关键词检索各自适合什么场景？
  6. Rerank 解决什么问题，代价是什么？
  7. 为什么引用必须验证是否支持结论？
  8. RAG 权限过滤应该在哪些环节做？
  9. RAG 评测为什么要分检索、排序、生成和 groundedness？
  10. RAG 和微调分别适合什么问题？

11. 延伸阅读​

官方与框架资料​

检索与向量数据库资料​

建议阅读方式​

  • 先读 RAG 框架文档，跑通最小链路。
  • 再集中研究 chunk、metadata、hybrid search 和 rerank。
  • 最后用 eval 集驱动优化，不要靠单个 demo 判断效果。

12. 本阶段总结​

RAG 的价值是把外部知识带进模型上下文，并让答案更可追溯。但可靠 RAG 不只是向量检索，它依赖数据质量、切分策略、元数据、权限、排序、引用、拒答和评测。

你应该形成一个判断：RAG 失败时不要第一反应换模型。先拆链路，看正确证据有没有进入候选、有没有排在前面、有没有进入上下文、有没有被模型正确使用。

下一阶段进入 AI 应用工程。你会学习如何把模型、Prompt、RAG 接入真实 Web/服务端系统，并处理 streaming、异步任务、成本、错误和用户体验。