1. 先把话说透RAG 和大模型到底谁在给谁打工很多人第一次接触 RAG脑子里冒出来的画面是“给大模型外挂一个知识库”。这个理解不算错但太浅了。我做了几个企业级知识问答项目之后越来越觉得更准确的比喻是大模型是一个知识渊博但记性不太靠谱的顾问RAG 是给他配了一个随叫随到的资料员。顾问负责组织语言、推理逻辑、给出结论资料员负责在回答之前把相关的原始材料翻出来、递到顾问手边。顾问再厉害手边没资料也只能凭记忆瞎编资料员再勤快顾问不会总结递上去的也只是一堆散乱的文件。所以 RAG 的全称 Retrieval-Augmented Generation拆开看就是三个动作检索Retrieval、增强Augmented、生成Generation。检索是从你的私有资料里找相关内容增强是把找到的内容塞进大模型的上下文生成是大模型基于这些内容组织出人话。这三个动作里大模型只负责最后一步但很多人误以为大模型负责全部于是把所有问题都归咎于“模型不行”。实际上一个 RAG 系统答得烂八成问题出在检索环节而不是生成环节。这篇文章我想彻底把这两者的关系讲清楚它们各自负责什么、边界在哪里、怎么配合、配合不好会出什么问题。适合正在做 RAG 项目的人、准备选型的技术负责人以及被“大模型万能论”忽悠过、想搞清楚真相的开发者。读完你至少能判断一个问题该交给大模型还是该交给检索还是该交给两者之间的那层编排逻辑。2. 大模型的能力边界它到底能做什么、不能做什么2.1 大模型真正的强项是“语言组织”而非“知识存储”大模型最被低估的能力其实是语言理解和组织。你给它一段乱七八糟的文本它能提炼要点你给它一个模糊的问题它能改写成清晰的查询你给它几段互相矛盾的资料它能权衡后给出一个相对合理的表述。这些能力是传统检索系统完全做不到的。传统搜索引擎只能匹配关键词你搜“苹果”它分不清你要的是水果还是公司大模型能根据上下文判断这就是质的差别。但大模型的“知识”是训练时压缩进参数里的它有两个致命问题。第一是时效性训练数据截止到某个时间点之后发生的事情它一概不知。第二是私有性你公司内部的规章制度、产品文档、客户案例它训练时根本没见过。你问它“我们公司报销流程是什么”它要么说不知道要么一本正经地编一个流程出来。这就是所谓的幻觉Hallucination它不是故意骗你而是它在用语言能力填补知识空白。我见过太多团队踩这个坑以为把大模型接上就能回答内部问题结果上线第一天就被业务方投诉“胡说八道”。根本原因就是没搞清楚大模型的定位——它是一个推理和表达引擎不是一个数据库。2.2 上下文窗口不是万能药塞得越多反而越糟有人会说现在大模型上下文窗口都到 128K 甚至 1M 了直接把所有文档塞进去不就行了理论上可以实践上很坑。我实测过一个场景把 50 页产品手册全部塞进上下文问一个具体参数模型确实能答对但响应时间从 2 秒涨到 15 秒成本翻了十几倍。更麻烦的是当上下文里塞了大量无关内容模型的注意力会被稀释反而容易漏掉关键信息。这在学术上叫“Lost in the Middle”现象——模型对上下文开头和结尾的信息记得牢中间部分容易忽略。所以 RAG 的核心价值不是“让模型看到更多”而是“让模型只看到该看的”。检索环节的作用就是做减法从海量资料里筛出最相关的几段把宝贵的上下文窗口留给真正有用的信息。这个筛选质量直接决定了最终回答的质量。2.3 微调和 RAG 不是二选一而是解决不同问题经常有人问我想让大模型懂我的业务是该微调还是该上 RAG我的回答通常是先问你的需求是“改变说话风格”还是“补充事实知识”。微调Fine-tuning改变的是模型的行为模式——比如让它用你公司的口吻说话、按特定格式输出、学会某个领域的推理方式。RAG 补充的是模型的事实知识——比如最新的政策、内部的文档、私有的数据。打个比方微调像是送员工去培训让他学会你们公司的做事风格RAG 像是给他配了一台能随时查资料的电脑。培训一次成本高、周期长而且知识更新了还得重新培训查资料成本低、实时更新但前提是资料本身得整理好。实际项目里两者经常一起用先微调让模型学会输出格式和领域术语再用 RAG 给它喂实时数据。但如果预算有限、只能选一个优先做 RAG因为知识更新的需求远比风格调整更频繁。3. RAG 的工作流拆解一条链路上每个环节都在决定成败3.1 从文档到向量索引阶段决定了检索的天花板RAG 的第一步是把你的原始文档变成可检索的形式。这个过程叫索引Indexing包含几个关键动作文档解析、文本切分、向量化、存入向量数据库。很多人觉得这一步就是“跑个脚本”实际上坑最多。文档解析阶段PDF 里的表格、图片、页眉页脚都是噩梦。我遇到过一份产品规格书表格里的参数被解析成了一堆乱序的文字检索出来完全没法用。后来换了专门的解析工具把表格转成 Markdown 格式效果才正常。所以选型时一定要看你的文档类型纯文本用普通解析就行PDF 带复杂排版就得用能处理布局的工具扫描件还得先做 OCR。文本切分Chunking是另一个容易被忽视的环节。切得太碎一段完整的意思被拆散检索出来断章取义切得太大一个块里混了好几个主题向量表示被稀释检索精度下降。我的经验是中文文档按 300 到 500 字切分比较稳同时保留 10% 到 20% 的重叠避免边界处的信息丢失。如果是技术文档最好按标题层级切让每个块有明确的主题边界。3.2 向量化模型的选择不是越贵越好而是越匹配越好把文本转成向量Embedding的模型直接决定了语义检索的质量。市面上有大量选择从开源的 BGE、M3E 到各种商业 API。我的选型原则是先看你的语言和领域再看成本和延迟。中文场景下BGE 系列的开源模型表现相当能打本地部署没有 API 成本适合数据敏感的项目。但如果你的文档里有大量专业术语通用模型可能把“变压器”和“电压互感器”的向量算得很近因为它们字面相似但含义不同。这时候要么用领域数据微调 embedding 模型要么在检索后加一层重排序Rerank来纠正。重排序是我强烈建议加的一个环节。它的逻辑是先用向量检索快速召回 Top 50 个候选再用一个更精细的模型对这 50 个逐一打分选出真正最相关的 Top 5。这就像招聘先用关键词筛简历再人工细看。加了重排序之后我的项目里检索准确率普遍能提升 20% 到 30%代价只是多几百毫秒的延迟。3.3 检索策略单一向量检索远远不够纯向量检索有个盲区它对精确匹配不敏感。比如用户问“错误码 E5021 是什么意思”向量检索可能返回一堆讲错误处理的文档但就是漏掉那个专门讲 E5021 的条目。这时候需要混合检索Hybrid Search把向量检索和关键词检索如 BM25的结果融合既照顾语义相似又保证精确命中。融合的方式有几种一种是加权求和给两种检索结果各打一个分再合并另一种是倒数排名融合RRF只看排名不看分数对分数尺度不敏感实践中更稳。我一般用 RRF因为它不需要调权重换数据集也不用重新调参。还有一个进阶玩法是查询改写Query Rewriting。用户的问题往往口语化、有指代、信息不全直接拿去检索效果差。可以先让大模型把问题改写成几个更清晰的查询分别检索后再合并结果。比如用户问“那个新功能怎么开”大模型可以改写成“XX 新功能的开启方法”“XX 功能配置步骤”检索命中率会明显提升。4. 生成阶段大模型在 RAG 里到底该怎么用4.1 提示词设计决定了模型是“照抄”还是“总结”检索回来的内容怎么交给大模型直接决定了回答的风格。最简单的做法是把检索结果拼在问题前面加一句“请根据以下资料回答”。但这样模型容易变成“复读机”把原文照搬一遍甚至把不相关的内容也塞进回答。我的做法是在提示词里明确几个约束只根据提供的资料回答、资料里没有就说不知道、回答要简洁、引用来源。这四条看起来简单但能解决大部分幻觉和冗余问题。特别是“资料里没有就说不知道”这一条能大幅降低编造风险。有些团队怕说“不知道”影响体验但实际上一个诚实的“不知道”比一个自信的错误答案有价值得多。另外检索结果里难免有噪声可以在提示词里让模型先判断每段资料是否相关再决定用哪些。这相当于让模型做一次二次筛选虽然多花一点 token但回答质量更稳。4.2 上下文组装顺序和格式都有讲究检索回来的多个文本块怎么排列也有学问。前面提到“Lost in the Middle”现象所以最相关的块应该放在最前面或最后面不要埋在中间。我通常按相关性排序最相关的放开头次相关的放结尾中间放补充信息。格式上给每个块加上编号和来源标记方便模型引用也方便你排查问题。比如[资料1] 来源产品手册第3章 内容... [资料2] 来源FAQ 第12条 内容...这样模型在回答时可以说“根据产品手册第3章”用户一看就知道答案有据可查信任度会高很多。4.3 什么时候该让大模型“闭嘴”RAG 系统里有一个反直觉的设计原则不是每个问题都需要大模型生成。如果检索结果里有一个高度匹配的问答对直接返回标准答案可能比让模型重新组织更准确、更快、更便宜。我在客服场景里就这么做高频问题走预设答案长尾问题才走 RAG 生成。这样既保证了核心问题的准确率又控制了成本和延迟。判断标准可以设一个相似度阈值检索到的内容相似度超过某个值直接返回原文低于阈值才交给大模型。这个阈值需要根据你的数据和业务容忍度来调没有万能数字一般从 0.85 开始试。5. 实战中最容易踩的坑与排查思路5.1 答非所问先查检索再查生成RAG 回答不对第一反应往往是“模型不行换个更大的”。但我排查过几十个案例大部分问题出在检索环节。排查顺序应该是先把检索到的内容打印出来人工看一遍。如果检索内容里根本没有正确答案那换再大的模型也没用得回去优化切分、embedding 或检索策略。如果检索内容里有正确答案但模型没用那才是提示词或模型的问题。我整理了一个简单的排查表遇到问题按这个顺序过一遍基本能定位到根因现象可能原因排查动作回答完全无关检索没召回相关内容打印检索结果检查切分和 embedding回答部分正确检索召回了噪声加重排序调整 Top K回答编造信息提示词约束不够加强“不知道就说不知道”的约束回答太啰嗦提示词没限制长度明确要求简洁回答精确查询失败纯向量检索不敏感加关键词检索做混合响应太慢上下文太长或模型太大减少 Top K换小模型5.2 知识库更新了但回答还是旧的这是 RAG 项目上线后最常见的运维问题。原因通常是索引没有及时更新。文档改了但向量数据库里还是旧版本。解决办法是建立增量索引机制文档变更时触发重新切分和向量化只更新变化的块而不是全量重建。全量重建在数据量大时可能要好几个小时期间服务不可用体验很差。另外要注意删除逻辑。文档删了对应的向量也得删否则检索时还会召回已删除的内容。我见过一个项目因为没做删除同步用户问一个已经下线的功能系统还在拿旧文档回答闹了笑话。5.3 多模态内容怎么处理现在很多知识库里有图片、表格、流程图纯文本 RAG 处理不了。常见做法是用多模态模型给图片生成文字描述把描述文本一起索引。用户检索到相关描述后再把原图一起返回。这样虽然损失了一些细节但至少能命中。如果图片里的文字很关键可以先做 OCR 提取文字再和描述一起存。表格的处理更麻烦。我的经验是把表格转成 Markdown 或自然语言描述比如“产品 A 的重量是 2kg尺寸是 10x20cm”这样检索和生成都友好。直接存 HTML 表格模型理解起来很吃力。6. 几个实际项目里的经验之谈6.1 小模型加好检索往往打赢大模型加烂检索我做过一个对比实验同一个知识库方案 A 用大参数模型加基础向量检索方案 B 用中等模型加混合检索加重排序。结果方案 B 的准确率高出近 15 个百分点成本还低了一半。这个结论让我彻底放弃了“模型越大越好”的执念。RAG 系统是一个整体检索质量是木桶的底板底板漏了上面装再大的模型也白搭。6.2 评估体系比调参更重要没有评估调优就是盲人摸象。我建议项目一开始就建一个评测集收集 100 到 200 个真实问题人工标注正确答案每次改动后跑一遍看准确率、召回率、延迟的变化。这样你才知道某个改动是真的有效还是只是碰巧。评测集不用很大但要有代表性覆盖高频问题和边界情况。6.3 别忽视用户体验的细节技术上再牛用户用起来别扭也是失败。几个小细节很影响体验回答里标注来源让用户能点进去看原文检索不到时给一个友好的提示而不是硬编一个答案响应时间超过 3 秒要有加载状态。这些不是核心技术但决定了用户愿不愿意继续用。6.4 关于本地部署和成本很多团队关心本地部署。我的建议是如果数据敏感、查询量大、有运维能力本地部署划算否则先用 API 快速验证跑通了再考虑迁移。本地部署的隐性成本不低显卡、电力、运维人力、模型更新都要算进去。我见过团队为了省 API 费用自己部署结果运维成本远超预期得不偿失。选模型时也别只盯着参数规模。7B 到 14B 的模型在 RAG 场景下配合好的检索和提示词效果往往够用推理速度和成本却友好得多。先用小模型跑通流程确实遇到能力瓶颈再换大的这是更稳妥的路径。7. 把 RAG 和大模型的关系想清楚项目就成功了一半回到最开始那个比喻大模型是顾问RAG 是资料员。顾问再聪明资料员递错材料回答就是错的资料员再精准顾问不会总结用户也看不懂。两者是协作关系不是替代关系。大模型负责理解和表达RAG 负责提供事实依据中间的编排逻辑负责把两者接好。我现在的习惯是每做一个 RAG 项目先花时间把检索链路打磨好再考虑模型选型和提示词优化。因为检索是地基地基不稳上面盖什么都是危房。等检索准确率上去了你会发现很多所谓的“模型能力问题”自动消失了。最后分享一个我常用的自检方法随便挑一个业务问题手动走一遍完整流程——从文档里找到答案、切分成块、看检索能不能召回、看模型怎么组织回答。走通一遍你就知道瓶颈在哪了。这个方法比看任何文档都管用因为它是你自己的数据、你自己的场景骗不了人。