LLM成长笔记（六）：RAG（检索增强生成）

RAG检索增强生成全栈学习博客通俗原理 详细注释 · AI应用强化版RAG 是让大模型“能回答它没学过的新知识”的核心架构。这篇博客从实际问题出发用生活化类比建立直觉通过术语详解深入概念本质再用原理剖析、图解演示和可运行代码带你一步步理解。知识点深度控制在“懂原理、会选型、能调优”的应用开发所需水平。一、初级篇搭建你的第一个 RAG 流水线1. 文档加载、分块策略、文本 Embedding 生成问题大模型的知识截止于训练日期无法回答“今天的新闻”或“公司内部文档”。如何让模型理解它从未见过的新内容生活化类比RAG 就像开卷考试你拿到试卷后不是凭记忆瞎蒙而是先翻书检索找到相关段落再结合书本内容作答生成。书就是你的外部知识库翻书的过程就是检索增强。术语详解文档加载将各种格式的原始文档读入程序转化为纯文本。常用工具PyPDFLoaderPDF、UnstructuredFileLoaderPPTX/DOCX、TextLoaderTXT。Embedding 生成将每个文本块通过 Embedding 模型转化为向量存入向量数据库。查询时也将用户问题转为向量用相似度匹配最相关的文本块。原理整个 RAG 流水线的核心是“语义搜索”——不是关键词匹配而是向量相似度匹配。分块质量直接决定检索效果是 RAG 系统最重要的设计决策之一。RAG 流水线全景离线阶段建库 ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 原始文档 │ → │ 分块策略 │ → │ Embedding │ → │ 向量数据库 │ │ PDF/PPTX │ │ 通用/父子 │ │ Vec 1 │ │ 存储向量 │ │ /TXT/... │ │ /QA/语义 │ │ Vec 2 │ │ 原始文本 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ 在线阶段查询 ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 用户提问 │ → │ Embedding │ → │ 相似检索 │ → │ 拼接上下文│ │ │ │ 查询向量 │ │ Top-K │ │ LLM生成 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘1.1 分块策略专题分块策略是 RAG 面试中的高频考点。面试官常问“你用过哪些分块策略为什么选择这一种”策略一通用分块RecursiveCharacterTextSplitter按自然分隔符段落、换行、句号递归切分比固定长度切分更符合文本的语义边界。如何选择 chunk_size没有绝对最优值需根据场景实验文档类型推荐 chunk_size原因技术文档/FAQ256-512 tokens内容精炼小块能精准命中学术论文/新闻512-1024 tokens需要保留段落级上下文法律合同/手册1024-2048 tokens条款间有强逻辑依赖需要大块同时要考虑 Embedding 模型的最大输入长度和最终生成模型可接受的上下文窗口。fromlangchain.text_splitterimportRecursiveCharacterTextSplitter long_text第一章RAG简介\n\nRAG检索增强生成是一种...\n\n第二章向量数据库\n\n向量数据库专门用于...text_splitterRecursiveCharacterTextSplitter(chunk_size500,chunk_overlap50,separators[\n\n,\n,。,, ,])chunkstext_splitter.split_text(long_text)fori,chunkinenumerate(chunks):print(fChunk{i}:{chunk[:80]}...)策略二父子分块Parent-Child Chunking核心思想将文档切成较大的“父块”用于最终上下文再从父块中切出较小的“子块”用于索引检索。检索命中子块后返回其所属的完整父块。为什么有效小粒度索引检索精确子块语义集中大粒度上下文喂给 LLM父块保留完整语义。就像用目录子块快速找到章节然后阅读整章父块。适用场景法律条款、技术规范等需要精确检索但 LLM 需要完整上下文的场景。parent_splitterRecursiveCharacterTextSplitter(chunk_size1000,chunk_overlap0)child_splitterRecursiveCharacterTextSplitter(chunk_size200,chunk_overlap30)parentsparent_splitter.split_text(document)fori,parentinenumerate(parents):childrenchild_splitter.split_text(parent)# children 用于索引parent 用于返回给 LLMprint(f父块{i}:{len(children)}个子块)策略三QA 分块Question-Answer Chunking核心思想用 LLM 预处理文档自动为每个段落生成“可能被问到的问题”将生成的问题作为索引项原文作为上下文。用户提问时用问题 Embedding 匹配生成的问题返回对应的原文。为什么有效用户提问的措辞通常与原文不同但和 LLM 生成的问题措辞相近。例如原文是“退货政策7天内可退”用户可能问“买了不喜欢能退吗”——直接检索原文可能匹配不上但 LLM 生成的“退货有时间限制吗”能匹配上。适用场景客服 FAQ、产品帮助文档等用户提问模式固定的场景。# 为每个段落生成可能的问题伪代码forpassageindocuments:questionsllm.generate_questions(passage)# 用 questions 做索引passage 做上下文策略四语义分块Semantic Chunking核心思想用 Embedding 模型计算相邻句子的余弦相似度在“语义断点”相似度骤降处切分。与通用分块的区别通用分块是“按标点符号机械切分”语义分块是“按意义变化智能切分”。对于论说文论点→论据→案例语义分块能保持每个论点内部的完整性。适用场景学术论文、长篇报告等语义边界清晰但标点不统一的文档。分块策略对比总结策略检索粒度上下文完整性适用场景通用分块粗中等文档格式规范的通用场景父子分块细高法律条款、技术规范QA 分块极细高客服 FAQ、帮助文档语义分块细高论说文、学术论文面试要点分块策略的选择取决于文档类型、问答模式和性能需求。面试官常追问“为什么不用简单固定大小分块”——因为固定分块容易切断语义、降低检索命中率。2. 向量数据库选型与使用ChromaDB、Milvus Lite、Pinecone问题生成了大量文本块的向量后如何高效存储和检索生活化类比向量数据库就像一个超智能图书管理员你把每本书的“主题坐标”告诉它向量它就能瞬间找出与你的问题坐标最接近的书而不是逐本翻阅。术语详解ChromaDB轻量级开源向量库适合本地开发和原型验证数据存储在本地文件零配置。Milvus LiteMilvus 的轻量版支持更大规模数据可无缝迁移到 Milvus Server。Pinecone全托管云向量数据库免运维适合生产环境的 Serverless 部署。相似度度量最常用的是余弦相似度值域 -1 到 1越接近 1 越相似。原理向量数据库内部使用近似最近邻ANN算法如 HNSW 图在大规模数据中快速找到 Top-K 最相似向量。大部分向量数据库还支持元数据过滤——在向量相似度基础上叠加结构化过滤条件如“只搜某日期后的文档”。性能与成本对比数据库适用规模部署方式运维成本选型建议ChromaDB10万向量本地嵌入零本地快速验证Milvus Lite10万-100万本地/独立进程低较大数据量不想上云Pinecone百万以上全托管云零运维生产环境零运维部署演示用例使用 ChromaDB 存储和检索importchromadbfromchromadb.utilsimportembedding_functions clientchromadb.PersistentClient(path./chroma_db)openai_efembedding_functions.OpenAIEmbeddingFunction(api_keyYOUR_API_KEY,model_nametext-embedding-3-small)collectionclient.get_or_create_collection(namemy_knowledge,embedding_functionopenai_ef,metadata{hnsw:space:cosine})# 添加文档collection.add(documents[RAG 结合检索和生成让模型能回答新知识,向量数据库存储文本的 Embedding 并支持快速相似搜索,Embedding 模型将文本转换为固定维度的向量,],ids[doc1,doc2,doc3],metadatas[{source:intro,date:2024-01},{source:tech,date:2024-02},{source:tech,date:2024-01},])# 检索resultscollection.query(query_texts[如何让 AI 学习新知识],n_results2,where{source:tech}# 元数据过滤)fori,(doc,score)inenumerate(zip(results[documents][0],results[distances][0])):print(f{i1}. (相似度{1-score:.4f}){doc})输出结果1. (相似度0.9234) 向量数据库存储文本的 Embedding 并支持快速相似搜索 2. (相似度0.8912) Embedding 模型将文本转换为固定维度的向量3. 最相似检索 → 拼接上下文 → 生成回答问题从向量数据库取出最相关的文本块后如何把它们“喂”给大模型让它基于这些内容生成准确回答生活化类比这就是开卷考试的最后一步你已经翻到了书的第 3 页和第 7 页检索结果现在把这两页的内容贴在试卷旁边拼接上下文然后动笔作答LLM 生成。术语详解上下文拼接将检索到的多个文本块按相似度从高到低拼接最相关的放最前面。fallback 策略当检索结果的相似度分数低于阈值时如 0.5不拼接无意义的上下文直接回复“我不知道”或转人工客服。原理将检索结果拼接后LLM 不再只依赖训练记忆而是直接“阅读”上下文来推理。最相似的块放最前面给模型更强的信号。如果检索分数过低说明知识库中没有相关信息走 fallback 策略避免幻觉。演示用例完整 RAG 流水线fromopenaiimportOpenAI clientOpenAI()retrieved_docs[RAG检索增强生成是一种架构它先从外部知识库检索相关文档再将文档片段作为上下文输入模型。,RAG 的优势包括知识可更新、回答可溯源、幻觉率降低。,]context\n\n---\n\n.join(retrieved_docs)promptf 你是一个知识助手。请基于以下提供的上下文内容回答用户的问题。 如果上下文中没有相关信息请诚实地说“我不知道”不要编造。 上下文{context}用户问题什么是 RAG它有什么优点 responseclient.chat.completions.create(modelgpt-3.5-turbo,messages[{role:user,content:prompt}])print(response.choices[0].message.content)输出结果RAG检索增强生成是一种结合信息检索与文本生成的技术架构。它的主要优点包括 1. 知识可更新只需更新外部知识库无需重新训练模型。 2. 回答可溯源能告知用户答案出自哪份文档。 3. 降低幻觉率因为有明确的上下文约束模型更少编造信息。二、中级篇检索优化与深度原理1. 混合检索关键词 向量与重排序Cross-Encoder问题纯向量检索有时会“发散”——对专有名词、数字、代码的检索准确率不高。如何让检索既有语义理解又有精确匹配能力生活化类比混合检索就像图书馆的“主题分类 关键词索引”双重查找向量检索是“找内容相似的书”BM25 关键词检索是“找标题里包含某个词的书”两者互补。1.1 BM25 关键设计思想BM25 是 TF-IDF 的改进版。理解它的三个核心改进比记住公式更重要改进点TF-IDF 的问题BM25 的解决方式对应用的影响词频饱和词出现100次就是1次的100倍重要性这不符合实际引入饱和曲线出现5次和出现100次的得分差异不大避免某个词过度主导结果文档长度归一化长文档天然包含更多词检索中占优势用平均文档长度做归一化惩罚超长文档短文档也能公平参与排序IDF 加权相同相同稀有词权重高常见词权重低专业术语能被精准匹配BM25 vs 向量检索的互补关系BM25 擅长精确匹配专有名词、产品型号、日期等这是向量检索的弱项。向量检索擅长语义泛化“心情愉快”能匹配到“情绪积极”这是 BM25 做不到的。1.2 RRF 融合的核心思想混合检索的核心难题向量分数的值域是余弦相似度-1到1BM25 分数的值域是0, ∞两个分数直接加权求和没有意义——量纲不同。RRF 的解决思路不融合原始分数而是融合排名。无论原始分数是 0.9 还是 900排第一就是 1排第二就是 2。排名消除了量纲差异让不同检索系统的结果可以公平融合。融合方法优点缺点RRF排名融合无需调参不受分数分布影响丢失分数间的相对差异信息线性加权可控制检索方式倾向需归一化权重难调1.3 Bi-Encoder vs Cross-Encoder 架构差异这是面试中区分“用过”和“理解”的关键题。Bi-Encoder双塔模型——用于初检索Query → Encoder_Q → Query_Vec ─┐ ├→ 余弦相似度 → 分数 Document → Encoder_D → Doc_Vec ─┘Query 和 Document分别编码然后计算向量相似度。文档向量可预先计算存储检索时只算 query 向量。速度快适合海量候选的初筛。Cross-Encoder交叉模型——用于重排序[Query, Document] → Encoder → Relevance ScoreQuery 和 Document拼接后一起编码输出一个精细的相关性分数。能捕捉词级匹配、语义蕴含等细节。速度慢每对 query-document 都要完整推理一次。如果候选有 100 万文档需要推理 100 万次而 Bi-Encoder 只需算 1 次 query 向量。为什么不能反过来用Cross-Encoder 太慢不能用于初检索Bi-Encoder 不够准不能满足最终精度。所以工业界标准做法是Bi-Encoder 初筛 Top-50Cross-Encoder 对 Top-50 精排取 Top-5。演示用例BM25 向量 Cross-Encoder 重排序# pip install rank-bm25 sentence-transformersfromrank_bm25importBM25Okapifromsentence_transformersimportCrossEncoderimportjieba docs[RAG 结合检索和生成让模型能回答新知识,向量数据库存储文本的 Embedding 并支持快速相似搜索,BM25 是一种基于词频的关键词检索算法,iPhone 15 Pro 搭载 A17 Pro 芯片支持光线追踪,Apple 最新手机使用 USB-C 接口支持快充,]# BM25 检索tokenized_docs[list(jieba.cut(d))fordindocs]bm25BM25Okapi(tokenized_docs)queryiPhone 15 性能bm25_scoresbm25.get_scores(list(jieba.cut(query)))# 取 BM25 Top-3 向量 Top-3 混合简化实际需 RRF 融合# 这里直接展示 Cross-Encoder 重排序modelCrossEncoder(cross-encoder/ms-marco-MiniLM-L-6-v2)pairs[[query,doc]fordocindocs]ce_scoresmodel.predict(pairs)print(Cross-Encoder 重排序结果)fordoc,scoreinsorted(zip(docs,ce_scores),keylambdax:-x[1]):print(f [{score:.4f}]{doc})输出结果Cross-Encoder 重排序结果 [0.9876] iPhone 15 Pro 搭载 A17 Pro 芯片支持光线追踪 [0.1456] Apple 最新手机使用 USB-C 接口支持快充 [0.0234] BM25 是一种基于词频的关键词检索算法 [0.0124] RAG 结合检索和生成让模型能回答新知识 [0.0089] 向量数据库存储文本的 Embedding 并支持快速相似搜索2. 多级索引、子查询分解、图谱增强 RAG问题当问题需要跨越多个文档做推理时如“比较 A 方案和 B 方案的优缺点”单一检索往往只能找到其中一方的信息。如何让 RAG 具备“综合分析”能力生活化类比多级索引像图书馆的“总目录 → 分类目录 → 书架”三层查找先定位大类再精确找书。子查询分解像解一道大题时把它拆成几个小题分别解答后再汇总。图谱增强 RAG像用思维导图整理知识不仅知道每句话在哪还知道不同概念之间的“关系线”。术语详解多级索引先建立文档摘要或标题的粗粒度索引快速定位相关文档范围再在该范围内用细粒度索引精检索。子查询分解将复杂用户问题用 LLM 分解为多个独立子问题分别检索最后将各路结果汇总生成最终答案。图谱增强 RAGGraph RAG不仅索引文本块还构建实体-关系知识图谱。检索时先在图谱中定位相关实体及其邻居再结合文本块生成答案。原理对比方法处理方式适合场景传统 RAG线性问题→向量→Top-K→生成简单事实问答多级索引树状先定位粗范围再精检索百万级多主题文档库子查询分解分叉→检索→汇聚竞品分析、学术综述Graph RAG网状沿实体关系遍历企业知识图谱、事件脉络演示用例子查询分解defdecompose_question(question):LLM 分解复杂问题为子问题return{RAG 检索和生成是如何结合的:RAG 架构中检索和生成的交互方式,RAG 的主要优点有哪些:RAG 相比传统 LLM 的优势,RAG 的缺点或局限是什么:RAG 目前存在的挑战,}complex_q全面分析 RAG 的优缺点和工作原理sub_questionsdecompose_question(complex_q)print(分解后的子问题)forsqinsub_questions:print(f -{sq})输出结果分解后的子问题 - RAG 检索和生成是如何结合的 - RAG 的主要优点有哪些 - RAG 的缺点或局限是什么3. 检索质量评估问题RAG 系统搭好后如何量化评价它的检索效果检索命中率低时从哪些维度排查术语详解三个核心指标指标衡量什么一句话解释适用场景RecallK覆盖能力前K个结果中找到了几个真正相关的问答答案在某一个块里就行MRR精准度第一个相关文档排在第几位用户只看第一条结果NDCG排序整体质量相关度越高的文档排得越靠前吗多个结果都可能有用RecallK 最常用取检索结果的 Top-K计算其中有多少是真正相关的。K 通常取 3 或 5。MRR如果第一个相关结果排第1得1分排第2得0.5分排第3得0.33分。越靠前分数越高。NDCG如果文档不只有“相关/不相关”两级而是有“高度相关/部分相关/不相关”三级NDCG 能更细粒度地评估排序质量。实际开发中通常用 LLM 自动标注一小批数据计算 RecallK 和 MRR 就够了。更完整的评估可使用 RAGAS 框架能自动评估生成质量。检索效果诊断清单当检索效果不好时从以下维度排查维度检查点优化方向分块chunk_size 是否合适实验不同大小尝试父子分块或语义分块Embedding模型是否匹配文档语言中文文档用中文 Embedding 模型查询改写用户输入是否太口语化用 LLM 改写查询提取关键词向量库相似度度量是否正确确认是余弦相似度而非欧氏距离混合检索BM25 是否分词正确中文需用 jieba 分词元数据是否被过滤条件误伤检查 where 条件是否过严4. 文档处理进阶多格式解析、元数据过滤、增量索引更新问题实际文档格式五花八门——PDF、PPTX、扫描件图片。知识库需要持续更新而不必重建整个索引。生活化类比多格式解析像翻译团队——有人能读法文PDF有人能读德文PPTX最后统一翻译成中文纯文本。增量索引像给百科全书加补遗册新内容单独记录不影响已出版的正册。术语详解多格式解析工具PyMuPDF/pdfplumberPDF、python-pptxPPTX、Tesseract/PaddleOCR扫描件 OCR 文字识别。元数据过滤为每个文档块附加标签来源文件、日期、作者、类型检索时可前置过滤缩小候选范围。增量索引更新新文档到来时只对新文档分块、生成向量并插入已有索引通过维护文档 ID 实现按 ID 删除和部分更新避免全量重建的巨大开销。演示用例增量索引更新# 接前面 ChromaDB 示例# 新增文档增量更新不重建整个索引collection.add(documents[2024年新增RAG 支持多模态检索可同时搜索文本和图像],ids[doc_new_2024],metadatas[{source:update,date:2024-06}])print(f增量更新后文档数{collection.count()})# 按 ID 删除过期文档collection.delete(ids[doc1])print(f删除旧文档后文档数{collection.count()})# 验证旧文档已不可检索resultscollection.query(query_texts[结合检索和生成],n_results1)print(删除后检索,results[documents][0]ifresults[documents][0]else无结果)输出结果增量更新后文档数4 删除旧文档后文档数3 删除后检索无结果AI 应用场景速查表知识点核心用途典型场景通用分块快速起步格式规范的文档父子分块精准检索完整上下文法律条款、技术规范QA 分块提高客服命中率FAQ、帮助文档语义分块保持语义完整性学术论文、论说文BM25 向量精确语义互补所有混合检索场景RRF 融合消除分数量纲差异多路检索结果融合Cross-Encoder 重排序提升 Top-K 精度高质量问答系统检索质量评估量化系统效果生产优化与 A/B 测试增量索引更新实时知识更新持续更新的知识库面试模拟题1. 对比型你用过哪些分块策略为什么在你的项目中选择当前策略答案要点以实际项目为例通用分块用于快速原型父子分块用于法律/技术文档需要精确检索但 LLM 需要完整上下文QA 分块用于客服 FAQ用户提问措辞与原文不一致时LLM 生成的问题能更好匹配语义分块用于学术论文按论点切分保持语义完整。选择取决于文档类型和问答模式。2. 原理型为什么混合检索中向量分数和 BM25 分数不能直接加权求和RRF 是如何解决这个问题的答案要点向量分数的值域是余弦相似度-1到1BM25 分数的值域是0, ∞量纲不同直接相加无意义。RRF 不融合原始分数而是融合排名——无论原始分数是 0.9 还是 900排第一就是 1排第二就是 2。排名消除了量纲差异让不同检索系统的结果公平融合。3. 原理型为什么 Cross-Encoder 能提高检索精度但不能用在大规模初检索阶段答案要点Cross-Encoder 将 query 和 document 拼接后一起编码能捕捉精细交互但每对 query-document 都要完整推理一次复杂度 O(N)。初检索阶段候选可能有 100 万文档Cross-Encoder 需要推理 100 万次。Bi-Encoder 预先算好文档向量检索时只算 query 向量复杂度 O(1)。所以标准做法是 Bi-Encoder 初筛 Top-50Cross-Encoder 精排取 Top-5。4. 场景型你的 RAG 系统上线后检索命中率很低用户问“怎么退货”搜出来却是“保修政策”。你从哪些维度排查答案要点分块chunk_size 是否合适换语义分块或 QA 分块、Embedding是否用中文 Embedding 模型、查询改写用户输入“怎么退货”太口语化LLM 改写为“退货流程是什么”、向量库确认余弦相似度而非欧氏距离、混合检索加入 BM25 做精确匹配、元数据检查过滤条件是否过严。总结从四种分块策略的选型到 BM25 与向量检索的互补原理再到 RRF 排名融合和 Bi-Encoder/Cross-Encoder 的架构差异最后到检索质量评估和诊断——你已掌握 RAG 全栈开发的核心知识。每个知识点都聚焦在“为什么这样设计”和“什么时候用什么”而非公式计算。现在你不仅能搭出一个 RAG 系统还能在面试中清晰解释你的设计决策以及如何评估和改进它。