最近总有人问我“既然大模型这么强为什么还要搞RAG它俩到底是什么关系”尤其做知识库问答、智能客服、企业文档检索的朋友被模型的“胡说八道”折磨到崩溃转头看到各种RAG教程又觉得一头雾水。这篇我就把RAG和大模型的关系彻底拆开讲清楚从设计思路、分工边界、实际搭建到瓶颈排查全部用落地视角聊一遍。它适合被幻觉坑过的开发者、准备做私有知识库的方案评估人员以及刚接触大模型应用想找切入点的小白。看完你至少能回答三个问题RAG解决什么、大模型在里面干什么、为什么不能只用微调。1. RAG是什么先搞懂它解决的核心问题1.1 大模型的“记忆力”短板参数记忆不是数据库大模型本质上是一个基于海量文本训练出来的“参数化记忆系统”。它把训练时见过的规律、知识、语感压缩进几十亿甚至几千亿个参数里当你问它“什么是光合作用”它能给出像模像样的回答靠的不是现场查资料而是内部参数的激活组合。听起来很神奇但这里有个致命问题它的记忆是“截止”的训练数据之后发生的事情它不知道它的记忆是“模糊”的容易把相似概念混在一起它的记忆也不包含你的业务私有数据。举个生活化的例子大模型像一个见识极广但没有资料室的顾问你问行业常识他口若悬河你问公司内部最新政策他只能靠猜猜错了还一脸笃定。这就是“幻觉”的根源——不是模型想骗你而是它没有事实依据只能用语言习惯去“圆”一个看起来合理的答案。很多人一开始试图用微调解决这个问题后面我会详细比较但先说结论如果你需要模型回答的内容经常变化、需要逐条追溯出处、涉及大量私有文档给大模型配一个动态可查的“资料室”远比反复锻炼它的大脑更实用这个资料室就是RAG。1.2 RAG的工作机制索引、检索、生成三段式RAG全称Retrieval-Augmented Generation检索增强生成。名字已经说得很直白在生成之前先做检索把检索到的相关资料拼进提示词里再让大模型基于这些资料作答。整个系统拆成三段就很好理解。第一段是索引Indexing。你有一堆文档PDF、Word、Markdown、数据库里的文本字段先把它们清洗、切分成合适的片段再用嵌入模型Embedding Model把每个片段转换成一串向量——也就是把文本语义“压缩”成几百维的数字坐标。这些向量连同原文一起存进向量数据库比如FAISS、Chroma、Milvus、pgvector。第二段是检索Retrieval。用户提个问题同样用嵌入模型把问题转成向量然后在向量数据库里做相似度搜索找出语义上最接近的Top-K个文档片段。注意这里比传统的关键词搜索高级的地方在于你把“苹果好吃吗”和“苹果的营养价值”都能关联起来哪怕用户只说“苹果口感”系统也能找到相关片段因为向量空间里语义相近的文本距离近。第三段是生成Generation。把检索到的片段拼进Prompt模板格式大致是“请仅根据以下资料回答问题……资料……问题……”然后交给大模型让它组织语言生成最终答案。大模型在RAG里扮演的是“读资料、写答案”的角色而不是“背书”的角色。1.3 为什么是“检索增强”而不是“微调”选型背后的逻辑很多人一聊到大模型落地就想到微调Fine-tuning似乎让模型“学会”业务知识才算真正定制。这个想法没错但成本高、周期长、灵活性差。微调的本质是改变模型权重你得准备大量“问题-标准答案”对在GPU上跑训练迭代几轮后再重新部署模型服务。一旦业务文档改了对不起重新训练一遍。RAG的思路完全相反模型权重不动只改“输入”。新知识来了把文档重新切块入库就行不需要训练。这种“数据与模型解耦”的设计让知识更新变得像写文章一样快。所以选型时你可以用这个决策矩阵知识更新频繁周级、天级→ 选RAG答案需要引用出处、可追溯 → 选RAG业务数据量大且分散 → 优先RAG需要改变模型风格、语气、角色人设 → 微调更直接需要让模型学会某种固定技能如特定SQL生成、特定代码风格→ 微调预算充足且知识长期稳定 → 可以考虑微调但仍建议RAG打底我在实际项目里见到最多的错误是把微调当万能药训完发现新知识更新后模型又开始“一本正经地胡说”。微调和RAG不是二选一而是互补先用RAG解决事实来源问题再针对模型输出风格做少量微调效果往往更好。这个“RAG打底、微调优化”的组合才是很多企业私有化部署的真实形态。2. RAG与大模型的分工边界谁负责什么谁离不开谁2.1 大模型负责“生成”RAG负责“提供事实”搞清边界很重要。RAG系统里大模型不是唯一的智能体但它是不可或缺的“大脑”而RAG更像“外接硬盘”或“资料员”。具体分工可以这样看大模型负责三件事。第一理解用户问题哪怕问得含混、口语化、有错别字模型能解读真实意图。第二组织答案结构把检索到的零散片段整理成逻辑通顺、语气自然的回答。第三做有限的推理比如比较多个片段里的数据、按时间线梳理事件、提取关键结论。RAG负责两件事。第一缩小知识范围把模型从“几十亿参数里的模糊记忆”拉回到“几百个token里的事实段落”大幅降低幻觉概率。第二提供证据让答案可溯源用户能点开对应原文核对这在医疗、金融、法律领域几乎是刚需。如果你把RAG去掉光靠大模型做企业知识问答模型就会用训练数据里的“常识”去覆盖业务细节答错是常态。如果你把大模型去掉光有检索系统你得到的是“相关文档片段列表”而不是一句话就能用的答案。所以两者高度耦合RAG给大模型装上实时更新的知识补给线大模型给RAG装上能说人话的输出口。2.2 嵌入模型、向量数据库、重排器在RAG里的角色把RAG拆开中间有多个零部件每个都影响最终效果。嵌入模型Embedding Model是第一个关键角色。它决定文本相似度判断准不准。常用的有OpenAI的text-embedding-3-small/large、BGE系列、M3E、GTE等。中文场景我实测下来BGE和M3E的性价比不错本地部署也方便。注意嵌入模型和生成大模型是两套东西嵌入模型把文本变向量它不需要会写诗只需要能区分语义远近。向量数据库是第二个关键角色。它负责存向量、建索引、做相似度搜索。轻量级用Chroma、FAISS生产环境可用Milvus、Qdrant、pgvector。选型要点数据量多大并发多高需不需要持久化需不需要过滤条件比如只搜某个分类下的文档FAISS是库不是服务适合单机脚本Milvus适合大规模分布式场景。重排器Re-ranker是第三个容易被忽略的角色。向量检索的规则是“整体语义相似”但用户真正关心的可能只是某一段具体数字或条件。比如搜索“2024年华东区销售额”向量召回的第一名可能是“华东区整体业绩分析”第二名才是“2024年各省销售额明细表”。依靠向量相似度直接取Top-5很容易把最关键的片段漏掉。重排器的作用是粗召回Top-50后用交叉编码器做精排让真正相关的片段浮到前面。这个环节能明显提升问答准确率强烈建议加上。2.3 多模态与本地部署场景下的新变化有个热搜问题很典型“RAG知识库能存储图片吗”直接回答能但要分情况。如果你的图片只是作为文档配图不需要理解图片内容你可以把图片的标题、上下文文字一并存进向量库检索文字时显示图片。如果你需要让模型根据图片内容回答问题就得引入多模态嵌入模型比如CLIP把图片也向量化或者用多模态大模型做视觉解析后再走文本RAG。我建议在实际项目里优先用“图文分离”方案PDF解析时把图片抽出来用视觉大模型生成图片描述文字再将描述文字进入向量索引。这样既能让图片作为答案素材又不至于拖慢检索速度。另一个热门场景是本地部署。很多人问“有没有本地RAG文本拆解工具”“Ollama怎么搭简易知识库”。答案是完全可行。本地版RAG 本地嵌入模型 本地向量库 本地大模型数据不出内网适合企业私有化需求。常见的组件组合Ollama拉取Qwen、Llama等模型配BGE-M3嵌入模型向量库用Chroma或FAISS整个链条可以跑在一台16G内存的普通服务器上。我在第三部分会给出可复制的操作步骤。3. 从零搭建一个RAG应用的关键实操环节3.1 文档切分与索引构建chunk大小怎么定RAG的效果50%取决于切分30%取决于检索20%取决于Prompt和模型。很多人把功夫全花在调Prompt上切分随便搞结果召回一堆垃圾再调Prompt也救不回来。文档切分就是把原始文本切成一个个小单元每个单元独立向量化。切分太粗比如把整本手册当一个chunk检索时这个chunk包含大量无关内容提交给大模型后会淹没关键信息导致“检索到了但答不准”。切分太细比如按一句话切上下文割裂模型读到的片段缺少背景回答显得支离破碎。我实测的几个可靠策略按结构切分先解析文档标题层级Markdown标题、Word的Heading、PDF目录按章节切分。保留章节路径信息比如“第三章 第二节 退换货政策”检索时能利用层级上下文。按段落切分后补窗口可以用LangChain的RecursiveCharacterTextSplitter先按段落切再设定chunk_size500、chunk_overlap80。重叠部分的作用是避免关键信息被拦腰截断。比如一个长段落里“退款需在7天内申请”被切到前一段的末尾后一段只剩“申请需附订单截图”模型就丢失了一半信息重叠窗口能缓解。特殊文档场景代码仓库按函数切分合同按条款编号切分客服FAQ直接按“问题-答案”对作为chunk。不要拿一套切分器走天下。切分完之后建议给每个chunk补上一些元数据比如来源文件、页码、标题路径、更新时间。这些信息一方面可以用于过滤另一方面在生成答案时作为引用来源展示。3.2 检索召回与重排top-k参数怎么选文档入库后核心是检索链路。这里有三类参数需要关注。第一是召回数量。常见做法是先用向量检索取Top-20到Top-50再做重排取Top-3到Top-5。如果直接向量检索只取Top-5很容易漏掉重排后真正靠前的片段。我的经验是召回量管够、重排精排效果和性能都兼顾。第二是相似度阈值。向量检索返回的score通常不是标准概率不同向量库的度量方式不同内积、余弦、欧氏。你需要测试并设一个“最低分”低于这个阈值宁可告诉用户“资料库没有相关信息”也别硬答。阈值设置太严会降低召回率太松会增加幻觉一般用验证集反复调Chroma和Milvus都支持返回score我习惯记录测试集上每个score对应的准确率和覆盖率找一个平衡点。第三是混合检索。向量检索擅长语义匹配但对专有名词、编号、精确型号无能为力。比如用户搜“BUG-2048”向量检索可能把它当普通token给打散关键词检索却能精准命中代码块里的“BUG-2048”。所以成熟方案往往用向量检索 BM25关键词检索并行再用重排器合并两者结果。这个叫Hybrid Search在ES、Milvus里都能配置。重排器选择上国内开源推荐bge-reranker-base实测中文效果不错如果追求更高精度可以上cross-encoder模型代价是推理速度慢些。重排阶段一般只看Top-50所以速度压力不大。3.3 构造Prompt与生成约束怎么把检索结果喂给大模型Prompt是让大模型“听话”的最终关卡。很多RAG系统检索没问题但Prompt写得太开放导致模型还是凭记忆写答案。我常用的RAG Prompt骨架是这样你是一个基于检索资料的问答助手。请仅根据以下资料回答用户问题。 如果资料中没有足够信息请直接回答“资料库中未找到相关信息”不要编造。 资料 【1】来源公司制度-离职流程.pdf 第3页 “离职需提前30天书面申请……” 【2】来源公司制度-离职流程.pdf 第7页 “未结清费用将从最后一个月工资中扣除……” 问题 离职手续有哪些注意事项 请用清晰的条目列出步骤并标注每步对应的资料来源编号。这个Prompt有几个关键设计“仅根据资料回答”是硬约束抑制幻觉“资料中没有就说不知道”给了模型一条“安全出口”避免它强行胡诌来源编号让答案可追溯用户能核对问题放最后、资料放前面符合大模型的注意力偏好另外一个实操细节如果检索到的资料塞满了上下文但其中一部分与问题无关大模型容易“分心”。可以在把资料拼入Prompt前先做一次“片段排序”或过滤只保留重排后最相关的片段。有些框架比如LangChain的MapReduceQA会把多片段的答案分别生成再汇总效果更干净但耗时更长适合离线分析场景。3.4 本地化部署参考Ollama 本地向量库的简易方案现在很多团队想先跑通一个“零基础可复制”的本地RAG。我推荐用Ollama BGE嵌入 Chroma。整个流程不需要GPU也能跑CPU慢一些适合学习验证。第一步安装Ollama并拉取模型。以中文场景为例ollama pull qwen2.5:7b ollama pull bge-m3第二步安装Python依赖pip install langchain langchain-community chromadb sentence-transformers第三步写一个简单的索引脚本把本地文档切分、向量化、存入Chromafrom langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import Chroma loader TextLoader(docs/help.txt) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size300, chunk_overlap50) chunks splitter.split_documents(docs) embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, query_instruction为这个句子生成表示以用于检索 ) vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db ) print(索引完成)第四步写检索问答脚本from langchain_community.chat_models import ChatOllama from langchain.chains import RetrievalQA llm ChatOllama(modelqwen2.5:7b, temperature0) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), chain_typestuff ) answer qa.run(退货政策是什么) print(answer)这套流程能跑通后再考虑换成更重的方案比如用vLLM部署大模型服务承载更高并发用Milvus管理大批量知识库或者用Dify这类平台把RAG流程可视化。但底层组件和核心思路是一样的。对于企业私有化部署把Ollama替换成vLLM把Chroma换成Milvus再做好权限控制和审计追踪就是一个可落地的生产方案。4. RAG实战中的瓶颈、常见问题与排查技巧4.1 检索不准、噪声干扰、上下文超限三大瓶颈怎么破先说检索不准。RAG的瓶颈大多不在模型而在检索质量。用户提问“怎么申请报销”你的知识库里可能同时有“员工报销流程”“差旅报销标准”“发票合规指南”向量检索返回的前几名可能只覆盖了流程没覆盖标准。解决思路是混合检索加重排同时优化切分粒度让每个片段具备完整的“业务含义”。另一个坑是Embedding模型选型不对中文业务术语密集的场景通用英文Embedding效果很差。实测BGE-M3在中文上明显优于较早版本的text-embedding-ada-002。再说噪声干扰。检索出的片段里有大量重复、宣传语、表格乱码会把模型带偏。我遇到过一篇产品手册页面页脚反复出现“版权所有翻版必究”切分后成了多个chunk检索时占比过高导致模型回答“翻版必究”而不是产品参数。解决办法是清洗文档去除页眉页脚对表格内容单独解析不能简单把表格转成文本就完事。最后是上下文超限。大模型有窗口限制比如4K、8K、128K但你不能所有片段都塞进去塞得越多注意力越稀释。一般控制在3-5个精排片段就好。如果检索需求确实多可以先用“Map-Reduce”方式把每个片段单独总结再合并总结摘要但牺牲了速度和成本。4.2 常见问题速查表症状、原因与解法我把实战里见过的高频问题整理成一张速查表可以直接当排查手册用。症状常见原因解决办法检索结果明显与问题无关Embedding模型不适合业务语言换成中文专用模型BGE/M3E并测试几种模型答案在资料里有但模型答错切分把关键信息截断增加chunk_overlap按结构切分减少chunk_size模型仍然编造答案Prompt约束不够强制“仅根据资料回答”资料不足时拒绝回答检索速度慢向量库索引未配置IVF/HNSW调整索引类型优化批量写入生成的回答结构混乱片段过多、顺序乱重排器精排后再拼Prompt限制片段数量同义词搜索不到纯向量匹配对专有名词不友好加入BM25关键词检索混合召回更新文档后旧结果还在切分或向量ID未关联文档版本按文档hash做版本管理旧的chunk批量删除多轮对话答非所问对话历史混淆了当前问题独立做query改写再检索不把整段历史塞入检索图片内容完全没被索引到未做多模态解析用视觉大模型生成图片描述后再向量化本地部署反应太慢无GPU且模型过大换小模型量化版或将嵌入模型换轻量版本这里重点提一下query改写。用户多轮对话中说“那如果晚一周呢”单独看这句话没法检索。正确做法是用大模型先结合对话历史把query改写为完整问题比如“离职申请晚一周提交会有什么影响”再做检索。我在LangChain里用ConversationalRetrievalChain时遇到过类似问题后来改成先改写再检索准确率提升明显。4.3 RAG与大模型微调的选型矩阵别再纠结二选一聊到这里可以再回头深入比较一下RAG和微调。我在1.3用了选型逻辑这里给出一张更具体的决策矩阵方便你直接对照业务场景。对比维度RAG微调知识更新时间分钟级重新入库即可天级到周级训练、验证、部署成本存储和检索资源为主无需训练GPU需要高性能GPU训练成本翻几倍可解释性高答案可溯源到原文档低模型内部权重难解释私有数据安全性数据以文档存储可控可审计数据被“揉进”模型参数无法单独摘除模型风格改变弱只能通过Prompt引导强可以重塑语气、格式、输出习惯所需数据量少几篇文档就能跑多至少几千条高质量样本才见效维护复杂度文档治理工作持续存在权重版本管理复杂从热搜词里能看到很多人同时搜“rag”和“大模型微调”说明大家都在两者之间摇摆。我的建议是首个版本不要微调先把RAG跑通把知识库清洗、切分、检索调优做到位如果仍然觉得回答风格不像自己公司的人再收集一批“问题-标准答案”对去做微调。微调和RAG结合的最佳姿势是用RAG控制事实来源用微调控制表达方式。5. 我个人在实际操作中的几点体会做了几年大模型应用落地处理过合同问答、设备维修辅助、客服知识库、科研文献综述等不同场景踩过的坑比教程里写的多得多。最后分享三点掏心窝的体会。第一先建评测集再谈优化。没有评测集的RAG项目就是盲人摸象。我从一开始就给每个知识库建立20到50条测试问题每条问题标注好理想答案和来源文档。每次改切分、改检索、改Prompt都用同一套测试集跑一遍看准确率变化。很多团队上线前才发现效果不行就是因为没有评测集兜底。第二检索质量决定天花板Prompt只是逼近天花板。我之前花大量精力调Prompt后来发现症结在于检索回来的片段本身就不对再怎么写“请仔细阅读资料”都白搭。优先看召回结果人工检查检索到的前5条是不是包含正确答案如果连检索都不准调Prompt没用。第三最小闭环比大而全的方案重要。不要一开始就上Milvus集群、上重排模型、上多模态解析。先用最简单的Ollama加Chroma跑通一个文件的知识问答然后逐步加功能。很多项目死在“设计过度连一个文档都跑不通”的环节。跑通最小闭环后你会对RAG的瓶颈有体感再优化就有了明确方向。好了RAG和大模型的关系说完本地代码也给了坑也排了。你可以直接复制第三部分的脚本跑一遍然后把测试问题换成自己业务里的真实问题看看检索效果你会比我写再多文字更能理解RAG的价值。 
长河君 · 2026/10/31 8:32:14 · 阅读 1.2k RAG是什么？一文拆解大模型检索增强原理、搭建与微调选型
最近总有人问我“既然大模型这么强为什么还要搞RAG它俩到底是什么关系”尤其做知识库问答、智能客服、企业文档检索的朋友被模型的“胡说八道”折磨到崩溃转头看到各种RAG教程又觉得一头雾水。这篇我就把RAG和大模型的关系彻底拆开讲清楚从设计思路、分工边界、实际搭建到瓶颈排查全部用落地视角聊一遍。它适合被幻觉坑过的开发者、准备做私有知识库的方案评估人员以及刚接触大模型应用想找切入点的小白。看完你至少能回答三个问题RAG解决什么、大模型在里面干什么、为什么不能只用微调。1. RAG是什么先搞懂它解决的核心问题1.1 大模型的“记忆力”短板参数记忆不是数据库大模型本质上是一个基于海量文本训练出来的“参数化记忆系统”。它把训练时见过的规律、知识、语感压缩进几十亿甚至几千亿个参数里当你问它“什么是光合作用”它能给出像模像样的回答靠的不是现场查资料而是内部参数的激活组合。听起来很神奇但这里有个致命问题它的记忆是“截止”的训练数据之后发生的事情它不知道它的记忆是“模糊”的容易把相似概念混在一起它的记忆也不包含你的业务私有数据。举个生活化的例子大模型像一个见识极广但没有资料室的顾问你问行业常识他口若悬河你问公司内部最新政策他只能靠猜猜错了还一脸笃定。这就是“幻觉”的根源——不是模型想骗你而是它没有事实依据只能用语言习惯去“圆”一个看起来合理的答案。很多人一开始试图用微调解决这个问题后面我会详细比较但先说结论如果你需要模型回答的内容经常变化、需要逐条追溯出处、涉及大量私有文档给大模型配一个动态可查的“资料室”远比反复锻炼它的大脑更实用这个资料室就是RAG。1.2 RAG的工作机制索引、检索、生成三段式RAG全称Retrieval-Augmented Generation检索增强生成。名字已经说得很直白在生成之前先做检索把检索到的相关资料拼进提示词里再让大模型基于这些资料作答。整个系统拆成三段就很好理解。第一段是索引Indexing。你有一堆文档PDF、Word、Markdown、数据库里的文本字段先把它们清洗、切分成合适的片段再用嵌入模型Embedding Model把每个片段转换成一串向量——也就是把文本语义“压缩”成几百维的数字坐标。这些向量连同原文一起存进向量数据库比如FAISS、Chroma、Milvus、pgvector。第二段是检索Retrieval。用户提个问题同样用嵌入模型把问题转成向量然后在向量数据库里做相似度搜索找出语义上最接近的Top-K个文档片段。注意这里比传统的关键词搜索高级的地方在于你把“苹果好吃吗”和“苹果的营养价值”都能关联起来哪怕用户只说“苹果口感”系统也能找到相关片段因为向量空间里语义相近的文本距离近。第三段是生成Generation。把检索到的片段拼进Prompt模板格式大致是“请仅根据以下资料回答问题……资料……问题……”然后交给大模型让它组织语言生成最终答案。大模型在RAG里扮演的是“读资料、写答案”的角色而不是“背书”的角色。1.3 为什么是“检索增强”而不是“微调”选型背后的逻辑很多人一聊到大模型落地就想到微调Fine-tuning似乎让模型“学会”业务知识才算真正定制。这个想法没错但成本高、周期长、灵活性差。微调的本质是改变模型权重你得准备大量“问题-标准答案”对在GPU上跑训练迭代几轮后再重新部署模型服务。一旦业务文档改了对不起重新训练一遍。RAG的思路完全相反模型权重不动只改“输入”。新知识来了把文档重新切块入库就行不需要训练。这种“数据与模型解耦”的设计让知识更新变得像写文章一样快。所以选型时你可以用这个决策矩阵知识更新频繁周级、天级→ 选RAG答案需要引用出处、可追溯 → 选RAG业务数据量大且分散 → 优先RAG需要改变模型风格、语气、角色人设 → 微调更直接需要让模型学会某种固定技能如特定SQL生成、特定代码风格→ 微调预算充足且知识长期稳定 → 可以考虑微调但仍建议RAG打底我在实际项目里见到最多的错误是把微调当万能药训完发现新知识更新后模型又开始“一本正经地胡说”。微调和RAG不是二选一而是互补先用RAG解决事实来源问题再针对模型输出风格做少量微调效果往往更好。这个“RAG打底、微调优化”的组合才是很多企业私有化部署的真实形态。2. RAG与大模型的分工边界谁负责什么谁离不开谁2.1 大模型负责“生成”RAG负责“提供事实”搞清边界很重要。RAG系统里大模型不是唯一的智能体但它是不可或缺的“大脑”而RAG更像“外接硬盘”或“资料员”。具体分工可以这样看大模型负责三件事。第一理解用户问题哪怕问得含混、口语化、有错别字模型能解读真实意图。第二组织答案结构把检索到的零散片段整理成逻辑通顺、语气自然的回答。第三做有限的推理比如比较多个片段里的数据、按时间线梳理事件、提取关键结论。RAG负责两件事。第一缩小知识范围把模型从“几十亿参数里的模糊记忆”拉回到“几百个token里的事实段落”大幅降低幻觉概率。第二提供证据让答案可溯源用户能点开对应原文核对这在医疗、金融、法律领域几乎是刚需。如果你把RAG去掉光靠大模型做企业知识问答模型就会用训练数据里的“常识”去覆盖业务细节答错是常态。如果你把大模型去掉光有检索系统你得到的是“相关文档片段列表”而不是一句话就能用的答案。所以两者高度耦合RAG给大模型装上实时更新的知识补给线大模型给RAG装上能说人话的输出口。2.2 嵌入模型、向量数据库、重排器在RAG里的角色把RAG拆开中间有多个零部件每个都影响最终效果。嵌入模型Embedding Model是第一个关键角色。它决定文本相似度判断准不准。常用的有OpenAI的text-embedding-3-small/large、BGE系列、M3E、GTE等。中文场景我实测下来BGE和M3E的性价比不错本地部署也方便。注意嵌入模型和生成大模型是两套东西嵌入模型把文本变向量它不需要会写诗只需要能区分语义远近。向量数据库是第二个关键角色。它负责存向量、建索引、做相似度搜索。轻量级用Chroma、FAISS生产环境可用Milvus、Qdrant、pgvector。选型要点数据量多大并发多高需不需要持久化需不需要过滤条件比如只搜某个分类下的文档FAISS是库不是服务适合单机脚本Milvus适合大规模分布式场景。重排器Re-ranker是第三个容易被忽略的角色。向量检索的规则是“整体语义相似”但用户真正关心的可能只是某一段具体数字或条件。比如搜索“2024年华东区销售额”向量召回的第一名可能是“华东区整体业绩分析”第二名才是“2024年各省销售额明细表”。依靠向量相似度直接取Top-5很容易把最关键的片段漏掉。重排器的作用是粗召回Top-50后用交叉编码器做精排让真正相关的片段浮到前面。这个环节能明显提升问答准确率强烈建议加上。2.3 多模态与本地部署场景下的新变化有个热搜问题很典型“RAG知识库能存储图片吗”直接回答能但要分情况。如果你的图片只是作为文档配图不需要理解图片内容你可以把图片的标题、上下文文字一并存进向量库检索文字时显示图片。如果你需要让模型根据图片内容回答问题就得引入多模态嵌入模型比如CLIP把图片也向量化或者用多模态大模型做视觉解析后再走文本RAG。我建议在实际项目里优先用“图文分离”方案PDF解析时把图片抽出来用视觉大模型生成图片描述文字再将描述文字进入向量索引。这样既能让图片作为答案素材又不至于拖慢检索速度。另一个热门场景是本地部署。很多人问“有没有本地RAG文本拆解工具”“Ollama怎么搭简易知识库”。答案是完全可行。本地版RAG 本地嵌入模型 本地向量库 本地大模型数据不出内网适合企业私有化需求。常见的组件组合Ollama拉取Qwen、Llama等模型配BGE-M3嵌入模型向量库用Chroma或FAISS整个链条可以跑在一台16G内存的普通服务器上。我在第三部分会给出可复制的操作步骤。3. 从零搭建一个RAG应用的关键实操环节3.1 文档切分与索引构建chunk大小怎么定RAG的效果50%取决于切分30%取决于检索20%取决于Prompt和模型。很多人把功夫全花在调Prompt上切分随便搞结果召回一堆垃圾再调Prompt也救不回来。文档切分就是把原始文本切成一个个小单元每个单元独立向量化。切分太粗比如把整本手册当一个chunk检索时这个chunk包含大量无关内容提交给大模型后会淹没关键信息导致“检索到了但答不准”。切分太细比如按一句话切上下文割裂模型读到的片段缺少背景回答显得支离破碎。我实测的几个可靠策略按结构切分先解析文档标题层级Markdown标题、Word的Heading、PDF目录按章节切分。保留章节路径信息比如“第三章 第二节 退换货政策”检索时能利用层级上下文。按段落切分后补窗口可以用LangChain的RecursiveCharacterTextSplitter先按段落切再设定chunk_size500、chunk_overlap80。重叠部分的作用是避免关键信息被拦腰截断。比如一个长段落里“退款需在7天内申请”被切到前一段的末尾后一段只剩“申请需附订单截图”模型就丢失了一半信息重叠窗口能缓解。特殊文档场景代码仓库按函数切分合同按条款编号切分客服FAQ直接按“问题-答案”对作为chunk。不要拿一套切分器走天下。切分完之后建议给每个chunk补上一些元数据比如来源文件、页码、标题路径、更新时间。这些信息一方面可以用于过滤另一方面在生成答案时作为引用来源展示。3.2 检索召回与重排top-k参数怎么选文档入库后核心是检索链路。这里有三类参数需要关注。第一是召回数量。常见做法是先用向量检索取Top-20到Top-50再做重排取Top-3到Top-5。如果直接向量检索只取Top-5很容易漏掉重排后真正靠前的片段。我的经验是召回量管够、重排精排效果和性能都兼顾。第二是相似度阈值。向量检索返回的score通常不是标准概率不同向量库的度量方式不同内积、余弦、欧氏。你需要测试并设一个“最低分”低于这个阈值宁可告诉用户“资料库没有相关信息”也别硬答。阈值设置太严会降低召回率太松会增加幻觉一般用验证集反复调Chroma和Milvus都支持返回score我习惯记录测试集上每个score对应的准确率和覆盖率找一个平衡点。第三是混合检索。向量检索擅长语义匹配但对专有名词、编号、精确型号无能为力。比如用户搜“BUG-2048”向量检索可能把它当普通token给打散关键词检索却能精准命中代码块里的“BUG-2048”。所以成熟方案往往用向量检索 BM25关键词检索并行再用重排器合并两者结果。这个叫Hybrid Search在ES、Milvus里都能配置。重排器选择上国内开源推荐bge-reranker-base实测中文效果不错如果追求更高精度可以上cross-encoder模型代价是推理速度慢些。重排阶段一般只看Top-50所以速度压力不大。3.3 构造Prompt与生成约束怎么把检索结果喂给大模型Prompt是让大模型“听话”的最终关卡。很多RAG系统检索没问题但Prompt写得太开放导致模型还是凭记忆写答案。我常用的RAG Prompt骨架是这样你是一个基于检索资料的问答助手。请仅根据以下资料回答用户问题。 如果资料中没有足够信息请直接回答“资料库中未找到相关信息”不要编造。 资料 【1】来源公司制度-离职流程.pdf 第3页 “离职需提前30天书面申请……” 【2】来源公司制度-离职流程.pdf 第7页 “未结清费用将从最后一个月工资中扣除……” 问题 离职手续有哪些注意事项 请用清晰的条目列出步骤并标注每步对应的资料来源编号。这个Prompt有几个关键设计“仅根据资料回答”是硬约束抑制幻觉“资料中没有就说不知道”给了模型一条“安全出口”避免它强行胡诌来源编号让答案可追溯用户能核对问题放最后、资料放前面符合大模型的注意力偏好另外一个实操细节如果检索到的资料塞满了上下文但其中一部分与问题无关大模型容易“分心”。可以在把资料拼入Prompt前先做一次“片段排序”或过滤只保留重排后最相关的片段。有些框架比如LangChain的MapReduceQA会把多片段的答案分别生成再汇总效果更干净但耗时更长适合离线分析场景。3.4 本地化部署参考Ollama 本地向量库的简易方案现在很多团队想先跑通一个“零基础可复制”的本地RAG。我推荐用Ollama BGE嵌入 Chroma。整个流程不需要GPU也能跑CPU慢一些适合学习验证。第一步安装Ollama并拉取模型。以中文场景为例ollama pull qwen2.5:7b ollama pull bge-m3第二步安装Python依赖pip install langchain langchain-community chromadb sentence-transformers第三步写一个简单的索引脚本把本地文档切分、向量化、存入Chromafrom langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import Chroma loader TextLoader(docs/help.txt) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size300, chunk_overlap50) chunks splitter.split_documents(docs) embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, query_instruction为这个句子生成表示以用于检索 ) vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db ) print(索引完成)第四步写检索问答脚本from langchain_community.chat_models import ChatOllama from langchain.chains import RetrievalQA llm ChatOllama(modelqwen2.5:7b, temperature0) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), chain_typestuff ) answer qa.run(退货政策是什么) print(answer)这套流程能跑通后再考虑换成更重的方案比如用vLLM部署大模型服务承载更高并发用Milvus管理大批量知识库或者用Dify这类平台把RAG流程可视化。但底层组件和核心思路是一样的。对于企业私有化部署把Ollama替换成vLLM把Chroma换成Milvus再做好权限控制和审计追踪就是一个可落地的生产方案。4. RAG实战中的瓶颈、常见问题与排查技巧4.1 检索不准、噪声干扰、上下文超限三大瓶颈怎么破先说检索不准。RAG的瓶颈大多不在模型而在检索质量。用户提问“怎么申请报销”你的知识库里可能同时有“员工报销流程”“差旅报销标准”“发票合规指南”向量检索返回的前几名可能只覆盖了流程没覆盖标准。解决思路是混合检索加重排同时优化切分粒度让每个片段具备完整的“业务含义”。另一个坑是Embedding模型选型不对中文业务术语密集的场景通用英文Embedding效果很差。实测BGE-M3在中文上明显优于较早版本的text-embedding-ada-002。再说噪声干扰。检索出的片段里有大量重复、宣传语、表格乱码会把模型带偏。我遇到过一篇产品手册页面页脚反复出现“版权所有翻版必究”切分后成了多个chunk检索时占比过高导致模型回答“翻版必究”而不是产品参数。解决办法是清洗文档去除页眉页脚对表格内容单独解析不能简单把表格转成文本就完事。最后是上下文超限。大模型有窗口限制比如4K、8K、128K但你不能所有片段都塞进去塞得越多注意力越稀释。一般控制在3-5个精排片段就好。如果检索需求确实多可以先用“Map-Reduce”方式把每个片段单独总结再合并总结摘要但牺牲了速度和成本。4.2 常见问题速查表症状、原因与解法我把实战里见过的高频问题整理成一张速查表可以直接当排查手册用。症状常见原因解决办法检索结果明显与问题无关Embedding模型不适合业务语言换成中文专用模型BGE/M3E并测试几种模型答案在资料里有但模型答错切分把关键信息截断增加chunk_overlap按结构切分减少chunk_size模型仍然编造答案Prompt约束不够强制“仅根据资料回答”资料不足时拒绝回答检索速度慢向量库索引未配置IVF/HNSW调整索引类型优化批量写入生成的回答结构混乱片段过多、顺序乱重排器精排后再拼Prompt限制片段数量同义词搜索不到纯向量匹配对专有名词不友好加入BM25关键词检索混合召回更新文档后旧结果还在切分或向量ID未关联文档版本按文档hash做版本管理旧的chunk批量删除多轮对话答非所问对话历史混淆了当前问题独立做query改写再检索不把整段历史塞入检索图片内容完全没被索引到未做多模态解析用视觉大模型生成图片描述后再向量化本地部署反应太慢无GPU且模型过大换小模型量化版或将嵌入模型换轻量版本这里重点提一下query改写。用户多轮对话中说“那如果晚一周呢”单独看这句话没法检索。正确做法是用大模型先结合对话历史把query改写为完整问题比如“离职申请晚一周提交会有什么影响”再做检索。我在LangChain里用ConversationalRetrievalChain时遇到过类似问题后来改成先改写再检索准确率提升明显。4.3 RAG与大模型微调的选型矩阵别再纠结二选一聊到这里可以再回头深入比较一下RAG和微调。我在1.3用了选型逻辑这里给出一张更具体的决策矩阵方便你直接对照业务场景。对比维度RAG微调知识更新时间分钟级重新入库即可天级到周级训练、验证、部署成本存储和检索资源为主无需训练GPU需要高性能GPU训练成本翻几倍可解释性高答案可溯源到原文档低模型内部权重难解释私有数据安全性数据以文档存储可控可审计数据被“揉进”模型参数无法单独摘除模型风格改变弱只能通过Prompt引导强可以重塑语气、格式、输出习惯所需数据量少几篇文档就能跑多至少几千条高质量样本才见效维护复杂度文档治理工作持续存在权重版本管理复杂从热搜词里能看到很多人同时搜“rag”和“大模型微调”说明大家都在两者之间摇摆。我的建议是首个版本不要微调先把RAG跑通把知识库清洗、切分、检索调优做到位如果仍然觉得回答风格不像自己公司的人再收集一批“问题-标准答案”对去做微调。微调和RAG结合的最佳姿势是用RAG控制事实来源用微调控制表达方式。5. 我个人在实际操作中的几点体会做了几年大模型应用落地处理过合同问答、设备维修辅助、客服知识库、科研文献综述等不同场景踩过的坑比教程里写的多得多。最后分享三点掏心窝的体会。第一先建评测集再谈优化。没有评测集的RAG项目就是盲人摸象。我从一开始就给每个知识库建立20到50条测试问题每条问题标注好理想答案和来源文档。每次改切分、改检索、改Prompt都用同一套测试集跑一遍看准确率变化。很多团队上线前才发现效果不行就是因为没有评测集兜底。第二检索质量决定天花板Prompt只是逼近天花板。我之前花大量精力调Prompt后来发现症结在于检索回来的片段本身就不对再怎么写“请仔细阅读资料”都白搭。优先看召回结果人工检查检索到的前5条是不是包含正确答案如果连检索都不准调Prompt没用。第三最小闭环比大而全的方案重要。不要一开始就上Milvus集群、上重排模型、上多模态解析。先用最简单的Ollama加Chroma跑通一个文件的知识问答然后逐步加功能。很多项目死在“设计过度连一个文档都跑不通”的环节。跑通最小闭环后你会对RAG的瓶颈有体感再优化就有了明确方向。好了RAG和大模型的关系说完本地代码也给了坑也排了。你可以直接复制第三部分的脚本跑一遍然后把测试问题换成自己业务里的真实问题看看检索效果你会比我写再多文字更能理解RAG的价值。