很多时候别人问我 RAG检索增强生成到底在解决什么问题我会先反问一句你有没有试过把一个内部项目文档直接丢给大模型然后问它一个只有这份文档里才有的问题我做过。结果很典型——它先一本正经地说了一堆听起来很有逻辑的话内容跟文档对不上甚至细节全是错的。一开始我以为是模型不够聪明后来才反应过来这里的问题压根不是“模型笨不笨”而是它手里根本没有这份资料。模型答不上来只是因为它“不知道”于是只能靠自己的语言习惯去补一个最像样的答案。RAG 解决的就是这件事让大模型在回答问题之前先按需查阅外部文档再基于找回来的材料作答。它把“背书式生成”改成了“先查资料再答题”这不是某种技巧上的优化而是整个问答架构在信息源层面换了个底座。这篇文章我从一个从业者的视角把 RAG 的前因后果、工程细节以及我自己在 Mac 上搭本地知识库的经历一起整理出来希望能帮还在概念期打转的人少走一点弯路。1. 大模型记不住私有文档问题的真正起点1.1 为什么“把文档喂给大模型”是个伪需求经常有同事这么问我“文档 Word 都在这了直接把内容拖进对话框不就行了吗”这个直觉背后其实有一个误解——大模型不是数据库不是一个可以用 CtrlF 在里面搜索内容的容器。它的“知识”来自于预训练时见过的语料形成的统计规律而不是从某份指定文档里临时读取。举个例子。你问一个通用大模型“离职审批在公司流程里要走几步”如果它训练的时候没看过你们公司的制度手册那它只能根据普遍认知给你一个平均值。这个答案听起来挺合理但它不是你公司真正的规矩。这才是企业内部知识问答最大的痛点通用大模型不掌握私有知识而对私有知识的准确性要求又恰恰是刚需。RAG 的出发点就是承认这个事实不指望模型把一切都背下来而是在回答时给它一条获取外部知识的通道让它每一次回答都能“临时去查”。1.2 “一本正经胡说”的本质不是骗人是没有信息来源你有没有观察过一个现象模型在被问到自己不知道的事情时并不会说“我不知道”而是会流利地给出一段听起来很有道理的话。很多人把这个归为“幻觉”但从工程角度看本质是模型在给定上下文里找不到相关信息时只能按概率去续写一个“最像正确答案”的序列。我举个例子问一个没读过你们项目周报的模型“上周版本发布是否有回滚风险”它可能会写“团队对发布风险进行了充分评估并建立了完整的回滚机制……” 这段话放在任何项目里都不算错但它不针对你的项目属于一个泛化的“安全答案”。在没有外部事实支撑的场景下模型给出的所有自信回答都只能是这样一种“基于语言惯例的外推”。RAG 要改变的不是模型“说大话”的坏习惯而是让它在回答前被喂入真实的上下文——有真实信息可依它就不需要靠编来凑答案了。2. 压缩记忆还是索引记忆模型权重里存不下公司文档2.1 一个粗略但震撼的计算7B 模型到底记住了多少语料搞 RAG 之前我觉得有必要先把“模型记忆”这件事量化一下不然很容易对模型产生不切实际的期望。以 7B 参数的模型为例如果用 FP16 存储权重大约 14GB。它的预训练语料通常在上万亿 token 级别。为了理解这个信息量级我做个粗略估算假设预训练语料是 2 万亿 token每个 token 在原始文本里平均约 3-4 字节那么原始语料大约 6-8TB 规模而模型的全部知识被压缩进 14GB 的权重里压缩比大概是 1/500 到 1/600。这说明什么说明模型存储的是“统计规律”和“语义模式”不是原文。它可能知道“苹果是一种水果”这种高频常识但对于你们公司内网上那条“报销超过 5000 元需要总监审批”的信息它在预训练时见都没见过你指望它靠权重把它记住这违背了压缩记忆的基本逻辑。2.2 那为什么不把文档全部塞进微调训练里一定会有人问既然模型记不住那我用公司的文档做一次微调不就让模型学会了吗这个思路有一定道理但工程上很难成立。微调适合调整模型的“说话方式”和“领域术语感”不适合注入大批量、持续变化的具体事实。原因有三点成本太高每次知识变更都要重新微调一次公司制度一个月改三次训练就永远追不上知识粒度太粗微调让模型学到的是一种“倾向”不是一条可追溯的记录它还是会自己发挥验证困难训练完之后你没法快速定位它对某一条制度记得准不准排查问题非常痛苦。RAG 的方案是反过来模型不需要记住文档内容只需要把文档切好、索引好等用户提问时检索到相关内容再把原文片段拼进 Prompt 让模型“照着读”。知识的更新从改权重变成了改索引这是质的变化。3. RAG 的解决路径检索加生成本质是让模型“先查再答”3.1 五步流水线缺一步效果都会打折扣我把 RAG 的流程拆成五个环节这也是现在各种 RAG 框架的通用骨架文档处理把 PDF、Word、Markdown 等原始资料解析成纯文本并保留标题、页码、来源等元信息文本切片按语义边界或长度把长文档切成若干 chunk因为嵌入模型和生成模型都不能处理无限长的上下文向量化存储用嵌入模型把每个 chunk 转成向量写入向量数据库检索把用户的问题也转成向量在库里做相似度检索取回 TopK 最相关的片段生成把检索到的片段拼接到 Prompt 里让大模型基于这些片段生成回答。这五个环节里最容易被忽视的是第 1 步和第 2 步。很多人刚接触 RAG兴致勃勃地跑通了一个 Demo觉得能回答问题就完事了。但生产环境里 80% 的效果问题都出在文档解析和切分上根本轮不到调模型。3.2 让回答“有出处”是 RAG 比纯模型更值钱的地方纯大模型问答有个天然短板不知道答案从哪来。RAG 不一样——它的每个答案背后必须依附于检索到的原文片段。你可以把引用的文档名、页码甚至原句摆在回答旁边让对方自己核对。我在实际项目里养成了一个习惯不管用户有没有要求回答时都要求模型把依据句的片段简要标注出来。效果非常明显。同事拿到答案后第一反应不再是“它说的对吗”而是“哦原来依据是这一条”信任成本一下子就降下来了。所以我说 RAG 解决的不只是准确率问题更是“答案可验证性”问题这一点在知识库、客服、合规审查这些场景里比准确率本身还要重要。4. 文本拆解才是效果分水岭切分器、chunk 大小与中文场景4.1 别把 chunk 调大就完事自包含性与嵌入模型上限很多初学 RAG 的人会问chunk 设多大最合适我的答案永远是看你的嵌入模型和检索场景不要盲目追求大 chunk。这里有几个判断依据。首先绝大多数嵌入模型都有 token 长度上限。比如很多模型限制 512 token如果你把 chunk 设成 1500 token向量化的时候后面 1000 token 会被直接截断等于信息丢了。其次chunk 太大会引入大量无关噪声检索时真正相关的可能只有其中一两句话但整段都会被塞进 Prompt降低回答精度。而 chunk 太小又容易把一句话拆得支离破碎语义不完整。我自己在中文文档上常用的配置是chunk_size 在 400-800 token 之间chunk_overlap 取 10%-20%。这样既能保住一段相对完整的语义又让相邻切片的衔接信息不丢失。下方是一个常用的切分对照切分策略适合场景常见问题按固定字符数切快速验证、纯文本切断句子、割裂上下文按标点/段落切新闻、公告等段落清晰的文本长段落仍然超限按 Markdown 标题切Wiki、文档库标题层级断裂时效果变差语义切分按嵌入相似度聚合内容主题变化明显的文本计算成本较高4.2 中文拆解的独有痛点与本地可用工具中文文本拆解比英文麻烦得多。英文天然有空格分词句子边界清晰中文靠标点符号和语义断句如果只用字符数硬切很容易把“虽然他很努力但是”和“结果还是失败了”这种因果句切到两个 chunk 里模型检索到其中一半根本没法作答。针对中文我一般会做三层处理先用标题和段落结构做大粒度切分让章节边界天然成为 chunk 边界如果一段还是太长再用标点符号优先的递归切分把它继续拆小最后设置 overlap把相邻 chunk 的头部或尾部重复一小段避免“断头语”。本地工具方面我推荐优先看 LangChain 的文本切分器或者是单纯基于正则的切分脚本没必要一上来就上重型服务。很多开源框架自带的切分器已经够用手动指定分隔符列表为句号、分号、换行等再加上字符长度兜底效果并不比重型方案差。笔记类工具、本地知识库工具里也内置了类似的文本切分功能可以先用它们跑通全流程。4.3 图片、表格与排版RAG 知识库能存图片吗热词里有一个高频问题“RAG 知识库能存储图片吗”我的回答是能但得分清楚“存图片”和“让模型理解图片”的区别。如果你仅仅是希望用户搜到图片那可以把图片路径存进元数据搜索图片描述文字即可如果你是希望模型回答问题时用到图片里的信息让模型直接“看图”将大幅度提高实现成本。更务实的做法是用 OCR 或者视觉模型把图片内容转成文字再把文字片段作为这一页的 chunk 存进知识库。图片本身可以存一份原始文件路径做展示但回答依赖的是文字化之后的内容。表格的处理也一样。千万别直接把一张满是数字的截图塞进知识库——模型很难从向量化后的图像里“算”出准确数字。我在项目中一律把表格先转成 Markdown 或 CSV 文本再进入切分索引流程。这一步虽然是笨办法但在绝大多数业务场景下是最稳、最可控的方案。5. 不是所有知识都适合塞进 RAG知识图谱、结构化知识库与 Wiki 的边界5.1 三者的本质区别从数据形态和查询方式说起做知识类项目时总有人把 RAG 知识库、知识图谱、结构化知识库混为一谈。其实它们的适用边界很清楚。我用一个偏生活的类比解释RAG 知识库像一个“开卷考试”你需要从一本本书里翻出相关段落答题知识图谱像一张“人物关系网”你知道节点和连线可以做路径推演结构化知识库像一张“Excel 表”适合做精确筛选和统计。类型数据形态擅长回答的问题典型场景RAG 知识库非结构化文本切片“文档里怎么说的”规章制度、产品手册FAQ知识图谱实体关系三元组“谁和谁是什么关系”供应链、组织架构、风险传导结构化知识库表格、SQL 数据库“某条件下统计值是多少”库存、订单、财务数据5.2 实际选型的三条判断标准我自己的选型经验可以用三个问题来定夺问完问题之后你需要给用户一份原文出处让他自己核对吗需要就走 RAG问题里含有“通过什么关系能关联到谁”、甚至要展开多层路径吗这种情况用知识图谱会顺畅得多问题是一个精确条件比如“上个月华东区总销售额是多少”吗这种计算任务交给 SQL 查询别难为向量数据库。网上常提到 Wiki 与 RAG 的对比这里补充一下Wiki 本身是“人类导航式”的知识组织方式按目录维护、靠人阅读RAG 是“机器检索式”的知识利用方式按向量匹配、让模型阅读。它们不是二选一很多成熟的架构是把 Wiki 的标题结构作为 chunk 边界再用 RAG 做问答入口。Wiki 负责维护权威知识RAG 负责把知识以问答形式分发出去。5.3 本体和知识图谱什么时候能补上 RAG 的洞用到大模型问答时有一类问题 RAG 很吃力需要跨多条文本做逻辑推断的“多跳问题”。比如文档 A 说“A 公司持有 B 公司 60% 股份”文档 B 说“B 公司持有 C 公司 100% 股份”模型要回答“A 公司对 C 公司有没有控制权”单个 chunk 里根本没有现成答案。这种场景知识图谱的价值就体现出来了。图谱里已经把这个关系抽象成节点和边查询可以从 A 节点走到 B 节点再到 C 节点路径关系一目了然。本体Ontology则更进一步它给图谱定义了严格的类别和属性规则保证“持股”“控制”这些关系的语义一致。所以别问 RAG 和知识图谱哪个好得问你的问题属于“文本找答案”还是“关系找路径”。现实项目里两者完全可以串成一个混合架构先做实体抽取把关键关系灌入图谱同时保留原文切片做 RAG 检索。遇到需要点对点精确查询时走图谱遇到开放表述时走 RAG。6. 实际业务中 RAG 的真正瓶颈召回精度与“长上下文幻觉”6.1 TopK 检索的错觉向量搜不到不代表文档里没有RAG 上线后最常见的用户反馈是“明明文档里就有它却说不知道。” 这种问题十有八九出在召回环节不在生成环节。向量检索的本质是相似度匹配不是关键词精确匹配。如果两个句子表达不一致但语义接近向量检索能找到如果文档中的表述非常特殊、低频而用户的提问方式恰好绕开了这个语义空间那向量检索可能完全召不回。这也是“RAG 瓶颈”被讨论最多的地方它的上限被检索召回率卡死了。我的解决办法是不要把召回当作一次性的 TopK 就结束了。在小知识库里可以先取 Top50 召回结果再经过一轮重排序模型把最相关的 5 条挑出来把它作为 Prompt 上下文。我实测下来加了重排序这个环节之后答案可用度提升非常明显。6.2 “Lost in the Middle”定律上下文塞得越满模型越容易迷路还有一个容易踩的坑是很多人以为“只要我把检索到的内容全部喂进去模型肯定能答对”。事实恰恰相反。现有研究表明大模型对长上下文中间部分的注意力是低于开头和结尾的也就是所谓的“Lost in the Middle”。如果你把 Top20 甚至 Top30 个 chunk 全部拼进 Prompt中间夹着真正有用的依据模型很可能聚焦不到它反而被无关内容干扰。与其追求检索得多不如追求检索得准。我现在做 Prompt 拼接时习惯把最相关的 3-5 个片段放前面明确标注来源并要求模型只能依据这些片段作答效果远比“片段堆砌”式方案稳定。6.3 RAG 之上再加一层智能体调度才能覆盖更多问题最后聊一下“RAG 智能体”这个热词。纯 RAG 适合回答“文档里有什么”一旦问题变成“文档里查不到但外部系统能算出来”比如“当前有多少订单未发货”RAG 本身无能为力但智能体可以补全。实际操作中我会在 RAG 外层加一个简单的意图路由如果用户问题是事实查证类就走向量检索如果问题是聚合统计类就调用 SQL 工具去查数据库如果问题涉及关系推断就调用知识图谱查询接口。这个“路由 多个工具”的做法本质上就是在用智能体的方式扩展 RAG 的能力边界。它不是一个花哨的噱头而是当你把 RAG 真正接进业务系统时几乎必然要走到的下一步。7. 在 Mac 上落地一个本地 RAG 知识库的实操路径7.1 为什么我建议先跑本地而不是直接用线上服务最后这部分直接回应一个很多人问过我的问题怎么在 Mac 上搭建一个本地的 RAG 知识库我的建议是先跑本地别急着上云。本地跑的好处有三个一是文档不需要上传到第三方接口隐私方面安心二是你可以把每个环节拆开调试切分、向量化、检索、生成每一步都能看到中间结果三是成本基本为零Mac 哪怕只有 8GB 内存也能跑通一个小型验证项目。等验证完业务价值再决定是否部署成服务也不迟。7.2 从一份本地文档到第一个 RAG 问答我给出一个最简可跑通的流程。假设你手上有一份help.pdf想让它变成一个可以问答的知识库。第一步解析 PDF把文字抽出来。本地可以用常见的文档解析库把 PDF 转成纯文本同时尽量保留页眉、章节标题。第二步做文本切分我一般会先用标题结构切再对超长段落按标点做二次切分from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, # 中文场景下建议保守500~800 token 比较稳 chunk_overlap80, # 重叠区域用于防止断句丢信息 separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_text(extracted_text)第三步用本地嵌入模型把每个 chunk 转成向量写入一个持久化的向量库。Chroma 这类轻量向量库在本地项目中很顺手不需要额外部署服务import chromadb client chromadb.PersistentClient(path./local_rag_db) collection client.get_or_create_collection(namehelp_docs) # 为每个 chunk 生成唯一 id然后写入 collection.add( ids[fchunk_{i} for i in range(len(chunks))], documentschunks, metadatas[{source: help.pdf} for _ in chunks] )第四步查询时把用户问题向量化后在库里做相似度检索取回相关片段results collection.query( query_texts[如何导出报表], n_results5 ) print(results[documents])第五步把检索到的片段拼进 Prompt交给本地模型生成回答。Prompt 我会尽量写成这种结构“以下是相关资料请仅依据这些资料回答若资料中未提及则明确说明。”这里要提醒一句本地推理能力的配置很重要。如果 Mac 内存只有 8GB本地大模型建议选 7B 以下参数量的量化版本否则推理速度会慢到怀疑人生嵌入模型则选择轻量中文模型即可不需要上最大规模。7.3 Mac 本地项目容易踩的细节最后补几个我在 Mac 上实测时踩过的坑都是小事但碰到一次就够你折腾老半天中文路径与编码问题。文件路径里带中文、文档内容又是 UTF-8 时有些老脚本会直接乱码。跑 Python 前先设置PYTHONIOENCODINGutf-8保存和读取都用 UTF-8能省很多事PDF 扫描件必须 OCR。如果你的 PDF 是扫描版抽出来是空文本后续全白做。先做一次 OCR 再进切分流程先做 30 篇文档的小规模验证。我见过太多人一上来就灌 10 万篇文档切分脚本跑了半天结果检索效果稀烂还找不到原因。先用小样本跑通全链路把切分和检索调顺了再逐步放大规模。我在实际项目中始终保留一份原始文档目录向量库里只存 chunk 文本和元数据。这样每次出问题我都能快速回溯到原始文本确认是切分丢了信息还是检索没召回到位。这个习惯帮我排查了很多问题。RAG 真正要解决的其实不是让模型记住什么而是让模型在回答时知道该去查什么。把这个思路理清楚后面调参、换框架、加智能体都是在同一个正确的底座上做添砖加瓦的事。