3月21日到4月7日我给自己排了一个两周半的学习计划专门攻RAG开发相关知识。起因很简单——我在做大语言模型应用时发现光会调接口根本不够业务方问得最多的永远是“能不能让它回答我们内部文档里的东西”“它怎么又在胡说”。这两个问题指向同一个解法就是检索增强生成RAG。所以我决定集中一段时间把这条路完整走一遍从文档加载一路到效果评估。这篇文章就是这次学习过程的完整记录包括我前期梳理的知识地图、每天的时间安排、最小系统怎么搭、检索质量为什么上不去以及最后项目落地的真实感受。如果你也想系统学RAG开发但不知道从哪里下手、该按什么顺序学可以参考这条路线能省掉不少瞎摸索的时间。1. 决定学RAG之前我到底在焦虑什么1.1 大模型应用的三个真实痛点先说说我为什么非学RAG不可。过去大半年我一直在做大模型相关的落地尝试越做越发现光靠模型本身的能力根本撑不起一个正经产品。问题主要集中在三个方面。第一是幻觉。模型没见过的东西它会一本正经地编。客服场景里用户问一件根本没上架的商品模型能给你推荐出三个型号还带详细参数。这在内部demo里无所谓真放生产环境就是事故。第二是知识边界。通用模型训练完就固定了它不知道你公司刚发布的产品规格、不知道你最新的售后政策。每次更新文档都要重新训练一次模型成本高得离谱。第三是知识溯源。就算模型答对了你也说不清它依据的是哪份文档。业务方要求给答案加引用来源普通对话模型根本做不到。这三个问题恰好都是RAG的射程范围。RAG的思路很直白你问我问题我先去你的知识库里检索最相关的内容然后把检索结果拼进提示词让模型照着这些材料回答。重点不是模型知道什么而是它“现在能看到什么”。1.2 为什么我选择RAG而不是微调我在前期调研时特意对比过RAG和微调这两条路线。很多人一上来就想微调模型觉得这样最“彻底”但实际做过就知道微调解决的是模型的“表达方式”和“知识内化”问题不适合频繁更新的业务知识。我整理了一张对比表看完基本就清楚该怎么选了对比维度RAG微调知识更新成本替换或新增文档即可需要重新训练和部署能否溯源可以返回原文片段很难解释知识来自哪里幻觉控制通过约束生成明显改善改善有限硬件门槛普通开发机即可实验需要训练环境的算力开发周期几周内可上线数据、训练、评测周期更长适合场景私有知识库、实时信息、客服问答风格迁移、领域术语强化、格式固定任务我的结论是如果你要处理的是“不断变化的业务文档”比如产品手册、制度文件、售后知识库RAG是优先级最高的方案。微调可以作为补充手段等RAG效果跑通之后再去考虑。1.3 学RAG开发到底要学什么这里想给同样零基础的朋友一个预期管理。所谓“RAG开发相关知识”并不是一个单一技能而是一条完整的技术链路。从原始文档到最终回答至少要经过五个环节文档加载、文本切分、向量化、检索召回、生成回答。任何一个环节做得不到位最终效果都会打折扣。所以我在定学习计划的时候就没指望一口吃成胖子而是把两周半拆成了“概念理解、最小实现、质量优化、综合实战”四个阶段一个阶段一个阶段地推进。2. RAG开发前必须补上的几块拼图2.1 文档加载与解析比想象中麻烦第一个环节是文档加载。我一开始以为就是读文件真做起来才发现坑很深。知识库里的文件格式五花八门PDF、Word、Markdown、扫描件、表格每一种都有各自的解析难点。PDF是最折磨人的尤其是扫描生成的PDF本质上是图片需要先做OCR识别。就算是一般的电子版PDF表格和分栏的处理经常会把版面读乱。Word文档里嵌了图片、公式、页眉页脚的解析出来全是噪声。我做项目时专门花了一天时间处理“PDF里表格读成乱序文本”的问题最后没有找到一劳永逸的方案只能针对自家文档格式做定制策略。这里有个经验解析完的文本不能直接入库必须做清洗。把页眉页脚、多余换行、乱码字符统一处理掉。别小看这一步脏文本切出来的片段向量化之后质量很差检索命中率会明显下降。2.2 文本切分直接决定检索能不能命中文本切分是最容易被忽视的模块也是后来影响我检索效果最大的变量。切分的核心目标是让每个片段在语义上完整、粒度合适。切得太大会混入无关信息导致向量表示不准确切得太小会丢失上下文模型生成时没有足够的依据。最基本的做法是固定长度切分比如每300到500字一段段与段之间留几十字的重叠避免刚好把一句话拦腰截断。更进阶的做法是按文档结构切分比如Markdown的标题、段落、列表都是天然边界优先按结构切切完不够再补固定长度。我现在的默认策略是先按结构切保证语义完整片段超过上限再按固定长度二次切分每个片段之间保留适量的重叠。这套组合在大多数业务文档上都适用。2.3 向量化、向量库与检索召回的逻辑关系文本切好之后要把它变成机器能算相似度的东西这一步叫向量化。我的粗浅理解是嵌入模型会把一段文本映射成一个几百上千维的浮点数组语义相近的文本在向量空间中距离更近。你用同一套嵌入模型把你的问题和知识片段都转成向量然后算余弦相似度或者内积就能找出最相关的几个片段。这些向量需要一个地方存着这就是向量数据库。向量库除了存、取向量核心功能是提供高效的近似最近邻检索。你在上万条片段里找最相关的5条如果用暴力遍历也做得动但数据量上百万之后没有索引支撑就完全跑不动了。检索召回这块我建议不要一上来就追求花哨的混合检索和重排序。先把“向量相似度检索”这条路跑通理解top_k、相似度阈值这些基本概念再考虑加关键词检索和重排模型去提升效果。2.4 生成环节最容易犯的错误最后一个环节是把检索到的片段拼进提示词让模型基于这些内容生成回答。看起来简单但有一个非常典型的新手错误提示词里没有约束“只能根据给定资料回答”。如果不明确写这句模型在资料里找不到答案时照样会调用自己的常识作答幻觉又回来了。正确做法是在提示词里明确两件事一是回答的依据只能是给定的资料二是资料不足时直接说“资料中没有相关信息”不要自行补充。2.5 评估指标没有评测就没有优化我前面拖了很久才意识到RAG开发里最容易被忽略的是评估。没有评测体系你就说不清改动到底变好还是变坏了。RAG的评估一般分成几个维度检索能不能找到相关片段、生成内容忠不忠实于检索资料、答案完不完整、有没有幻觉。实际做的时候可以用人工评测小批量样本也可以用大模型当裁判自动打分。建一个小测试集固定几十条问题和标准答案每次改动之后跑一遍对比前后得分。这套机制简单但非常有用我在第四阶段优化时全靠它定位问题。3. 3.21-4.7两周半我的RAG学习实测路线3.1 第一周3.21-3.27把最小闭环跑通我第一周的目标非常明确别管效果好不好先把“文档进来、答案出来”的完整链路跑通。前两天专门折腾文档加载和切分。我找了一批模拟项目的产品手册、售后常见问题文档写了脚本把PDF和Word批量解析成纯文本然后是清洗、去页眉页脚、按标题结构切分。这段时间做出来的东西很粗糙切分规则硬编码在脚本里但至少我理解了每一段文本是怎么从原始文档里走出来的。第三天到第五天重点做向量化和入库。我花了不少时间比较不同嵌入模型在真实语料上的表现用了一小批人工标注的“问题-相关文档”去验证哪个模型召回最准。这一步的结论对我后续选型帮助很大因为嵌入模型长期被当成“默认组件”看待其实它对最终效果的影响非常显著。第六天第七天我把查询侧接了进来写查询函数向量化用户问题去向量库检索取出top片段拼提示词再调模型生成回答。第一版Demo在周六晚上跑通了当时问了一个文档里有明确答案的问题回答基本正确虽然格式很丑但那种“终于跑起来了”的感觉还是值得记一下的。3.2 第二周3.28-4.3解决检索质量问题第二周我开始面对现实简单Demo能跑但一旦问题稍微绕一点效果就崩。这一周主要干了三件事。一件是调切分参数。我把几个典型问题在旧切分参数下检索出来的片段翻出来看发现很多正确信息被截断了根本不出现在片段里。后来调小了切分长度、增加了重叠比例命中率立刻涨了一截。一件是引入关键词检索做混合。因为光靠向量检索遇到专业术语、精确型号时经常失手。我把BM25关键词检索加进来把两路结果做一个简单的分数融合问题就改善了不少。还有一件是加了一个小的测试集开始做评测。我从知识库里挖了三十个问题每个问题标注了标准答案。每次修改完配置就跑一遍这三十个问题统计有多少回答能命中标准答案。也是从这时候开始我所有的优化动作都有了数据反馈。3.3 第三周4.4-4.7整合一个像样的项目4月4日到4月7日这两天半我没再折腾零散的功能模块而是把前面的代码整合成一个结构清晰的项目。主要做了四件事把配置变成参数化让切分长度、检索数量、相似度阈值这些可以随时调整写了一个简易的问答页面方便测试把日志完善了一下能看到每次查询检索到了哪些片段最后拿着新问题做了一轮完整验收。这个过程最大的收获是我终于把RAG开发的全链路串起来了知道哪个环节效果不好时应该去调哪里。到4月7日收工前这个模拟项目已经能稳定回答大部分业务问题很少出现幻觉了。4. 手把手搭建一个最小RAG问答系统4.1 整体流程与代码骨架这一节我用一个极简示例还原最小RAG系统的样子让读者能看到全貌。我用自己的占位对象名来写逻辑是完整的替换成你手头的手艺就能跑。# 步骤一加载本地文档 docs doc_loader.load(./knowledge_base/, formats[pdf, md, txt]) # 步骤二清洗与切分 clean_docs text_cleaner.clean(docs) # 去页眉页脚、去乱码、统一换行 chunks text_splitter.split(clean_docs, chunk_size350, chunk_overlap75) # 步骤三向量化并写入向量库 vectors embed_model.encode(chunks) # 每个片段生成一个向量 vector_db.add(vectors, chunks) # 片段原文和向量一起入库 # 步骤四查询、检索、生成 query 某产品的退货政策是什么 query_vector embed_model.encode([query]) hits vector_db.search(query_vector, top_k5) context \n.join([f[片段{i1}] {hit.text} for i, hit in enumerate(hits)]) prompt f请只根据下面的资料片段回答问题。 资料 {context} 问题{query} 如果资料中没有相关信息请直接说资料中没有提到相关内容。 回答 answer llm.generate(prompt) print(answer)这段代码对应的完整流程是先加载文档接着清洗并切分成语义完整的片段然后向量化入库。查询时把用户问题也转成向量去向量库检索最相关的几个片段最后把这些片段组装成提示词交给模型生成回答。整个链路里真正需要动态调整的就是切分参数、检索数量和提示词写法。4.2 关键参数怎么定以切分长度为例参数设置是新手最常见的问题比如“chunk_size应该设多少”。我给一个经验值范围如果文档内容是中文通用文本每个片段在300到500字之间比较合适如果是技术手册可以适当放宽到600字左右。太短会丢上下文太长会让向量被无关内容稀释。重叠比例一般在10%到20%左右比如片段长度350字、重叠75字相当于20%。重叠的作用是避免一句话刚好被切断后后半句在下一个片段里没有前文支撑。还有一个容易被忽略的是top_k。检索返回的片段数量不是越多越好。取1到2个可能信息不够取10个又会让提示词里混入大量噪声模型的注意力被稀释。我的经验是先设5再在测试集上尝试3和7做对比选分数最高的。4.3 为什么我建议先跑通再优化学习过程中我最大的体会是先别追求完美方案用最简单的路数把代码跑起来然后逐环节观察、替换、调参。很多人卡在“选型”这一步总想一开始就选到最优解。我自己的做法是先随便选一个合理的嵌入模型和向量库跑通之后再用评测集去对比替换。没有基线你连对比的对象都没有有了一条简单的基线后续每一步改动是否有效才说得清。5. 踩坑记录检索质量为什么总是上不去5.1 第一个坑切分把语义切碎了这是我踩得最深的一个坑。刚开始我把切分长度设成了800字理由是“片段长一点信息多模型生成时更充分”。结果测试集分数一直上不去翻检索日志发现很多命中的片段虽然包含关键词但整段是拼起来的关键的那句话被夹在中间语义非常混乱。后来我把长度调到350字重叠调到75字重新看日志命中的片段终于能对上一个完整的小节了。测试集分数涨了一大截。这段经历给我最大的启发是搜索引擎的召回靠词RAG的召回靠语义片段语义完整是检索命中的第一前提。5.2 第二个坑相似度阈值设得太高或太低向量检索会返回一个相似度分数我在项目里加了“低于某个阈值就判定为不相关”的逻辑。第一次我把阈值设得很高结果很多能回答的问题被拦下来了模型直接说“资料中没有提到”。后来我又调低阈值看似什么都搜得到其实放进来一堆不相关片段生成效果反而更差。最终的解决方法是拿测试集一遍一遍试记录不同阈值下检索命中的准确率选一个平衡点。这个阈值没有放之四海而皆准的数和你的文档领域、嵌入模型都有关系。5.3 第三个坑不加重排序关键信息排不到前面单纯靠向量检索相关片段不一定排在Top5里。尤其是当局部相似度很高但全局不相关或者语义相近但表达差异大的时候问题会更加明显。我第四阶段加了重排序环节也就是先快召回Top20或Top50个候选片段再用一个精度更高的模型对这些候选重新排序最后取前5个。虽然重排序需要额外开销但效果提升非常直接。建议所有知识库超过一定规模的RAG项目都把这个环节加上。5.4 第四个坑提示词没约束幻觉又回来了我有一段时间只顾着优化检索把生成端给忽略了。后来发现测试集里不少回答“流畅但错误”模型把资料里没有的信息用自己的知识补上了。原因很简单提示词里没写“只能根据资料回答”。这个问题修正之后测试集上的幻觉相关错误几乎清空。RAG不是接入检索就万事大吉生成端的约束和提示词设计同样关键。5.5 我最终形成的问题排查链路踩过这些坑之后我把RAG调试的排查顺序固定了下来。效果不好时我会按照这个顺序逐项检查排查步骤检查要点第一步看检索日志返回的片段里有没有包含正确答案第二步如果没有怀疑切分和嵌入查片段是否语义完整、嵌入模型是否适合领域第三步如果有但答案还是不对怀疑生成端查提示词和重排序第四步如果答案胡编查提示词约束和相似度阈值再看资料是否不足第五步每改一步就跑一遍测试集记录分数变化不要凭感觉判断这套链路后来帮我快速定位了绝大多数RAG问题也推荐给正在调试RAG的开发者。它不是万能药但大部分时候问题确实就出在这几个环节上。6. 学习RAG后续的事再往前走的话6.1 从基础RAG到进阶变体两周半的学习让我把基础RAG这条路走通了但也只是“入门”。调研过程中我了解到还有不少进阶方向比如基于知识图谱增强的GraphRAG它把实体和关系抽取出来建图处理多跳问题时比纯向量检索更有优势。还有把大模型作为代理Agent来主动规划检索任务的Agentic RAG每一步都会根据当前结果决定下一步检索什么。这些变体不是要取代基础RAG而是在特定场景下提供更好的方案。学了基础RAG之后这些方向理解起来就不会那么吃力了。6.2 结合场景的工程化思考RAG开发不只是把模型和向量库拼起来工程化的问题同样关键。比如如何做增量更新知识库新增了一篇文档是重新建索引还是只处理新增部分如何做权限控制不同用户角色只能检索到各自范围内的文档以及如何做性能优化检索延迟能不能压到几百毫秒以内响应时间能不能稳定。这些问题在我搭Demo的时候都没有遇到但一进入真实业务场景每一个都会变成硬指标。6.3 一点个人体会先把链路跑通再说回看这段学习经历我最想分享的体会是RAG开发不是“懂一个模型”就行而是一套系统工程。它要求你把数据、切分、检索、生成、评估这些环节都吃透任何一个短板都会拖累最终效果。我给自己的后续规划也很明确把GraphRAG和重排序部分深入研究下去再把文档数据管线好好打磨一番。因为当基础链路跑通之后决定项目上限的往往是对数据和检索细节的雕琢程度。两周半只是个开始这条路还远没走完。