LangChain这个系列写到第8篇前面聊过模型调用、提示词工程、记忆机制基本都在讨论怎么让模型本身“会说话”。这一篇终于来到一个分水岭——检索增强生成也就是大家常说的RAG。一句话说清楚先把模型之外的资料拿出来做一次检索把命中的内容拼到提示词里再让模型结合这些资料作答。本质上就是给模型外挂了一个可随时查证的知识空间“外脑”这个说法很形象它把一大部分知识需求从模型参数里挪到外部存储里。这套思路的适用范围非常广。企业内部的制度问答、产品的帮助文档、法律条款检索、教研资料答疑凡是“信息封闭、答案必须基于给定材料”的场景都得靠RAG兜底。适合谁看呢如果你已经会调用大模型API能写点Python想进一步解决“模型乱编、资料零散、答案过时”的痛点这篇文章正好卡在你的进阶路径上。我会把RAG的原理拆开再带一套用LangChain落地的完整代码最后聊几个只有踩过坑才会注意到的细节。1. 先搞清楚RAG是来救什么场的模型记不准的事交给外置知识1.1 三个明显的信任危机幻觉、时效性与私域知识先问一个问题为什么不能直接把内部资料全部喂给模型让模型“记住”答案很简单模型是拿概率猜文字的它没有“查档案”的意识。你把一份2024年才发布的内部报销制度扔给一个训练截止在2022年的模型它只会按照自己的经验编一个报销流程错误率极高。这是RAG要解决的第一个问题幻觉。可以把幻觉理解成“记忆模糊时强行答题”。我们人也会有这种情况考试时记不清某个公式但题目又必须作答于是只能凑一个公式出来。大模型没有“知道自己不知道”的自觉它的训练目标就是生成通顺的、概率最高的下文。所以一旦遇到超出知识范围的内容它宁可编也不愿意说“我不知道”。RAG的思路不解决“模型会不会编”而是让模型在回答前先看到一段确凿的资料把它“编”的空间压缩到最小。第二个问题是时效性。大模型内部的知识是训练时定下来的之后世界发生了什么、公司政策改了什么它一概不知。你可以重新训练模型但成本和周期非常夸张。RAG则把“知识更新”变成了一次简单的写入操作新文档入库旧文档替换回答立刻基于最新资料。这让系统不再是“训练一次、用一辈子”而是可以随业务持续更新的活系统。第三个问题是私域知识。每个公司都有自己内部的流程、专有的产品说明、内部的FAQ这些内容不会出现在公开互联网上模型在预训练阶段根本没见过。RAG对私域知识几乎是唯一的工程化答案因为微调虽然也能学进去但要把每一条更新都做成训练样本、反复调参运维压力很大。这三个痛点叠加让RAG成了目前大模型应用落地里最稳的路线。1.2 一套RAG要拆成哪几个器官很多人把RAG理解成一个“向量数据库加个HTTP接口”这其实是把问题想简单了。一套完整的RAG系统在离线阶段和在线阶段各有分工。离线阶段负责构建知识库文档进来以后先按格式解析把PDF、Word、Markdown里的文字提取出来然后清洗掉页眉页脚、水印、无效换行接着做分块把长文本切成适合检索的小段每一段再用嵌入模型转成向量最后把向量连同原文、来源、时间等信息一起存进向量数据库。这个阶段的目标是建立索引相当于给外脑建好“图书目录”。在线阶段负责回答用户问题用户输入一个问题先判断是否需要检索如果需要就把问题也转成向量去向量库里做相似度搜索找出最相关的几个文本块再把原文块、用户问题、历史对话拼成一个完整的提示词最后交给大模型生成答案同时还可以返回引用了哪些原始片段。在线阶段的目标是“查得准、答得稳”。离线在线分开设计的好处是两边可以独立扩展。文档多了就加索引任务用户访问量大了就给检索服务扩容互不干扰。很多教程只给一段“读文档→存向量→检索→回答”的十几行代码实际工程要复杂得多但从原理上讲脉络就是这条。这里还想多说一句RAG看起来简单但这套框架拆开以后每个环节都有不少门道。嵌入模型选型、分块策略、检索召回、提示词构造任何一环做得糙最终回答质量都会明显下降。这也是为什么很多团队说“RAG没效果”仔细排查后往往是某一个环节没做扎实。2. 理解RAG的四个核心环节嵌入、分块、向量库、检索2.1 嵌入把“语义”变成可计算的数字先说说RAG里最基础的环节嵌入。什么是嵌入你可以把它理解成给一段文字做“语义编码”——把一个句子、一个段落映射成一组几百维的浮点数向量。这组向量最神奇的特性是语义相近的文本向量在空间里的方向也相近用数学测距就能判断“语义距离”。这里有个生活类比。想象你在给书架上的书贴标签你不可能贴满所有关键词而是概括成“这个主题的书大概在哪个方向”。嵌入模型做的就是这件事它把“报销需要填写哪些信息”和“发票怎么贴、走什么流程”这一类语义相近的句子映射到相邻的向量区域。查询时用户问题也映射成向量去这片区域里找最近的邻居。实际操作中选嵌入模型有四个关注点。一是维度常见的有384维、768维、1024维甚至更高维度越高表达力越强但存储空间和计算量也越大需要平衡。二是语言适配中文场景必须优先看中文语料训练过的模型否则语义区分度很受影响。三是成本调用在线嵌入服务按token计费大型知识库光嵌入费用就不低可以考虑本地部署开源模型。四是稳定性嵌入模型一旦确定就不要随意更换因为不同模型产生的向量空间不兼容换模型意味着整个索引要重新构建工程上很痛苦。嵌入在RAG链路里属于“牵一发动全身”的角色。我在早期项目里就吃过亏第一次用了一个通用英文模型做中文文档检索结果惨不忍睹换模型后发现向量库已经存了几万条旧向量只能全量重新处理。所以上线前一定要先做一轮嵌入模型的小规模评测拿一批典型问题跑一遍检索测试确认命中率再大规模入库。2.2 分块决定检索颗粒度分块是RAG最容易被低估、却又影响巨大的环节。文档本身是一大段连续文字但模型上下文窗口有限不可能把整本手册塞进去。分块的任务是把长文档切成若干小段让检索时能精准命中与问题相关的片段。分块尺寸没有唯一正确答案。块太大单块包含的噪声信息变多检索召回的“相关度”被稀释而且填充进提示词后浪费大量上下文窗口块太小语义可能被切碎比如一个完整的审批流程被砍成两段检索只能找回后半截答案就残缺。一个常用的起点是每块300到500个字符块与块之间留50到100个字符的重叠保证跨越块边界的语义不断层。更进阶的做法是按文档结构感知分块。比如对Markdown文档先按标题层级切分再对每个标题下的正文做二次切分这样检索到的每个块都有明确的章节上下文。对表格、代码块、引用等特殊元素最好单独处理——表格转成Markdown表格代码块保持缩进不被换行打散。很多解析库支持自定义分隔符LangChain里的RecursiveCharacterTextSplitter就是干这个的后面实操部分会详细演示。另外一个容易被忽略的思路是“父子分块”。父块保持较大粒度适合交给模型生成答案子块切得更细适合做检索命中。检索时用子块找位置拿到命中后返回对应的父块给模型。这样做的好处非常明显既保证了检索命中的准确率又让模型看到足够的上下文。处理“问题很短但答案依赖一整节背景”的场景这个方案尤其好用。2.3 向量库外脑的“记忆宫殿”向量都算出来以后要存到一个能按相似度查找的地方这就是向量数据库的活。你可以把向量库理解成一个巨大的记忆宫殿它不是按关键词查而是按“语义距离”查存进去的每条文本都会变成一个坐标点查询时把用户问题转化成坐标点然后找出离它最近的坐标点。市面上的向量存储方案可以分几类。一类是轻量级的本地工具比如Chroma、FAISS适合原型验证和小规模场景。FAISS严格说只是一个检索库不负责数据管理和持久化适合嵌入到自己的服务里Chroma则更像一个完整的单机向量数据库开箱即用简单接口就能CRUD。另一类是生产级的分布式向量数据库比如Milvus、Elasticsearch的向量检索插件、专用的云上向量服务支持海量数据、高并发、多租户、权限控制适合企业级部署。选型的核心看两个参数数据规模和查询频率。个人项目用Chroma存几万条向量完全够如果是面向企业客户有几十个部门同时在用查询QPS上千那就要考虑独立部署向量数据库服务。同时还要看运维能力Elasticsearch如果团队本来就在用直接开启向量检索插件是成本最低的路径如果从零开始Milvus的生态更聚焦。值得注意的是向量库本身并不理解文本它只是做数学计算。所以“存在向量库里的数据是否准确、是否最新、是否覆盖完整”这些问题都需要在入库阶段解决。很多团队过度关注向量库性能却忽略了“喂进去的东西其实就是最后的答案来源”这一点我认为比选哪个数据库更重要。2.4 相似度检索与TopK召回不是越多越好检索是整个RAG系统里决定答案上限的环节。用户在提问后系统把问题嵌入成向量然后在向量库里计算所有存储向量与问题向量的距离按距离从近到远排序返回TopK个结果。这一步用的数学指标通常是余弦相似度简单说就是看两个向量在方向上的接近程度方向越一致值越接近1语义越相关。关于网络热词热搜词与核心技术无关这里不作展开。这里有个常见的错觉相似度分数越高越好。其实不同嵌入模型的分数分布差异很大有的模型普遍打出0.8有的模型可能只在0.6徘徊不能拿一个模型的阈值直接套到另一个模型上。正确做法是先拿一批已知正确的问题文档对测试出分数的大致分布再定阈值或做后续处理。TopK的选择也直接影响回答质量。K设得太小比如1或2会漏掉正确答案K设得太大比如20会塞入大量干扰片段模型容易被无关信息带偏。我建议从K5开始试验根据回答质量上下调整。进阶一点的做法是做两阶段召回先用宽松条件召回几十个候选再用重排模型精排取前3到5个这一点后面单独聊。检索阶段的另一个配套操作是元数据过滤。比如企业知识库里既有2023年的制度又有2024年的制度检索时应该限定生效版本或者用户在意的是客户端操作文档不是服务端部署文档。这些场景都可以在检索之前先按元数据筛选缩小搜索范围比纯粹依赖语义相似度靠谱得多。3. LangChain落地实操一个可跑的RAG问答管道3.1 环境准备与最小依赖进入实战环节。我们用LangChain搭一条最完整的RAG链路先跑通再谈优化。建议在干净的Python虚拟环境里操作Python版本不低于3.9然后安装以下依赖pip install langchain langchain-community langchain-openai chromadb这里说明一下LangChain框架本身拆成了很多子包langchain-openai负责OpenAI风格接口的适配langchain-community里包含各种文档加载器。如果用的是本地开源模型可以通过langchain-ollama或者langchain-openai搭配兼容端点接入代码结构区别不大。向量库我们先用Chroma因为它简单、无外部服务依赖适合学习阶段。准备数据方面建议新建一个docs目录放几篇Markdown或者纯文本文档比如一份模拟的企业内部制度说明。不需要追求多先保证内容里有明确的实体关系比如“请假审批需要经理签字、HR备案”这样后面提问时能看到检索命中。3.2 用LangChain的LCEL搭一条完整RAG链我们用LangChain新版的LCEL语法来写。LCEL是一种管道式的写法用|把各个组件串起来代码读起来像一条流水线非常直观。完整代码如下from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI # 1. 加载文档 loader DirectoryLoader(docs, glob**/*.md, loader_clsTextLoader) docs loader.load() # 2. 分块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) # 3. 向量化并存入Chroma embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) retriever vectorstore.as_retriever(search_kwargs{k: 5}) # 4. 定义提示词 template 你是一个企业知识库助手。请仅依据下面给定的资料回答用户问题。 如果资料中没有相关信息请直接回答“资料中没有相关信息”不要编造。 资料 {context} 问题{question} 回答 prompt ChatPromptTemplate.from_template(template) # 5. 定义模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 6. LCEL管道 def format_docs(docs): return \n\n.join(doc.page_content for doc in docs) rag_chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | llm ) # 7. 调用 result rag_chain.invoke(请假审批需要走哪些流程) print(result.content)这段代码信息量有点大我按步骤拆开讲。第一步加载文档用DirectoryLoader把docs目录下所有Markdown文件读进来。这里注意loader_cls用的是TextLoader说明我们以纯文本方式读取适用于标题正文的结构化文档。如果换成PDF或Word需要替换成对应的解析器后面会提到。第二步分块用的RecursiveCharacterTextSplitter是LangChain里最实用的通用分块器。它的切分顺序看separators列表先找连续两个换行再找单个换行然后按中文句号、感叹号、问号最后按空格切。这种“由粗到细”的策略能尽量保住语义完整的自然段落。chunk_size设500chunk_overlap设80让相邻块之间保留重叠文字避免语义断层。第三步是向量化入库。这里用OpenAI的嵌入式模型把每个文本块编码成向量然后一次性写入Chroma。persist_directory参数指定了持久化目录这样vectors数据落在磁盘上下次运行可以重新加载。as_retriever方法把向量库包装成一个检索器对象search_kwargs里的k5表示每次取回最相关的5个块。第四和第五步是定义提示词和模型。这里有个值得说的细节我把“仅依据资料回答”“没有信息就直说”直接写进了模板。这是RAG提示词工程里的一个重要习惯。你是在用模型做信息检索式的问答不是在请它自由发挥。temperature设成0最大程度降低模型编造的概率。第六步是最有LangChain风格的LCEL管道。retriever | format_docs的意思是先让检索器拿到候选文档再用format_docs函数把多个文档拼接成一段上下文文本RunnablePassthrough()原样传递用户问题这两个值被映射进prompt模板里。整个管道用|串联最终输出模型的回答。调用环节问题直接传给chain。跑一遍如果文档里确实包含“填写请假单→直属经理审批→HR备案”这类描述模型会照着资料回答还会自动带上资料里的细节。3.3 生产化之前必须补的细节上面这段代码能跑但离生产还差几步。首先加载器太简陋。正式场景里的文档多是PDF、Word、表格PDF解析尤其关键。建议按文档类型选用合适的加载器比如PDF用PyPDFLoader或PyMuPDFLoaderWord用Docx2txtLoader表格类内容先用解析工具转成Markdown再用MarkdownHeaderTextSplitter做结构感知分块。不要指望TextLoader能处理所有格式格式解析不清后面的检索和生成全部受影响。其次代码里的模型和嵌入配置写死了生产环境应该抽到配置中心或者环境变量里。再次Chroma的本地文件模式适合单机如果多人共享或者需要高可用就得换服务端向量数据库。这些属于架构层面的选型不必在学习阶段过度纠结但心里要清楚RAG的代码只是骨架工程化要靠周边设施。还有一点文档入库后如果更新了要维护文档版本。最简单的方式是给每个chunk记录source文件路径和文档hash更新时先删除旧hash对应的chunk再写入新的。否则同一个问题可能同时命中老版本和新版本的内容模型就会把互相矛盾的信息都拿进去回答容易混乱。4. 实战踩坑排查检索质量差时先查这四件事4.1 召回结果“有关系但没说到点上”这是我被问得最多的问题答案引用的资料看起来和问题是同一个主题但就是没击中关键信息。比如用户问“请假的审批流程是什么”检索回来的却是“请假和考勤的关系”章节里面全是背景介绍没有流程。这个问题的根本原因是向量相似度和答案相关性不是一回事。嵌入模型抓的是整体语义方向“请假”和“考勤”经常出现在同一段话里所以向量距离很近。但用户要的是流程步骤检索回的是概念说明粒度有偏差。解决思路有三个第一给文档做更细的元数据标注比如给“审批流程”类型的内容打上专门标签检索时按标签过滤第二用“父子分块”或者给每个块加标题前缀让语义信息更聚焦第三引入关键词匹配做补充召回比如问题里出现“流程”就在检索结果里优先保留标题或正文含“流程”的片段。在实际项目里三个手段我往往会组合着用。只调向量相似度阈值解决不了粒度错位问题因为那不是相似度不够而是语义对齐方式不对。4.2 分块切断导致答案残缺第二个高频问题是文档里明明有完整答案但模型只答了一半。比如一份产品规格说明书里一个完整参数表被分块器从中间切开上半部分在ChunkA下半部分在ChunkBTopK只召回了ChunkA答案自然缺参数。规避方案有两个层面。分块层面优先用结构感知分块器比如按Markdown标题层级切并且把表格作为独立块如果文档没有明显结构就增加块重叠让被切开的语义在相邻块里都有残留。检索层面用父子分块——子块定位、父块回答子块负责搜得准父块负责答得全。我强烈建议在索引服务设计阶段就把父子分块纳入MVP而不是等出了问题再补。4.3 表格类内容检索效果差很多企业的知识库大量依赖表格比如价目表、人员通讯录、进度跟踪表。表格在解析成纯文本以后往往变成一堆用空格隔开的字符串嵌入模型很难理解这种排布检索命中率和回答可读性都直线下降。这里我有一个实测有效的做法在解析阶段把表格转成Markdown表格格式也就是用竖线和横线画出来的那种。Markdown表格有明确的列与行结构嵌入模型对这种格式的理解比纯空格分隔好得多。如果你用的解析库输出不是这种格式就写一层转换逻辑把表格区域单独识别出来重排。不要指望模型能“看懂”所有无结构文本尽量在给出去之前就把结构保留好。4.4 多轮对话里第二问丢了上下文用户先问“请假需要什么材料”模型给了答案用户接着问“需要提前几天申请”如果这条对话直接拼接进RAG管道第二个问题的检索词就会变成“需要提前几天申请”向量库里找不到完整匹配。这里的“需要提前几天”其实指向“请假申请”但向量检索会把“几天”当成核心语义去匹配结果大概率召回不相关的内容。严格来说这不是RAG本身的缺陷而是多轮场景下查询需要被改写。做法是把历史对话和当前问题一起交给模型生成一个包含上下文的独立查询再去检索。LangChain里可以用专门的历史感知检索器比如把历史消息和最新消息汇总成“完整版问题”。如果不想额外调模型也可以简单粗暴地把最近一轮的历史回答拼到当前问题后面。总之多轮RAG不要跳过查询改写否则越往后答越跑偏。5. 进阶优化让“外脑”更聪明的三种手段5.1 混合检索向量和关键词做搭档向量检索擅长“语义相似”但遇到专业术语、型号编码、人名地名这种精确匹配需求就容易翻车。比如用户搜索“A100-80G”向量可能把它理解为“某个高性能显卡”但知识库里写的是“A100-80G”这个确切型号两边的向量表示完全对不上。这时候传统的关键词匹配反而更准。所以生产级RAG常常采用混合检索一路走向量相似度一路走BM25或Elasticsearch这样的关键词匹配两路结果做融合排序。融合方式可以是简单的分数加权也可以用RAG Fusion这类基于排名融合的算法。实践下来混合检索对“同时包含模糊语义和精确标识符”的领域问题效果提升非常明显。5.2 重排先广召回再精排序我之前提到两阶段检索这里的核心是不要把TopK直接当最终答案而是先放宽条件召回50到100个候选再用一个更精细的重排模型通常是Cross-Encoder对候选重新打分选出前3到5个。为什么要这样做因为双塔向量模型同时编码问题和文档实际上是压缩语义后再比对速度快但精度有损耗。而重排模型是让问题和文档同时进入模型做细粒度的交互匹配精度高但计算量大。用在粗召回阶段不划算用在精排阶段非常合适。工程上可以先粗召回再精排既保证速度又显著提升答案的精准度。需要强调的是重排模型也要自己评测。不同重排模型对中文领域的支持差异很大建议用小规模人工标注数据集做效果测试不要只看排行榜上的英文指标。5.3 元数据过滤、版本管理与引用溯源最后聊三个支撑“外脑”长期可用的周边能力。元数据过滤是硬需求在企业场景里尤其明显用户可能只想查询某个部门、某个时间段的文档同名的制度文件可能下发了多个版本必须按生效日期过滤。这些信息在入库阶段就应该作为字段存储查询时做结构化过滤再进入向量检索。版本管理的思路是给每个文档分配唯一文档ID更新时先清理旧ID的所有块再写入新块。如果文档本身是增量变化的还可以做部分更新。不要用“删掉整个向量库再重新入库”的粗暴方案大库重建耗时耗力还会影响在线服务稳定。引用溯源这个点往往被忽略。RAG的答案是基于资料生成的生产环境应该让用户看到回答的依据。做法很简单给每个块带上来源文件路径、页码、章节标题生成答案时把命中的块ID传回前端展示。这不只是用户体验问题更是排查问题的手段——回答不对时首先看它引用了哪些资料立刻就能定位是检索错了还是模型理解错了。最后分享一点个人的实操心得带过好几个RAG项目以后我最大的感受是决定系统效果的往往不是模型选得多强而是你有没有把“资料怎么组织、怎么检索、怎么给到模型”这件事想清楚。很多人一上来就追求最新的向量数据库、最大参数的模型结果卡在了分块不合理、文档格式解析乱、TopK没调这三个最基础的环节上。我自己养成了一个习惯每次调整分块策略或嵌入模型后都会准备一组固定的测试问题集先不看模型生成的答案只看检索召回里是否包含正确答案所在的片段。这一步叫“检索质量回归”比直接看端到端回答要容易判断得多因为生成环节会掩盖检索环节的问题。只要召回能稳定命中后面的生成基本不会出大乱子。另外RAG这条路线后续还有不少可以扩展的空间查询改写、多路召回、智能路由、知识图谱增强、评估指标自动化。本篇先把原理和最小闭环跑通下一期可以专门聊聊如何搭一套RAG的评估流水线用数据而不是感觉来迭代这个“外脑”。