Day 12 - RAG Basics

今日目标

能说清清洗、切分、embedding、检索、重排、生成、引用这条完整链路。

学习安排

核心概念

阅读重点

• 对应章节：第 3 章中 RAG、知识库、结构化索引相关内容
• 关注点：RAG 解决什么问题：模型内置知识有限且会过期，检索外部知识让回答可更新、可核验
• 关注点：为什么不能把所有文档塞进上下文：超出窗口、噪声稀释注意力、成本随 token 上升
• 关注点：Chunk 大小的权衡：太大命中粒度粗、浪费 token；太小上下文不完整、语义断裂
• 关注点：完整链路：retrieval → rerank → answer synthesis → citation，缺一环都不完整
• 补充材料：LangChain 官方 RAG 概念文档，看 loader / splitter / retriever 的模块划分
• 补充材料：向量数据库（Chroma、FAISS 等）官方文档，了解相似度检索的基本用法

理解检查

• RAG 解决了什么问题？请说出它针对模型的两个固有缺陷。
• 为什么不能直接把所有文档塞进上下文？至少给出两个理由。
• Chunk 太大或太小分别有什么问题？各自会体现在检索的哪个环节？
• Top-K 应该如何选择？判断依据是感觉还是可验证的信号？

实践任务

背景：你的团队有 3 篇技术文档（1 篇 Nginx 排查手册、1 篇压测报告模板、1 篇缺陷报告规范），你准备把它们做成一个问答知识库。

• 选好 3 篇文档，为每篇写清"回答哪类问题"
• 按 6 个环节走一遍 RAG 流程：文档清洗、Chunk 切分、Embedding、向量检索、Top-K 重排、生成回答并引用来源
• 每个环节写明：输入、输出、你的具体选择与理由
• 用下方模板输出《RAG 流程设计表》，这是 Day 14 实现 Demo 的施工图

输出模板

# RAG 流程设计：[知识库名称]

## 文档清单
| 文档 | 类型 | 用途 |
|---|---|---|
| [文档名] | [手册/模板/规范] | [回答哪类问题] |

## 1. 文档清洗
- 处理动作：[去掉页眉页脚 / 去除模板占位符 / 修正乱码]
- 保留内容：[正文 / 示例代码 / 结论]

## 2. Chunk 切分
- 策略：[按段落 / 按固定长度]
- 参数：chunk_size=[500]，overlap=[50]
- 理由：[说明选择依据]

## 3. Embedding
- 模型选择：[如 text-embedding-3-small]
- 粒度：[按 chunk 逐块向量化]

## 4. 向量检索
- 查询处理：[直接使用原问题 / 先改写为检索语句]
- 参数：top_k=[5]

## 5. 重排
- 方式：[不做 / 用重排模型 / 按关键词加权]
- 取前 N 条：[3]

## 6. 生成与引用
- 生成约束：[只基于片段回答，信息不足时说明]
- 引用格式：[来源文件名 + 片段编号]

示范输出

# RAG 流程设计：Nginx 排查知识库

## 文档清单
| 文档 | 类型 | 用途 |
|---|---|---|
| nginx-cpu-spike.md | 排查手册 | 回答 CPU 升高、WAF 开关、连接数问题 |
| load-test-report-template.md | 模板 | 回答压测报告字段含义 |
| defect-report-guideline.md | 规范 | 回答缺陷单怎么写、优先级怎么定 |

## 1. 文档清洗
- 处理动作：去掉导出的页眉页脚、删除模板占位符、统一代码块缩进
- 保留内容：正文、命令示例、结论与"待验证"标注

## 2. Chunk 切分
- 策略：按标题段落切，超长段落再按固定长度切
- 参数：chunk_size=500，overlap=50
- 理由：按段落切能保住上下文，overlap 防止跨段信息断裂

## 3. Embedding
- 模型选择：text-embedding-3-small
- 粒度：每个 chunk 一个向量，同时存原始文本与来源编号

## 4. 向量检索
- 查询处理：问题去掉"如何""为什么"再检索，如"如何排查 Nginx CPU 升高" → "Nginx CPU 升高 排查"
- 参数：top_k=5

## 5. 重排
- 方式：先按关键词得分加权，再人工抽查前 3 条
- 取前 3 条进入生成

## 6. 生成与引用
- 生成约束：只基于片段回答，片段没提的结论标注"知识库未覆盖"
- 引用格式：[nginx-cpu-spike.md #3] 这类来源编号

追问练习

• Top-K 应该如何选择？试想 top_k=1 和 top_k=50 各会带来什么问题？
• 检索结果相关但不准确时，应该在链路哪一步拦截？重排能解决吗？
• RAG 回答为什么需要引用来源？引用和"可核验性"是什么关系？
• 什么样的文档不适合放进 RAG？包含大量命令输出或宽表格的文档，清洗时要小心什么？

常见误区

• RAG 不等于向量数据库：向量库只是存储与检索环节，清洗、切分、重排、引用、评估与更新缺一不可。
• 文档切完直接丢进向量库不做清洗：页眉页脚、模板占位符会被当成正文检索到。
• chunk_size 随手定：太大命中粒度粗、浪费 token，太小语义断裂、召回差，需要按文档结构调整。
• 以为 embedding 结果天然准确：语义相近不等于事实正确，"CPU 升高"和"CPU 温度升高"是两件事。

进阶扩展

• 混合检索：BM25 关键词检索与向量检索并行，用 RRF 合并结果，兼顾字面与语义。
• 重排模型与精排：初检召回 50-100 条，用 rerank 模型精排到 5 条，命中质量提升明显。
• 知识库更新流水线：文档变更后重新清洗、切分、向量化，并做增量索引，避免回答过期内容。

今日作业

• 完成《RAG 流程设计表》，6 个环节每步写清输入、输出与选择理由。
• 用 3 篇真实文档替换模板里的示例，注明每篇文档回答哪类问题。
• 在流程表里标注一个你觉得最容易出错的环节，并写出应对方案。
• 明天用这份设计去实现最小 Demo（Day 14）。

自检清单

• 我能按顺序说出 RAG 完整链路：清洗、切分、embedding、检索、重排、生成、引用。
• 我能解释为什么不能把所有文档塞进上下文。
• 我能说清 chunk 大小和 top-k 的权衡依据。
• 我的流程设计表 6 个环节都有具体选择和理由。
• 我知道明天要复习哪一点。