RAG这个词现在丢进任何技术群都能炸出一圈人但真追问一句RAG到底在解决什么问题你会发现大部分人只答得出半句不就是给大模型喂资料嘛。这不算错但跟真相差得有点远。RAGRetrieval-Augmented Generation检索增强生成确实是围绕外部资料做文章的可它真正要解决的是大模型在真实场景里完全没法直接用的那几大硬伤幻觉、知识过期、私有知识不可见、答案不可追溯。这篇文章是这个系列的第一篇我想从最底层的为什么要RAG讲起然后把知识库怎么选、框架怎么挑、在Mac上怎么搭本地RAG、文本拆解工具怎么选以及我踩过的瓶颈和排查经验一次性摊开聊明白。无论你是在翻RAG教程准备入门还是已经在跑RAG项目但总觉得效果不对这篇的内容应该都能给你点实际参考。1. RAG到底在解决什么问题1.1 大模型装不下的那些事先说最直接的痛点。你在公司内部做个文档问答助手把大模型接上去了结果同事问一句咱们去年的报销流程是什么模型一本正经地编了一个完整流程出来还编得挺合理——这就是幻觉。大模型本质上是字词接龙大师它并不知道自己不知道它只会用概率分布给你拼一个最像样的答案。这个毛病在开放域闲聊里无伤大雅但在企业知识问答、客服、法律、医疗这些场景里就是致命的因为用户根本没有能力分辨哪些是对的、哪些是模型编的。第二个痛点是知识陈旧。大模型的训练数据有截止日期做完预训练之后它对新发生的事情一无所知。你问它一个上个月刚发布的产品版本参数它只能根据训练数据里的旧版本去猜猜出来的东西自然是错漏百出。第三个痛点是私有知识完全不可见。企业内部文档、个人笔记、专业领域资料这些内容根本不在大模型的训练数据里。你问它一百遍它也答不出来因为它没见过就是没见过这不是靠提示词能解决的。第四个痛点是答案不可追溯。普通对话模型给你一个答案但你没有任何办法知道这个答案的依据是什么一旦出了错连查都无从查起。这四个痛点叠加在一起导致大模型在真实业务里光靠通用能力根本落不了地。很多人第一反应是微调但微调的本质是让模型把特定知识背进参数里。且不说微调的成本高、周期长更麻烦的是每更新一次知识就要重新调一次模型这在知识快速变化的场景里基本行不通。你总不能为了改一条报销流程就去重训一次模型。我在做第一个RAG项目的时候项目方提的需求特别朴素把公司客服的几千条历史工单变成知识库让新人客服能直接问出标准答案。当时想着大模型这么强接上API应该轻松搞定结果跑起来才发现工单里的客户骚操作、产品简称、命令参数全在模型训练数据之外编出来的答案一个比一个离谱。那一刻我才意识到光有模型能力真不够必须有一个能把外部知识精准塞进回答链路的东西。1.2 RAG的本质开卷考试RAG的思路则完全不同。你可以把它想象成一场开卷考试闭卷考的是你的记忆能力开卷考的是你知道去哪查、查到之后怎么用。RAG先把知识库里的文档切成片段、做好索引用户提问时系统先检索出最相关的几个片段再把片段和问题一起交给大模型让它在看着资料的状态下作答。为什么这个思路有效因为大模型虽然记忆不靠谱但它理解语言、组织语言的能力很强。你给它一段相关资料它能读明白并用自己的话把答案组织出来。RAG说白了就是把记忆这个最不靠谱的环节从模型里摘出来换成数据库这种精确可靠的存储让模型专注于做它最擅长的事——理解和生成。这也是为什么RAG检索增强能在大模型落地中迅速成为标配而不是什么冷门技巧。你可以把它理解成给模型配了一个可以随时翻阅的资料架比让它把书都背下来可靠得多也灵活得多。2. RAG的核心流程与组件拆解2.1 索引阶段从文档到向量的流水线RAG项目实操起来第一个环节是知识库构建也就是索引阶段。整个过程分四步文档加载、文本切分、向量化、存储。文档加载没什么好说的PDF、Word、Markdown、HTML各种格式都有对应的解析库。但这个环节真正的坑在切分上。大模型的上下文窗口再大也是有限的你不能把一整本书全塞进去而且检索系统需要按语义块来匹配不是按整本书匹配。所以得把文档切成一个个片段这个片段在RAG术语里叫Chunk。切多碎合适这个没有标准答案取决于文档类型和检索需求。我见过最省事的做法是固定字数一刀切比如512个字符切一块。它简单但问题也多可能把一个句子的语义拦腰切断也可能把前后本应连在一起读的段落硬生生拆开导致检索时召回一堆残缺片段。更好的做法是按文档结构切比如Markdown的标题层级、PDF的章节、段落的空行。按结构切的好处很明显切出来的每块都有相对完整的语义边界下游检索和生成都会舒服很多。这个环节千万别图省事我见过太多项目最后效果不好回溯下来都是切分惹的祸。给你一个参考数值对一般企业文档我通常把块大小设置在400到800字之间重叠50到100字对技术手册块可以稍大一些因为技术描述经常需要前后文一起理解。如果是Markdown结构文档完全可以用标题层级切那样更有把握。向量化是索引阶段的第三步。这一步要把每个文本片段扔进Embedding模型转成一长串浮点数也就是向量。向量的精髓在于语义相近的两个文本它们的向量在高维空间里距离更近。报销流程和费用申请流程在字面上差得挺远但在向量空间里可能挨得很近。最后一步是存储把向量和原始文本存进向量数据库常见的有Milvus、Qdrant、Chroma也有直接用PostgreSQL加pgvector插件的。存储本身不难但后续检索是否高效、能否支持百万级向量的相似度查询很大程度上取决于这一步的选型。2.2 检索阶段怎么把最相关的片段捞出来索引建好之后每当用户提问系统就把问题也转成一个向量然后去向量库里做相似度计算取最相似的Top-K个片段。这一步就是RAG里那个R也就是Retrieval检索的核心动作。相似度计算最常用的是余弦相似度通俗讲就是看两个向量的方向有多一致。听起来不复杂但实际在RAG项目里单纯靠向量检索往往不够。原因在于Embedding模型对字面差异、专有名词、数字信息并不敏感。你问2024年Q3的销售额是多少向量检索很可能把2023年的数据也召回来因为语义太接近了数字本身的差异被模型忽略了。所以现在的主流做法是做混合检索向量检索加关键词检索并行跑再用重排序模型Reranker把两路候选结果综合打分。关键词检索负责精确命中专有名词和数字向量检索负责语义泛化Reranker负责最终排序。这套组合拳的效果比单一路径好用一大截代价是多一个环节、多一份延迟但通常这个延迟是值得的。我自己的项目里混合检索加Rerank之后召回准确率提升非常明显具体数据后面在瓶颈部分细说。2.3 生成阶段Prompt组装是门手艺检索回来几个片段接下来要组装Prompt了。这一步的细节直接决定最终答案的质量。基础的Prompt结构一般是系统指令、背景说明、候选片段、用户问题、输出要求。看起来就五样东西但怎么组织很有讲究。我在实际项目里踩过不少Prompt相关的坑。第一个坑是把太多片段全塞进去指望模型自己挑重点。上下文一长模型容易被无关信息干扰反而忽略关键片段。第二个坑是忘记写只根据提供的资料回答。如果不加这句模型一旦遇到它熟悉的话题就会被内部记忆带着跑开始自由发挥。第三个坑是忽略引用溯源。在正式场景里要求模型在回答里标注信息来源非常重要出了问题你至少能追溯是哪段资料引起了误解。这三点现在几乎成了我做RAG问答的默认配置缺一不可。3. 知识库形态怎么选向量库、KG知识库还是结构化数据库3.1 向量知识库是RAG的默认配置现在市面上绝大多数RAG项目知识库都是向量库。文档、PDF、网页抓下来的纯文本切块向量化存进去。这套方案最大的优点是简单通用什么文本都能往里塞不需要额外做人工建模。适合的角色包括企业制度文档问答、产品说明书查询、FAQ问答、个人笔记检索。说到底它就是把非结构化文本变成可检索的切片。但向量知识库解决不了关系推理。你问哪些客户的订单金额超过五万且退货率低于百分之二哪怕文档里所有信息都存在单纯靠文本切片也拼不出一个准确的跨字段答案。因为这个问题已经不属于文本检索了它是一个结构化查询问题。这也是为什么需要下面两种变体。3.2 KG知识库与Ontology RAG关系密集型场景的解药于是有了KG知识库也就是知识图谱。知识图谱的核心是实体—关系—三元组。比如王小明—就职于—研发部研发部—属于—公司A。把文档里的实体和关系抽出来建成一张图就能支持多跳查询从王小明出发找到他所在的部门再找到该部门负责的所有项目再定位项目的负责人。这在金融风控、医疗诊断、科研文献这类关系密集、术语严谨的场景里价值非常突出纯向量检索根本做不到这种跨实体的组合查询。Ontology RAG是知识图谱方向上更进一步的玩法。Ontology也就是本体它给知识图谱定义了类型体系有哪些类型的实体比如人、组织、产品、事件实体之间有哪些关系比如雇佣、生产、隶属于、发生于。有了本体之后模型能更准确地理解公司员工和公司CEO在语义上的差异检索和问答的准确度都会更高。我在一个垂直领域的项目里试过用本体约束图谱效果确实比无组织的关系抽取稳很多。但这个方案的代价同样明显构建知识图谱需要投入人力做实体抽取、关系定义和质量控制。本体设计本身就是专家活普通团队硬做很容易做成四不像。我的建议是先判断场景到底是不是关系密集型。如果只是简单文档问答就别费劲上图谱了向量库完全够用。3.3 结构化知识库与Wiki的定位再有一种形态是结构化知识库也就是表格和数据库本身。销售数据在CRM里库存数据在ERP里这些都是结构化数据没法简单切块向量化。对这种数据做RAG主流做法是Text-to-SQL让大模型理解用户问题生成SQL查询把查询结果从数据库拿出来再交给大模型整理成自然语言回答。这条路的难点在于大模型生成的SQL准确率需要仔细打磨一不留神就会查错字段。进阶做法是先做元数据检索让大模型从一堆表和字段里选出相关的那部分再生成具体查询流程更长但可控性更好。聊到Wiki和RAG的关系其实很有意思。Wiki本身就是半结构化文本有目录、段落、链接、信息框所以很多公开的RAG评测集都基于维基百科构造比如Natural Questions、HotpotQA。因为Wiki的文档结构相对规整切分起来不头疼特别适合当基准测试。但真实企业里的文档普遍没有Wiki那么规整很多老旧的PDF连目录都没有。所以别指望跑通一个用Wiki数据的RAG教程就能直接套用到自家乱七八糟的文档上中间还有大量清洗工作要做。3.4 知识库到底能不能存图片热词里有个高频问题RAG知识库能存储图片吗严格说纯文本的RAG链路处理不了图片因为常规Embedding模型只能编码文本。但如果你用的是多模态Embedding模型比如CLIP系列图片可以被编码成视觉向量同样可以参与向量检索这就构成了多模态RAG。在实际项目里我一般建议别一上来就多模态。更务实的做法是把图片当作附件处理对图片做OCR抽取文字或让模型生成一段图片描述再把文字描述放进知识库。这样既能保留图片信息又不破坏文本检索的简单性和稳定性。如果业务场景确实需要以图搜图或者图文混合检索再上多模态RAG不迟。总的原则是能靠文本解决的先别加复杂度。4. RAG框架、本地部署与工具选型4.1 主流RAG框架怎么选聊完原理和知识库形态回到实操。现在RAG框架一大堆最常见的是LangChain、LlamaIndex、Haystack三个。我说说自己的选型体会。LangChain生态最大组件最多文档也丰富但抽象层太厚出了问题经常要追着源码才能定位。LlamaIndex一开始就专注文档索引与检索对RAG场景更聚焦代码量最小适合快速验证想法。Haystack来自deepset团队有完整的Pipeline编排思路生产化程度不错。你让我做推荐更偏向这样看想快速跑通验证直接选LlamaIndex要做带Agent的复杂工作流LangChain案例最多如果对检索管线有明确设计要求且偏生产Haystack值得重点看。除了这三个近两年还冒出不少轻量级项目。选型时我重点看三件事一是社区活跃度决定你踩坑时能不能搜到答案二是底层组件的抽象粒度太粗和太细都别扭三是接口稳定性。一些项目更新太快API每天都在变今天写的代码下周就废这种我一般不敢用在正式项目里。框架本身其实不是项目成败的关键对业务数据的理解才是。4.2 在Mac上搭建本地RAG知识库很多人搜怎么在Mac上搭建RAG知识库我猜是想本地跑起来验证又不想花API的钱。我实测下来Mac上搭建本地RAG完全可行核心就三步装一个本地大模型运行时、装一个向量库、写代码串起来。本地大模型运行时现在用Ollama最省事下载安装命令行拉模型一条命令跑起来。Mac对内存要求很苛刻我建议至少16GB内存起步32GB更舒服。模型大小方面7B级别的模型在M1/M2芯片上勉强能用速度一般13B以上除非内存奇大否则别硬上。向量库本地一般用Chroma或者sqlite-vec最轻量Milvus Lite也可以在Mac上跑。我自己的M1 MacBook Air8GB内存跑7B模型加上Chroma回答一个问题大概十几秒演示和个人笔记问答可以接受如果换M1 Pro或者M2芯片体验会好很多。脚本环节用LangChain或LlamaIndex把本地Embedding模型和本地LLM接进去读文档、切分、向量化、建索引、检索、生成一条流程下来并不复杂。我补充一句本地搭RAG最大的价值不只是省钱而是隐私。很多企业内部数据根本不允许出内网本地跑通意味着后续可以平滑迁移到私有化部署环境这个价值比省API费用大得多。4.3 本地文本拆解工具怎么选热词里还有一句有没有本地的RAG文本拆解工具。文本拆解也就是Document Parsing和Chunking确实是决定RAG质量的核心环节而且最容易被低估。我常用的本地工具分两类。一类是通用文档解析。Unstructured是我用得最多的开源库能处理PDF、Word、HTML、PPT还带表格识别和文档分块能力。Docling是IBM开源的文档解析库PDF版面分析做得不错尤其是表格和图片位置还原。Tika是Apache的老牌项目主打格式识别和文本抽取胜在稳定。textract也可以一揽子抽取但它依赖多装起来有时折腾。我在项目里一般优先Unstructured或者Docling效果基本符合期待。另一类是精细化切分工具。LlamaIndex和LangChain都自带切分器从最基础的按固定长度切到按结构的MarkdownHeaderSplitter再到综合的RecursiveCharacterTextSplitter都有。实际使用下来MarkdownHeaderSplitter对规整文档很友好RecursiveCharacterTextSplitter是默认选择。如果追求更智能的切分可以试试基于Embedding的语义切分器思想是根据句向量之间的突变点切分块与块之间语义更完整代价是慢。我这套方案是先Docling解析文档保留标题层级和表格位置再用Markdown结构切分器切块实测下来对PDF手册和Markdown笔记的检索都比较稳。5. RAG的瓶颈与实战避坑5.1 检索质量瓶颈是最普遍的痛RAG效果不好的头号原因八成在检索环节。症状很典型用户问A召回来的资料全是B相关模型只能基于B语料硬编答案最后答非所问。检索质量差的根源常见的有几个。第一Embedding模型选得太随意。通用Embedding模型到了垂直领域比如法律、医疗、代码专业术语一多向量表示就会失真。第二切分粒度不合适。切碎了相关段落被拆得七零八落切粗了一个块里混了一堆主题相似度计算被噪声带偏。第三只用向量检索没有关键词兜底。专有名词、缩写、版本号、数字这些恰恰是向量检索最容易丢的。我目前验证下来最稳的组合还是混合检索加Rerank。向量检索和关键词检索并行合并结果后交给Reranker统一重排。相当于先粗筛一遍再精排一遍虽然多了一步延迟但召回精度提升非常明显。在内部文档问答场景实测引入Rerank之后答案准确率能提高两到三成属于性价比很高的优化方案。如果你只让我给一个建议那我一定推荐这个。5.2 切分粒度一个反复踩的坑切分是RAG项目里看着简单、实际最磨人的环节。复盘过不少失败的RAG项目之后我发现切块太粗和切块太碎是两个极端而且都极其常见。太细的例子按200字符切一个完整的操作流程被截成五六段用户问完整的操作流程是什么系统只召回其中一两段答案自然残缺不全。太粗的例子干脆不切把整章文档当一个向量检索时相似度被大量无关句子稀释召回内容跟问题对不上。比较实用的经验是先看文档结构再决定切法。有标题层级的多级结构文档用结构切分器按章节切开块与块之间保留标题前缀这样模型能知道当前段落属于哪个主题。连续的长文没有清晰标题用递归字符切分器优先按段落切保持语义完整。另外有个小技巧切分时每段之间保留少量重叠比如50到100字。这样即使关键语义正好跨在切分边界上检索时也能通过重叠部分把完整信息捞回来。这个技巧简单但解决了很多疑难杂症。5.3 多跳问答与推理瓶颈RAG的另一个瓶颈是多跳问答。所谓多跳就是答案藏在多个资料片段里需要把两个甚至更多片段的信息组合起来才能得出结果。简单检索只做一轮很难把这些分散的信息凑齐。举个例子用户问上一季度销量最高的产品现在库存还够吗。你需要先查出哪个产品销量最高再查这个产品当前库存。两步属于不同信息片段单轮RAG大概率答不上来。目前的解法有几个方向一是Agent式RAG让模型自行规划检索步骤一步一步检索并汇聚信息二是迭代式RAG先做粗检索根据初步结果补充检索三是结合知识图谱关系信息走图查询文本细节走向量检索两边合并。这些方案都能缓解多跳问题但没有一个能根治推理能力不足的问题。根本原因在于RAG只是把更多相关资料喂给模型并不能提升模型本身的推理逻辑。所以在多跳场景下Prompt设计要尽量引导模型分步思考把过程拆开再拼。多跳这块还有一个隐形坑评估。单跳问答的错误好定位多跳场景你根本不知道是哪一步检索带偏了。所以我建议项目里给检索过程加日志把每一步检索的片段和最终答案一起记录下来出了问题能拉出来复盘否则多跳场景基本等于黑盒。5.4 常见问题排查速查表最后整理一张排查速查表跑RAG项目遇到问题可以先按这个顺序排查大部分情况能定位到原因。现象可能原因处理建议检索结果与问题不相关Embedding模型不匹配或切块粒度不对换垂直领域Embedding调整切分策略加Rerank答案跟资料无关开始自由发挥Prompt缺少限定或上下文混入无关块写清只根据资料回答减少TopK数量回答内容残缺关键信息缺失相关片段被切碎只召回了一部分改善切分增大TopK加段落重叠回答太长超过模型上下文TopK太大或单块太长压缩TopK和块长用重排筛选关键段落有正确数据但模型答错查询向量与存储向量不一致统一Embedding模型确认没缓存旧向量检索很快但答案质量低缺少重排序TopK里噪声太多引入Reranker做二次筛选这张表是我在多个RAG项目复盘时攒下来的覆盖的是最常见的几类问题。每个项目的具体细节不同但排查思路基本通用——先怀疑检索再怀疑切分最后才怀疑模型本身。按这个顺序查很少会跑偏。6. RAG与智能体边界与演进6.1 RAG智能体是什么热词里还有RAG智能体这个高频项。简单说RAG智能体就是把RAG的检索能力作为底层的记忆工具交给一个有规划和工具调用能力的Agent去用。传统RAG工作流是检索一次、生成一次是一条固定直线Agent式RAG则让模型循环决策每走一步都问自己我掌握的信息够了没还要不要继续查。比如用户提一个复杂问题Agent先决定要不要检索检索完发现信息不够再决定换关键词重试拿到初步答案后可能还要验证答案的完整性。整个流程是动态的。我的理解是Agent是大脑RAG是记忆仓库工具是双手。两者结合之后多跳问答和信息综合能力确实比固定流程强不少但代价是系统复杂度、延迟、调试难度都上去了。我的建议很直接先把固定流程的RAG调好、调稳确定单轮已经顶不住了再引入Agent。否则一堆问题混在一起排查的时候会很痛苦。6.2 从能用到好用评估比框架更重要说实话RAG这个方向离终点还远得很。检索质量、切分策略、评估手段每个环节都有一堆开放问题。很多人跑通一个RAG demo之后就开始打摆子觉得效果不行于是到处换更神的框架。我的个人体会是框架解决不了数据问题。你花在文档清洗、切分优化、检索调参上的时间永远比换框架重要。如果真要往下一步走我最想叮嘱的是搭建评估体系。RAG项目能不能从Demo走到线上不取决于模型多聪明而取决于你能不能稳定评估每一次回答的好坏。没有评估你就永远说不清楚这次效果变好了是优化起作用还是运气好。我自己接下来想尝试的方向就是把高频问题沉淀成一个离线评测集每次改完切分或检索策略就全量跑一遍用指标说话。我个人从做RAG到现在最大的转变就是不再执着于换模型、换框架而是把精力放在检索结果的逐一检查上。所以如果你问我对新手有什么建议我的回答很简单先做一个最小可用的RAG流程然后把每个环节的输出打印出来多看几轮检索结果你自然知道问题出在哪。工具都是次要的对业务数据理解的深度才是RAG项目真正的分水岭。