先说我自己的结论RAG 和大模型不是“二选一”的关系而是一条生产线上两种角色。大模型负责“想”RAG 负责“找”。很多人在刚开始接触这两者时会下意识地觉得 RAG 是某种大模型的分支甚至有人以为 RAG 就是“给大模型联网”——这都不准确。如果你正在搭知识库问答、做私有数据对话、或者刚把大模型接入业务系统却被“幻觉”问题折磨这篇文章就是给你准备的。我会从两者为什么必须配合的原因讲起拆一遍 RAG 的完整工作流程把索引、检索、生成这三个环节里最容易忽略的细节逐一点出来再拿 RAG 和微调、长上下文、传统检索引擎做一轮对比最后把我自己在落地过程中反复踩过、也帮别人排查过的坑整理成一份速查表。整个篇幅比较长但读完之后你至少能回答三个问题RAG 在哪个环节解决大模型的什么问题、大模型在 RAG 里到底发挥什么作用、以及当你遇到“答案不对”的时候应该去调哪一层。1. 大模型的先天不足RAG 的诞生原因1.1 大模型到底缺什么知识不是内存要理解 RAG先得接受一个事实大模型本质上是一个“语言推理引擎”不是一个“数据库”。训练过程确实让模型记住了大量参数但这部分记忆有几个天生的硬伤。第一是知识有截止时间。模型训练语料切到某个时间点之后新发生的事件、新发布的政策、新产品参数它一概不知道。哪怕模型再大你问它三个月前上线的新功能它也只能靠“脑补”给你编一个答案。第二是幻觉问题。因为大模型的生成机制是基于概率预测下一个词当它“不确定”时并不会老老实实说不知道而是会很流利地编一段听起来合理的答案。这在客服、医疗、法律这些对准确率要求极高的场景里是致命的。第三是私有数据隔离。企业内部文档、个人笔记、业务系统的订单数据根本不在大模型的训练语料里。你不可能把公司资料拿去训练模型就算可以训练成本和周期也不现实。这就是 RAG 出现的原因。它的核心思路特别直白不指望大模型记住所有知识而是在它回答之前先从一个外部知识库中检索出相关的片段塞进提示词里让大模型基于这些“现查到的资料”来作答。换句话讲大模型不需要“知道”它只需要“会读”。我习惯用一个类比来解释这个过程大模型像一位记忆力不太好但文字功底很强的顾问RAG 就像一位随时待命的资料员。你向顾问提问资料员先把相关档案翻出来放在他桌上顾问读完之后再组织语言回答你。没有资料员的顾问只能凭脑子里那点老记忆硬撑有资料员的顾问每次都能看到最新、最相关的材料。这两种角色的关系如果换成技术术语大模型负责的是“生成”RAG 负责的是“检索并增强上下文”。也就是说RAG 不是一个独立的新模型而是一种围绕大模型搭建的应用架构。你完全可以对 GPT 系列、开源的 Llama、Qwen 这类模型都套上 RAG效果差异主要取决于基座模型的理解能力而不取决于 RAG 本身。1.2 从“生成优先”到“检索增强”一个思路的转变RAG 这个概念在 2020 年由 Lewis 等人提出时论文标题叫《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。论文的核心思想其实已经点破了本质对知识密集型的 NLP 任务单靠参数记忆是不够的应该引入外部非参数记忆——也就是检索回来的文档。早期大家做问答系统主要靠两套方案一套是把文档直接拼到 Prompt 里硬喂给模型另一套是预先用模型微调让模型把知识“背”进参数。前者的缺点是上下文窗口有限塞不下大规模知识后者的缺点是每更新一次知识就要重新训练。RAG 把两者做了一个优雅的折中文档不用全塞进去而是用检索器从知识库里挑出最相关的几条模型也不微调它只负责读挑出来的内容并生成答案。后来 RAG 的发展又分出了很多分支比如 Self-RAG模型自己判断要不要检索、CRAG检索结果质量不高时做修正、HyDE先让模型生成一个虚拟答案再拿它去检索。但不管哪个变种底座仍然是“检索增强生成”这条主线。现在你听到的“RAG 知识库问答”“企业私有化部署的文档机器人”“PDF 对话”本质上都是这个框架的具体落地。这个思路对工程实践最重要的启发是RAG 的价值不在于让大模型变聪明而在于让大模型变“靠谱”。你不需要一个大而全的模型来背所有行业知识你只需要一个推理能力合格的模型配合一份维护得当的知识库。这也是为什么 RAG 框架能在一个不太大的本地模型上跑出不错效果的原因——检索兜底了知识模型专注推理两者的分工清晰了选型思路就宽了。2. RAG 核心工作流程逐层拆解2.1 索引环节知识库是怎么被“喂”进去的RAG 的第一步是把文档转成模型能用的形式这个环节叫索引。它的工作流程是加载文档、分块切分、向量化、写入向量数据库。每一步都有讲究草率处理的话后面检索质量会大打折扣。文档加载是最容易但最让人头疼的一步。PDF、Word、Markdown、网页这些不同格式的文档加载方式差异很大。PDF 里混合了扫描图片和文字层的需要 OCR表格信息多的要优先考虑转成结构化数据扫描件带水印的会干扰切分。我的建议是不要把加载器当成万能工具先检查源的格式质量。同样是 PDF文字版和扫描版的处理难度完全是两个量级。然后是分块切分这一步直接决定检索粒度。切得太粗一个块里包含多个主题向量化后语义平均化检索时匹配到“沾边但不精准”切得太细语义上下文断裂模型拿到的片段缺乏完整信息回答也不尽如人意。经验上我们通常用 300 到 500 个 Token 作为一个块的默认大小再配 50 到 100 的重叠区间。固定数字不是银弹中文场景还要考虑句号和段落边界。我现在做切分时会优先保证“一个块内至少讲完一个完整的小段落”在这个前提下再去调整块大小。向量化是这个环节里最核心的一步。它的作用是把文本变成一串数字数组语义相近的文本在向量空间里的距离也更近。常见的 Embedding 模型比如 OpenAI 的 text-embedding-3-small、开源的中文 BAAI/bge系列、智源的 text2vec 等各有各的适用场景。选 Embedding 模型时要看三个指标语义理解能力、向量维度带来的存储开销、对中文的支持程度。我的做法是拿自己领域里的一批典型问题跑一个小规模召回实验用 Top-K 命中率来判断哪个模型更合适。最后是写入向量数据库。向量数据库的任务是存储向量并支持快速近邻搜索。Milvus、Weaviate、Qdrant、Chroma、pgvector 都是常见选项。选型时主要看数据量几千条的小项目用 Chroma 或 pgvector 就够百万级以上的可以考虑 Milvus 或 Qdrant。这里提醒一个常被忽略的坑向量数据库只存向量和元数据原始文本要同步存一份。否则检索出来的结果只有坐标你没法把原文拼到 Prompt 里给大模型看。2.2 检索环节如何把“最相关的”捞出来索引完成后每次用户提问时系统要做的是把问题转成向量去向量数据库里做相似度搜索。这个阶段有四个关键词Embedding 对齐、Top-K、相似度阈值、重排序。Embedding 对齐是个隐蔽问题。如果文档向量化和查询向量化用的是同一个模型一般没问题但如果你接入了独立的检索服务或用了不同 Embedding 模型两边向量空间的含义就可能不匹配导致相似度分数失真。我见过不少项目因为查询用 A 模型、文档用 B 模型检索结果乱七八糟。所以建立索引和查询时务必保持同一个 Embedding 模型。Top-K 决定你要取出多少条内容给大模型。K 值太大会把不相关的噪音也塞进去干扰生成质量K 值太小又可能漏掉关键信息。一般默认 K4 到 5实际调优时我会先看这 K 条结果的置信度分布如果前 1 条得分明显高于后面几条K 可以缩小如果分数普遍接近说明知识库分块可能有问题或者问题本身太宽泛需要靠重排序来精排。相似度阈值是一道安全阀。很多 RAG 系统“没找到资料还硬答”的问题根源就是没设阈值。默认情况下向量检索总能返回 Top-K 条结果哪怕文档库里根本没有相关答案。解决方案是给相似度分数设一个底线低于 0.7 或 0.75 时不把结果交给大模型直接回复知识库中暂未找到相关信息。这里的阈值和模型分数体系相关不同 Embedding 模型的分数范围不一样得实测后确定不能盲抄网上的参数。重排序是我强烈推荐加的一步。向量检索擅长语义召回但在精细排序上不够聪明。重排序模型比如 bge-reranker 系列会逐条计算查询和候选文档的相关性分数把真正有用的排到前面。我做过一个实验不加重排序时RAG 回答准确率大约 70%加上重排序后提高到 85% 以上尤其是对一个查询可能涉及多个细碎知识点的行业场景效果非常明显。代价是多了一次模型推理增加几十毫秒到几百毫秒的延迟但这点代价在问答质量面前完全值得。2.3 生成环节大模型到底在扮演什么角色检索回来之后系统要把用户问题、检索得到的参考内容组装成一个新 Prompt交给大模型生成最终回答。这个环节很多人以为无所谓其实大模型的“人设”就是在这里被定义的。最基本的 Prompt 模板大概是这样的请根据以下资料回答问题。 资料 {{检索到的文本片段}} 问题{{用户问题}} 要求 1. 优先使用资料中的信息作答资料中没有的明确说不知道。 2. 回答中适当引用资料原文的关键表述保持语气自然。注意这里的关键要求模型“优先使用资料资料没有的明说不知道”目的是把幻觉的闸门关死。很多 RAG 效果不佳的案例就是因为 Prompt 没有强调约束模型要么自由发挥要么把无关资料强行揉进答案里。生成环节里大模型的温度参数temperature也要调低。我常用的范围是 0.1 到 0.3温度越低越保守输出就越贴近资料内容。如果把温度调成 0.7 以上即使资料再精准模型也可能在修饰措辞时偏离原意。此外引用来源也在这个环节实现。你可以要求模型在回答后附带参考文档编号比如“根据资料[1]和[3]”。这样做的价值不只是让用户看到出处更是方便你在调试时快速定位如果答案是错的你一眼就能看出它是检索没找对还是模型理解偏了。我自己维护的问答系统里每条回答都会带上参考来源的文档 ID 和片段位置排查问题时效率极高。整个流程跑完你可以看到一个清晰的职责划分索引和检索环节负责“找对资料”生成环节负责“读资料并说人话”。大模型在整个 RAG 结构里并不是全知全能的神而是被限定在“阅读理解语言组织”这个岗位上。明白了这一点你之后调试系统的思路就会很清晰——回答不对先查检索再查生成。3. RAG 和微调、长上下文、传统检索引擎的界限3.1 什么时候用 RAG什么时候该去微调这是我在社区里被问到最多的问题。我的回答很直接两者解决的问题维度完全不同。微调是改变大模型本身的行为方式和风格RAG 是给大模型补充外部知识。你可以微调一个模型让它说话更简洁、更有同理心、更符合公司客服语气但你没法靠微调让它记住你们公司 3 万份产品文档里的所有细节——不是做不到是性价比太低。微调适合的场景是有固定的输出格式要求、固定的业务指令、固定的语气风格。比如让模型学会从客户聊天记录里抽取结构化字段或者让它习惯用某种特定话术回复。RAG 适合的场景是知识频繁更新、知识面广且杂、对答案可解释性要求高。比如企业制度问答、产品手册客服、科研文献综述。两者也可以组合使用。我记得一个很典型的案例先用微调让模型学会行业术语的表达习惯再挂上 RAG 知识库提供实时业务内容。这样模型既懂行话又知道具体细节效果比单独用其中任何一项好得多。但要注意组合的调试复杂度会指数级上升新手建议先跑通 RAG再考虑微调。如果你在纠结“我的场景到底要不要微调”可以用一个问题来判断如果我把正确的知识直接写到 Prompt 里喂给模型它能不能给出正确的回答如果能那就不需要微调你需要的是 RAG如果不能说明模型本身的理解、指令跟随或格式能力不够这时才考虑微调。这个判断原则帮我省下了很多不必要的训练成本。3.2 现在上下文窗口大了RAG 还有必要吗近两年大模型上下文窗口一路从 4K 涨到 128K、200K 甚至上百万。很多人据此认为 RAG 会被“长上下文”取代——既然模型一次能读完一本书为什么还要检索这个观点看似有道理但落地时会撞上三面墙。第一面墙是成本。上下文越长Token 消耗越大成本线性上涨。你每次请求都传 50 万 Token 的资料推理费用普通项目根本扛不住。第二面墙是注意力分散。模型处理超长上下文时对信息密度低的内容很容易“遗忘”这就是业界常说的 lost in the middle 问题。就算模型宣称支持百万 Token实际在你需要的那个关键细节上它的表现可能还不如先把资料筛选到 2000 Token 再来得可靠。第三面墙是准确率。你可以做个简单实验把答案埋在一份 30 万 Token 的技术文档的中间部分然后问模型关键数据。你会发现它远不如从文档里抽出最相关三页再问来得准。所以我个人倾向于一种混合策略长文档先做切片和检索把相关内容压缩到一个较小的集合里再交给大模型。这本质上仍然是在做 RAG只不过“检索器”从向量数据库换成了滑动窗口加粗筛。长上下文的价值在于“能装下”RAG 的价值在于“知道该装什么”两者不太互相排斥。3.3 RAG 和 Wiki、Elasticsearch、知识图谱的边界还有一个常见混淆点RAG 和传统检索系统到底差在哪用 Wiki 站内搜索或 Elasticsearch 也能搜出文档为什么非要搞 RAG区别在于谁是消费方。传统检索系统的消费方是人人看了搜索结果自己能判断哪条有用RAG 的消费方是大模型模型需要的是“干净的、直接对应问题的文本片段”而不是一页有十几个超链接的列表。你完全可以拿 Elasticsearch 做 RAG 的检索引擎只要它能返回精准的文本切片就行。不少企业就是这么干的——ES 负责过滤关键词向量检索负责语义召回两者取并集再重排序。知识图谱则是从另一个维度补充 RAG它把实体和关系结构化地组织起来。比如问“A 公司的供应链上游有哪些”纯向量检索可能只能找到相关文档片段而知识图谱可以直接给出实体关系路径。RAG 框架也出现了 GraphRAG 这样的方案把知识图谱的构建和检索纳入 RAG 流程。但 GraphRAG 的构建成本高、维护复杂小项目慎入。所以我的建议是不要神化 RAG也不要把它修辞成一股颠覆一切的浪潮。它是一个工程架构解决的是“模型缺乏最新、私有、事实性知识”这一具体问题。真正聪明的做法是把 RAG、微调、传统检索引擎、知识图谱看成工具箱里的不同工具按场景组合使用。4. RAG 落地实操我踩过的坑和排查经验4.1 知识库到底能不能存图片和扫描件先说结论可以存但要看你怎么存。“RAG 知识库能存储图片吗”这个问题大概率是新手把“RAG”和“多模态”两个概念混在一起了。如果你使用的是纯文本 Embedding 模型那么图片本身是没法变成向量的你只能存图片的 OCR 文本或者图片描述。这种情况下用户提问时检索到的是图片对应的文字内容大模型回答时也不会真的“看到”图片。如果你用的是多模态大模型比如 GPT-4V 这类支持图像输入的模型和多模态 Embedding那么图片确实可以直接参与检索和生成。流程变成图片先被编码成向量查询时匹配到图片后把图片本身送给多模态模型生成描述或回答问题。这在实际中很常见比如产品说明书里的示意图、故障照片、设计稿等。实操层面的经验是不要为了“能处理图片”而硬上多模态它增加的是模型推理和向量存储的成本。绝大多数知识库场景OCR 提取文字常规 RAG性价比最高。遇到真的需要“理解图中字符结构”的场景——比如解读一张复杂的报表截图——再投入多模态。另外提醒一点扫描版 PDF 直接用文本加载器解析出来全是乱码先 OCR 再切分才是正解。4.2 切分参数、检索阈值和提示词的三联动如果你问一个 RAG 项目为什么效果欠佳九成问题不在大模型而在切分参数、检索阈值和提示词没对齐。这三个参数是一条链上的切分粒度影响检索能否命中、阈值决定要不要把结果交给模型、提示词决定模型怎么理解资料。我见过一个案例某团队的文档切块设成了 2000 Token结果一段文本同时包含产品参数和售后政策向量化后语义被平均掉了。用户问产品参数检索出来的块里包含更多售后内容的文本重排序也没救回来。后来把块切成 400 Token 加 80 重叠准确率立刻提升。切分参数最好结合文本结构来做——Markdown 标题、PDF 章节标记都可以当成切分边界而不是纯按 Token 硬切。阈值这种数字网上给的值只能参考。不同 Embedding 模型的相似度分数分布差异极大。我建议先跑 20 条已知答案的测试问题记录最低命中的分数把阈值设在这一分数再下探一点。这样做出来的阈值才是你自己的系统的合格线。提示词方面除了“资料中没有的不要编”还可以加上“如果资料与问题无关直接说明”避免模型强行把不相关内容拼成答案。这三个参数调好之后大部分 RAG 项目的效果都能达到“可上线”水平。如果还不行那就进入下一层排查看看是不是向量数据库里的脏数据太多。4.3 本地小模型做 RAG 的硬件与部署建议我还被问到过非常多的部署类问题“我的 8GB 内存电脑能用本地模型跑 RAG 吗”答案是能跑但要合理控制规模。本地部署 RAG 分为两部分Embedding 模型和大模型。Embedding 模型通常很小几百 MB 到 1GB 级别普通 CPU 跑起来没有压力。大模型要跑得动7B 级别以下加 4-bit 量化在 16GB 内存的机器上勉强可用8GB 内存就要考虑 3B 级别或更小的模型了。部署工具方面Ollama 是目前最省心的一站式方案拉模型、起服务都很方便。上线项目还可以搭配 vLLM 做高性能推理能显著提升吞吐。本地模型做 RAG 有一个优势数据不出内网安全可控也有明显劣势推理速度慢、生成质量不如商用大模型。建议你在测试阶段把“本地小模型重排序”作为默认组合质量控制效果后再逐步替换成更强大的生成模型。硬件优化方面有个细节容易被忽略Embedding 模型和大模型如果同时挤在同一块 GPU 上显存分配要提前规划。Embedding 占得不多大头是大模型的 KV cache 和参数权重。我习惯先用nvidia-smi观察两者峰值显存占用再决定要不要把 Embedding 模型单独部署到 CPU 上避免互相挤压导致推理直接 OOM。4.4 常见问题排查速查表为了你在排障时能少走弯路我把实践中高频遇到的问题整理成了一份速查表。你可以直接把它当成排查索引按图索骥。现象优先排查方向处理建议回答内容与资料明显无关向量化模型是否一致、切块粒度统一 Embedding 模型按语义边界切块资料库明明有答案却说找不到检索阈值是否设得太高、索引是否真正构建完成调低阈值重测检查向量库数据条数答案有资料支撑但生成乱编提示词约束不足、温度参数过高强化“没有就直说”约束temperature 降到 0.2每次回答速度很慢重排序模型延迟、上下文太长先确认是否多取了不必要的 Top-K再考虑模型显存是否不足检索结果很杂相关和不相关混着重排序缺失、知识库本身太乱加 reranker清理文档重复内容与无关文本客户端无论问什么回答都差不多检索逻辑被短路跑到了规则分支检查是否命中缓存的兜底话术确认检索真正执行了这张表的核心逻辑是分层排查先看索引构建、再看检索质量、最后看生成提示词。顺序反了容易白费力气——比如你反复调提示词却发现问题的根源是切出来的文本块本身就不相关。4.5 关于 RAG 知识库的维护一个容易被低估的短板最后想提醒一个容易被忽视的问题RAG 知识库需要持续维护。很多人把 RAG 想成“一次导入长期使用”这是犯了经验主义错误。文档会改版、产品参数会更新、政策会调整如果知识库里的旧内容不删检索结果会被过期信息污染。我建议每一步文档变更都走这样的流程新版本文档入库、旧版本标记过期但保留备份、同时记录变更时间。检索结果里如果出现两个版本的同名文档要确保新版本在向量空间中优先级更高。做到这一点的成本不高但能帮你规避“模型引用旧政策回答新问题”的尴尬。知识库的权限控制也同样容易被忽略。RAG 系统本质上是把你内部的文档共享给了大模型的推理过程如果你的知识库里有不同级别的保密文档检索时必须按访问者权限做过滤否则就会发生提问者凭 RAG 直接看到了他本不该看的内容。这个问题的严重程度近两年不少企业踩过跟头。根据我个人实际操作中的体会RAG 项目的成败往往不是大模型选得够不够好而是知识库整得够不够干净、检索链路够不够可靠。大模型在 RAG 里的角色就像一位能力很强的员工他帮你读材料、写总结但你得确保递到他手上的材料是对的。目录乱、版本杂、信息过期员工再能干也回答不出正确答案。最后再分享一个我自己的小习惯每次上线 RAG 系统之前我都会准备 30 到 50 条带标准答案的“验收问题集”覆盖知识库里的高频知识点和模糊问法。跑完一遍准确率达标后才交付。这个习惯救了我很多次也强烈推荐你试试。
