|
| 1 | +Title: Deeplearning.ai 《Retrieval-Augmented Generation (RAG)》课程导读(一) |
| 2 | +Date: 2025-09-13 10:00 |
| 3 | +Tags: RAG, 信息检索, LLM, 检索增强生成 |
| 4 | +Slug: deeplearning-ai-rag-course-intro-1 |
| 5 | + |
| 6 | +[课程视频][1] |
| 7 | + |
| 8 | +> 根据视频字幕生成,是给不想看视频的人准备的速读文档 |
| 9 | +
|
| 10 | +--- |
| 11 | + |
| 12 | +## 课程背景 |
| 13 | + |
| 14 | +1. **核心思想与价值** |
| 15 | + RAG 将传统检索系统与大型语言模型(LLM)结合,提升回答的准确性和时效性。它能接入额外数据(文档、内部资料等),解决训练数据覆盖不到的事实性问题。常用于客服、内部知识查询、医疗、教育等,是当前最主流的 AI 应用之一。 |
| 16 | + |
| 17 | +2. **发展趋势** |
| 18 | + 随着模型输入窗口增大和新一代推理模型出现,RAG 在减少幻觉、处理复杂任务、利用长文档方面进步显著。新趋势包括: |
| 19 | + |
| 20 | + * 多模型协作(不同模型分工处理环节); |
| 21 | + * 自主检索策略(模型自行决定查询方式)。 |
| 22 | + |
| 23 | + 这使 RAG 更智能、更实用。 |
| 24 | + |
| 25 | +3. **课程目标** |
| 26 | + 本课程覆盖从入门到进阶的 RAG 技术:数据准备、提示设计、上下文管理、超参调优与系统评估。重点是如何构建、优化和持续改进 RAG 系统,所学方法也能迁移到更广泛的生成式 AI 应用中。 |
| 27 | + |
| 28 | +4. **学习收获** |
| 29 | + 学员将系统理解 RAG 原理,掌握构建与调优技能,并具备将其应用到复杂场景的能力。这是一项跨行业的高价值技能。 |
| 30 | + |
| 31 | +--- |
| 32 | + |
| 33 | +## 课程导览 |
| 34 | + |
| 35 | +### 总述 |
| 36 | + |
| 37 | +LLM 在问答、总结、改写、代码生成中表现突出,但知识仅限训练数据,缺乏**最新、私有、专业信息**,容易产生错误或“幻觉”。RAG 通过检索额外上下文,使输出更准确可靠,适应更多场景。 |
| 38 | + |
| 39 | +### LLM 的能力与局限 |
| 40 | + |
| 41 | +LLM 本质是基于概率的“智能补全”:预测最可能的词序列,而非事实。当遇到未知知识(如企业数据或新闻)时,容易生成听似合理但错误的答案。 |
| 42 | +局限包括: |
| 43 | + |
| 44 | +* **幻觉问题**:模型生成了听起来合理但事实错误的内容 |
| 45 | +* **上下文窗口限制**:提示过长会增加成本甚至溢出 |
| 46 | + |
| 47 | +### RAG 架构 |
| 48 | + |
| 49 | +RAG = **检索 + 生成**: |
| 50 | + |
| 51 | +1. 用户问题 → 检索器 → 找到相关文档; |
| 52 | +2. 问题 + 文档 → 增强提示 → 交给 LLM 生成回答。 |
| 53 | + |
| 54 | +三大组件: |
| 55 | + |
| 56 | +* **语言模型**:生成自然语言回答; |
| 57 | +* **知识库**:存放结构化/非结构化文档; |
| 58 | +* **检索器**:搜索并排序最相关的内容。 |
| 59 | + |
| 60 | +### 优势与挑战 |
| 61 | + |
| 62 | +优势: |
| 63 | + |
| 64 | +* 接入外部信息(私有/最新/专业); |
| 65 | +* 减少幻觉; |
| 66 | +* 更新知识只需替换文档,不用重新训练; |
| 67 | +* 回答可带来源,便于验证; |
| 68 | +* 分工明确:检索器找信息,LLM 负责生成。 |
| 69 | + |
| 70 | +挑战: |
| 71 | + |
| 72 | +* 检索结果排序难以完美; |
| 73 | +* 返回文档过多或过少都会影响效果; |
| 74 | +* 需要持续评估和调优。 |
| 75 | + 向量数据库是高效检索器的核心,但传统搜索引擎和关系型数据库的理念依然重要。 |
| 76 | + |
| 77 | +### 课程展望 |
| 78 | + |
| 79 | +后续将深入探讨: |
| 80 | + |
| 81 | +* LLM 的生成与训练机制; |
| 82 | +* 检索器的相似度计算与优化; |
| 83 | +* 知识库的设计与更新策略。 |
| 84 | + 学员将掌握原理与工程实践,能在不同场景中优化 RAG 系统。 |
| 85 | + |
| 86 | +--- |
| 87 | + |
| 88 | +## 信息检索与搜索基础 |
| 89 | + |
| 90 | +* **现实挑战**:用户提问自然语言;知识库数据多样且为“人读型”;系统需毫秒级返回高相关结果。 |
| 91 | +* **目标**:掌握检索核心技术、混合搜索、性能评估与调优;通过实操为生产级 RAG 打基础。 |
| 92 | + |
| 93 | +### 检索器架构:混合搜索 |
| 94 | + |
| 95 | +流程:查询 → 并行执行**关键词检索**与**语义检索** → 得到候选 → **元数据过滤** → 融合排序 → 返回 Top-k。 |
| 96 | + |
| 97 | +三大技术: |
| 98 | + |
| 99 | +1. **关键词检索**:快、稳,适合术语/SKU/法条; |
| 100 | +2. **语义检索**:覆盖同义表达; |
| 101 | +3. **元数据过滤**:基于权限、地区、时间等硬规则。 |
| 102 | + |
| 103 | +融合方法: |
| 104 | + |
| 105 | +* RRF(Reciprocal Rank Fusion) |
| 106 | + * **$d$**:一个候选结果(文档/段落/块) |
| 107 | + * **$i$**:第 $i$ 个独立的检索通道(或“基排器”) |
| 108 | + * **$\operatorname{rank}_i(d)$**:$d$ 在通道 $i$ 的**名次**(1 表示第 1 名,2 表示第 2 名……)。 |
| 109 | + * 若 $d$ 不在该通道的候选截断(如 top-50)里,可视为**没有贡献**(等价于 rank → ∞,分数趋近 0)。 |
| 110 | + * **$K$**:一个**平滑常数**,用来“压低”尾部名次的贡献、凸显头部。 |
| 111 | + * **越小**的 $K$:前几名与后面名次的差距被**放大**(更偏爱头部)。 |
| 112 | + * **越大**的 $K$:各名次之间差别被**缩小**(融合更温和)。 |
| 113 | + * 经验上常取 10~100;也有人把 $K$ 设成与各通道候选截断(如 50/100)同量级。 |
| 114 | + |
| 115 | +$$ |
| 116 | +\text{RRF}(d)=\sum_i \frac{1}{K+\operatorname{rank}_i(d)} |
| 117 | +$$ |
| 118 | + |
| 119 | +* 线性加权和分 |
| 120 | + * **$\text{score}(d)$**:融合后的**最终分数**(用于排序) |
| 121 | + * **$\text{score}_{\text{sem}}(d)$**:来自**语义检索**的分数(如余弦相似度、内积或其变体) |
| 122 | + * **$\text{score}_{\text{kw}}(d)$**:来自**关键词检索**的分数(如 BM25) |
| 123 | + * **$\beta\in[0,1]$**:权重系数,表示**语义分数所占比例**;$1-\beta$ 是关键词分数比例。 |
| 124 | + * $\beta$ 大 → 更看重语义;$\beta$ 小 → 更看重关键词。 |
| 125 | + |
| 126 | +$$ |
| 127 | +\text{score}(d)=\beta\,\text{score}_{\text{sem}}(d)+(1-\beta)\,\text{score}_{\text{kw}}(d) |
| 128 | +$$ |
| 129 | + |
| 130 | + |
| 131 | +业务取舍:关键词优先 → 提高关键词权重;语义优先 → 提高语义权重。 |
| 132 | + |
| 133 | +### 三大技术要点 |
| 134 | + |
| 135 | +#### 1) 元数据过滤 |
| 136 | + |
| 137 | +* 基于标题/作者/日期/部门/权限/地区等字段裁剪结果; |
| 138 | + * **优点**:简单、高速、可审计;能用硬规则保证“该/不该返回”; |
| 139 | + * **局限**:不考虑内容相关性,不能排序,需与其他检索结合。 |
| 140 | + |
| 141 | +#### 2) 关键词搜索(TF-IDF / BM25) |
| 142 | + |
| 143 | +* **核心思想**:根据词频与重要性打分。 |
| 144 | +* **优缺点**:快、稳、保证命中精确词,但无法处理同义改写,需语义补充。 |
| 145 | + |
| 146 | +**TF-IDF** |
| 147 | + |
| 148 | +$$ |
| 149 | +\text{TF-IDF}(t,d)=\text{TF}(t,d)\times \text{IDF}(t) |
| 150 | +$$ |
| 151 | + |
| 152 | +其中,$t$ 表示一个词(term),$d$ 表示某个文档。词频(TF)刻画的是词在文档中的相对出现频率: |
| 153 | + |
| 154 | +$$ |
| 155 | +\text{TF}(t,d)=\frac{f_{t,d}}{\sum_{t'} f_{t',d}} |
| 156 | +$$ |
| 157 | + |
| 158 | +这里 $f_{t,d}$ 是词 $t$ 在文档 $d$ 中出现的次数,分母是文档中所有词的出现总数。 |
| 159 | + |
| 160 | +逆文档频率(IDF)则衡量一个词的区分能力: |
| 161 | + |
| 162 | +$$ |
| 163 | +\text{IDF}(t)=\log\frac{N}{1+n_t} |
| 164 | +$$ |
| 165 | + |
| 166 | +其中 $N$ 是语料库的总文档数,$n_t$ 是包含词 $t$ 的文档数。一个词在语料中越常见,它的 IDF 值就越小,因而在计算 TF-IDF 时权重越低。 |
| 167 | + |
| 168 | +**BM25** |
| 169 | + |
| 170 | +$$ |
| 171 | +\text{BM25}(q,d)=\sum_{t\in q}\text{IDF}(t)\cdot |
| 172 | +\frac{f_{t,d}(k_1+1)}{f_{t,d}+k_1\left(1-b+b\frac{|d|}{\text{avgdl}}\right)} |
| 173 | +$$ |
| 174 | + |
| 175 | +这里,$q$ 表示查询,$d$ 表示候选文档,求和遍历查询中的每个词 $t$。 |
| 176 | + |
| 177 | +其中的 $\text{IDF}(t)$ 与 TF-IDF 中类似,用来衡量词的区分能力: |
| 178 | + |
| 179 | +$$ |
| 180 | +\text{IDF}(t)=\log\frac{N-n_t+0.5}{n_t+0.5}+1 |
| 181 | +$$ |
| 182 | + |
| 183 | +公式里的 $f_{t,d}$ 是词 $t$ 在文档 $d$ 中出现的次数;$|d|$ 表示文档的长度(通常用词数计),$\text{avgdl}$ 是语料库中的平均文档长度。 |
| 184 | + |
| 185 | +分母部分的参数 $k_1$ 和 $b$ 起调节作用: |
| 186 | + |
| 187 | +* $k_1$(常取 1.2–2.0)控制**词频饱和度**,即当词频越来越大时,得分增加会逐渐放缓; |
| 188 | +* $b$(取值在 0–1,常设 0.75)控制**文档长度归一化**,防止长文档因为词数多而天然占优。 |
| 189 | + |
| 190 | +换句话说,BM25 在保留 IDF 权重的同时,对词频做了非线性饱和处理,并根据文档长度进行校正,比简单的 TF-IDF 更适合实际检索。 |
| 191 | + |
| 192 | +#### 3) 语义搜索(向量检索) |
| 193 | + |
| 194 | +* **机制**:嵌入模型 → 文本 → 高维向量;语义相似 → 向量接近。 |
| 195 | +* **相似度度量**:余弦相似度、点积、欧氏距离。 |
| 196 | +* **流程**:建向量索引 → 查询编码 → 相似度搜索 → 返回近邻。 |
| 197 | +* **训练直觉**:对比学习让相似语义靠近,不同语义远离。注意不同嵌入模型不可直接对比。 |
| 198 | + |
| 199 | +### 评估与调优 |
| 200 | + |
| 201 | +在评估检索器或 RAG 系统时,需要三类数据:一组查询、系统返回的排序列表,以及人工标注的“相关文档”基准集。基于这些数据,可以计算以下指标: |
| 202 | + |
| 203 | +#### 1. Precision / Recall(@k) |
| 204 | +精确率与召回率是最常见的指标。 |
| 205 | + |
| 206 | +$$ |
| 207 | +\text{Precision@}k=\frac{\#\text{ relevant in top-}k}{k} |
| 208 | +$$ |
| 209 | + |
| 210 | +$$ |
| 211 | +\text{Recall@}k=\frac{\#\text{ relevant in top-}k}{|\text{Relevant}|} |
| 212 | +$$ |
| 213 | + |
| 214 | +* Precision\@k:前 k 个结果中有多少比例是相关文档; |
| 215 | +* Recall\@k:前 k 个结果覆盖了多少比例的相关文档。 |
| 216 | + |
| 217 | +通常,召回率上升往往会带来精度下降,因此需要根据场景设定合适的 k 值。 |
| 218 | + |
| 219 | +#### 2. AP / MAP(排序质量) |
| 220 | +平均精度(AP)用于衡量排序效果,强调“相关文档排得越靠前越好”。 |
| 221 | + |
| 222 | +$$ |
| 223 | +\text{AP@}k=\frac{1}{\min(R,k)}\sum_{i=1}^{k}\big[\text{rel}(i)\cdot \text{Precision@}i\big] |
| 224 | +$$ |
| 225 | + |
| 226 | +其中 $R$ 是相关文档总数,$\text{rel}(i)$ 表示第 i 个结果是否相关。 |
| 227 | + |
| 228 | +将多个查询的 AP 取平均,就得到 MAP(Mean Average Precision): |
| 229 | + |
| 230 | +$$ |
| 231 | +\text{MAP@}k=\text{mean of AP@}k |
| 232 | +$$ |
| 233 | + |
| 234 | +#### 3. MRR(Mean Reciprocal Rank) |
| 235 | +MRR 衡量系统把**第一个相关文档**排在什么位置: |
| 236 | + |
| 237 | +$$ |
| 238 | +\text{MRR}=\text{mean}\left(\frac{1}{\text{rank of first relevant}}\right) |
| 239 | +$$ |
| 240 | + |
| 241 | +相关文档越早出现,MRR 越高。 |
| 242 | + |
| 243 | +#### 调优抓手 |
| 244 | + |
| 245 | +* **BM25**:调整 $k_1$(词频饱和)和 $b$(长度归一化); |
| 246 | +* **语义索引**:调整近邻搜索的参数; |
| 247 | +* **元数据**:权限、地区、时间窗等过滤策略; |
| 248 | +* **融合层**:RRF 的 $K$,线性加权的 $\beta$。 |
| 249 | + |
| 250 | +调优方法通常是基于 **Precision\@k、Recall\@k、MAP、MRR** 的 A/B 测试,验证系统是否“找得到、排得对”。虽然这些指标依赖人工标注,但可以通过抽样和滚动监控,形成持续的评估闭环。 |
| 251 | + |
| 252 | +### 实操与落地 |
| 253 | + |
| 254 | +* **设计顺序**:先设定硬过滤 → 再调关键词/语义权重与候选规模 → 最后融合排序。 |
| 255 | +* **业务权衡**: |
| 256 | + |
| 257 | + * 法条/零件号/药品名 → 关键词优先; |
| 258 | + * 客服问答/自然语言 → 语义优先。 |
| 259 | +* **工程目标**:平衡延迟、吞吐与质量;用少量超参(\$k\_1,b,K,\beta\$)做精细调优。 |
| 260 | +### 结论 |
| 261 | + |
| 262 | +掌握“关键词 × 语义 × 元数据”的混合检索,并用可重复的评估体系迭代优化,是构建**可用、可控、可维护** RAG 系统的关键。接下来可以将这些方法应用到生产级检索器和增强提示链路中。 |
| 263 | + |
| 264 | +[1]: https://www.bilibili.com/video/BV1QRbnzTEyK?spm_id_from=333.788.videopod.episodes&vd_source=dbe2034ffbdf969aa84f0fa33428b1ae |
0 commit comments