1. 开始之前RAG到底解决了什么问题1.1 大模型的记忆短板和一本正经胡说八道近两年AI圈最热的话题RAG技术绝对排得上号。就算你没亲手搭过也肯定听过这个名字——检索增强生成英文全称Retrieval-Augmented Generation。它要解决的是大模型最让人头疼的毛病明明很多事不知道却还要硬编一个看起来合理的答案。业内管这叫幻觉说直白点就是一本正经地胡说八道。为什么模型会这样因为大模型本质上是个概率预测器它训练时的知识都有截止日期而且压缩过程一定会丢失大量细节。你问它最新的行业政策它答不上来你让它查你自己公司的私有文档它完全没概念就算问通用知识它也可能把相似概念混在一起。这时候你不能怪模型笨因为它的记忆方式是参数化的不是一个能随时翻看的资料库。RAG的思路特别朴素模型不懂没关系给它配一个外挂记忆库。回答问题之前先从记忆库里把相关资料检索出来连同问题一起扔给模型让模型基于资料作答。说白了就是给大模型开卷考而不是闭卷猜。这么做的收益非常直接答案更准确、能回答时效性强的问题、还能做到可溯源。你可以很清楚模型是基于哪段文档得出的结论这放在企业级场景里几乎是刚需。1.2 RAG的本质给模型配一个可查询的外部记忆我习惯用一个类比来理解RAG大模型像一个学识渊博但记忆会过期、还容易把记忆混淆的专家RAG就是给这位专家配了一个助理。每次专家回答问题前助理先跑到资料室翻出相关卷宗把关键段落摘抄到专家手边专家看着卷宗再开口。你说专家是不是更靠谱当然。所以RAG的本质不是替代大模型也不是修改模型权重而是用一套检索系统去增强模型生成时的上下文。它由三部分组成数据侧文档切块、清洗、向量化、检索侧召回候选文档、生成侧把候选文档拼进提示词并让模型作答。这三部分任何一个环节出问题整体效果都会打折这也是后面所有进阶技巧的出发点。1.3 谁适合用RAG、谁不适合根据我的经验下面这些场景特别适合RAG企业内部知识库问答、客服机器人、法规政策查询、产品文档助手、教育辅导以及任何要求答案必须能追溯到出处的内容生产场景。如果你遇到的主要痛点是模型不知道最新资料或模型给出的内容无法验证RAG基本就是首选方案。反过来如果你的需求是写故事、做头脑风暴、生成代码这类偏创造性的工作RAG能提供的帮助比较有限它更适合约束性强的任务如果你的资料量极小且问题固定可能用轻量微调更划算如果你的场景对延迟极其敏感RAG每次查询都要走完整检索链路成本和耗时都会比纯生成高出不少。决策之前先想清楚你要补的到底是知识还是推理能力。缺知识RAG能救缺推理光加RAG还不够后面我会专门说怎么让RAG学会思考。2. RAG的经典架构检索、增强、生成2.1 数据准备阶段切块、清洗、向量化很多人以为RAG难在系统搭建其实真正的坎是数据准备。这个阶段决定了整个系统的上限。你喂进去的是垃圾检索出来的就是垃圾最后生成的自然也是垃圾。第一步是数据清洗。PDF要转文本表格要结构化网页要去掉导航和广告。这里有个容易被忽略的细节如果原PDF是扫描件必须先做OCR光学字符识别否则你切出来的全是乱码。我见过不少项目因为这一步漏了最后检索出来的文本连人都读不通模型当然更读不通。第二步是切块。长文档不能一股脑全丢进去得切成大小合适的片段。切块粒度太粗比如一整篇论文算一个块检索时命中率低而且塞进提示词后上下文太长切块粒度太细比如一个句子一个块语义容易破碎模型抓不住重点。我常用的做法是两个维度一起控制单块长度控制在300到800字之间块与块之间保留少量重叠比如50到100字避免关键信息正好卡在两块交界处被切断。既可以用固定长度硬切也可以按标题、段落这些结构边界来切后者对PDF、HTML这类有层级的内容效果更好。第三步是向量化也就是把每个文本块通过embedding模型变成一串浮点数向量。语义相近的文本在向量空间里距离也更近。选embedding模型时要注意语言匹配度中文场景优先选对中文理解能力强的模型否则检索质量会明显下降。另外向量维度不是越高越好维度太高存储和计算成本都会上涨需要自己权衡。2.2 检索阶段为什么向量检索是标配、BM25为什么还没退役检索阶段是RAG的核心环节当前最常见的技术是向量检索。它的优势在于能理解语义相近的表达比如你问怎么退费文档里写的是退款流程这两句话表面没有共同关键词但向量空间里距离很近就能被召回来。这就是向量检索比传统关键词检索聪明的地方。但我不建议一上来就抛弃传统检索。BM25一类的词汇检索靠字面匹配在处理标准化术语、编号、精确产品名时往往比向量检索更靠谱。你搜型号ABC123如果文档里恰好有这串字符BM25能精确命中向量检索却可能被语义接近的其他内容干扰。最稳的做法是让两种检索并行再做结果融合这也是行业里常说的多路召回。后面我会给一个具体的融合策略作为参考。2.3 提示词拼接让模型结合资料而不抄袭资料检索完文档接下来就是把候选资料和原始问题拼成提示词让模型作答。这个环节看着简单实际上讲究不少。首先提示词里要明确告诉模型请仅根据以下资料回答不要依赖内部知识这能明显减少幻觉其次要给资料按相关度编号让模型回答时标注引用来源如果资料和问题没关系要允许模型回答资料不足而不是强行编造最后拼接的资料数量要克制不是越多越好。我一般取Top 3到Top 5个片段太多会把真正有用的信息淹没模型反而抓不住重点。在表达风格上提示词可以写得很细比如分点作答先给结论再给过程如果资料间有冲突如实指出这些约束都能让输出结构更符合业务需求。但我也提醒一句提示词不是越长越好你写一大堆规则模型同样可能忽略。关键规则往前放并且用清晰的分隔符隔开效果会好些。3. 从能检索到会思考进阶进化的五个关键闸门3.1 重排序别让召回率困住你的精度基础RAG跑起来之后大家很快会遇到一个典型问题召回率高精度不够。也就是说相关的内容都被召回了但真正能回答问题的片段可能排在第五六位而最后只取前三名答案就没被送进生成器。解决这个问题最直接有效的办法就是加一个重排序模型。重排的基本思路是向量检索先用效率换取宽召回比如召回60条候选然后交给一个精度更高的模型逐条打分排序最后取最靠前的几条。重排模型比向量检索更精细它能做完整的交叉匹配更擅长判断这个问题和这段资料之间到底有没有真正的逻辑关系。这一步加上之后答案命中率的提升往往是肉眼可见的。我在一个模拟知识库项目上试过不加重排时正确率大约72%加了一轮重排之后直接到86%。这不是玄学而是宽召回加精排序的组合确实能把最好的结果顶到最前面。3.2 多路召回与融合策略只靠一路检索相当于只用一只眼看世界。多路召回是并行跑多个检索通道比如向量检索、BM25关键词检索、元数据过滤然后把各路结果合并。合并时有个麻烦各路的打分量纲不一样不能直接比较。最常用的做法是加权融合。我自己的经验是向量打分的权重可以稍高比如0.6BM25的权重0.3元数据过滤作为强制条件而不是打分项参与剩下的0.1留个时间衰减或新鲜度加分。具体权重要基于验证集反复调不存在一个万能值。融合之后还会遇到一个问题不同路召回的片段经常重复必须做去重否则一个片段会占掉多个名额。去重可以用simhash也可以直接判断来源段落ID是否相同后面那种方式更简单但前提是切块阶段已经给每个块分配了全局唯一ID。另外如果同一份文档有多个版本最好在去重时保留时间戳最新的那个版本这个细节很容易被忽略。3.3 查询改写与多跳检索用户的原始问题往往不适合直接拿去检索。比如那它的价格呢这句话里那指代什么必须结合上文才能判断。所以我通常会在检索之前加一步查询改写用大模型把用户的模糊问题重写成完整、独立的表述再交给检索器。这一步看似多余实际上能挽回大量因为表达不规范导致的漏召回。另一种情况是复杂问题拆解。用户问某产品去年的营收和主要客户分别是什么这个问题包含两个完全不同的检索需求。如果你不拆解直接拿整句话去检索往往找不回两方面的资料。多跳检索的做法是把问题按意图分解成子问题每个子问题分别检索收集结果后再合并。更进一步还可以迭代检索先检索第一轮发现资料缺少某个细节再根据已知信息生成下一步检索问题。这个过程和人查资料时不断缩小范围是一样的道理。3.4 思维链与规划让RAG学会推理到这里RAG已经能准确找到资料但遇到需要多步推理的问题还是会露怯。比如文档里提到某产品采用了某项新技术那么这项技术的专利编号是多少——这需要把两份文档的内容拼接起来才能回答单路检索很难一次完成。这时候就需要引入规划能力让模型在生成前先列一个推理计划决定先去检索哪些信息、按什么顺序检索、检索结果之间如何推导。实际操作上我经常用轮询式Agent的模式模型先规划步骤每执行一个检索动作就观察结果再决定下一步动作直到收集够信息才给出最终答案。这其实就是把RAG和思维链结合业内常叫Agentic RAG。这种模式效果确实好但代价是推理次数变多延迟和成本都会上升。所以我会给它加一个简单的入口控制器简单问题直接走快速路径复杂问题才启动多步规划不要一刀切。很多项目一开始就上Agent骨架结果大部分简单问题也被拖得又慢又贵得不偿失。3.5 记忆机制让RAG记住上次聊到哪了多轮对话场景里RAG特别容易失忆。比如用户先问某设备的维护周期是多久然后接着问那另外那款呢前一轮的上下文是很有价值的但如果会话管理做得不够细致第二个问题可能被当作独立问题丢去检索范围自然就偏了。我通常会把最近几轮交互压缩成一个对话摘要或者至少保留最近两三轮的原始文本让查询改写模块结合这些上下文来重写当前问题。更进阶的做法是长期记忆。把历史问题、答案、用户偏好、常用实体都存起来在检索阶段作为额外上下文参与打分。相当于RAG不仅查外部文档还查一份内部记忆。这个方向很有意思未来问答体验的差异化很大程度上就取决于记忆管理做得好不好。它和短期会话摘要的区别是长期记忆要跨会话、跨用户对隐私和权限管理的要求也更高。4. 实操环节从零搭一个能跑的RAG系统4.1 技术选型与架构设计很多初学者一上来就被框架选择困住。我建议先不要纠结于是用某个全功能框架还是自己拼积木你先想清楚自己的目标是什么。如果只是想快速验证想法那用成熟框架最省事如果你想真正理解每个环节或者需要深度定制检索逻辑我更推荐自己组装一个embedding模型、一个向量库、一个对话模型、一段胶水代码就够了。我的一个最小架构长这样数据源是几个Markdown文档文档经过解析后按标题切块每块通过embedding接口生成向量写入一个支持向量检索和元数据过滤的服务查询时先做查询改写向量检索和全文检索并行跑融合后用重排模型精排最后把Top K拼进提示词调用大模型接口生成答案。整套系统用不到300行核心代码就能跑通这个规模很适合学习也适合做业务原型。4.2 代码骨架检索、重排、融合、生成这里我给出一个可以直接参考的流程骨架用接近伪代码的形式来写避免把你绑定到某个具体框架上。每个环节的接口你都可以按自己的需求替换。文档切块与清洗from doc_parser import extract_text from chunking import split_by_structure, split_by_size chunks [] for doc in documents: text extract_text(doc) # 按文档类型选择解析器 for section in split_by_structure(text): # 按标题、段落切分 sub_chunks split_by_size( section, size500, # 单块目标长度 overlap80 # 相邻块重叠长度 ) chunks.extend(sub_chunks)写入向量库for chunk in chunks: vec embedding_model.encode(chunk.text) vector_store.add( idchunk.id, textchunk.text, vectorvec, metadatachunk.metadata )查询与多路召回query_vec embedding_model.encode(rewritten_query) vector_hits vector_store.vector_search(query_vec, top_k60) keyword_hits bm25_index.search(rewritten_query, top_k60) fused fuse_hits( vector_hits, keyword_hits, weights[0.6, 0.3, 0.1] # 向量、BM25、时间新鲜度 )重排与生成reranked reranker.rerank(question, fused[:60], top_k5) context format_context(reranked) prompt build_prompt(question, context) answer llm.chat(prompt)这套流程跑通之后你才算真正掌握了RAG的基本盘。后面做任何优化脑子里都会有一个清晰的可插拔点改了哪个模块影响的是哪些环节怎么评测。4.3 评测方法没有评测就没有优化做RAG最忌讳的是感觉效果还行。你必须建立一套评测集让效果变得看得见、可比较。我的建议是准备至少50到100条真实业务问题覆盖典型场景、容易混淆的情况和长尾问题。给每条问题准备标准答案和预期引用的文档ID然后跑一个批处理脚本自动算两个核心指标答案准确率可以用语义相似度也可以让一个独立的裁判模型打分和引用正确率判断模型引用的文档ID是否属于预期文档。评测跑完还要能定位问题到底出在检索还是生成。方法很简单单独看检索层的召回率也就是正确答案是否出现在TopK里再看生成层的准确率也就是答案是否贴合已召回的文本。如果召回率低问题在检索侧重点优化切块、Embedding、重排如果召回没问题而生成错问题在提示词或模型能力。有了这套机制你才不会像无头苍蝇一样到处乱调参数每次改动都有数据支撑。5. 踩坑实录与排查技巧5.1 检索效果差先查切块还是先查Embedding我自己的排错顺序是先看切块。打开可视化的日志工具把召回回来的文本块看一遍。如果文本块本身包含问题相关关键词和上下文但排序排不到前面那问题出在重排或融合如果文本块里压根没有相关内容说明这一步就断了。切块粒度、重叠窗口大小、文档结构解析是否保真这些就是重点排查项。切块没问题再看Embedding模型。你可以做个小实验拿几个语义相同但字面差异很大的句子算它们的向量相似度。如果相似度不高说明模型对这类语义不太敏感或者需要给文本块补一些检索上下文。什么叫做补充检索上下文就是切块时把章节标题、摘要、甚至块内关键词提取出来拼到向量化内容里。很多知识库里一个块只有两三句话语义太单薄向量化后容易跑偏用这个方法往往能显著提升召回率。5.2 生成结果和文档矛盾怎么破生成内容和文档矛盾大多数时候是提示词约束不够严。我在提示词里加了如果资料中没有信息请直接回答资料不足之后幻觉率立刻降了一截。有些严肃场景还需要限制模型的自由发挥程度比如医疗和法律领域可以要求答案必须逐句对应引用没有引用的内容不要输出。还有一类情况是重排取回了多个互相矛盾的资料。比如不同版本的文档某个参数新旧不一样。这时你要在提示词里让模型指出资料之间的冲突并根据时间或版本属性判断优先级同时让它把冲突事实并列展示。让模型自己编一个统一口径反而更危险。正确的做法是保留分歧、说明依据最终取舍交给用户判断。5.3 性能与成本的平衡RAG系统越复杂延迟越高成本也越高。多跳检索、重排、Agent规划这些能力都相当贵。我通常采用的策略是分级处理用一个轻量打分模型判断问题复杂度简单问题走单次检索加轻量生成复杂问题才进入Agent化流程。这样既保证整体体验又能把平均延迟和成本控制在一个合理范围。还有一个容易被忽视的成本点向量化阶段重复计算。如果你的文档每天都在更新没必要每天对全量文档重新向量化只更新新增和变更的部分即可。常见的做法是按文档ID记录变更状态增量计算向量并写入索引。这个坑我踩过某次发布新版本时对整个知识库重刷了一遍结果那批数据的算力开销暴涨了好几倍延迟和账单同时爆表。5.4 实战中的三个独门技巧除了上面的排查方法再分享三个我长期用下来觉得非常管用的小技巧。第一个是锚点补充在切块向量化时把文档标题、章节标题、上一级目录信息拼到文本块前面当锚点。向量检索时这些锚点会参与语义匹配特别适合那种正文很碎片化的文档。第二个是答案级联先用小模型把粗粒度结果跑出来再让大模型基于小模型的结果做二次精读和改写。有些场景这样做比一开始就用最强模型更省钱效果也不差。第三个是否定词检查检索前先判断问题里是否有不、非、没有、除外这类否定词如果存在普通检索往往会把否定意义弄丢这时候需要在查询改写时特别提示模型保留否定含义甚至单独走一遍关键词排除逻辑。6. 写在最后从工具到智能RAG还能走多远做了这么多RAG项目我最大的感受是RAG的意义不只是给模型加一个搜索框它其实是让AI从记忆型走向思考型的关键桥梁。当检索不只是一个关键词匹配过程而是一套能规划、能判断、能取舍的信息获取流程模型就不再只是背答案它开始理解该怎么找到答案。再往后RAG还会和更多方向结合多模态检索、复杂推理、记忆网络、工具调用这套思路的生命力远比我们想象的强。如果你正在做RAG项目我的建议是先把基础链路做稳再谈高级技巧。别一开始就上Agent、上多跳把系统搞到连自己都无法排错。先把文档切好把检索召回做稳把提示词约束到位这个时候已经能解决绝大部分问题。之后再根据业务瓶颈逐步加入查询改写、重排、规划这些进阶动作。一步步来效果看得见优化也做得踏实。最后分享一个我个人的习惯每次改完一个环节我都会把评测集分数记录在一张表格里哪怕是改了一个权重、加了一句提示词也要记录前后对比。RAG优化靠的不是灵感而是持续的实验和数据。你把这个习惯坚持下去很多别人口中的玄学在你手里都会变成可复现的工程经验。