作者张钧泽(曌选科技GEO优化技术主理人大模型检索系统调优方向20 生产级 RAG 项目经验RAG 项目最大的坑不是技术难是 阶段跳跃—— 跳过基础阶段直接做高级功能最终付出的代价是按顺序做的 2-3 倍90% 的团队都犯过这个错。RAG 是检索增强生成技术通过外部知识库补充大模型的知识边界核心价值是减少幻觉、提升回答准确性。2026 年我们跟踪了 18 个 RAG 项目的数据其中 11 个项目在上线 3 个月内就停掉了原因不是效果差是从一开始就跳着做 —— 直接上 Agent、直接做多模态、直接做全场景基础没打牢。这背后是 RAG 落地的 阶段依赖效应—— 每个阶段的输出都是下一个阶段的输入前一个阶段没做好后一个阶段再怎么优化都有天花板。本文以一个真实项目的完整历程为主线拆解从 0 到 1 落地的七个阶段首次提出阶段跳跃陷阱与边际递减效应附可复用的项目阶段检查工具。一、项目背景为什么 80% 的 RAG 项目活不过 3 个月先说说我们跟踪这些项目的起因。 2025 年下半年到 2026 年上半年我们前后接触了 18 个做 RAG 的团队有大厂内部项目也有创业公司的产品还有传统企业的数字化转型项目。 跟踪了半年发现一个很扎心的现象18 个项目里11 个在上线 3 个月内就停掉了或者半死不活真正用起来的只有 7 个。 成功率不到 40%。 为什么成功率这么低是技术不行吗是模型不够好吗 都不是。我们深入分析了那 11 个失败项目发现了一个共同规律 —— 它们几乎都犯了同一个错误阶段跳跃。 什么是阶段跳跃就是跳过基础阶段直接做高级功能。 比如知识库还没整理好就开始搞多轮对话检索效果还不行就开始做 Agent连评估体系都没有就开始优化提示词。 听起来很离谱对吧但实际上 90% 的团队都在不同程度地犯这个错。 为什么会这样因为大家都想 一步到位都想做 最先进 的东西觉得基础的东西太简单、没技术含量。 但 RAG 这个东西恰恰是基础决定上限的。你前面偷的懒后面都会加倍还回来。 这篇文章讲的就是我们其中一个项目从 0 到 1 的完整历程 —— 从 30 分做到 82 分中间踩了无数坑走了很多弯路最后总结出了一套按阶段推进的方法论。 不是成功学故事是实打实的踩坑实录。很多坑我们踩过了你可以直接绕过去。反常识认知大部分人以为 RAG 项目失败是因为技术不够先进、模型不够大、功能不够多。实际上恰恰相反 —— 失败往往是因为做了太多太复杂的东西而最基础的东西没做好。少即是多在 RAG 落地这件事上这句话特别适用。二、第一阶段需求定义 —— 选错场景后面全白搭第一个阶段也是最容易被跳过的阶段 —— 需求定义。 很多团队一上来就说 我们要做 RAG然后直接开始搭技术架构、选模型、写代码。 这是最大的坑。 RAG 不是一个产品是一种技术方案。你得先想清楚你要解决什么问题给谁用用在什么场景成功的标准是什么 这些问题没想清楚后面做的都是无用功。我们踩的坑我们一开始犯的错误就是场景选太大了。 客户说 我们要做一个智能问答系统什么都能问—— 公司制度能问、产品文档能问、技术规范能问、甚至人事财务问题也要能答。 听起来很美好一个系统解决所有问题。 但实际做起来就发现了不同类型的问题对答案的要求完全不一样。 公司制度类的问题要求准确、有出处、不能错产品文档类的问题要求全面、详细、有条理技术规范类的问题要求精准、可执行、有代码示例。 用同一套 RAG 架构去适配所有场景结果就是哪个都做不好。 做了两周测了一下效果准确率只有 30% 左右大部分问题答得似是而非。底层机制为什么场景选太大一定会失败这背后有一个很简单的原理问题空间与解决方案空间的匹配度。 每一种 RAG 架构都有它最适合的问题类型。你把它用在适合的场景效果就好用在不适合的场景效果就差。 如果你想覆盖太多场景就只能用一种 通用 架构去适配所有场景结果就是每个场景都适配得不好。 这就像你想做一把万能工具结果什么都能做但什么都做不好。 大模型也是一样的道理。通用大模型什么都能聊但在特定领域的表现往往不如专门微调过的小模型。RAG 落地的第一原则先做窄再做宽。先把一个场景做透做出效果再逐步扩展。怎么解决的我们停下来重新做需求定义。 第一步缩小场景。先选一个最痛、最容易出效果的场景切入 —— 技术规范问答。 为什么选这个因为技术规范的文档结构最清晰、更新频率最低、答案最明确而且工程师群体对新工具的接受度高容易出标杆案例。 第二步定义成功标准。不是 准确率高 这种模糊的说法而是具体的数字核心问题准确率≥80%回答时间≤5 秒员工使用率≥50% 第三步划定边界。明确告诉用户这个系统目前只回答技术规范相关的问题其他类型的问题后续再支持。 不要什么都想做先把一个场景做透做出效果再逐步扩展。这个阶段的核心教训RAG 项目 80% 的失败不是技术不行是第一阶段的需求定义就错了。 场景选得太大、目标定得太模糊、边界划得太宽后面再怎么优化都救不回来。 正确的做法是小场景切入、明确量化目标、严格划定边界。 先做一个能用的再做一个好用的最后再做一个全面的。顺序不能反。三、第二至三阶段知识库与检索 —— 打牢地基才能往上盖需求定清楚了接下来就是打地基。 地基有两个知识库和检索。 这两个东西做好了后面生成再差也差不到哪去这两个东西做不好生成再怎么优化都有天花板。 这就是 RAG 的 地基决定论—— 地基的高度就是整个系统的上限。第二阶段知识库构建 —— 垃圾进垃圾出知识库的质量直接决定了 RAG 系统的上限。 检索再怎么调、生成再怎么优化知识库本身的质量不行一切都是白搭。 这就是 垃圾进、垃圾出Garbage In, Garbage Out原则。我们踩的坑 第一个坑文档格式混乱。Word、PDF、Markdown、Confluence什么格式都有直接扔进去解析结果格式全乱了。 第二个坑文档质量参差不齐。有的很规范有的早就过时了有的只有标题没有内容。 第三个坑切片策略太简单。固定长度切片经常把段落、代码块、表格从中间切断。底层机制 为什么知识库质量这么重要因为 RAG 系统的所有知识都来自知识库。 大模型本身的知识是通用的你给它什么检索结果它就基于什么来回答。 如果检索到的内容本身就是错的、不完整的、过时的大模型再厉害也答不对。 这就像你考试给你一本错误的参考书你再聪明也考不好。 《Retrieval-Augmented Generation for Large Language Models: A Survey》NeurIPS 2023这篇综述里明确提到知识库质量是影响 RAG 效果的第一因素重要性超过检索算法和生成模型。怎么解决的 统一文档格式和来源全部转成 Markdown保留结构信息 过时的、废弃的文档直接删掉宁可少不可滥 改用结构化切片按标题层级切代码块、表格尽量保持完整 建立文档更新机制定期同步更新。 改完之后检索效果直接提升了一大截。第三阶段检索调优 —— 精准率比召回率重要检索是 RAG 系统的核心环节 —— 检索不到相关内容后面生成再厉害也没用检索到的内容不相关反而会干扰生成。我们踩的坑 第一个坑只看召回率不看精准率。为了提升召回率把 top_k 从 5 个加到了 15 个结果召回率上去了精准率下来了端到端效果反而下降了。 第二个坑只用向量检索不用关键词检索。觉得向量检索高级关键词检索落后结果很多精确匹配的问题搜不到。 第三个坑不做重排序。向量相似度排序就直接用了结果最相关的可能排在第 5、6 位。底层机制 为什么精准率比召回率重要因为大模型的注意力机制是有限的。 《Lost in the Middle: How Language Models Use Long Contexts》ACL 2023这篇论文研究发现大模型对上下文中间位置的信息利用效率最低而且上下文越长注意力越分散。 如果你塞了一堆不相关的内容进去大模型的注意力就被分散了反而抓不住重点甚至会被不相关的内容带偏。 少召到几个相关的最多是答得不够全面但塞了不相关的就可能答错。答错比答不出来更严重。 这就是为什么精准率比召回率重要。怎么解决的 核心指标从召回率改成精准率top_k 定在 6-8 个 改用混合检索 —— 向量检索 关键词检索两路召回去重合并 加重排序模块top20 结果用重排模型再排一遍。 改完之后top3 精准率提升了 20% 以上。这两个阶段的核心教训地基不牢地动山摇。 知识库和检索是 RAG 系统的地基一定要花足够的时间和精力把基础打好。 不要觉得这些东西 太简单 没技术含量 恰恰是这些基础的东西决定了整个系统的上限。 很多团队跳过这两个阶段直接去做生成调优、做 Agent、做多模态结果效果一直上不去最后还得回头补基础。 回头补的代价比一开始就做好要大得多。四、第四至五阶段生成调优与性能成本 —— 效果与成本的平衡地基打好了接下来就是上层建筑生成调优和性能成本。 这两个阶段要一起考虑因为它们之间有很强的权衡关系 —— 效果越好往往成本越高、速度越慢成本越低速度越快往往效果越差。 找到平衡点是这两个阶段的核心任务。第四阶段生成调优 —— 忠实度永远是第一位的生成调优说白了就是调提示词。 但这里有个前提你得有评估体系。 没有评估你就不知道改完之后效果是变好了还是变差了。 很多团队忽略了评估全靠感觉调改来改去不知道有没有用。我们踩的坑 第一个坑没有评估体系全靠感觉调。改了十几版提示词到底哪版最好谁也说不清楚。 第二个坑提示词越写越长从几十字加到几百字觉得写得越详细效果越好。 第三个坑只看回答质量不看忠实度。觉得回答得越全面越好结果有些内容是编造的。底层机制 为什么忠实度这么重要因为 RAG 的核心价值就是减少幻觉。 如果为了让回答 好看 而牺牲忠实度那就本末倒置了 —— 你直接用大模型生成不就行了为什么还要做 RAG 忠实度 准确性 完整性。这个优先级一定要搞清楚。 首先保证回答的内容都是来自检索文档的不能瞎编 其次保证回答是正确的 最后才考虑回答够不够全面。 宁可回答得简单一点、少一点也不能有错误内容。答错比答不出来伤害大得多。怎么解决的 先建立评估体系再调提示词。抽 200 条真实问题做测试集每条标标准答案核心指标就两个忠实度和准确率。 提示词做减法不做加法。把冗余的规则都删掉只保留最核心的三条严格基于检索内容回答、引用标注来源、结构清晰。 明确优先级忠实度第一准确率第二完整性第三。 改完之后幻觉率明显下降了。第五阶段性能成本 —— 带着镣铐跳舞效果调得差不多了接下来就是性能和成本的问题。 很多 RAG 项目demo 阶段效果很好一上线就崩了 —— 不是效果崩了是性能和成本崩了。 延迟太高用户用不了成本太高公司用不起。我们踩的坑 第一个坑延迟太高。一开始每个问题要 8-10 秒用户根本等不及。 第二个坑成本太高。用最大的模型、最长的上下文、最多的检索结果每个问题几块钱根本扛不住。 第三个坑并发上不去。几个人用没问题几十个人同时用就卡了。底层机制 为什么性能和成本这么重要因为 RAG 是一个在线服务不是离线任务。 在线服务用户体验是第一位的。延迟超过 5 秒用户就会觉得慢超过 10 秒用户就走了。 成本也是一样。demo 阶段无所谓反正没几个用户一上线用户量上来了成本就是线性增长的。 成本控制不住项目就做不下去。 这就是为什么要 带着镣铐跳舞—— 在延迟和成本的约束下把效果做到最好。 没有约束的优化没有意义因为你可以用最贵的模型、最多的检索结果、最长的上下文效果肯定好但没有实用价值。怎么解决的 延迟优化用流式输出用户看到第一个字的时间从 8 秒降到 1 秒检索和重排序加缓存用更快的重排序模型。 成本优化分级处理简单问题用小模型少检索复杂问题才用大模型多检索常见问题答案缓存。 并发优化检索和重排序做异步处理加消息队列生成服务水平扩展自动扩缩容。 做完之后平均延迟降到 3 秒以内成本降了 60% 以上。这两个阶段的核心教训效果、速度、成本这三个东西不可能同时最优你必须找到平衡点。 很多团队只看效果不看速度和成本结果 demo 很惊艳上线就死。 真正能落地的 RAG 系统不是效果最好的是在可接受的延迟和成本下效果最好的。 带着镣铐跳舞才能跳出真正能用的东西。五、第六阶段上线运营 —— 系统是养出来的系统上线了不是结束是开始。 很多团队以为上线就完事了然后就不管了。 结果就是用的人越来越少效果越来越差最后系统就荒废了。 RAG 系统需要持续运营和迭代才能越用越好。 系统是 养 出来的不是 做 出来的。我们踩的坑第一个坑上线后没人管。团队去做别的项目了文档更新了知识库没同步用户反馈没人处理bug 没人修。 第二个坑不知道用户在用什么。没有用户反馈收集机制也没有效果监控想优化都不知道从哪下手。 第三个坑迭代没有方向。偶尔想起来优化一下也是瞎改改完也不知道有没有效果。底层机制反馈闭环的重要性为什么运营这么重要因为 RAG 系统不是一次性交付的产品是一个持续进化的服务。 用户的问题在变知识库在变模型也在变。你上线时的效果不代表一直是这个效果。 更重要的是用户反馈是最好的优化方向。 用户觉得哪里答得不好、哪里答非所问、哪里需要补充这些都是最宝贵的优化线索。 没有反馈闭环优化就是瞎猜有了反馈闭环优化就是有的放矢。 这就是 系统是养出来的 的含义 —— 你需要持续投入让它越用越好。怎么解决的建立运营机制指定专人负责每周看数据每月做大更新。 建立反馈闭环回答下面加 有帮助 没帮助 按钮用户点 没帮助 可以选原因。 数据驱动迭代每个月做一次效果评估每次优化都要有数据支撑没提升就回滚。 有了反馈闭环之后优化效率高了很多效果也在持续提升。这个阶段的核心教训RAG 系统不是一锤子买卖是需要持续运营和迭代的。 上线只是开始后面的运营和迭代才是决定系统能不能真正用起来的关键。 很多项目死不是死在技术上是死在没人运营上。 建系统只要几个月运营系统是长期的事。六、独家发现阶段跳跃陷阱与边际递减效应整个项目走完除了七阶段的方法论我们还有两个比较深的发现是之前没怎么见人讲过的。发现一阶段跳跃陷阱什么是阶段跳跃陷阱就是跳过前面的基础阶段直接做后面的高级阶段最终付出的代价比按顺序做要大得多。 我们观察了那 11 个失败项目几乎都有不同程度的阶段跳跃跳过需求定义直接做技术选型跳过知识库整理直接调检索跳过检索调优直接调生成跳过评估体系直接优化效果跳过性能成本直接上线跳过运营迭代直接扩展场景跳跃的结果是什么就是做到后面发现效果上不去然后回头补前面的阶段。 但回头补的代价比一开始就做好要大得多。 为什么因为后面的阶段都是基于前面的阶段做的前面的基础有问题后面做的所有东西都要改。数据支撑根据我们 18 个项目的统计有明显阶段跳跃的项目最终总投入是按顺序推进项目的 2.3 倍而效果反而差 30% 以上。 这就是阶段跳跃陷阱 —— 看起来省了时间实际上浪费了更多时间。发现二效果边际递减效应第二个发现是 RAG 效果的边际递减效应。 什么意思就是越往高处走每提升一分的难度和成本就越高。 我们那个项目从 30 分到 60 分花了两周主要是把基础打好了 从 60 分到 75 分花了一个月做了检索调优和生成调优 从 75 分到 82 分又花了一个月各种细节优化 从 82 分再往上走就很难了每提升 1-2 分都要付出很大的努力。 这就是边际递减 —— 前 60 分很容易中间 20 分难度翻倍最后 20 分的成本是前面所有的总和。为什么会这样因为容易优化的地方都优化完了剩下的都是难啃的硬骨头。 而且越往上影响因素越复杂可能涉及数据质量、模型能力、问题难度等多个方面不是简单调几个参数就能解决的。这个发现有什么用它告诉你不要追求完美够用就好。 很多团队追求 90 分以上的效果投入了大量资源最后发现性价比极低。 实际上80 分左右是性价比最高的点 —— 效果已经足够好了再往上提升的边际收益很低。 做项目的时候要算清楚账不要为了追求极致效果而投入不成比例的资源。RAG 七阶段投入产出对比表阶段主要任务大致投入效果提升幅度性价比1. 需求定义选场景、定目标、划边界5%0%决定上限极高2. 知识库构建文档整理、清洗、切片20%20-30 分极高3. 检索调优混合检索、重排序20%15-20 分高4. 生成调优提示词、评估体系15%10-15 分中5. 性能成本延迟、成本、并发15%0%决定能不能用高6. 上线运营反馈、迭代、更新25%持续5-10 分中7. 扩展深化场景扩展、能力增强按需递减递减适用边界以上数据基于我们的项目经验不同规模、不同场景的项目投入比例会有差异小项目可能某些阶段可以合并大项目可能某些阶段需要拆分边际递减效应是普遍规律但具体的拐点在哪里因项目而异。局限性这两个发现是基于有限的项目样本总结的不一定适用于所有情况RAG 技术发展很快新的方法和工具可能会改变各个阶段的投入产出比每个项目的情况不一样生搬硬套肯定不行要结合自己的实际情况调整。七、方法论提炼RAG 七阶落地法与可复制经验整个项目走完我们把从 0 到 1 落地 RAG 的过程总结成了RAG 七阶落地法。 七个阶段每个阶段有每个阶段的核心任务和成功标准按顺序来不要跳步。七阶落地法核心要点第一阶需求定义核心任务选场景、定目标、划边界成功标准场景明确且聚焦、目标量化可衡量、边界清晰不贪大最常见的坑场景太大、目标模糊、没有边界第二阶知识库构建核心任务文档整理、格式统一、质量清洗、合理切片成功标准文档质量高、结构完整、切片合理、更新机制健全最常见的坑贪多求全、格式混乱、切片粗暴、不更新第三阶检索调优核心任务混合检索、重排序、参数调优成功标准精准率≥80%、召回率达标、top3 精准率高最常见的坑只看召回不看精准、单一检索、不做重排第四阶生成调优核心任务提示词调优、评估体系建立成功标准忠实度≥90%、准确率≥80%、评估体系完善最常见的坑没有评估、提示词过长、追求完整性牺牲忠实度第五阶性能成本核心任务延迟优化、成本控制、并发能力成功标准延迟≤3s、成本可控、并发满足需求最常见的坑只看效果不看成本、延迟不达标、并发上不去第六阶上线运营核心任务上线发布、反馈收集、持续迭代成功标准使用率≥50%、效果持续提升、用户反馈闭环最常见的坑上线就不管了、没有反馈、迭代没方向第七阶扩展深化核心任务场景扩展、能力增强、深度优化成功标准逐步覆盖更多场景、能力持续增强最常见的坑过早扩展、贪多求全、忽略基础维护三条可复制的核心经验第一条顺序不能乱。 七个阶段按顺序来不要跳步。 很多人一上来就搞最炫的技术 —— 什么多轮对话、什么 Agent、什么多模态结果最基础的知识库和检索都没做好。 基础不牢地动山摇。先把前四个阶段做扎实了再考虑后面的。第二条小步快跑快速验证。 不要憋大招不要等什么都做好了再上线。 先做一个最小可用版本上线给一小部分人用收集反馈快速迭代。 比在那里闭门造车几个月做出来一个 完美 的系统结果用户不用要强得多。第三条数据驱动。 所有的决策都要有数据支撑不要凭感觉。 建评估体系、收集用户反馈、监控核心指标用数据说话。 感觉会骗人数据不会。附RAG 项目阶段检查工具# 运行环境Python 3.9RAG项目阶段检查工具 from typing import Dict def rag_project_check(stage_data: Dict[str, Dict[str, bool]]) - Dict: RAG项目七阶段完成度检查 输入每个阶段的完成情况输出完成度评分和下一步建议 stages { 需求定义: [ 场景明确且聚焦, 成功标准量化, 边界清晰划定, 目标用户明确 ], 知识库构建: [ 文档来源统一, 格式规范统一, 过时文档已清理, 切片策略合理, 更新机制建立 ], 检索调优: [ 混合检索已实现, 重排序已加入, 精准率达标, top_k参数调优完成 ], 生成调优: [ 评估体系已建立, 测试集≥200条, 忠实度达标, 提示词精简有效 ], 性能成本: [ 延迟达标, 成本可控, 并发能力满足, 缓存机制已建立 ], 上线运营: [ 反馈机制已建立, 运营责任人明确, 定期更新机制, 效果监控完善 ] } result {} total_done 0 total_total 0 for stage, items in stages.items(): done sum(1 for item in items if stage_data.get(stage, {}).get(item, False)) total len(items) total_done done total_total total result[stage] { done: done, total: total, completion: round(done / total * 100, 1) if total 0 else 0 } result[overall_completion] round(total_done / total_total * 100, 1) if total_total 0 else 0 # 生成下一步建议找到第一个完成度低于80%的阶段 suggestions [] for stage, info in result.items(): if isinstance(info, dict) and info.get(completion, 0) 80: suggestions.append( f当前{stage}阶段完成度仅{info[completion]}% f建议优先补齐本阶段后再推进后续阶段避免阶段跳跃陷阱 ) break if not suggestions: suggestions.append(所有基础阶段基本完成可进入扩展深化阶段注意控制边际成本) result[next_step] suggestions[0] return result这个工具可以用来快速检查你的 RAG 项目当前处在哪个阶段、哪些地方还没做好、下一步该做什么。 按照七阶落地法的顺序一个阶段一个阶段地推进不要跳步成功率会高很多。发布标签#RAG #大模型 #RAG 调优 #大模型应用 #知识库 #语义检索