前阵子一个朋友找我说他手头有一堆公司内部文档想让AI帮忙答疑。他原以为这事很简单把文档拖进对话框就行。结果试了一圈发现对话模型要么回复我不知道要么煞有介事地编出一段看起来挺合理、实际完全对不上的答案。他问我的时候我脑子里第一个跳出来的词就是RAGRetrieval-Augmented Generation中文叫检索增强生成。这不是什么高深的新概念但它恰好解决的就是模型知道的东西和你想让它知道的东西之间的那道鸿沟。这篇文章我想以初学者的视角把RAG从原理到实战、从踩坑到进阶完整讲一遍。不管你是想给自己的知识库加一个问答入口还是单纯想弄清楚热搜里那些RAG框架RAG智能体到底在说什么这篇文章应该都够用了。1. 先想明白RAG到底在解决什么问题1.1 大模型天生有三块短板大模型确实很能聊但认真用起来你会撞见三个非常具体的问题第一是幻觉。模型不知道答案的时候它不是老老实实说不知道而是会编。而且编得特别自然偶尔还带着根据公开资料显示这种伪引用。原因不复杂大模型本质上是在预测下一个词的概率分布它追求的是流畅合理不是事实正确。第二是知识截止时间。训练一次大模型要花几个月、烧掉大量算力所以它的知识往往停留在某个时间点。你问最近上市的产品参数、最新的行业政策它答不上来或者答错是必然的。第三是私域知识盲区。你的公司制度、项目复盘、设备手册、个人笔记这些内容全世界只有你自己有模型在训练时根本没见过。想让它理解这些资料靠聊是聊不出来的。这三块短板决定了把文档丢给大模型这个朴素想法必然失败。那怎么办有三个常见路径微调、把文档全塞进提示词、RAG。1.2 为什么不是微调也不是硬塞文档微调看起来最直接——让模型记住你的资料。但实际操作下来它有几个很麻烦的代价需要整理标注数据训练周期以天为单位成本不低而且知识一旦更新就得重训。微调更适合改变模型的行为风格比如让它说话更简洁、更像客服不太适合注入那种高频变化、动辄几百上千份的文档知识。把文档硬塞进提示词呢这个方法在小规模场景临时用用确实有效果但受限于上下文窗口大小。文档稍微多一点先超的是上限即使强行塞进去模型处理超长输入的注意力会分散经常把最早的内容忘掉而且每次请求都要把这堆内容重新传给模型接口费用直线上升。RAG的思路完全不同它不试图让模型记住任何东西而是把知识放在外部存储里每次用户提问的时候先去知识库里检索出最相关的几段资料把这几段资料连同问题一起交给模型让模型带着参考答案作答。你可以把它理解成开卷考试和闭卷考试的区别——微调和硬塞都是在努力让模型闭卷记住而RAG干脆让模型开卷查资料。1.3 RAG不改变模型改变的是输入这里有个新手很容易误解的点RAG全程没动大模型本身的参数。它只是在你提问时临时从外部知识库里找了一些资料拼进提示词里。这套流程看起来简单但想象空间非常大因为它意味着你的知识库可以随时增删内容——今天放进一份新文档明天就能被检索到某份文档过时了从库里删掉就行。知识不再被锁在模型参数里而是变成了一块可以自由插拔的外部硬盘。这也是RAG这两年热度一直很高的根本原因。它解决的不只是答错的问题还顺带解决了知识更新和回答可溯源的问题。检索出来的资料是可见的模型为什么这么答你可以查可以审可以在出错时追责。这一点在企业场景里太重要了。2. 一次完整的RAG请求内部到底发生了什么很多教程一上来就甩代码我反而建议先弄明白流程。一次RAG请求从发出到返回内部其实分三个阶段知识入库、向量检索、增强生成。你可能听过索引分块embedding这些名词它们全部落在这三个阶段里。2.1 知识入库解析、清洗与分块RAG的第一个阶段是离线进行的——你要先把文档喂给系统。这里的文档可能是PDF、Word、Markdown、网页甚至是一堆纯文本。系统要做三件事解析把不同格式的内容提取成纯文本。PDF尤其麻烦扫描件还要先过OCR不然提取出来全是乱码。清洗去掉页眉页脚、重复的空行、无意义的表格碎片。分块把长文本切成一个个大小合适的段落块。分块这个环节是新手最容易轻视、但实际影响最大的一步。块太大检索出来的噪声多模型答得笼统块太小语义不完整检索经常命中半句话。我之前处理一份技术规格文档时早期用固定512字符切分结果把一个表格的列名和数据切到了两个块里模型回答时怎么都对不上。后来改成按章节标题切用递归分裂器优先保留段落边界问题立刻缓解。热搜词里有有没有本地的rag文本拆解工具确实是个普遍需求。常见的开源工具包括unstructured能处理PDF、Word、HTML等多种格式并输出结构化元素、pdfplumber专门啃PDF处理表格和版面信息比较稳、textract老牌文本提取库。如果你用的是LangChain或LlamaIndex这类框架它们内置的分裂器比如RecursiveCharacterTextSplitter、MarkdownHeaderTextSplitter也足够满足大部分需求。选工具的核心标准就一条你的文档是什么格式为主、结构性强不强。纯Markdown笔记用内置分裂器就够了没必要额外上重工具。2.2 向量化把句子变成坐标分块完成后下一步是对每一个文本块做向量化embedding。所谓向量化就是用一个嵌入模型把一段文字转换成一串几百到几千维的浮点数。听起来玄乎你可以把它理解成给每个文本块在语义空间里标了一个坐标语义相近的句子坐标距离就近语义无关的句子坐标就散得远。这一步替代的是传统的关键词搜索。你可能遇到过这种情况用CtrlF搜故障原因文档里写的却是宕机分析结果搜不到。关键词匹配只能找字面相同向量检索却能理解语义相近。搜故障原因它能看见写宕机分析的那一段。向量化之后的文本块会被存进向量数据库。Chroma、FAISS、Milvus、Qdrant都是这个领域的常见选手。向量库的核心能力可以用一句话概括你给我一个查询向量我快速返回库里最相似的K个向量。相似度的计算方式常见的有余弦相似度、内积、欧氏距离工程上余弦相似度用得最多因为它在归一化之后不受文本长度影响。这里有个实用建议嵌入模型的选择要和你后面的生成模型匹配。你拿英文场景的embedding模型处理中文文本效果会明显打折反过来也是一样。中文场景下目前比较稳的选择有BGE系列bge-m3、bge-large-zh和m3e等。另外嵌入模型的维度也值得留意高维度通常表达能力更强但存储和检索的开销也更大入门阶段不必刻意追求大模型。2.3 检索与重排相似度不是全部用户提问之后系统会把问题也做一次向量化然后去向量库检索最相似的K个文本块K通常设为4到10。这一步叫召回。召回的块再多也有噪声所以现在工程上普遍会加一个重排环节用一个专门的排序模型reranker对上一步召回的块重新打分排序。为什么需要重排因为向量检索擅长找相关的东西但不擅长精确判断哪个最相关。举个我实测过的例子我拿一份公司差旅制度文档做RAG问出差住宿标准是多少向量检索召回的前几名里有住宿标准相关段落也混进了出差审批流程这种沾边但不含答案的段落。重排模型能把不相关的内容压到后面让真正的答案排到前面。如果只是做个入门Demo可以暂时跳过重排如果准备上真实业务建议一定要加。另外还有一类做法叫混合检索把向量检索和传统的BM25关键词检索结合起来两边的结果merge后再重排。在专业术语密集的法律、医疗领域这种做法几乎成了标配因为关键词能精准命中术语向量能处理同义改写两者互补。2.4 生成让模型带着答案开卷答题检索到相关内容后系统会把用户的问题和这些文本块拼成一个提示词交给大模型生成最终回答。提示词里通常会写你是一个知识库问答助手请仅根据以下提供的资料回答用户问题如果资料中没有相关信息请明确说明资料中未找到相关内容不要自行编造。这里有个判断值得留意很多人以为RAG是把整篇文档都塞给模型其实不是。系统只取出最相关的几块数量有限token消耗可控。这也正是RAG能够突破上下文窗口限制的原因——它不追求把文档都记住只追求把答题需要的部分精准找出来。从开卷考试这个视角看RAG还有个容易被忽略的好处你可以让模型在回答里标注信息的来源段落。用户点了问题能看到答案来自第三段第三节这种可追溯性在内部知识库场景里基本是刚需。3. 从零搭一个能跑的RAG项目工具选型与Mac环境实测理论讲完该动手了。我注意到搜索词里有一个很具体的问题怎么在mac上搭建rag知识库。我自己就在Mac上搭过几套RAG环境这里把选型思路和实际踩过的坑一起说清楚。3.1 初学者的工具选型三档方案怎么选我建议RAG初学者先想清楚一个问题你要不要全本地这会直接影响你接下来所有的工具选型。我把常见的方案分成三档Mac上均适用方案组成适合场景上手难度全托管Dify/Coze等平台或云API云向量库快速验证想法不想折腾环境低半本地本地向量库 云端大模型API文档敏感度不高追求回答质量中全本地本地向量库 本地模型Ollama/llama.cpp隐私敏感、免费探索、离线使用中高开源框架方面想用代码灵活组装的话LangChain和LlamaIndex是目前生态最活跃的两个想要带界面、开箱即用的应用可以看RAGFlow、Quivr、Dify。我的真实建议是第一次跑通流程要么选全托管的Dify要么选半本地——本地向量库负责存文档云端API负责回答。这两个方案能让你先避开一堆环境问题把注意力放在理解RAG流程上。等能力到位了再切全本地不迟。3.2 Mac上搭建的具体步骤与踩坑记录以全本地方案为例我讲一下为什么这么选不花钱、数据不出本机、断电断网都能用。Mac上最省事的本地模型运行工具是Ollama它把模型下载和运行封装得很好一条命令就能拉下一个能跑的模型。基础步骤如下在终端执行# 安装Ollama也可以直接去官网下载桌面版App brew install ollama # 拉取生成模型中文场景推荐qwen2.5系列7B是性能/资源平衡点 ollama pull qwen2.5:7b # 拉取嵌入模型 ollama pull nomic-embed-text # 或选择中文效果更好的bge-m3 ollama pull bge-m3 # 启动Ollama服务桌面版一般会自动起命令行版需要手动 ollama serve然后创建Python虚拟环境安装核心依赖python3 -m venv rag_env source rag_env/bin/activate pip install langchain langchain-community langchain-chroma chromadb这里有几个Mac上很真实的坑提前告诉你省点时间第一内存是硬约束。Mac统一内存的设计让CPU和GPU共享内存跑模型时模型权重要全部加载进内存。一个7B参数的模型4bit量化后大约占4~5GB运行内存如果你的Mac只有8GB内存建议换成qwen2.5:3b或者更小级别的模型否则系统会疯狂换页卡到你怀疑人生。我自己的16GB Mac跑7B模型开一个Chrome浏览器再跑RAG流程内存基本见底。入门阶段用小模型跑通流程完全够。第二首次加载模型很慢这是正常的。本地模型不像云端API那样秒回第一次加载要等几十秒甚至更久之后会好一些。嵌入模型也一样第一次向量化文档时Mac上的PyTorch MPSApple的GPU加速框架对部分算子支持不完整速度可能不如CPU推理别误以为死机了。第三向量库的持久化路径一定要显式指定。Chroma如果不指定路径默认存在临时目录你重启电脑之后会发现知识库不见了。正确做法是显式指定一个项目目录vectorstore Chroma( persist_directory./chroma_db, embedding_functionembeddings )第四如果你带的模型回答质量问题不要怀疑——本地7B小模型的生成质量确实比云端GPT级别的大模型差一截尤其在做长文本概括时会有明显差距。这属于预期内的情况不是你的RAG代码写错了。3.3 最小可跑的代码骨架下面这段代码是我在Mac上用Ollama加Chroma跑通的最小可运行骨架。前提是你已经按上面步骤装好依赖、拉好Ollama模型from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.llms import Ollama from langchain_chroma import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 1. 加载文档分块 loader TextLoader(./knowledge_base.txt, encodingutf-8) documents loader.load() splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(documents) # 2. 向量化并存入Chroma指定持久化目录 embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) # 3. 创建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 4. 组装提示词 prompt ChatPromptTemplate.from_template( 你是一个严谨的知识库助手。请仅根据以下资料回答用户问题。 如果资料中没有相关内容请直接说资料中未找到相关内容不要编造。 资料 {context} 用户问题{question} ) # 5. 组装RAG链 def format_docs(docs): return \n\n.join(f【来源{i1}】\n{doc.page_content} for i, doc in enumerate(docs)) llm Ollama(modelqwen2.5:7b, temperature0.2) rag_chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | llm | StrOutputParser() ) # 6. 提问 answer rag_chain.invoke(这份文档里提到的核心注意事项是什么) print(answer)几点补充说明。分块参数chunk_size300、chunk_overlap50是我处理中文笔记时比较常用的配置中文按。作为分界符收效明显。temperature调低到0.2是为了让模型更照本宣科减少自由发挥。LangChain迭代速度很快API偶尔有调整如果你的版本报错看下官方文档的迁移说明一般都能解决。4. 别踩这些坑召回质量、评估与看起来答对了的错觉跑通流程只是第一步。我见过很多人Demo跑通之后兴高采烈火速上线结果在真实文档上被问得漏洞百出。RAG这套系统最大的坑藏在一个你想不到的地方它自己也会一本正经地胡说八道。4.1 最隐蔽的问题检索错了后面全错RAG的错误传播路径是这样的如果向量检索召回的文本块本来就不相关模型拿到这些错误资料照样会基于它们编出一个看起来符合逻辑的答案。这个答案从措辞上非常流畅甚至比模型瞎编更有迷惑性——因为它确实参考了资料只不过参考的是不相关的资料。我处理过一个个案用户拿一份产品需求文档做RAG问登录功能有哪些权限控制检索出来的块里混进了密码重置流程的内容模型给出的回答虽然提到了权限细节全错而且错得有板有眼。当时如果不看溯源段落很难发现问题。这个例子说明RAG的质量上限取决于检索质量而不是生成模型的能力。以后再看到RAG效果好差先别急着怪大模型十有八九是检索环节的问题。4.2 分块策略的影响比想象中大分块这件事值得再多说几句。我踩过一个很具体的坑处理表格类文档时用固定长度的切分器结果把一个表格的表头和具体数据切到了不同块里检索到表头块时看不到数据检索到数据块时又不知道表头是什么意思。最后我把表格转成了列名值的自然语言描述再整体作为一个块入库效果才算正常。分块没有万能参数但有几个经验可以参考结构清晰的文档优先按章节标题分块句子特别长的专业文档块要适当调大避免把完整定义拦腰截断相反FAQ类短文本块可以调小方便精确命中。分块的核心目标是让一个块尽量成为一个完整语义单元。做一次小实验对比不同分块参数下的检索效果比看一百篇教程都管用。4.3 怎么评估RAG别只看答得顺不顺评估RAG新手最容易犯的错误是只看回答顺不顺、像不像那么回事。真正的评估至少要分三个维度检索命中率——正确答案所在的文本块是否被召回通常看top-K里有没有记为HitK忠实度——模型的回答是不是严格基于检索到的内容有没有自行发挥答案完整性——该覆盖的点是否都覆盖到了有没有漏答。具体做法上我会建议从第一天开始就建一个微型评测集挑20到30道覆盖文档关键内容的题目手动标注标准答案和来源段落。每次改动分块策略、换嵌入模型、调K值都拿这套题重新跑一遍。你可能会惊讶于一个小改动带来的结果差异。开源工具RAGAS可以做自动评估不过它本身也依赖大模型做裁判有误差入门阶段我建议还是以人工看题为主工具为辅。4.4 RAG的现实瓶颈它不适合回答所有问题热搜里rag瓶颈这个词的出现频率说明很多人在实践中碰壁了。RAG确实有几个客观存在的瓶颈下面这些是我亲身经历过的检索失败提问方式和文档写法差异太大时向量检索也可能找不对路。知识碎片化有些问题的答案分散在多个段落甚至多份文档里单次检索只能拿到其中一部分拼不出完整答案。结构信息丢失解析PDF时复杂的表格、图表、排版信息很容易丢失RAG对图表型知识天然弱势。统计与推理能力不足问过去三个月哪个部门提交的申请最多RAG需要先检索出所有申请记录才能统计这超出了单轮检索的能力范围。这些瓶颈不意味着RAG没用而是提醒你RAG最适合的是散落在文档里的局部性知识问答而不是全局性统计、推理、多跳分析。遇到后者就需要进一步升级方案了。5. 进阶路线当RAG不够用时还可以加什么如果你已经把基础RAG跑通也感受到了它的边界那么恭喜你你已经站在进阶路线的起点上了。这一章我围绕几个经常被搜到的概念讲清楚它们各自的定位。5.1 从RAG到RAG智能体常规RAG是检索一次回答一次属于单轮直线流程。真实问题往往更复杂我们部门这季度哪个项目的延期风险最高这种问题需要先检索项目列表再逐个检索项目状态最后综合对比才能回答。单轮RAG做不到。这时候就要引入智能体的概念了。RAG智能体的核心是让模型在检索-回答的循环中加入自主决策能力它可以根据问题决定要不要改写查询词、把复杂问题拆成几个子问题、选择去哪个知识库检索、拿到结果后再判断答案是否满意不满意就再检索一轮。这一进化的代价是流程变长、延迟变高、对模型能力要求明显提升通常需要更强的模型才能做出靠谱的决策但在处理多跳问题上效果立竿见影。5.2 知识图谱、RAG和结构知识库三者的边界与互补kg知识库、rag知识库和结构知识库区分以及应用场景这个问题被反复搜索说明不少人在这几个概念上绕晕了。我直接用一张表说清楚维度RAG非结构化文档知识图谱实体与关系结构化知识库数据表数据形态PDF、Word、笔记、报告实体、属性、关系三元组SQL表格、CSV、数据库适合问题制度问答、文档解读、FAQ关系查询某用户买了哪些产品精确条件查询、统计汇总优点不要求人工整理直接处理原始文档能表达复杂关系、支持多跳推理查询精准、可校验缺点理解不了全局关系、结构信息易丢构建成本高依赖人工或抽取模型不擅长非结构化文本三者不是竞争关系而是互补关系。工程上常见做法是混合文档用RAG做语义检索关键的实体关系用图谱维护精确数据落在结构化库里最后用路由Router根据问题类型选择走哪条链路。知识图谱方向还有一个热门分支叫GraphRAG。它的思路是用大模型自动从文档中抽取实体和关系构建出图谱再通过社区检测生成各层级的摘要检索时既可以用局部摘要回答问题也能支持整个知识库在讲什么这种全局性问题。如果你遇到的场景是我的文档太多了需要做全局概览GraphRAG值得花时间研究。至于ontology本体它是给知识图谱定义有哪些概念、概念间有什么约束的schema层用大白话说它是给图谱立规矩的在大规模工程化时能避免图谱长成一团乱麻。5.3 多模态RAG知识库能存图片吗rag知识库能存储图片嘛这个问题被我搜到过好多次答案其实很明确经典RAG的索引和检索都发生在文本空间图片本身不能直接入库。但现实需求又确实存在——你手里的资料里难免有图表、截图、扫描件。务实的路径有两种。第一种是以文搜图给每张图片生成文字描述OCR提取文字、视觉模型生成caption把描述文字向量化入库检索时先搜到描述再把原图作为附件展示给用户。这种方案实现简单、效果稳定可微调也是我目前更推荐的做法。第二种是直接向量化图片用CLIP这类多模态模型把图片本身转换成一个向量检索时在图文混合的向量空间里做相似度匹配。这条路更前沿但工程复杂度高入门阶段不建议一上来就整。记住一个原则能先把图片转成文字解决的就不急着上多模态模型。5.4 值得持续关注的方向最后聊几个我在实验中发现有价值、但篇幅所限无法展开的方向。Self-RAG让模型自己先判断这个问题需不需要查资料再决定走检索还是直接回答能省掉大量不必要的检索开销。HyDE的思路是先用模型生成一个假设性答案再用这个答案去向量库检索在某些主题上可以显著提升召回率。Rerank模型我在前面提过它是投入产出比极高的一个优化点。如果你有精力从Rerank入手做优化往往比换更大的生成模型更有效、成本也更低。如果让我给刚接触RAG的人一条建议我不会建议你第一天就去研究GraphRAG或者多模态检索而是先搭一个最朴素的流程——几个文件、一个向量库、一个模型跑通它然后用你手里最真实的文档去问它十个问题。你会发现它的聪明和笨拙都远超你想象。RAG的真正难点从来不是跑通Demo而是让你的知识库在真实场景里稳定地答对。这需要时间也需要一份愿意每天检查答案、不断调整分块策略和检索参数的耐心。这个过程中踩的坑、补的知识才是比会跑一个Demo更有价值的东西。