上周有个学员面鹅厂聊到他做的 RAG 项目。面试官问“你这个 RAG 系统现在什么状态”他说“Demo 已经跑通了十几行 Python 代码向量检索 LLM 生成基本流程都有了。”面试官笑了“Demo 跑通很正常我实习生都能写。那你把它部署到生产环境扔进去 5000 份企业文档让它稳定地给业务部门答问题能做到吗”他愣了一下说还没到那一步。面试官追问“你知道为什么很多团队的 RAG 项目Demo 阶段大家都很兴奋但一上生产就开始被投诉’答非所问’‘检索一堆垃圾’有时候对有时候错’吗”答不上来。面试官最后说了一句话“RAG 最难的从来不是把流程跑起来而是让它真的好用。你现在做的只是完成了 10% 的工作。”这个场景我听完很有感触。因为在我们训练营的 RAG 实战项目里几乎每个学员都会经历这个阶段写完第一版代码测试几个问题觉得挺好的啊然后扔到真实场景里发现处处是坑。今天这篇文章我想把 RAG 系统从能跑到好用这条路上最难搞定的几个关卡完整拆开讲。一、数据准备知识库质量决定了 RAG 的上限很多人上来就想着搭 Milvus 或 FAISS但根本没搞清楚自己要检索的是什么。RAG 的灵魂在知识库。而知识库的质量取决于数据处理的精细程度。在我们的金融保险 RAG 项目里最开始拿到的是 5000 份 PDF 文档——有产品说明书、理赔条款、内部培训资料、历史案例记录。第一版我们直接用 PyPDF 提取文本按 500 字一刀切成 chunk扔进向量库。结果用户问重疾险的等待期是多久检索出来的 top-3 chunk 是这样的chunk_1: ...保险责任包括但不限于以下情况。等待期内发生的疾病...后半句被切掉了 chunk_2: ...30天、90天、180天三种具体以合同约定为准...前面说的是什么产品不知道 chunk_3: ...客户张某在等待期后第5天确诊...这是个案例不是条款三段文本都提到了等待期语义相似度很高但没有一段能直接回答问题。为什么因为切块的时候把完整的语义切碎了。切块策略不是技术问题是理解问题后来我们调整了策略不再机械地按字数切而是按文档的逻辑结构切PDF 文档先做结构化解析——识别出标题、段落、表格、列表。标题和它下面的内容是一个完整的 chunk表格单独成 chunk列表项如果语义独立也单独成 chunk。每个 chunk 加上下文信息——在 chunk 的开头补充它的路径比如产品名称XX重疾险 第三章保险责任 3.2等待期规定。这样即使 chunk 本身只有一句话LLM 也能知道它在讲什么产品的什么条款。动态窗口——检索的时候不只返回命中的 chunk还返回它前后各一个 chunk。这样即使切块时切断了语义前后文也能补上。调整后同样的问题检索结果变成chunk: 产品名称XX重疾险 第三章保险责任 3.2等待期规定 本产品等待期为90天。等待期内发生的疾病保险公司不承担给付责任...一段话就能答清楚。召回准确率从 0.62 提升到 0.84。RAG文档切块流程对比二、检索召回不是找最相似的是找最有用的数据准备好了下一关是检索。很多人以为用个 embedding 模型就完事了。但 embedding 模型之间差距极大。在我们的项目中同样一份知识库换不同 embedding 模型RAG 的命中率能差出 30% 以上。最开始我们用的是 OpenAI 的 text-embedding-ada-002因为大家都在用。但测试下来发现中文保险条款的检索效果很一般。用户问意外伤害包括哪些情况召回的文档里经常混进意外医疗意外身故这些相关但不直接的内容。后来换成 BGE-large-zh智源开源的中文 embedding 模型同样的问题召回精度立刻上了一个台阶。为什么因为 BGE 是在大量中文语料上训练的对中文的语义理解更细腻。但光换模型还不够。真正让我们卡了很久的是召回阈值的调整。召回阈值一个参数决定生死向量检索会返回相似度分数你需要设一个阈值——高于这个分数的才算召回成功低于这个分数的直接丢弃。阈值设太低检索一堆垃圾LLM 被干扰答案质量下降。阈值设太高漏掉关键信息LLM 无米下锅只能瞎编。在我们的项目里这个阈值从 0.6 调到 0.75反复测试了上百个 query最后发现阈值 0.65召回率 0.89但 top-5 里有 2 个是噪音阈值 0.72召回率 0.84top-5 基本都是有用的阈值 0.78召回率 0.71开始漏掉一些边缘 case最终我们选了 0.72因为我们更在意精度——宁可少召回一点也不要让 LLM 被噪音带偏。但这还不是终点。单纯的向量检索有个天然缺陷——它只看语义相似度不看关键词匹配。举个例子用户问保单号 A12345 的理赔进度向量检索可能召回一堆理赔进度查询的通用文档但就是找不到 A12345 这个具体保单的记录。因为 embedding 模型会把A12345这种 ID 编码得很模糊。混合检索向量 关键词缺一不可最后我们用的是向量检索 BM25 混合检索。向量检索负责语义匹配BM25 负责关键词精确匹配。两路检索结果合并后用 Reranker 模型重新打分排序。代码大概是这样# 向量检索 vector_results vector_db.search(query_embedding, top_k10, threshold0.72) # BM25 关键词检索 bm25_results bm25_index.search(query, top_k10) # 合并去重 all_results merge_and_deduplicate(vector_results, bm25_results) # Reranker 重排 final_results reranker.rerank(query, all_results, top_k5)这套组合拳下来召回准确率从 0.84 提升到 0.91。Embedding模型选型对比三、Query 理解用户问的不一定是系统该搜的检索做好了还有一个很多人忽略的环节——Query 理解。在我们的项目里用户的问题千奇百怪有的是事实查询——“重疾险保障范围是什么”这种直接检索就行。有的是计算问题——“我投保 50 万免赔额 5000这次能赔多少”这种应该路由到计算模块而不是检索。有的是数据库查询——“上个月理赔审批平均时长多少天”这种要走 NL2SQL。有的是带时间约束的——“最新的车险理赔流程是什么”这种虽然走检索但要加时间过滤。如果你把所有 query 都一股脑丢进向量检索会出现两种尴尬一是该算的不算——计算题去检索文档拿回来的是理赔政策而不是计算结果。二是该过滤的不过滤——要最新流程却召回了旧版本因为语义检索不理解最新这个约束。意图识别三级组合方案我们用的是规则 ML 模型 LLM 三级组合。明显能用关键词命中的占大多数直接走规则零延迟。规则匹配不上的走 BERT 分类器几十毫秒解决。分类器信心度低的softmax 概率最高的类别只有 0.4才调 LLM 做最终判断。这样既保证了速度大部分 query 走规则几乎不耗时又保证了准确率疑难 case 有 LLM 兜底还控制了成本只有少量 query 需要调 LLM。路由逻辑大致如下意图“知识问答” → 走向量检索 BM25 混合检索意图“计算求解” → 跳过检索路由到计算模块意图“数据查询” → 路由到 NL2SQL 模块意图“闲聊” → 不走 RAG直接让 LLM 通用对话一个很实用的进阶策略是多索引路由。如果你的知识库按主题分成了多个索引比如理赔制度“销售策略”产品信息各一个索引意图识别后可以根据 query 的主题选择对应索引检索而不是在全库里搜。这样既提高了检索精度又减少了计算量。四、生成阶段RAG 不是检索生成的简单加法很多人以为 RAG 就是把检索结果拼到 Prompt 里然后让 LLM 生成答案。但真正成熟的 RAG 系统是在生成阶段做控制的。否则 LLM 很容易自作聪明胡编乱造。在我们的项目里最开始的 Prompt 是这样的根据以下文档回答用户问题 {检索结果} 用户问题{query}结果 LLM 经常自己发挥——检索结果里明明说等待期 90 天它非要补充一句不同产品可能有所不同建议咨询客服。听起来很负责任但用户要的是明确答案不是模棱两可的建议。后来我们改成了强约束 Prompt你是一个保险知识问答助手。请严格基于以下文档回答用户问题。 【重要规则】 1. 只使用文档中的信息不要添加额外推理 2. 如果文档中没有明确答案回复知识库中暂无相关信息 3. 不要说可能大概建议咨询等模糊表达 4. 引用文档时注明来源文档名称章节 文档内容 {检索结果} 用户问题{query}这样一改LLM 的自由发挥明显减少了。但还有一个问题——检索结果质量不稳定时LLM 怎么办置信度评估让 LLM 知道自己不知道我们加了一个机制——让 LLM 在生成答案的同时输出一个置信度分数1-5 分。response llm.generate(prompt \n\n请在答案末尾用【置信度X分】标注你的确定程度)如果置信度低于 3 分系统会自动触发二次检索——用改写后的 query 重新搜一遍或者降低召回阈值扩大检索范围。这个机制上线后答非所问的投诉率从 18% 降到 7%。RAG生成阶段控制策略如果我必须选一个RAG 最难的部分我会说最难的是让整个系统协同起来。你可以让每个模块都各司其职但要让它们协同到最优就需要你既懂算法又懂工程。比如你要同时考虑文档更新频率——知识库不是一次性导入就完事了。业务文档会更新旧版本要标记失效新版本要及时入库。我们的方案是每天凌晨跑一次增量更新脚本检测文档变化只对变化的部分重新 embedding。向量召回性能——5000 份文档还好说如果是 50 万份呢向量检索的延迟会线性增长。我们用的是 Milvus 的分区索引把文档按业务线分成多个分区检索时只搜相关分区速度提升了 3 倍。Prompt 格式——检索结果怎么拼到 Prompt 里也有讲究。如果直接把 5 个 chunk 平铺LLM 容易被前面的内容带偏。我们的做法是给每个 chunk 加序号和来源标签让 LLM 知道这是 5 段独立的信息不是一篇连贯的文章。模型响应速度——用户等不了 10 秒。我们做了两层优化一是对高频 query 做缓存相同问题直接返回缓存结果二是用流式输出LLM 生成一句就推送一句而不是等全部生成完。这些细节单独看都不难但要把它们串成一个稳定的系统需要大量的测试和调优。这也是为什么很多人能写出能跑的 RAG但写不出能上线的 RAG。面试中怎么聊 RAG 的难点如果面试官问你觉得 RAG 最难的是什么或者你的 RAG 系统遇到过什么坑可以这样组织先讲系统性思维。RAG 不是单点算法而是端到端的系统工程。每个环节看似简单但环环相扣任何一环的瑕疵都会导致答案质量下降。再讲具体的坑。数据准备阶段的切块策略、检索阶段的召回阈值调优、Query 理解阶段的意图识别、生成阶段的 Prompt 约束——每个环节都有具体的技术决策和权衡。然后讲量化指标。不要只说优化了检索要说召回准确率从 0.62 提升到 0.91。不要只说改进了 Prompt要说答非所问的投诉率从 18% 降到 7%。最后讲工程能力。RAG 的难点不只是算法还有文档更新、性能优化、缓存策略、监控告警。这些工程细节恰恰是面试官最想听到的。写在最后RAG 是所有大模型落地项目中最能体现算法工程师功底的模块。它要求你既能设计算法又能搭系统。既要懂 NLP又要懂数据库。既要能跑通 Demo又要能稳定上线。也许别人眼中这只是一个附属模块但真正懂的人都知道——RAG 是大模型落地的脊梁骨。它不花哨却决定成败。好用比能跑难十倍但也值十倍。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】