最近聊 RAG 的朋友特别多从刚接触大模型的初学者到已经在做企业知识库落地的工程师都在问同一个问题RAG 到底怎么搭、怎么做才能真的解决问题。我最早接触 RAG 是在给内部团队做文档问答的时候当时的痛点是模型再强也记不住我们自己的业务文档微调成本又太高RAG 几乎是唯一的合理选择。陆陆续续做了几个项目之后我发现自己踩过的坑、调过的参数、换过的方案其实是可以沉淀成一套有章可循的方法的。这篇文章就是把我从零开始搭建 RAG 的过程梳理出来的完整记录包括核心链路、文本拆解、向量化、检索优化、工具选型以及那些最容易让人抓狂的细节问题。如果你正准备做一个知识库问答、文档助手或者只是想把 RAG 跑通并搞清楚它的边界这篇文章应该能帮你省下不少摸索的时间。1. RAG 到底是什么先搞清楚它解决了什么问题1.1 大模型不是搜索引擎它只“记得”训练时见过的内容很多人第一次接触 RAG 时的第一反应是大模型不是什么都知道吗为什么还要外挂一个知识库这个理解偏差是后面所有困惑的根源。大模型在你提问时给出的答案本质上是对训练语料里学到的统计规律做逐词生成它没有能力去“查”任何实时资料。你问它今年发布的新产品规格它回答不出来不是它笨而是那些信息根本不在它的训练数据里。它也没有办法区分哪些信息是真实的、哪些是编造的因为它只是在做概率上的续写。所以当你要让模型回答“我们公司内部规章里迟到怎么定义”这种问题时如果你只把问题丢给模型它只会给你一段听起来合理但完全不可信的答案。RAG 做的事情就是改变这个局面在你的问题进入模型之前先从一个外部知识库里检索出相关的内容片段把这些片段作为背景材料拼进提示词里再让模型基于这些材料生成答案。这样一来模型回答的内容就不再依赖它“记得什么”而是依赖你的知识库里“有什么”准确性、时效性、可追溯性都发生了本质变化。用一句话概括RAG 是把“生成”和“检索”组合起来的问答架构外部知识库负责找材料大模型负责写答案。它最典型的应用场景就是企业内部知识问答、产品文档助手、合规审查辅助、客服工单处理这类“答案必须出自指定资料”的任务。适合的人群也很宽——在校学生、后端工程师、算法工程师、产品经理都可以通过它快速做出一个可用的问答系统而且不需要从头训练任何模型。1.2 RAG 的核心链路从文档到知识的五步流程RAG 的完整链路可以拆成两个阶段。第一个阶段是知识库构建也就是“离线处理”把原始文档变成可以被检索的形式。第二个阶段是在线问答用户提问后实时检索并生成回答。离线构建阶段通常分五步文档加载、文本拆解、向量化、建索引、存储。文档加载是指把 PDF、Word、Markdown、网页等不同格式的内容读成纯文本文本拆解是把长文档切成适合检索的小段也就是业内常说的 chunk向量化是调用 embedding 模型把每个文本段转换成一串浮点数向量让语义相近的文本在向量空间里距离更近建索引和存储则是把这些向量连同原文一起写入向量数据库方便后续快速查找。在线问答阶段也有固定流程把用户问题同样转成向量到向量数据库里做相似度检索取回最相关的一批文本段再把这些文本段和原始问题一起组装成提示词交给大模型生成最终答案。我第一次看这个流程时觉得不复杂但真正动手做才发现每一步都有不少隐藏的变量。文本拆成多长合适向量模型选哪个检索结果怎么排序这些问题如果只是默认参数跑通一遍出来的效果往往很一般。后文我会逐个环节展开讲具体怎么调。1.3 什么时候该用 RAG什么时候不该用RAG 不是万能方案它也有自己的适用边界。首先需要明确一点如果你的问题都能被模型自身知识准确回答且不需要引用任何外部资料那就不需要 RAG。比如“Python 列表怎么去重”这种基础问题直接问模型就够了加一套检索链路反而增加了延迟和复杂度。RAG 真正发挥价值的地方有三个特征一是答案必须来自特定资料比如公司内部制度、产品技术文档二是资料内容会持续更新比如每周发布的新版本说明不可能每次更新都重新微调模型三是需要答案可溯源用户抽查时能知道回答来自哪一份文档的哪一段。反过来如果这些问题涉及大量跨文档推理、需要多步逻辑链或者问题本身就是开放的、没有确定答案纯粹的 RAG 就会比较吃力这类任务通常要引入智能体或多跳检索机制而不是简单的一次检索一次生成。明白边界之后再接具体项目就不会乱。下面我从知识库构建开始带你走一遍完整的实操步骤。2. 从零搭一个 RAG 知识库文本拆解和向量化2.1 文档接入前的第一步格式归一化与文本抽取很多人拿到一批 PDF 就直接开始做切分这是第一个坑。PDF 里的内容并不都是“文本”大量商业文档里含扫描图片、复杂表格、页眉页脚直接抽取出来的文本经常是乱序或者缺失的。我处理过一份内部制度文件PDF 里正文分成了两栏默认抽取工具把左右两栏交叉读出来句子完全错乱检索结果自然惨不忍睹。所以文档接入的第一步不是切分而是格式归一化。把所有源文件统一转成干净、规范的纯文本或者结构化 Markdown再进入后续流程。对 Word、Markdown、HTML 这类本身就带文本层的内容标准做法是优先保留原有结构——标题、列表、表格里的内容按层级提取。对 PDF处理方案取决于文件质量如果是数字生成的 PDF直接用 pdfplumber 或者 PyMuPDF 提取文本保留基础版式如果是扫描件则需要先做 OCR这一步可以调用本地 Tesseract也可以接 PaddleOCR 这类效果更好的引擎。这里要重点说一个工具Unstructured。它是一个专门做文档解析的开源库能把 PDF、Word、PPT、HTML 等格式解析成带元数据的元素列表比如每个元素是标题、正文、表格还是图片。我在 Mac 上做本地解析时常用它配一个简单的 Python 脚本就能把整批文档抽出干净文本。如果你处理的是学术论文或者产品手册还可以试试 Marker它能把 PDF 直接转成带层级结构的 Markdown对双栏和表格支持比普通 PDF 抽取库好很多。文本抽取这个环节多花二十分钟后面检索效果能提升一个档次这是性价比最高的前期投入。2.2 文本拆解的“体感调参”chunk size 与 overlap文本拆解是 RAG 项目里让人又爱又恨的环节。切得太短语义碎片化一个问题可能被拆散到好几块里检索时哪一块里都找不到完整信息切得太长噪声太多向量化后语义被稀释检索出来的内容里真正有用的可能只有一两句话大模型还要从一大段废话里挑答案准确率同样下降。我常用的起点参数是 chunk size 在 256 到 512 token 之间overlap 按 chunk size 的 10% 到 20% 设置。以 512 token 的 chunk、64 token 的 overlap 为例相邻两个文本块之间会共享一部分内容这样即使一个关键句恰好落在前一个块的末尾也能在后一个块的开头再出现一次避免漏检。这个参数组合对绝大多数中文文档都算稳妥但实际效果仍然要按内容类型做调整。2.3 向量化与 embedding 模型选型文本切好之后下一步是把每一块转成向量。embedding 模型的选择直接决定了检索的召回质量这是 RAG 项目里最不该随便应付的环节。开箱即用的方案是调用 OpenAI 的 text-embedding-3-small 这类在线接口质量稳定、接入快缺点是每一篇文档都要上传到外部服务对数据敏感的内网项目不适用。本地部署的方案里我测试过 BGE 系列模型表现很好尤其是 BGE-M3在中文语义理解上比很多同体量英文模型强很多同时支持稠密检索和稀疏检索两种模式后面做混合检索时可以共用一套向量。如果你的环境跑不了大模型也可以用更轻量的 text2vec 或者 m3e 系列效果略逊一筹但速度更快。最近 Ollama 也支持了 nomic-embed-text 和 bge-m3一条命令就能在本地起一个 embedding 服务对做实验和搭建个人知识库来说性价比很高。选模型的时候有一个容易忽略的细节检索用的 embedding 模型和生成回答的大模型不需要来自同一家公司也不需要绑定运行。常有人觉得“我用 Llama 本地部署那 embedding 也必须用 Llama 系列”其实没有这个限制embedding 和生成两套模型是独立的可以分开选型。只要保证一个关键前提所有文档切片和用户查询都要用同一个 embedding 模型不能用两个不同的模型分别向量化否则向量空间不一致相似度计算就没有意义了。3. 知识库到底能不能存图片多模态 RAG 的边界3.1 为什么图片经常“进不了”知识库“RAG 知识库能存图片吗”是搜索热度很高的问题也是很多初学者绕不过去的困惑。直接回答纯文本 RAG 的向量库不能直接理解图片内容。原因在于最主流的 embedding 模型处理的是文本图片直接送进去没有任何意义。很多人在本地搭建知识库时发现传了几张截图进去检索的时候却完全检索不到就是因为没有对图片做任何处理图片压根没有变成可检索的文本。这并不意味着知识库完全和图片绝缘。如果你用的向量数据库本身支持多模态向量比如 Milvus 这类专业向量库接入了 CLIP 或 ImageBind 模型确实可以把图片编码成向量做图搜图。但这属于多模态检索的范畴实现成本和工程复杂度比普通文本 RAG 高不少初学者通常不需要一上来就走这条路。3.2 实际可行的做法图片转描述再入库对绝大多数知识库场景最稳妥的做法不是把图片直接入库而是把图片“翻译”成文本描述之后再把文本放进知识库。具体流程是用大模型或者专门的图像理解模型给每一张图片生成一段文字说明比如“图中展示的是系统登录界面左上角为用户名输入框右侧为验证码区域”然后把这段描述和图片在文档中的上下文一起拼成文本块入库。用户提问时检索发生在文字描述层模型读到的是“图片内容的文字版”照样能给出有用回答。我实际处理过一个产品说明书项目文档里有大量界面截图和流程图最初直接用 PDF 抽取图片内容全部丢失导致很多问题回答不了。后来我把 PDF 先转成 Markdown再用多模态模型对图片逐张生成描述插入到对应章节的位置整个知识库的召回率明显提升。这个流程现在有标准化的开源工具可以做比如一些文档解析库已经内置了“OCR 图像理解 文本化”的流水线无需自己组装。3.3 表格、PDF 扫描件这类“伪图片”怎么处理有些内容看起来不是图片但处理方式却和图片类似。表格就是最常见的例子原生从 PDF 抽取出来的表格经常是一堆散落的字符行列关系全丢扫描版的合同、发票就更不用提本质上就是图片。这些内容如果直接丢进文本 RAG检索到之后回答质量大概率是不合格的。表格类内容的推荐做法是转成 Markdown 表格或者 JSON 结构化之后当作一个整体 chunk 存入知识库。大模型对 Markdown 表格格式的识别能力很强只要文本块里保留了完整结构它在生成答案时就能正确理解“第一列是配置项第二列是默认值”这类关系。扫描件则必须走 OCR这一步做完之后还要做版式还原尽量把识别出来的文本按原始阅读顺序重新拼接。我见过不少项目卡在“扫描件检索到了但答案不对”这个问题上排查下来都是 OCR 文本顺序出了问题排版乱掉的文本块比检索不到更误导模型。4. 检索链路才是 RAG 的灵魂检索增强不只是搜一下4.1 相似度检索的局限关键词与语义之间的平衡很多初学者以为 RAG 的检索就是用向量数据库查一下相似度跑通之后发现效果时好时坏。原因在于纯向量检索对长尾关键词、编号、产品型号这类精确信息并不敏感。比如用户问“CH-3200 的额定功率是多少”向量模型可能把这串型号理解成“某个设备型号”但“CH-3200”这个精确匹配信号在向量检索里并不占优势最相关的文档反而排不到前面。解决这个问题需要意识到RAG 的检索本质上应该分两路走一路做语义召回靠向量相似度找到意思相近的内容另一路做关键词召回靠 BM25 这类经典算法做精确匹配。然后把两路结果做合并和重排术语叫“混合检索”Hybrid Search。我用过的方案里向量库用 Milvus 或者 Qdrant关键词检索可以直接用 Elasticsearch也可以用一个更轻量的 MeiliSearch 或者 SQLite FTS5按数据量级来选。合并策略上常用的是用倒数排名融合RRF算法把两份结果按排名做加权合并保证两路召回的内容都有机会进到最终候选集。4.2 重排序让最相关的答案排到最前面混合检索拿到一批候选文档之后另一个关键步骤是重排序。向量相似度衡量的是“整段文本语义上有多接近”但语义接近不等于“问题中的核心信息在答案里都有”。做重排序最有效的方法是引入一个专门的重排模型reranker它会把问题和候选文档逐条拼接起来计算相关性得分这种交互式打分比纯向量距离更精准。开源方案里我会优先推荐 BGE-Reranker它的模型设计就是针对中文问答场景做的重排效果和推理速度平衡得不错。实测下来一个嵌入模型召回后有 30 条候选的查询用重排模型重新排一遍之后Top 1 结果往往和实际需要的答案高度相关对比不重排的情况提升显著。需要注意重排模型也是本地部署时的主要算力消耗点之一对性能要求高的线上场景一些团队甚至会专门做缓存和并发优化。但哪怕只是做一个小工具我认为重排这一步也不该省它是性价比非常高的精度提升手段。4.3 知识图谱 RAG 和 RAG 智能体的差异“知识图谱 RAG”和“RAG 智能体”是最近热度很高的两个词初学者容易混为一谈。简单来说知识图谱 RAG 是在传统 RAG 基础上额外引入了一层的结构化知识文档切块和向量化照旧做但你同时把文档里的实体、关系抽取出来建成图谱结构比如“张三”是“市场部”的“员工”“市场部”的“负责人”是“李四”。图谱可以回答那些依赖多级关联的问题比如“张三的部门负责人是谁”普通 RAG 需要从多篇文档里拼凑推理知识图谱可以直接走关系路径。这类方案搭建成本高因为实体识别、关系抽取都要精确处理但对特定领域比如医疗、法律的关联问答场景收益明显。RAG 智能体则是把 RAG 从“查一次、答一次”升级成“可以多轮决策”的形态。智能体收到问题后先判断要不要检索再决定检索哪几个知识库对结果不满意就改关键词再检索一次甚至同时调用另外一个 API 获取结构化数据最后把多来源信息组装成答案。它的核心特征是拥有循环和工具调用能力适合复杂查询。但代价是可控性下降出问题的时候排查链路变长。对初学者我的建议是先扎实掌握普通 RAG 和混合检索再研究知识图谱和智能体否则很容易陷入“什么都要接智能体但什么问题都回答不准”的泥潭。5. 本地搭建 RAG 的常见路径与工具选型5.1 在自己电脑上搭建 RAG 的配置思路以 Mac 为例“怎么在 Mac 上搭建 RAG 知识库”是搜索量很高的问题确实很多刚接触大模型应用的朋友手上只有一台 Mac不想上来就买服务器。以一台 Apple Silicon 芯片的 Mac 为例完全可以在本地跑起一套完整的 RAG 链路Ollama 负责本地大模型和 embeddingChroma 做向量库再加一个小型 Python 脚本做文档处理全部内网运行数据不出本机。具体流程我建议按这样走第一步安装 Ollama拉取一个大语言模型起步可以用 qwen2.5:7b 这类中文表现不错的 7B 模型再拉一个 bge-m3 作为 embedding 模型第二步用 Python 写一个简单的文档加载脚本把 Markdown、TXT 这些文本类型直接读入PDF 用 Unstructured 解析第三步把文本块交给 embedding 模型转成向量写入 Chroma 持久化目录第四步写一个查询函数用户输入问题后先向量化再从 Chroma 取出相似度最高的几个文本块连同问题一起拼进提示词交给 Ollama 生成回答。整个过程不依赖任何外部云服务一台 16G 内存的 Mac 跑 7B 模型虽然速度不算快但做学习验证和个人知识库完全够用。如果你不想写代码也可以直接用现成的开源应用。RAGFlow 是我实测下来对新手比较友好的一套系统它自带文档解析、知识库管理、问答界面部署后就能用对中文文档支持也很好。LangChain 和 LlamaIndex 则更适合想深入理解原理、通过代码自由控制流程的人两者定位略有差异LangChain 的组件生态更丰富适合构建复杂链路LlamaIndex 主打文档索引和检索对 RAG 场景更聚焦。5.2 常见开源 RAG 框架怎么选框架选型是大家问得最多的问题之一我把几种典型方案的定位和适用场景整理成了表格方便对比。方案核心定位上手难度适合场景自研脚本Ollama Chroma最小可用链路低学习原理、快速验证LangChain / LlamaIndex开发框架中定制化程度高、需要代码控制RAGFlow开箱即用系统低快速搭建知识库应用中文友好Dify低代码平台低面向业务配置、可视化流程编排企业级生产方案Milvus Elasticsearch 等生产级链路高高并发、大规模文档、需要精细化治理初学者选择时不要一上来就上最重的框架。我见过不少朋友第一天就在折腾生产级集群最后光部署就卡了一周核心链路反而没跑通。建议先用手写脚本跑通最小链路切身理解每一环的功能之后再挑选框架去简化开发。纸上谈兵没有意义跑通一次你对 RAG 的体感会完全不同。5.3 从“demo”到“可用”要跨过的几道坎把 RAG 从演示跑通变成能稳定使用中间有几道坎几乎人人都会遇到。第一道坎是文档更新机制。很多人做了知识库之后就忘记更新文档内容已经变了检索出来的还是旧信息。这个问题不解决知识库很快失去价值。第二道坎是检索质量评估。跑一次效果好不好是主观感受但上线前需要建立客观评估基准准备一批有确定答案的测试问题统计检索结果里包含正确答案的比例用这个指标来驱动参数调优。第三道坎是提示词稳定性。同样的检索结果提示词写法不同回答质量可能差异巨大需要反复调试才能稳定输出。这三道坎不是一次性工程而是持续迭代的过程。我在做完第一个可用版本后花了将近一半的时间在整理测试集和调提示词上这个投入非常值得。后面常见问题部分我会再展开讲几个高频故障的排查思路。6. 常见问题与排查技巧实录6.1 检索结果差是模型的问题还是检索的问题这是排查 RAG 问题时的第一个分岔路。一个常见的错误是回答质量差就先怪大模型但很多时候问题出在检索环节知识库里根本没有相关内容或者相关内容没有被正确召回。排查方法很简单先在系统里把检索到的文本块原样打印出来人工判断这些文本块是否真的能回答问题。如果检索结果本身就对不上说明问题在文档处理、切分、向量模型或检索策略换再大的生成模型也没用如果检索结果是对的但模型回答得不好那才需要优化提示词或者换一个更强的生成模型。我经常用一个比喻RAG 系统的效果上限由检索决定下限由生成决定。检索不到关键信息再强的模型也巧妇难为无米之炊检索到了关键信息至少模型不会胡编太离谱。所以排查问题永远先查检索再查生成。6.2 知识库更新了为什么回答还是旧内容这个问题的根因几乎都是缓存和索引不同步。向量数据库里的数据是构建索引时刻的快照如果新增或者修改了文档但没有重新执行向量化和写入流程检索结果自然不包含新内容。解决思路是建立清晰的更新策略全量重建用在小规模知识库上最简单可靠每次变更后直接清空旧索引、重新入库增量更新用在内容经常变动的场景需要根据文档的唯一标识判断新增、修改、删除再对应地做向量写入和删除。增量更新实现起来比全量重建复杂得多如果文档总量不大系统设计时我倾向于先用全量重建每天定时跑一次成本不高逻辑还不会出错。等到文档量级上来之后再迁移到增量策略。6.3 RAG 的瓶颈与它不适用的场景明确说出瓶颈在哪里也很重要。当前 RAG 最主要的瓶颈有三个一是长文档多跳问题的推理能力弱当答案需要跨多个文档片段组合推理时单次检索往往漏掉必要信息二是知识冲突处理难同一问题在知识库不同位置有矛盾表述时模型很难判断以哪个为准三是评估困难没有标准化的评测集和统一指标很难准确判断系统的真实水平。不适合的场景同样需要警惕回答开放性的主观题、需要最新实时信息的强时效任务、以及需要深度逻辑推理的复杂分析这些场景里 RAG 的表现都会打折扣需要配合其他架构解决。说到底RAG 是一个需要持续调优的系统工程不是跑通 Demo 就结束的事情。根据我个人在这些项目里的体会投入产出比最高的三件事分别是前期的文档解析质量、检索阶段的重排序、以及一套能重复使用的评测问题集。把这三件事做好你的 RAG 项目就已经超过了大多数停留在平均水平的实现剩下的就是在具体数据上持续迭代了。 RAG知识库搭建全流程：从文本拆解到检索优化的实战指南
最近聊 RAG 的朋友特别多从刚接触大模型的初学者到已经在做企业知识库落地的工程师都在问同一个问题RAG 到底怎么搭、怎么做才能真的解决问题。我最早接触 RAG 是在给内部团队做文档问答的时候当时的痛点是模型再强也记不住我们自己的业务文档微调成本又太高RAG 几乎是唯一的合理选择。陆陆续续做了几个项目之后我发现自己踩过的坑、调过的参数、换过的方案其实是可以沉淀成一套有章可循的方法的。这篇文章就是把我从零开始搭建 RAG 的过程梳理出来的完整记录包括核心链路、文本拆解、向量化、检索优化、工具选型以及那些最容易让人抓狂的细节问题。如果你正准备做一个知识库问答、文档助手或者只是想把 RAG 跑通并搞清楚它的边界这篇文章应该能帮你省下不少摸索的时间。1. RAG 到底是什么先搞清楚它解决了什么问题1.1 大模型不是搜索引擎它只“记得”训练时见过的内容很多人第一次接触 RAG 时的第一反应是大模型不是什么都知道吗为什么还要外挂一个知识库这个理解偏差是后面所有困惑的根源。大模型在你提问时给出的答案本质上是对训练语料里学到的统计规律做逐词生成它没有能力去“查”任何实时资料。你问它今年发布的新产品规格它回答不出来不是它笨而是那些信息根本不在它的训练数据里。它也没有办法区分哪些信息是真实的、哪些是编造的因为它只是在做概率上的续写。所以当你要让模型回答“我们公司内部规章里迟到怎么定义”这种问题时如果你只把问题丢给模型它只会给你一段听起来合理但完全不可信的答案。RAG 做的事情就是改变这个局面在你的问题进入模型之前先从一个外部知识库里检索出相关的内容片段把这些片段作为背景材料拼进提示词里再让模型基于这些材料生成答案。这样一来模型回答的内容就不再依赖它“记得什么”而是依赖你的知识库里“有什么”准确性、时效性、可追溯性都发生了本质变化。用一句话概括RAG 是把“生成”和“检索”组合起来的问答架构外部知识库负责找材料大模型负责写答案。它最典型的应用场景就是企业内部知识问答、产品文档助手、合规审查辅助、客服工单处理这类“答案必须出自指定资料”的任务。适合的人群也很宽——在校学生、后端工程师、算法工程师、产品经理都可以通过它快速做出一个可用的问答系统而且不需要从头训练任何模型。1.2 RAG 的核心链路从文档到知识的五步流程RAG 的完整链路可以拆成两个阶段。第一个阶段是知识库构建也就是“离线处理”把原始文档变成可以被检索的形式。第二个阶段是在线问答用户提问后实时检索并生成回答。离线构建阶段通常分五步文档加载、文本拆解、向量化、建索引、存储。文档加载是指把 PDF、Word、Markdown、网页等不同格式的内容读成纯文本文本拆解是把长文档切成适合检索的小段也就是业内常说的 chunk向量化是调用 embedding 模型把每个文本段转换成一串浮点数向量让语义相近的文本在向量空间里距离更近建索引和存储则是把这些向量连同原文一起写入向量数据库方便后续快速查找。在线问答阶段也有固定流程把用户问题同样转成向量到向量数据库里做相似度检索取回最相关的一批文本段再把这些文本段和原始问题一起组装成提示词交给大模型生成最终答案。我第一次看这个流程时觉得不复杂但真正动手做才发现每一步都有不少隐藏的变量。文本拆成多长合适向量模型选哪个检索结果怎么排序这些问题如果只是默认参数跑通一遍出来的效果往往很一般。后文我会逐个环节展开讲具体怎么调。1.3 什么时候该用 RAG什么时候不该用RAG 不是万能方案它也有自己的适用边界。首先需要明确一点如果你的问题都能被模型自身知识准确回答且不需要引用任何外部资料那就不需要 RAG。比如“Python 列表怎么去重”这种基础问题直接问模型就够了加一套检索链路反而增加了延迟和复杂度。RAG 真正发挥价值的地方有三个特征一是答案必须来自特定资料比如公司内部制度、产品技术文档二是资料内容会持续更新比如每周发布的新版本说明不可能每次更新都重新微调模型三是需要答案可溯源用户抽查时能知道回答来自哪一份文档的哪一段。反过来如果这些问题涉及大量跨文档推理、需要多步逻辑链或者问题本身就是开放的、没有确定答案纯粹的 RAG 就会比较吃力这类任务通常要引入智能体或多跳检索机制而不是简单的一次检索一次生成。明白边界之后再接具体项目就不会乱。下面我从知识库构建开始带你走一遍完整的实操步骤。2. 从零搭一个 RAG 知识库文本拆解和向量化2.1 文档接入前的第一步格式归一化与文本抽取很多人拿到一批 PDF 就直接开始做切分这是第一个坑。PDF 里的内容并不都是“文本”大量商业文档里含扫描图片、复杂表格、页眉页脚直接抽取出来的文本经常是乱序或者缺失的。我处理过一份内部制度文件PDF 里正文分成了两栏默认抽取工具把左右两栏交叉读出来句子完全错乱检索结果自然惨不忍睹。所以文档接入的第一步不是切分而是格式归一化。把所有源文件统一转成干净、规范的纯文本或者结构化 Markdown再进入后续流程。对 Word、Markdown、HTML 这类本身就带文本层的内容标准做法是优先保留原有结构——标题、列表、表格里的内容按层级提取。对 PDF处理方案取决于文件质量如果是数字生成的 PDF直接用 pdfplumber 或者 PyMuPDF 提取文本保留基础版式如果是扫描件则需要先做 OCR这一步可以调用本地 Tesseract也可以接 PaddleOCR 这类效果更好的引擎。这里要重点说一个工具Unstructured。它是一个专门做文档解析的开源库能把 PDF、Word、PPT、HTML 等格式解析成带元数据的元素列表比如每个元素是标题、正文、表格还是图片。我在 Mac 上做本地解析时常用它配一个简单的 Python 脚本就能把整批文档抽出干净文本。如果你处理的是学术论文或者产品手册还可以试试 Marker它能把 PDF 直接转成带层级结构的 Markdown对双栏和表格支持比普通 PDF 抽取库好很多。文本抽取这个环节多花二十分钟后面检索效果能提升一个档次这是性价比最高的前期投入。2.2 文本拆解的“体感调参”chunk size 与 overlap文本拆解是 RAG 项目里让人又爱又恨的环节。切得太短语义碎片化一个问题可能被拆散到好几块里检索时哪一块里都找不到完整信息切得太长噪声太多向量化后语义被稀释检索出来的内容里真正有用的可能只有一两句话大模型还要从一大段废话里挑答案准确率同样下降。我常用的起点参数是 chunk size 在 256 到 512 token 之间overlap 按 chunk size 的 10% 到 20% 设置。以 512 token 的 chunk、64 token 的 overlap 为例相邻两个文本块之间会共享一部分内容这样即使一个关键句恰好落在前一个块的末尾也能在后一个块的开头再出现一次避免漏检。这个参数组合对绝大多数中文文档都算稳妥但实际效果仍然要按内容类型做调整。2.3 向量化与 embedding 模型选型文本切好之后下一步是把每一块转成向量。embedding 模型的选择直接决定了检索的召回质量这是 RAG 项目里最不该随便应付的环节。开箱即用的方案是调用 OpenAI 的 text-embedding-3-small 这类在线接口质量稳定、接入快缺点是每一篇文档都要上传到外部服务对数据敏感的内网项目不适用。本地部署的方案里我测试过 BGE 系列模型表现很好尤其是 BGE-M3在中文语义理解上比很多同体量英文模型强很多同时支持稠密检索和稀疏检索两种模式后面做混合检索时可以共用一套向量。如果你的环境跑不了大模型也可以用更轻量的 text2vec 或者 m3e 系列效果略逊一筹但速度更快。最近 Ollama 也支持了 nomic-embed-text 和 bge-m3一条命令就能在本地起一个 embedding 服务对做实验和搭建个人知识库来说性价比很高。选模型的时候有一个容易忽略的细节检索用的 embedding 模型和生成回答的大模型不需要来自同一家公司也不需要绑定运行。常有人觉得“我用 Llama 本地部署那 embedding 也必须用 Llama 系列”其实没有这个限制embedding 和生成两套模型是独立的可以分开选型。只要保证一个关键前提所有文档切片和用户查询都要用同一个 embedding 模型不能用两个不同的模型分别向量化否则向量空间不一致相似度计算就没有意义了。3. 知识库到底能不能存图片多模态 RAG 的边界3.1 为什么图片经常“进不了”知识库“RAG 知识库能存图片吗”是搜索热度很高的问题也是很多初学者绕不过去的困惑。直接回答纯文本 RAG 的向量库不能直接理解图片内容。原因在于最主流的 embedding 模型处理的是文本图片直接送进去没有任何意义。很多人在本地搭建知识库时发现传了几张截图进去检索的时候却完全检索不到就是因为没有对图片做任何处理图片压根没有变成可检索的文本。这并不意味着知识库完全和图片绝缘。如果你用的向量数据库本身支持多模态向量比如 Milvus 这类专业向量库接入了 CLIP 或 ImageBind 模型确实可以把图片编码成向量做图搜图。但这属于多模态检索的范畴实现成本和工程复杂度比普通文本 RAG 高不少初学者通常不需要一上来就走这条路。3.2 实际可行的做法图片转描述再入库对绝大多数知识库场景最稳妥的做法不是把图片直接入库而是把图片“翻译”成文本描述之后再把文本放进知识库。具体流程是用大模型或者专门的图像理解模型给每一张图片生成一段文字说明比如“图中展示的是系统登录界面左上角为用户名输入框右侧为验证码区域”然后把这段描述和图片在文档中的上下文一起拼成文本块入库。用户提问时检索发生在文字描述层模型读到的是“图片内容的文字版”照样能给出有用回答。我实际处理过一个产品说明书项目文档里有大量界面截图和流程图最初直接用 PDF 抽取图片内容全部丢失导致很多问题回答不了。后来我把 PDF 先转成 Markdown再用多模态模型对图片逐张生成描述插入到对应章节的位置整个知识库的召回率明显提升。这个流程现在有标准化的开源工具可以做比如一些文档解析库已经内置了“OCR 图像理解 文本化”的流水线无需自己组装。3.3 表格、PDF 扫描件这类“伪图片”怎么处理有些内容看起来不是图片但处理方式却和图片类似。表格就是最常见的例子原生从 PDF 抽取出来的表格经常是一堆散落的字符行列关系全丢扫描版的合同、发票就更不用提本质上就是图片。这些内容如果直接丢进文本 RAG检索到之后回答质量大概率是不合格的。表格类内容的推荐做法是转成 Markdown 表格或者 JSON 结构化之后当作一个整体 chunk 存入知识库。大模型对 Markdown 表格格式的识别能力很强只要文本块里保留了完整结构它在生成答案时就能正确理解“第一列是配置项第二列是默认值”这类关系。扫描件则必须走 OCR这一步做完之后还要做版式还原尽量把识别出来的文本按原始阅读顺序重新拼接。我见过不少项目卡在“扫描件检索到了但答案不对”这个问题上排查下来都是 OCR 文本顺序出了问题排版乱掉的文本块比检索不到更误导模型。4. 检索链路才是 RAG 的灵魂检索增强不只是搜一下4.1 相似度检索的局限关键词与语义之间的平衡很多初学者以为 RAG 的检索就是用向量数据库查一下相似度跑通之后发现效果时好时坏。原因在于纯向量检索对长尾关键词、编号、产品型号这类精确信息并不敏感。比如用户问“CH-3200 的额定功率是多少”向量模型可能把这串型号理解成“某个设备型号”但“CH-3200”这个精确匹配信号在向量检索里并不占优势最相关的文档反而排不到前面。解决这个问题需要意识到RAG 的检索本质上应该分两路走一路做语义召回靠向量相似度找到意思相近的内容另一路做关键词召回靠 BM25 这类经典算法做精确匹配。然后把两路结果做合并和重排术语叫“混合检索”Hybrid Search。我用过的方案里向量库用 Milvus 或者 Qdrant关键词检索可以直接用 Elasticsearch也可以用一个更轻量的 MeiliSearch 或者 SQLite FTS5按数据量级来选。合并策略上常用的是用倒数排名融合RRF算法把两份结果按排名做加权合并保证两路召回的内容都有机会进到最终候选集。4.2 重排序让最相关的答案排到最前面混合检索拿到一批候选文档之后另一个关键步骤是重排序。向量相似度衡量的是“整段文本语义上有多接近”但语义接近不等于“问题中的核心信息在答案里都有”。做重排序最有效的方法是引入一个专门的重排模型reranker它会把问题和候选文档逐条拼接起来计算相关性得分这种交互式打分比纯向量距离更精准。开源方案里我会优先推荐 BGE-Reranker它的模型设计就是针对中文问答场景做的重排效果和推理速度平衡得不错。实测下来一个嵌入模型召回后有 30 条候选的查询用重排模型重新排一遍之后Top 1 结果往往和实际需要的答案高度相关对比不重排的情况提升显著。需要注意重排模型也是本地部署时的主要算力消耗点之一对性能要求高的线上场景一些团队甚至会专门做缓存和并发优化。但哪怕只是做一个小工具我认为重排这一步也不该省它是性价比非常高的精度提升手段。4.3 知识图谱 RAG 和 RAG 智能体的差异“知识图谱 RAG”和“RAG 智能体”是最近热度很高的两个词初学者容易混为一谈。简单来说知识图谱 RAG 是在传统 RAG 基础上额外引入了一层的结构化知识文档切块和向量化照旧做但你同时把文档里的实体、关系抽取出来建成图谱结构比如“张三”是“市场部”的“员工”“市场部”的“负责人”是“李四”。图谱可以回答那些依赖多级关联的问题比如“张三的部门负责人是谁”普通 RAG 需要从多篇文档里拼凑推理知识图谱可以直接走关系路径。这类方案搭建成本高因为实体识别、关系抽取都要精确处理但对特定领域比如医疗、法律的关联问答场景收益明显。RAG 智能体则是把 RAG 从“查一次、答一次”升级成“可以多轮决策”的形态。智能体收到问题后先判断要不要检索再决定检索哪几个知识库对结果不满意就改关键词再检索一次甚至同时调用另外一个 API 获取结构化数据最后把多来源信息组装成答案。它的核心特征是拥有循环和工具调用能力适合复杂查询。但代价是可控性下降出问题的时候排查链路变长。对初学者我的建议是先扎实掌握普通 RAG 和混合检索再研究知识图谱和智能体否则很容易陷入“什么都要接智能体但什么问题都回答不准”的泥潭。5. 本地搭建 RAG 的常见路径与工具选型5.1 在自己电脑上搭建 RAG 的配置思路以 Mac 为例“怎么在 Mac 上搭建 RAG 知识库”是搜索量很高的问题确实很多刚接触大模型应用的朋友手上只有一台 Mac不想上来就买服务器。以一台 Apple Silicon 芯片的 Mac 为例完全可以在本地跑起一套完整的 RAG 链路Ollama 负责本地大模型和 embeddingChroma 做向量库再加一个小型 Python 脚本做文档处理全部内网运行数据不出本机。具体流程我建议按这样走第一步安装 Ollama拉取一个大语言模型起步可以用 qwen2.5:7b 这类中文表现不错的 7B 模型再拉一个 bge-m3 作为 embedding 模型第二步用 Python 写一个简单的文档加载脚本把 Markdown、TXT 这些文本类型直接读入PDF 用 Unstructured 解析第三步把文本块交给 embedding 模型转成向量写入 Chroma 持久化目录第四步写一个查询函数用户输入问题后先向量化再从 Chroma 取出相似度最高的几个文本块连同问题一起拼进提示词交给 Ollama 生成回答。整个过程不依赖任何外部云服务一台 16G 内存的 Mac 跑 7B 模型虽然速度不算快但做学习验证和个人知识库完全够用。如果你不想写代码也可以直接用现成的开源应用。RAGFlow 是我实测下来对新手比较友好的一套系统它自带文档解析、知识库管理、问答界面部署后就能用对中文文档支持也很好。LangChain 和 LlamaIndex 则更适合想深入理解原理、通过代码自由控制流程的人两者定位略有差异LangChain 的组件生态更丰富适合构建复杂链路LlamaIndex 主打文档索引和检索对 RAG 场景更聚焦。5.2 常见开源 RAG 框架怎么选框架选型是大家问得最多的问题之一我把几种典型方案的定位和适用场景整理成了表格方便对比。方案核心定位上手难度适合场景自研脚本Ollama Chroma最小可用链路低学习原理、快速验证LangChain / LlamaIndex开发框架中定制化程度高、需要代码控制RAGFlow开箱即用系统低快速搭建知识库应用中文友好Dify低代码平台低面向业务配置、可视化流程编排企业级生产方案Milvus Elasticsearch 等生产级链路高高并发、大规模文档、需要精细化治理初学者选择时不要一上来就上最重的框架。我见过不少朋友第一天就在折腾生产级集群最后光部署就卡了一周核心链路反而没跑通。建议先用手写脚本跑通最小链路切身理解每一环的功能之后再挑选框架去简化开发。纸上谈兵没有意义跑通一次你对 RAG 的体感会完全不同。5.3 从“demo”到“可用”要跨过的几道坎把 RAG 从演示跑通变成能稳定使用中间有几道坎几乎人人都会遇到。第一道坎是文档更新机制。很多人做了知识库之后就忘记更新文档内容已经变了检索出来的还是旧信息。这个问题不解决知识库很快失去价值。第二道坎是检索质量评估。跑一次效果好不好是主观感受但上线前需要建立客观评估基准准备一批有确定答案的测试问题统计检索结果里包含正确答案的比例用这个指标来驱动参数调优。第三道坎是提示词稳定性。同样的检索结果提示词写法不同回答质量可能差异巨大需要反复调试才能稳定输出。这三道坎不是一次性工程而是持续迭代的过程。我在做完第一个可用版本后花了将近一半的时间在整理测试集和调提示词上这个投入非常值得。后面常见问题部分我会再展开讲几个高频故障的排查思路。6. 常见问题与排查技巧实录6.1 检索结果差是模型的问题还是检索的问题这是排查 RAG 问题时的第一个分岔路。一个常见的错误是回答质量差就先怪大模型但很多时候问题出在检索环节知识库里根本没有相关内容或者相关内容没有被正确召回。排查方法很简单先在系统里把检索到的文本块原样打印出来人工判断这些文本块是否真的能回答问题。如果检索结果本身就对不上说明问题在文档处理、切分、向量模型或检索策略换再大的生成模型也没用如果检索结果是对的但模型回答得不好那才需要优化提示词或者换一个更强的生成模型。我经常用一个比喻RAG 系统的效果上限由检索决定下限由生成决定。检索不到关键信息再强的模型也巧妇难为无米之炊检索到了关键信息至少模型不会胡编太离谱。所以排查问题永远先查检索再查生成。6.2 知识库更新了为什么回答还是旧内容这个问题的根因几乎都是缓存和索引不同步。向量数据库里的数据是构建索引时刻的快照如果新增或者修改了文档但没有重新执行向量化和写入流程检索结果自然不包含新内容。解决思路是建立清晰的更新策略全量重建用在小规模知识库上最简单可靠每次变更后直接清空旧索引、重新入库增量更新用在内容经常变动的场景需要根据文档的唯一标识判断新增、修改、删除再对应地做向量写入和删除。增量更新实现起来比全量重建复杂得多如果文档总量不大系统设计时我倾向于先用全量重建每天定时跑一次成本不高逻辑还不会出错。等到文档量级上来之后再迁移到增量策略。6.3 RAG 的瓶颈与它不适用的场景明确说出瓶颈在哪里也很重要。当前 RAG 最主要的瓶颈有三个一是长文档多跳问题的推理能力弱当答案需要跨多个文档片段组合推理时单次检索往往漏掉必要信息二是知识冲突处理难同一问题在知识库不同位置有矛盾表述时模型很难判断以哪个为准三是评估困难没有标准化的评测集和统一指标很难准确判断系统的真实水平。不适合的场景同样需要警惕回答开放性的主观题、需要最新实时信息的强时效任务、以及需要深度逻辑推理的复杂分析这些场景里 RAG 的表现都会打折扣需要配合其他架构解决。说到底RAG 是一个需要持续调优的系统工程不是跑通 Demo 就结束的事情。根据我个人在这些项目里的体会投入产出比最高的三件事分别是前期的文档解析质量、检索阶段的重排序、以及一套能重复使用的评测问题集。把这三件事做好你的 RAG 项目就已经超过了大多数停留在平均水平的实现剩下的就是在具体数据上持续迭代了。