最近被问得最多的问题其实是这么几个RAG 是不是就是给大模型配了个数据库大家都在做 RAG 知识库为什么不直接做大模型微调RAG 和大模型到底谁依赖谁作为一个把本地知识库、RAG 流水线、微调方案都实际跑过的人我觉得有必要把这件事彻底掰扯清楚。RAG 不是一个神秘的新模型也不是大模型的替代品它更像是在大模型外面接了一套资料检索系统让模型在回答问题时先查资料、再写答案。本文不堆概念尽量用大白话把 RAG 和大模型的分工、完整流程、选型逻辑、实战代码和排查经验讲透适合刚接触大模型应用开发、想在企业内部搭建知识库或者被各种技术名词绕晕的同学。1. 先定位RAG 和大模型到底谁给谁打工1.1 大模型负责想RAG 负责找先给结论RAGRetrieval-Augmented Generation的完整叫法是检索增强生成它不是一个独立的模型而是一套围绕大模型设计的外部机制。大模型本身负责理解和生成它在你提问时基于自己的参数知识去组织语言、推理逻辑RAG 的职责则是在模型开口之前先去外部资料库把相关的内容找出来再把这些内容拼进提示词里引导模型基于这些材料回答。用人话说大模型就像一个文笔很好、但记忆范围有限的员工。如果你直接问他公司年假制度他可能只能根据训练时见过的通用职场知识来回答甚至编一个看似合理的答案。RAG 相当于给他配了一个内网资料柜回答前先去柜子里翻出《员工手册》里年假相关的那几页再让他照着这几页写回复。这样答案有出处、更新及时、还能追踪溯源。这也是为什么各大企业做私有知识库时往往首选 RAG 而不是直接微调RAG 不改变大模型本身的任何参数只是动态地给模型喂外部资料。大模型负责的是想清楚怎么表达RAG 负责的是想清楚该找什么材料。两者各管一段配合起来才形成一套完整的问答系统。1.2 知识库里的知识是如何被大模型理解的很多人对大模型有误解以为它能直接看懂PDF、Word、Excel 里的内容。实际上大模型处理的是 token 序列也就是文本片段。你给它一个 PDF 文件它并不能像人一样翻页阅读它只能接收有限长度的文本输入。知识库里的文档必须先经过切分、向量化、检索最终变成一段段普通文本塞进 Prompt 里大模型才理解到了这些内容。这里很多同学问RAG 知识库能存储图片吗先说结论传统的文本型 RAG 知识库存的是文档切块后的文本和对应的向量直接检索图片本身是不行的。但图片可以通过 OCR 提取文字、或用多模态模型生成文字描述把这些文字内容纳入知识库再在回答时把相关图片路径一并提供给用户。本质上是把图片翻译成了文字后再交给大模型处理而不是让大模型直接看图片。后面第 5 章我会专门展开。理解这个原理特别重要既然大模型只能理解文本那么 RAG 系统的关键就不只是模型强不强更在于你能不能把需要的信息准确变成文本并且在提问时准确捞出来。2. 拆开 RAG 这条链路离线索引与在线推理2.1 离线索引文档到向量的翻译过程RAG 的第一阶段是建立索引也就是把原始文档变成可以被搜索的知识。这个阶段通常在正式问答之前就做完所以叫离线。步骤看起来简单但里面全是细节第一步是加载文档。PDF、Word、Markdown 各有各自的解析方式PDF 还要考虑扫描件需要 OCR。第二步是清理去掉页眉页脚、多余换行、无关水印。第三步是最关键的切分Chunking把长文档切成若干片段。第四步是调用嵌入模型Embedding Model把每个片段编码成一个向量最后写入向量数据库。切分为什么这么重要大模型的上下文窗口是有限的就算现在很多模型能处理 128K、200K 个 token也不能把整本手册都塞进去。更重要的是一段文本越长和问题的相关性就越容易被稀释。想象你在一本书里查年假如果整本书只有一个向量那么年假这个内容会被整本书的其他信息掩盖检索分数不会突出如果把文档切成每段几百字的块每一块都有独立的向量检索时年假相关的块才能精准浮出水面。但切分也不是越小越好。切得太碎一个完整的概念被切成两半语义不完整召回的片段读起来前言不搭后语。切得太粗一个块里塞了多个主题检索出这一块可能只与提问沾一点边。我常用的经验是在语义完整和块大小之间找平衡从 256 到 512 个 token 之间尝试再用滑动窗口让相邻块有少量重叠避免一段内容恰好被从中间截断。由于文本变成了向量向量数据库里实际存的是两类东西向量本身以及对应的原始文本片段。向量用来做相似度计算原始文本用来拼进 Prompt 和展示给用户看。2.2 在线推理从问题到答案的四个阶段当检索库已经建立好来了一条新问题时系统会走一个典型流程第一阶段是查询处理。你可以直接把用户问题拿去检索也可以先让大模型把问题改写得更适合检索。用户问大家年假一般能休息多久改写模型可能把它转换成公司年假制度与休假天数这样与知识库中《员工手册》的表述更匹配。第二阶段是向量召回。把改写后的问题交给同一个嵌入模型得到问题的向量然后在向量库里找出与它最相似的 Top K 个片段。这里的相似度一般用余弦相似度来算取值范围在 -1 到 1 之间越接近 1 代表方向越一致。在实际工程里TopK 的选择很关键K 太小可能漏掉关键材料K 太大又会把一堆低质量内容塞进上下文。我的项目一般先设 K5再根据效果调整。第三阶段是精排Rerank。向量召回看的是语义相似有时候召回来 5 段有 3 段都沾边但排在前面的未必是最准的。所以更稳的流水线会加一个 Rerank 模型把召回的候选片段按和问题的匹配度重新打一次分挑出真正有用的两三个片段。这一步不是必须的但加了之后效果提升非常明显。第四阶段是生成。把最终选中的片段合并成一段文本连同用户问题一起拼进 Prompt发给大模型让它在限定的上下文里生成答案。这里特别注意大模型看到的还是文本并不是向量。向量只负责检索阶段的排序生成阶段回归到普通的语言模型能力。这就是检索增强生成的完整含义检索只是增强手段生成仍然靠大模型。2.3 Naive RAG 和 Advanced RAG 到底差在哪最早期的 RAG 结构就是我上面说的那套流程学术界叫 Naive RAG意思是朴素版。它在简单问答场景下够用但在复杂场景下问题很多用户问题表述绕检索不到知识库里相关片段分散召回的只有一部分多个片段之间存在矛盾模型不知道怎么取舍。于是出现了 Advanced RAG 的概念。它在前处理阶段做了更多事情比如用 LLM 做查询改写把口语变成关键词比如做 HyDE让模型先根据问题生成一个假设性答案再用这个答案去检索实验下来能明显提升召回率比如在索引阶段利用文档结构做层次化切分让标题、章节、段落保持层级关系。更进一步的还有模块化 RAG把检索和生成拆成可编排的模块甚至可以和 Agent智能体结合。比如系统先通过路由判断用户问的是内部知识还是常识再决定是否调用 RAG又比如多轮对话中先追问用户把问题限定清楚后再检索。热词里有个RAG 智能体说的就是这种把检索能力当作工具交给 Agent 调用的形态。下表可以快速看出朴素版和进阶版的差异维度Naive RAGAdvanced RAG查询处理直接用原问题检索查询改写、HyDE、多轮理解召回策略单一向量召回混合检索、多路召回排序方式按向量相似度直接取 TopK召回后加 Rerank 精排上下文处理简单拼接自动裁剪、去重、压缩适用场景入门、Demo、小规模知识库生产级、复杂业务知识库初学者不需要一上来就搞 Advanced RAG先把朴素版跑通再一个个加模块这样出问题时才知道是哪一步救回来的。3. 为什么先用 RAG 而不是大模型微调3.1 微调是改脑子RAG 是加外挂很多刚接触大模型的朋友会把 RAG 和微调放在一起比较其实它们是两条完全不同的路线。大模型微调Fine-tuning是在原有模型参数的基础上用一批有标签的数据继续训练把新知识、新格式、新风格写进模型参数里。这个过程会改变模型内部的权重相当于给员工做封闭式培训让他在不查资料的情况下也能记住公司话术。RAG 则完全不碰模型参数。它只是搭了一个外部检索通道在每次问答时把相关内容临时送进上下文。用一句话区分微调改变的是模型的记忆RAG 改变的是模型的输入。这里要注意参数化知识是有知识截止日期的。2023 年发布的模型到了 2024 年你问它新增的规章制度它大概率不知道。但 RAG 可以在文档里补充最新信息模型就能基于最新文档回答。而且 RAG 的更新成本极低文档变了重新切块、重新索引一遍就行无需重新训练。微调也有它不可替代的价值如果你想改变模型的说话风格、让模型学会特定格式输出、或者提升它执行某个任务的稳定能力微调更合适。比如你想让模型在所有回答结尾都加上一段安全提示这是输出习惯的改造属于微调的强项RAG 做不到。3.2 决策表什么场景选 RAG什么场景选微调选 RAG 还是微调本质上是看你要解决的是知识缺失还是能力改变。业务诉求推荐方案原因企业内部规章制度、产品文档RAG更新频繁需要溯源错知识能快速修正最新资讯、实时行情RAG微调数据准备时间长赶不上变化特定领域术语、行业黑话RAG 微调协同RAG 提供知识微调帮助模型熟悉术语表达统一回复语气、固定输出格式微调这是行为层面的改变RAG 很难约束模型输出经常出现幻觉RAG有依据内容可参考明显降低胡编概率私有数据不能出域RAG 本地部署本地向量库加本地模型数据不离开内网实际企业项目里RAG 和微调并不是二选一。很多成熟方案是先用 RAG 解决知识实时性问题再用微调解决表达风格问题。比如客服机器人RAG 负责从最新知识库里查政策微调负责让整个回答读起来像官方客服。这两者配合起来基础模型的能力被发挥得更充分。现在很流行的本地部署大模型、使用免费大模型 API其实都是模型接入方式的问题和 RAG 是正交关系。你可以用本地模型加 RAG也可以用云端 API 加 RAG流程没有任何本质区别。区别只在于数据是否出域、并发能力、以及模型本身的推理质量。4. 零基础可复制的本地 RAG 知识库实战4.1 本地环境准备与工具选型前面讲了一堆原理这部分我给出一个能直接跑通的本地 RAG 知识库最小实现。选型上我特意选了最简单、零门槛的组合Ollama 加 Chroma。Ollama 是一个本地大模型运行工具可以一键拉取开源模型并在本机跑推理同时也提供嵌入模型接口。Chroma 是轻量级向量数据库支持持久化非常适合作个人知识库和项目原型。整套方案不需要 GPU 也能跑只是慢模型我用相对轻量的 Qwen2.5 系列和 nomic-embed-text 嵌入模型。先装依赖。系统需要有 Python 3.9 以上版本然后命令行执行pip install ollama chromadb pypdf接着拉取模型ollama pull qwen2.5:7b ollama pull nomic-embed-text如果你的机器显存不够可以把 7b 换成 3b 甚至更小的模型。嵌入模型 nomic-embed-text 本身很小普通 CPU 也能跑。注意这里选 Ollama 不只是因为它方便更重要的是它的嵌入接口和生成接口完全本地化数据不出机器适合企业内部做私有化验证。4.2 完整代码建库、检索、生成一次跑通下面是一段完整的 Python 示例代码。它做的事是读取本机上一个 txt 文件按固定长度切分逐段调用 Ollama 嵌入接口生成向量写入 Chroma 数据库然后实现检索和问答。import ollama import chromadb # 1. 初始化向量库 client chromadb.PersistentClient(path./rag_demo) collection client.get_or_create_collection(nameknowledge) # 2. 读取并切分文档 def split_text(text, chunk_size300, overlap50): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks with open(manual.txt, r, encodingutf-8) as f: content f.read() chunks split_text(content) print(f切分得到 {len(chunks)} 个片段) # 3. 逐段生成向量并入库 ids [fchunk_{i} for i in range(len(chunks))] embeddings [ ollama.embed(modelnomic-embed-text, inputchunk)[embeddings][0] for chunk in chunks ] collection.add(idsids, embeddingsembeddings, documentschunks) # 4. 检索函数 def search(query, top_k5): qvec ollama.embed(modelnomic-embed-text, inputquery)[embeddings][0] res collection.query(query_embeddings[qvec], n_resultstop_k) return res[documents][0] # 5. 问答函数 def ask(query): docs search(query, top_k5) context \n\n.join(docs) prompt f请仅根据下面的资料回答问题。如果资料中没有相关信息请直接说“资料中未提及”。 资料 {context} 问题{query} resp ollama.chat( modelqwen2.5:7b, messages[{role: user, content: prompt}], options{temperature: 0.2} ) return resp[message][content] print(ask(公司年假制度是什么))这段代码最关键的地方有两点。一是检索和生成用的模型是分开的nomic-embed-text 负责把文本变成向量qwen2.5 负责最终回答两者不能混用。二是 Prompt 里明确写了仅根据下面的资料回答以及没有就直说这是压制幻觉的第一道防线。4.3 跑通之后第一步怎么调优能跑通只是开始我在实际项目里发现调优优先级这么排先查召回质量再调生成参数最后才考虑换模型。先看召回质量。把 ask 函数里的 search 结果单独打印出来读一遍这 5 段内容是不是和问题相关。如果不太相关优先调 chunk_size 和 top_k。如果相关但答案还是不对再看 Prompt 有没有给足约束。比如 temperature 设置太高模型会自由发挥我一般控制在 0.1 到 0.3。如果召回的片段里包含大量无关内容可以试试在前面代码里加一个简单 Rerank让 qwen 对候选片段逐一打分选出最相关的两段再送去生成。嵌入模型的选择也很关键。nomic-embed-text 对英文效果好中文场景我会优先换成 bge-m3 这类中文强的模型。在 Ollama 里同样可以用 ollama pull bge-m3 拉取。换模型后 embeddings 的维度可能变化需要清空向量库重新建索引。还有一个容易被忽略的点建库时的文档质量决定系统上限。如果原始 PDF 是扫描件没有经过 OCR 直接切分那检索出来的全是乱码后面再怎么调整也没用。所以索引前花时间做清洗永远值得。5. 实际项目中常见的 RAG 瓶颈与排查实录5.1 五个能直接复用的排查思路我在真正把 RAG 系统接到业务里时踩过不少坑。下面这五个问题出现频率最高对应的排查方法可以直接抄走。现象常见原因排查方法答案完全没提到相关知识文档没进库或切分太粗导致检索不到用同一问题单独跑检索打印返回片段召回的相关片段不完整chunk_size 太小概念被切开调整为 300-500 字加 50 字 overlap上下文里相关内容太少TopK 太小增大 K 到 8-10再靠 Rerank 精排模型无视检索内容、自由发挥Prompt 约束力不够temperature 太高强化指令把 temperature 降到 0.2不同文档之间答案相互矛盾检索到了不同版本的资料建库时按文档来源打标签检索时用元数据过滤这里我特别想提示一个排查顺序不要一上来就怀疑大模型不行。RAG 系统的成绩70% 取决于索引和召回阶段。每次遇到效果差先问一个简单问题如果把这些检索结果给一个实习生看他能写出正确答案吗如果实习生都不能那说明材料根本没找对问题出在检索链路而不是生成链路。5.2 RAG 知识库能存图片吗完整回答这个热搜问题值得单独回答。标准文本型 RAG 知识库存的是纯文本片段和向量图片本身不能直接参与向量相似度检索。但在实际工程里图片可以通过三种方式纳入知识库第一种是图片转文字式 RAG。用 OCR 把图片里的文字抽出来或者用多模态大模型给图片生成一段详细描述再把这段描述作为文档片段入库。用户提问时系统检索到相关描述回答里附上图片路径。这种方式实现成本最低也是目前最主流的做法。第二种是多模态向量式 RAG。用 CLIP 这类多模态模型把图片本身也编码成向量和文本向量放在同一个检索引擎里。用户提问的文本向量可以同时检索图片向量直接找到视觉上相似的内容。这适合做以图搜图、商品匹配等场景但工程复杂度比第一种高不少。第三种是混合方案。把图片的相关文字、标签、描述全部入库同时保留元数据字段比如拍摄时间、产品型号、所属目录。业务层先通过数据库过滤缩小范围再做向量检索最终返回图文混合的答案。顺带说一句工业 AI 检测、服装检测这类场景核心能力其实是目标检测和图像分类模型不是 RAG 能直接替代的。RAG 在这些场景里的作用是辅助比如让工人用自然语言查询缺陷历史记录、对比不同批次的检测参数将检测结果和知识库里的标准文档关联起来。两者解决的问题不同不要搞混。5.3 效果评估才是长期维护的关键RAG 系统做完不是终点难的是持续迭代。我见过太多项目上线后凭感觉调参数今天觉得这个好明天觉得那个好最后越调越乱。正确做法是建立一套小型的评测集准备 30 到 100 条真实业务问题每条标注标准来源片段和期望答案。每次改动切分策略、换嵌入模型、调整 Prompt都把这套评测集跑一遍。评测指标不需要太复杂主要看三点召回率相关片段是否出现在检索结果中、忠实度模型回答是否忠于检索片段、有用性用户是否得到满意答案。前两个可以自动化第三个需要人工抽样。我自己在实际项目里坚持一个习惯每次发现问题就记录一条 badcase写清楚当时问题是什么、检索结果是什么、期望结果是什么。积累到二三十条后往往能看出一类共性原因比如所有关于价格的问题都召回到旧合同这比零散地调参数有效得多。最后再分享一个真实体会RAG 不是越复杂越好。很多人一上手就堆查询改写、多路召回、Rerank、Agent 编排结果系统里每个环节都有待调优很难定位问题。我建议先跑通一个最简单的切块-向量检索-拼 Prompt-生成流程让它稳定工作再按评测结果一个一个往上加模块。还要记住文档质量永远是地基地基没打好换再大的模型也救不回来。如果后续想把 RAG 用在更复杂的业务里可以从评估集先行、badcase 驱动迭代这个方向继续扩展它会让你少走很多弯路。