Day 21：Week 3 复盘与考试
学习目标
Week 3 的前六天，我们从 RAG 的原理一路学到了优化。今天是复盘和整合的一天。
复盘不是简单地回顾知识点，而是把散落的六天内容串成一个完整的认知体系。你需要回答一个核心问题：我能不能独立搭建一个企业知识库 Demo，从文档上传到问答输出，并且在效果不理想时知道怎么诊断和优化？
今天的实战任务是构建一个完整的企业知识库 Demo，用 5 篇文档、30 个测试问题来检验 Week 3 的学习成果。这是一个模拟真实项目交付的场景——你有一个客户需要知识库，你需要在一天内交付一个可演示的 MVP。
核心概念
一、RAG 架构复盘
先回顾 RAG 系统的全貌。
RAG 是什么。 Retrieval-Augmented Generation，检索增强生成。核心思想是”先搜后答”——先从知识库中检索相关内容，再让大模型基于检索内容生成答案。
RAG 解决的问题。 大模型的四个核心缺陷——知识过时、缺乏私有知识、幻觉、无法引用来源——RAG 针对性地解决了这四个问题。
RAG 的两个管线。
- 离线管线（Indexing）：文档 → 解析 → 清洗 → 切分 → 向量化 → 入库
- 在线管线（Querying）：问题 → 向量化 → 检索 → Prompt 组装 → 生成 → 引用标注
RAG 的局限。 检索质量决定上限、长文档处理困难、多跳推理能力弱、上下文窗口有限、维护成本不低。
复盘的关键不是记住这些条目，而是能在脑中形成一张清晰的图：当你听到”RAG”这个词时，脑海里应该浮现出两条管线、六个核心模块、以及它们之间的数据流。如果浮现不出来，说明前六天的学习还不够扎实，需要回头重新梳理。
二、文档解析复盘
文档解析是 RAG 管线的第一步，也是最容易低估复杂度的环节。
核心原则。 保留有价值的内容，去除噪声，保留结构信息。
五种文档格式的解析要点：
- PDF：最难，需要区分文字型和扫描型，注意多栏排版、表格、页眉页脚
- Markdown：最简单，天然有结构标记
- Word：需要从样式到结构的映射，注意表格和嵌入对象
- Excel：不是自然语言，需要文本化或摘要化处理
- HTML：技术最成熟，但需要处理 JS 渲染的内容
清洗的度。 宁可少去噪声，不要误杀有价值的内容。保守操作是基本原则。
元数据。 文档级别和片段级别的元数据是 RAG 系统的基础设施，从第一天就要设计好。
复盘时问自己：如果给你一份 50 页的 PDF 产品手册，你能不能设计一个解析和清洗方案，输出干净的文本 + 结构信息 + 元数据？如果不确定，回顾 Day 16 的内容。
三、Chunking 复盘
切分是影响 RAG 效果最显著的环节之一。
核心矛盾。 粒度要细（检索精准）vs 上下文要保留（理解完整）。
四种切分策略的对比：
- 固定长度：最简单，语义完整性最差
- 按段落：保留段落完整性，段落长度差异大
- 按标题：语义最完整，依赖文档有好的标题结构
- 语义切分：最智能，成本最高
Overlap 的作用和代价。 保留上下文但增加冗余。通常 10%-20% 的 Chunk Size。
Chunk 的上下文信息。 每个 Chunk 应该携带所属的章节标题等上下文信息，使得单独看一个 Chunk 也能理解它的背景。
复盘时问自己：如果给你一篇技术文档，你能不能选择合适的切分策略和参数，并解释为什么这样选择？
四、Embedding 复盘
Embedding 是连接文本和数学世界的桥梁。
核心原理。 把文本映射成数值向量，语义相似的文本在向量空间中距离近。
两个场景。 离线（文档 Chunk 向量化）和在线（用户问题向量化），必须使用同一个模型。
向量数据库选型。 根据数据规模、查询频率、功能需求、运维能力、成本预算来决策。
相似度检索。 余弦相似度是最常用的度量方式。Top-k 的 k 值需要根据场景调整。
元数据过滤。 在向量检索基础上增加按文档类型、时间等维度的过滤，提升检索精准度。
复盘时问自己：如果让你选择一个 Embedding 模型和向量数据库，为一个 500 篇文档的企业知识库做方案，你会怎么选？为什么？
五、检索优化复盘
检索优化是 RAG 系统从”能跑”到”好用”的关键。
八种优化手段的核心逻辑：
- Query Rewrite：改写问题，解决表述差异
- Multi-query：多角度查询，扩大覆盖面
- Hybrid Search：向量 + 关键词，互补短版
- Rerank：精细重排序，提升准确率
- Context Compression：去除噪声，聚焦关键信息
- Answer Grounding：约束模型，只基于检索内容回答
- Citation Check：验证引用，保证可追溯
- 检索失败回退：优雅处理失败，保证用户体验
优化原则。 一次加一种，测量效果，确认有效后再加下一种。不要一股脑全加上。
性价比排序。 Rerank > Query Rewrite > Hybrid Search > Multi-query > Context Compression > Citation Check。这个排序不是绝对的，但在大多数场景下 Rerank 的性价比确实最高。
复盘时问自己：如果一个 RAG 系统的主要问题是”专有名词检索不准”，你会选择哪些优化手段？如果主要问题是”答案中出现了文档里没有的信息”呢？
六、企业知识库产品化复盘
技术能力只是企业知识库的一部分。把它做成一个产品还需要考虑：
用户体验。 用户不需要知道 RAG、Embedding、向量数据库这些概念。他们只需要一个输入框和一个回答。界面的简洁程度直接影响用户的信任感。
文档管理。 文档上传、更新、删除的流程。权限控制（谁能看哪些文档）。文档版本管理。
答案可靠性。 引用来源、置信度提示、“不知道”的诚实回答。在面向企业用户时，可靠性比花哨重要得多。
运维体系。 系统监控（延迟、错误率、使用量）、定期评估（答案质量是否下降）、知识库更新（新文档入库、旧文档过期）。
成本控制。 每次问答的 API 调用成本、Embedding 成本、存储成本。需要给客户一个明确的成本预期。
概念关系图
Week 3 知识体系全景图
=========================================================
Day 15: RAG 原理与架构
|
| 建立"先搜后答"的认知框架
| 理解离线管线和在线管线
|
v
Day 16: 文档解析与清洗
|
| 原始文档 -> 干净文本 + 结构信息 + 元数据
| 核心原则：保留价值、去除噪声、保留结构
|
v
Day 17: Chunking 切分策略
|
| 干净文本 -> 适当大小的 Chunk + 元数据
| 核心矛盾：粒度 vs 上下文
|
v
Day 18: Embedding 与向量数据库
| |
| Chunk -> 向量 -> 向量数据库 | 选型决策
| 语义空间的数学表示 |
|
v
Day 19: RAG 问答链路 v1
|
| 问题 -> 向量化 -> 检索 -> Prompt -> 生成 -> 引用
| 端到端跑通，建立基线
|
v
Day 20: RAG 优化
|
| Query Rewrite / Hybrid Search / Rerank / Grounding / ...
| 针对性优化，量化效果
|
v
Day 21: 复盘与整合
|
| 完整的企业知识库 Demo
| 从技术能力到产品能力
|
RAG 系统排错指南
=========================================================
症状：答案不正确
|
+-- 检索到了正确的 Chunk 吗？
| |
| +-- 没有 --> 检索问题
| | |
| | +-- Chunk 中有答案但检索不到？
| | | --> 改进检索：Query Rewrite / Multi-query / Hybrid
| | |
| | +-- 知识库中根本没这个内容？
| | --> 补充知识库
| |
| +-- 有 --> 生成问题
| |
| +-- Prompt 中有正确的上下文？
| | --> 没有 --> 检查上下文拼接逻辑
| |
| +-- 模型基于上下文回答了吗？
| | --> 没有 --> 加强 Grounding / 降低 Temperature
| |
| +-- 检索结果中有太多噪声？
| --> Rerank / Context Compression
RAG 系统质量评估维度
=========================================================
维度一：检索质量
- 召回率：正确 Chunk 出现在检索结果中的比例
- 准确率：检索结果中相关 Chunk 的比例
- 排序质量：正确 Chunk 的平均排名位置
维度二：生成质量
- 准确性：答案内容是否正确
- 完整性：答案是否覆盖了问题的所有方面
- 简洁性：答案是否多余信息
维度三：引用质量
- 引用准确率：引用标注的 Chunk 是否确实支持答案
- 引用覆盖率：答案中的信息点是否都有引用
- 引用完整性：引用信息是否包含来源文档、章节、页码
维度四：系统性能
- 端到端延迟：从提问到获得答案的总时间
- 检索延迟：向量化 + 检索的时间
- 生成延迟：模型生成答案的时间
实战分析
任务一：构建一个企业知识库 Demo
这是今天的主线任务。用 Week 3 学到的全部知识，构建一个完整的企业知识库 Demo。
选一个行业场景。 建议选你熟悉的行业。如果你在制造业，就用制造业的文档；如果你对半导体行业有了解，就用半导体的文档。如果都不熟悉，用通用的产品文档和制度文件也行。
准备 5 篇文档。 文档要求：
- 至少包含 PDF 和 Markdown 两种格式
- 至少包含一篇超过 10 页的长文档
- 至少包含一个表格密集的文档
- 内容应该有足够的事实性信息（数字、流程、规则等）
完整执行 RAG 管线：
- 文档解析：对每篇文档选择合适的解析方式，提取文本和结构信息
- 文本清洗：去除噪声，保留结构
- 文本切分：选择切分策略，设置参数，执行切分
- 质量检查：检查 Chunk 的大小分布、语义完整性
- 向量化：选择 Embedding 模型，批量向量化
- 入库：选择向量数据库，写入向量和元数据
- 问答链路：实现问题向量化、检索、Prompt 组装、答案生成的完整流程
- 引用标注：确保答案带有引用来源
这个流程你应该已经很熟悉了。今天的重点不是学习新东西，而是整合和练习。
任务二：30 个测试问题
准备 30 个测试问题，比昨天的 20 个更多、覆盖面更广。
问题分布建议：
- 10 个简单事实型（有明确的单一答案）
- 8 个流程型（需要描述步骤或流程）
- 5 个条件判断型（需要根据规则判断）
- 4 个跨文档型（答案分布在不同文档中）
- 3 个知识库范围外的问题（测试失败处理）
运行测试。 对每个问题记录：
- 检索到的 top-3 Chunk 的摘要和相似度分数
- 系统生成的答案
- 正确答案（人工标注）
- 正确性判断
- 引用准确性判断
- 如果有问题，属于哪类错误（检索错误/生成错误/引用错误）
汇总统计。 计算整体准确率、引用准确率、不同类型问题的准确率、知识库范围外问题的处理表现。
任务三：输出 RAG 评估报告
基于 30 个问题的测试结果，写一份评估报告。
报告结构：
- 系统概述：用了什么技术栈、处理了多少文档、生成了多少 Chunk
- 整体表现：准确率、引用准确率、平均响应时间
- 分类型表现：不同类型问题的准确率对比
- 错误分析：每个错误案例的原因分类和根因分析
- 优化建议：基于错误分析，建议下一步的优化方向
- 已知局限：系统当前无法解决的问题，以及对应的处理策略
这份报告不是给自己看的，而是给”客户”看的——如果你在给企业做知识库项目，这就是交付文档的一部分。
当日产物说明
产物一：《企业知识库 Demo》
这是一个完整的、可演示的 RAG 系统。
应该包含：
- 5 篇已索引的文档
- 文档上传和索引的入口
- 问答界面（可以是命令行，也可以是简单的 Web 界面）
- 30 个测试问题的完整记录
- 答案带引用来源
质量标准：
- 30 个测试问题中，简单事实型的准确率不低于 80%
- 整体准确率不低于 60%
- 知识库范围外的问题至少能正确处理 2 个（回答”不知道”而非硬编答案）
- 每个答案都有引用来源（准确性可以不完美，但必须有）
产物二：《RAG 评估报告》
这是一份专业的评估文档。
应该包含：
- 系统概述和技术栈说明
- 测试方法和测试集描述
- 量化评估结果（准确率、引用准确率、响应时间）
- 分类型分析
- 错误案例和根因分析
- 优化建议和路线图
- 已知局限和风险提示
质量标准： 报告的专业程度可以让一个非技术人员理解系统的当前水平和局限。数据真实，分析到位，建议可执行。
产物三：《RAG 排错手册》
这是一份实用的排错指南。
应该包含：
- 常见症状和可能原因的对照表
- 每种原因的诊断方法
- 每种原因的修复方案
- 典型错误案例和解决过程
质量标准： 当 RAG 系统回答不好时，按照这个手册的步骤，能定位到问题所在。不需要覆盖所有可能的错误，但常见问题（检索不到、答案不对、引用不准）都要有对应的诊断流程。
产物四：《Week 3 学习总结》
这是一份个人学习总结。
应该包含：
- Week 3 学到的核心概念列表
- 每个概念的一到两句话理解
- 概念之间的关系图
- 个人觉得最难理解的知识点
- 还需要继续深入的方向
- Week 3 和 Week 1-2 的知识衔接关系
质量标准： 这份总结是你自己对 Week 3 的消化和沉淀。不需要完美，但需要真实。
常见误区与避坑
误区一：复盘就是重读笔记
复盘不是把前六天的笔记重新看一遍。那叫复习，不叫复盘。
复盘是站在更高的视角，重新审视学过的内容。问自己：
- 这些知识点之间的关系是什么？
- 哪些知识我已经内化了，哪些还是死记硬背？
- 如果让我给一个新人讲 RAG，我能讲清楚吗？
- 如果让我独立搭建一个 RAG 系统，我知道第一步做什么吗？
把六天的散点知识变成一张网，这是复盘的核心目的。
误区二：Demo 追求完美
今天的 Demo 不需要完美。它的目标是：
- 能跑通（端到端流程没有断点）
- 能演示（给别人看能理解 RAG 是什么）
- 能评估（有量化数据说明当前水平）
不需要：
- 界面好看
- 支持所有文档格式
- 准确率 90% 以上
- 支持多用户并发
MVP 的原则是”最小但可行”。先做到可行，再逐步完善。
误区三：忽略错误案例
测试 30 个问题，18 个答对了、12 个答错了。很多人会把注意力放在 18 个答对的上面，觉得”60% 的准确率还不错”。
但真正有价值的是那 12 个答错的。它们告诉你系统的薄弱环节在哪里。是检索的问题还是生成的问题？是某些类型的文档处理不好？还是某些类型的问题回答不了？
错误案例是优化的起点。没有错误的系统是不需要优化的系统，而真实的系统一定有错误。
误区四：不建立知识库范围说明
用户不知道知识库中有什么内容，也不知道系统能回答什么类型的问题。他们可能会问知识库范围之外的问题，然后得到一个错误的答案，进而对系统失去信任。
解决方案是为知识库建立一份”范围说明”：列出知识库包含哪些文档、涵盖哪些主题、可以回答什么类型的问题。在系统界面上明确展示这个范围说明，引导用户在范围内提问。
误区五：不复盘 Week 3 和 Week 1-2 的衔接
Week 3 不是孤立的。RAG 系统中的很多环节直接用到了 Week 1-2 的知识：
- API 调用（Week 2）→ 调用 Embedding API、LLM API
- 结构化输出（Week 2）→ RAG 答案的 JSON 格式化
- Prompt Contract（Week 1）→ RAG Prompt 的设计
- 错误处理（Week 2）→ API 调用失败的重试机制
理解这种衔接关系，有助于把七周的学习内容融会贯通，而不是一个个孤立的知识岛屿。
延伸思考
Week 3 到 Week 4 的过渡
Week 4 的主题是 Workflow、Agent 与 Tool Calling。RAG 和 Agent 的关系是什么？
RAG 解决的是”从静态文档中检索信息”的问题。但企业场景中有很多问题不是靠检索文档能解决的：
- “帮我查一下工单 #12345 的当前状态”——需要查询实时系统
- “把这个分析结果发邮件给张经理”——需要执行操作
- “对比一下产品和竞品的功能差异”——需要多步推理和综合
这些场景需要 Agent：能自主决策、调用工具、多步执行的智能体。Agent 可以调用 RAG 作为它的工具之一（当需要从知识库检索信息时），但 Agent 不局限于 RAG。
Week 4 会学习如何设计 Agent 系统，以及如何把 RAG 作为 Agent 的一个工具来使用。这种组合（Agent + RAG + Tool Calling）才是企业 AI 应用的完整形态。
从学习者到实践者
三周过去了。如果你认真完成了每天的学习任务，你应该已经：
- 理解了 AI 应用开发的全景（Week 1）
- 掌握了 API 调用和 Prompt 工程的基础能力（Week 2）
- 能够搭建一个端到端的 RAG 知识库系统（Week 3）
这三周的学习重点在”技术能力”。接下来的五周，重心会逐渐从技术转向应用：行业拆解、方案设计、商业化。因为技术能力只是基础，把技术能力变成可以交付的价值，才是最终目标。
企业知识库项目的真实挑战
在学校里做 Demo 和在企业中交付项目是两回事。企业项目中你会遇到：
- 数据质量问题。 客户的文档可能格式混乱、内容过时、大量重复、缺少版本管理。你花在数据清洗上的时间可能比写代码还多。
- 预期管理。 客户可能期望 RAG 系统像 ChatGPT 一样什么都能回答，但实际的知识库只能回答特定范围内的问题。需要提前管理好预期。
- 持续运营。 Demo 交付后，文档需要持续更新，系统需要持续监控，效果需要持续评估。这不是一次性项目，而是持续运营的服务。
- 安全合规。 文档权限、数据隔离、审计日志，这些在企业场景中都是强制要求。
了解这些挑战，不是为了吓退你，而是为了让你在进入真实项目时有心理准备。
自测问题
-
用自己的话完整描述 RAG 系统的离线管线和在线管线，包括每个环节的输入和输出。
-
如果一个用户问”产品 A 的保修期是多长”，但系统回答”未找到相关信息”，你怎么排查问题？列出诊断步骤。
-
选择 Embedding 模型时需要考虑哪些因素？如果知识库中大部分是中文文档，你会怎么选？
-
对比四种切分策略的优缺点。什么场景下选哪种策略？
-
Rerank 为什么比初始的向量检索更准确？它的成本体现在哪里？
-
设计一个 RAG 系统的评估方案：有哪些指标、需要多少测试问题、怎么判断效果好坏。
-
如果你的 RAG Demo 在 30 个测试问题中只有 50% 的准确率，你会怎么分析原因和优化？
-
企业知识库项目中，除了技术实现，还需要关注哪些非技术因素？
-
RAG 和 Agent 的关系是什么？为什么说”Agent + RAG + Tool Calling 是企业 AI 应用的完整形态”？
-
用三句话总结你 Week 3 最大的收获、最大的困惑、下一步最想深入的方向。
关键词
- RAG 全流程：从文档解析到答案生成的端到端管线，包括离线索引和在线查询两个阶段
- 文档处理管线：解析 → 清洗 → 切分，将原始文档转换为可检索的文本片段
- 向量检索管线：向量化 → 检索 → 重排序，根据用户问题找到最相关的文档片段
- 答案生成管线：上下文拼接 → Prompt 组装 → 模型生成 → 引用标注
- 检索优化工具箱：Query Rewrite、Multi-query、Hybrid Search、Rerank、Compression、Grounding、Citation Check
- RAG 排错：从症状出发，通过检索质量、生成质量、引用质量三个维度定位问题根因
- 评估体系：准确率、引用准确率、召回率、响应时间等多维度的量化评估
- 企业知识库产品化：从技术 Demo 到可交付产品的转化，包括用户体验、文档管理、运维体系、成本控制
- MVP 原则：最小但可行，先做到端到端跑通，再逐步优化
- 知识库范围说明：明确系统可以回答什么类型的问题，管理用户预期
Week 3 综合考试
以下是一套综合自测题，帮助你检验 Week 3 的学习效果。建议闭卷作答，写完后再回头查资料补充。
第一题（架构设计）。 你要为一家中型制造企业设计一个知识库系统，该企业有约 200 份内部文档（PDF 和 Word 格式），主要使用场景是新员工查询公司制度和产品规范。请设计系统架构，包括技术选型、处理流程、关键参数选择。
第二题（问题诊断）。 RAG 系统上线后，用户反馈以下三个问题： A. 问”年假怎么请”时，答案提到了年假天数但没说请假流程 B. 问”设备编号 EQ-2024-156 的维保记录”时，回答”未找到相关信息” C. 问”公司对加班的态度”时，回答了一段看似合理但文档中并未提及的观点
请分别分析每个问题的可能原因，并提出对应的优化方案。
第三题（方案对比）。 客户要求你比较两个方案： A. 基于 RAG 的知识库问答系统 B. 直接用大模型 + Fine-tuning 的问答系统
请从成本、效果、迭代速度、适用场景四个维度做对比，并给出推荐。
第四题（优化排序）。 你接手了一个 RAG 系统，评估发现以下问题（按严重程度排序）：
- 30% 的问题检索不到相关内容
- 检索到相关内容时，答案的准确率约 80%
- 引用标注的准确率约 60%
请制定优化计划，说明先做什么、后做什么、为什么这样排序。
第五题（口头表述）。 假设你要给一位不懂技术的企业老板解释 RAG 知识库是什么、为什么他的公司需要它、它能做什么不能做什么。写一段 3 分钟的口头表述。