上周同事拉我进一个项目会，客户的需求听着倒简单：企业内部一堆产品文档、售后记录、质检报告，想做个问答系统，让员工用自然语言直接问。会开完了，技术选型不出意外地吵了起来——有人要微调，有人喊上RAG，还有人觉得干脆把文档拼进Prompt喂给大模型就行。

其实这种场景我见过很多次，大部分团队折腾半天，最后发现问题的核心不是“用哪个技术”，而是根本没搞明白RAG和大模型之间到底是怎么配合的。很多人把RAG当成了一个独立的东西，好像它是大模型的平替；也有人觉得RAG就是“给大模型加个记忆”，但这说法太含糊，差得远。

我这篇文章不打算按“什么是RAG—RAG的流程—RAG的优缺点”这种课件结构写，那些资料一搜一大把。我想换个角度，从“大模型自身的能力边界在哪、RAG恰好补上了哪一块、两者在一条完整链路里各自扛什么活、以及你落地时会撞上的那些真实问题”这几个层面来讲。你会看到RAG其实是一个相当务实的工程方案，而不是什么玄乎的新模型。等把这层关系捋顺了，后面做技术选型、调优、甚至是说服团队，你都会心里有底。

1. 先搞懂一件事：大模型为什么需要RAG这个“外挂”

要理解RAG和大模型的关系，前提是得先承认一个事实：大模型本身有硬伤。我不是说它不好，而是它天生就有几个绕不过去的边界。

第一个边界是知识时效性。一个模型在训练完成后，它的参数里装的知识就“定格”了。哪怕你用的是当前最新最强的模型，它脑子里的信息也只是截止到某个训练时间点。今天是9月，你问它上周发布的某个新产品条款，它要么答不上来，要么一本正经地编一个答案。这在后端圈子里有个叫法——幻觉，但幻觉的本质其实不是模型“想撒谎”，而是它在知识盲区里被迫自圆其说。

第二个边界是私有知识的隔离。企业内部文档、行业规范、项目沉淀，这些内容根本不会出现在公开语料里。大模型训练再充分，也学不到你们公司那套内部系统怎么对接。这就意味着，如果你直接拿一个通用大模型去做企业问答，它对你公司的事几乎一无所知。这种情况不是靠“问得更清楚”能解决的。

第三个边界是容量和注意力。哪怕你愿意把文档全塞进Prompt里，大模型的上下文窗口也不是无限的。硬塞进去的后果有两个：一是费用成倍往上翻，二是真正关键的信息会被淹没在长文本里，注意力机制会“稀释”掉重点，回答质量不升反降。我见过有人把一整本操作手册塞进去，结果模型抓了一个根本不重要的细节当成重点来回答。

这三个边界合在一起，就构成了RAG存在的理由。RAG的英文全称是Retrieval-Augmented Generation，检索增强生成，翻译成人话就是：在模型生成回答之前，先从一个外部知识库里把相关的片段捞出来，作为参考资料提供给模型。大模型本身不懂你们公司的业务，没关系，RAG负责把相关文档送到它嘴边。

所以说到这儿，第一层关系就很清楚了：大模型是那个“思考者”，负责组织和生成语言；RAG是那个“资料员”，负责从外部存储里找到可用的素材递上去。两者不是替代关系，是分工关系。你甚至可以这样理解——大模型是一个读了万卷书但从来没有出过门的学者，RAG是那个学者身边的助理，每次回答问题前先跑去档案室里翻出对应的资料，学者再基于资料给出一个像样的回答。

这个设计思路最大的优点，是不需要改动大模型本身。你不用重新训练它，不用动它的参数，你只需要在外面搭一圈检索逻辑，就能让一个通用模型变成“懂你们公司业务”的专用助手。这也是为什么RAG在这两年迅速普及的根本原因——它是在不动大模型的前提下，用最小成本扩展大模型能力边界的最佳方案。

2. 拆开RAG这条链路：索引、检索、生成，每一环到底在做什么

关系说清楚了，下一步得钻进细节里。RAG不是单指某一个操作，而是一条完整的链路，一般拆成三个阶段：索引阶段、检索阶段、生成阶段。每个阶段都有自己的技术选型和容易踩的坑，我一个个说。

2.1 索引阶段：把文档变成机器能快速查找的“卡片”

索引阶段的任务，说白了就是给大模型做一个可以快速检索的外部知识库。原始文档是PDF、Word、Markdown，甚至可能是扫描件，这些格式模型没法直接高效检索，必须做预处理。

第一步是文本抽取。PDF要解析出文字，扫描件得走OCR。这一步听着简单，实际最脏最累。我处理过不少客户给的PDF，看着是文本型，结果里面混着大量表格、页眉页脚、多栏排版，随便用个开源库一抽，文本顺序全乱。一个成熟的RAG项目在索引阶段付出的工作量，往往比后面检索和生成加起来还多。很多团队RAG效果差，不是检索算法不行，而是文档源头就没处理好。

第二步是切块。这是RAG里非常重要的一个环节。你要把长篇文档切成一个个小块，让每个块尽量是一个语义完整的内容单元。切得太大，检索出来不精准，还容易超出模型的上下文限制；切得太小，单个块的信息不完整，语义碎片化，模型拿着碎片也拼不出答案。常规做法是按固定字符数切，比如每块500字符、相邻块重叠50字符，这样能减少正文被拦腰截断的概率。

切块这块没有万能参数，完全取决于你的文档类型。技术文档可以按标题结构切，法律合同按条款切，代码库按函数切。想省事可以先用固定大小跑通流程，后续再根据检索效果调优，别一开始就在切块策略上过度纠结。

第三步是向量化。每一块文本通过一个嵌入模型（Embedding Model）转换成向量。这个向量就是这块内容的语义指纹。为什么要转成向量？因为后续检索要做相似度计算，而向量空间里的距离能反映语义上的接近程度。比如“如何申请年假”和“年假申请流程”这两句话，字面上不完全一致，但在向量空间里离得很近，模型就能把它们关联起来。这一步做完，你就有了一个向量化之后的知识库，一般存进向量数据库，比如常见的Milvus、Qdrant、Chroma、pgvector，为后面的检索做好了准备。

2.2 检索阶段：从知识库里捞出最相关的内容

检索阶段做的事，是把用户的提问转成向量，然后去向量库里做相似度搜索，找出最相关的若干块文本返回。这里有个关键的参数叫Top-K，也就是取前多少个相关块，取值太小容易漏掉关键信息，太大又容易把噪音带进来。实际做的时候，我一般取4到8，具体看业务场景。

这个阶段的技术含量，远没有到“接一个向量数据库就能跑”那么简单。真正的分水岭在于检索质量，而检索质量主要受两个因素影响：

一个是嵌入模型本身的能力。不同嵌入模型的语义理解能力差距很大。早期模型对中文的支持普遍一般，相近语义的句子匹配不上，检索召回率很低。这两年国产嵌入模型进步很大，比如BGE系列，中文场景下表现就很能打。选型时，别光看榜单和指标，最好拿自己的业务文档实测，检索效果好不好，跑一遍Top-5看命中率就知道。

第二个是检索的进阶策略，比如混合检索和重排序。纯向量检索擅长处理语义相似，但你搜一个“订单号12345”的时候，语义相似帮不上忙，因为这是精确匹配问题。所以很多成熟项目会做混合检索：向量检索加BM25关键词检索，最后再用重排序模型把两边的结果融合排序，把最靠谱的结果顶到最前面。效果通常会比单一向量检索好不少，但工程复杂度也上来了。

2.3 生成阶段：模型如何把检索结果变成答案

生成阶段是大模型的舞台。检索阶段拿到了若干块参考文本，加上用户的原始问题，一起拼成一个Prompt，交给大模型生成最终答案。

这里要留意一个容易被忽视的细节：Prompt怎么拼也是有讲究的。你需要在指令里明确告诉模型：请基于给定的资料回答，资料中没有的信息不要编造。这种约束能在一定程度上压制幻觉。很多人直接把资料一大段贴进去，什么指示都不给，模型就会延续它平时“自由发挥”的风格，效果自然不稳定。

我对生成阶段有个长期观察：大模型的文本生成能力，其实早就够用了。RAG这个工程方案真正决定成败的，往往是它前面那两个阶段——索引和检索。你的知识库切得好不好、检索命中的片段是不是相关，生成阶段才谈得上发挥。如果检索出来的是不相关的文件内容，你再换多少个生成模型都是白搭，这就像给一位技艺高超的厨师送了一堆过期食材，厨艺再高也做不出好菜。

3. 核心关系辨析：RAG、长上下文、微调，到底什么时候用哪个

聊完了RAG的链路，接下来要处理一个绕不开的问题。这几年大模型的上下文窗口越做越大，同时微调技术也很成熟，很多人会谈“既然窗口都百万级了，还需要RAG吗？”“与其折腾RAG，不如直接微调一个专用模型？”这两个问题如果不理清楚，你很难在项目里说服自己和团队。

先看长上下文和RAG的关系。长上下文的核心特点是——它把“输入的容量”变大了，模型一次性可以读入极大量的文本。RAG则是“精挑细选之后只给你看最相关的部分”。两者的定位完全不同：超长上下文面对的是“很多信息需要同时考虑”的场景，比如一次读入一整份几百页的合同；RAG面对的是“浩瀚资料中找一小块答案”的场景，比如在几万份产品说明中找出某个字段的定义。如果你把几万份文档全部塞进超长上下文，技术上勉强可行，但成本会高得惊人，而且检索精度无从谈起。我见过有人试过靠2M长上下文硬吃所有文档，推理耗时和费用直接翻了几个数量级，最后灰溜溜换回RAG。

再看微调和RAG的区别。微调是在模型权重上做文章——改变模型的“行为模式”“输出风格”“特定能力”，而不是给模型增补“百科知识”。你用企业内部问答数据微调，模型会学会“回答问题要简练”“语气要专业”，但如果你指望微调让模型记住几万条产品细节，那就大错特错了——这是把微调当数据库用，结果必然是灾难性的。如果一个东西是你希望模型“天生就会”的能力，比如客服话术风格，那选微调；如果一个东西是经常变化的业务知识，比如产品价格、库存信息、最新政策，那必须选RAG。

这三者的关系，我在实际项目中经常用下面这个方式向客户解释：

所以，一张图就能概括我这些年实践下来的想法：RAG解决的是“知识广度和时效性”问题，长上下文解决的是“单次输入的深度理解”问题，微调解决的是“行为习惯的塑造”问题。它们不是竞争关系，而是从三个完全不同的角度在扩展大模型的能力。成熟的项目里，这三者完全可以共存——用RAG保证知识新鲜，用长上下文做单文档深度分析，用微调固定输出风格。这是我比较推崇的做法，也是这几个方向在实际落地时最健康的组合方式。

4. 实操中的几个真相：图片进知识库、文本拆解、检索瓶颈

理论框架讲完，得回到地面上。热词的搜索数据里，有几个问题几乎每个做RAG的人都问过：RAG知识库能不能存图片？文本拆解有没有好用的本地工具？RAG的瓶颈到底在哪？这些看起来零散的问题，其实都指向同一个方向——RAG落地时，理想很丰满，现实很骨感。我挨个说说。

4.1 图片到底能不能进RAG知识库

很多人一开始想得简单：知识库嘛，肯定什么都能存，图片当然也应该能问。真做起来才发现这里藏着一个大坑，需要把“检索层”和“生成层”分开看。

如果你的文档里带图片，而你想让大模型“看懂”这张图并回答里面的内容，这不是RAG本身能解决的，它取决于你选的模型是不是多模态模型。现在常用的处理路径有这么几条：一是抽取图片里的文字，走OCR后当成文本块存进知识库——这条路径不要求模型是多模态的，实现简单，但对纯图片内容（比如图表、照片）无能为力；二是直接用多模态嵌入模型，把图片转成向量存进向量库，检索的时候把符合的图找出来，再交给多模态大模型去解析，这条路可以真正做到图文联合理解，但对技术栈的要求也高了一截。

我的建议很简单：先搞清楚你的“图片需求”到底是什么。如果只是PDF里有表格、公章、截图，OCR方案性价比最高；如果确实需要分析带有视觉语义的图片，那就一步到位，选支持图片的多模态链路，别在中间来回掰扯。还有一个容易忽略的点：图片入库之后，生成阶段的大模型也得多模态支持，否则检索层好不容易找到一张图，生成层却看图能力缺失或者只能把它丢到一边，整个链路依然跑不通。

4.2 本地文本拆解：别一上来就上收费服务

“有没有本地的RAG文本拆解工具”这个搜索词背后，是很多团队对数据隐私有硬要求，不想把内部文档传到外部服务。本地场景下，我常用的组合其实很朴素：PyMuPDF负责PDF文本抽取，配合PaddleOCR处理扫描件，Markdown再做结构化整理，LangChain或LlamaIndex负责把它们拼进切块流程。这套方案完全本地运行，不需要任何外部API，数据不出内网，能满足大部分企业的隐私合规要求。

有些文档结构复杂，比如带多级目录、页眉页码、混合表格的科学报告，纯文本抽取经常会弄乱顺序。这种情况我会上文档解析专用工具，现在有开源版本可以做版面分析，识别标题、段落、表格、图片区域，输出结构化的Markdown，然后按标题层级切块，质量比固定字符数切块高不少。顺便说一句，很多RAG项目效果不佳，根子不是模型不行，而是文档解析这关没做好。喂给模型的内容本身是乱序的碎片，后面做再多优化都救不回来，这点钱和时间千万别省。

4.3 RAG的瓶颈：多半出在检索上，而不是生成上

搜索“RAG瓶颈”的人多，说明大家在实际操作中确实遇到了真问题。我见过的RAG翻车现场，十次里有八次是检索环节掉链子。要么是嵌入模型太弱——用开源的旧版模型做中文场景，语义相近的句子匹配不上，召回率低得吓人；要么是切块策略太粗暴——一个语义单元被从中间切断，检索出来半截内容，模型只能拿到一个不完整的答案；要么是Query本身太短太模糊，比如用户只输入“报销”，但你不知道他是想问报销标准、报销流程还是报销系统，这也会导致检索结果跑偏。

应对策略也不复杂，就是按顺序排查。先看召回率，把Top-5结果打出来，用肉眼看跟问题相不相关。不相关，问题在检索，是嵌入模型还是切块策略的问题，逐个替换对比。相关但答案不对，问题就在生成阶段，是Prompt约束不够还是模型选择不当。这块还是要提一下重排序的价值——加上重排序之后，检索结果的头部命中率提升非常明显。不少团队跳过这一步，觉得能跑就行，但实际做完对比实验后，基本都回不去了。

5. 搭建一套可落地的RAG方案：模型选择、完整流程与实测调优

如果看完上一段你已经想动手了，那这一段就是给你准备的。我不会铺开讲某个框架的全部用法，而是给你一条经过验证的最小可行路径：本地部署、开源模型、端到端跑通、再看效果怎么调。

5.1 模型选型与部署方式

RAG链路里涉及两类模型：嵌入模型和生成模型。嵌入模型负责检索，我这边中文场景用得最多的是BGE系列，它对中文语义的理解在开源模型里表现很稳。生成模型可以用本地部署的开源模型，也可以用API服务，取决于你对数据隐私和成本的控制要求。

本地部署这块，有两个词这两年出现频率很高：Ollama和vLLM。Ollama的优势是几乎零门槛，装好之后几条命令就能把模型跑起来，内置了模型管理功能，特别适合个人开发者和团队快速验证原型。vLLM的优势是高吞吐和低延迟，PagedAttention机制优化了显存利用，适合生产环境服务化部署。我的经验是：原型阶段用Ollama，因为迭代速度快；真正上生产了再切到vLLM，并发上来了才有保障。如果你要接企业知识库平台，Dify这类工具可以直接配置本地模型和知识库，很多环节就不需要自己做UI了，能省不少事。

5.2 一套完整的目录结构和代码骨架

流程上我用LlamaIndex来做演示，因为它对数据接入的抽象比LangChain更友好，尤其适合文档型知识库场景。你不需要按我的代码逐行照抄，看整体结构就行。

索引阶段的核心操作：

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex # 1. 读取本地文档目录 documents = SimpleDirectoryReader("./data").load_data() # 2. 解析、切块、向量化并建索引 # 内部会调用嵌入模型，将每个文本块向量化并存入索引 index = VectorStoreIndex.from_documents(documents)

检索和生成阶段的核心操作：

# 转换成检索器 retriever = index.as_retriever(similarity_top_k=4) # 查询引擎会自动完成：向量检索 + 组装Prompt + 调用大模型 query_engine = index.as_query_engine() response = query_engine.query("我们公司的年假制度是怎么规定的？") print(response)

跑通之后，再按下面这个顺序做调优实验：

• 嵌入模型对比：拿同样的测试集，换不同的嵌入模型，看Top-5命中率。
• 切块大小对比：固定其他条件，把chunk_size从256到1024各跑一遍，找最佳值。
• 加重排序：在检索结果后面接一个重排序步骤，观察最终命中率变化。

这个方法的好处是，每次只改一个变量，你就能清晰看到哪个环节对结果影响最大。很多人一上来就是All-in大改，又是换配置又是上复杂架构，最后出了问题根本不知道是哪一步引入的。一套完整链路跑通之后，再逐步把高级组件（混合检索、重排序、Query改写）往里面加，每一步都做对比实验，确认有效再留着，无效就撤掉。RAG工程的优化，本质上就是反复执行“假设—实验—验证”这套循环。

5.3 用一套“最小验证集”来评估效果

聊完技术细节，还想补一个实用的建议：给RAG项目从第一天就建立一套自己的“最小验证集”。操作很简单，挑10到20个你的业务中真实会出现的高频问题，每个问题配好标准答案和对应文档来源。以后每次改任何配置——换嵌入模型、改切块策略、换提示词——都用同一套验证集跑一遍，对比正确率和检索命中率是不是变好了。这个习惯能让你在调优的时候不被感觉带着走，数据说明一切。我见过不少团队上了生产之后才临时攒验证集，结果线上出了Case都说不清是哪次改配置引入的回归问题，追溯成本极高。

6. 最后说一说部署时的注意事项和我的真实体会

到这里，RAG和大模型的关系应该已经梳理得很清楚了。它们之间的关系不是谁替代谁，而是大模型负责“表达和推理”能力，RAG负责“知识和资料”的供给，一个负责输出，一个负责输入。理解到这一层，你在任何项目里做技术选型，心里都会有一杆秤。

最后分享三个我踩过坑之后的切身体会，未必在任何官方文档里能看到。

第一个体会：RAG的复杂度要配得上问题的复杂度。不要为了显得技术先进，一上来就搭一套包含意图识别、Query改写、混合检索、重排序、多路召回的超大pipeline。多数内部知识问答场景，用一个还不错的嵌入模型加固定切块加Top-4检索，效果就已经可以见人了。过了基础线之后，你再去按需加复杂度，一步步做AB对比。盲目堆技术的下场通常只有一个——效果没提高多少，问题定位却难了几倍。

第二个体会：文档质量直接决定RAG的生死。我做过一个项目，业务方硬把一批字体不规范的扫描件塞进知识库，无论我换哪个嵌入模型，召回率都上不来。后来花了整整一周把所有扫描件重做OCR，效果立竿见影。凡是在这一步偷的懒，都会在检索结果里加倍还给你。

第三个体会：RAG和微调不是单选题。等你的RAG链路稳定之后，你可能会发现某些特定类型的回答，比如对外沟通邮件、标准化报告，风格总是不太对劲。这时候用微调塑造模型在这类任务上的表达习惯，RAG继续负责供知识，两条腿一起走，效果最理想。

我的个人做法是：每个新项目上线之前，都逼自己回答一个问题——我用这个模型的时候，到底是在靠它的“知识”还是靠它的“能力”？如果靠知识，那默认选RAG；如果靠能力，那白送知识库也要硬着头皮上。这个简单的判断经常能帮我在技术选型会议上少吵很多架。希望这篇文章也能帮你有同样的底气。