RAG检索增强生成是我做 AI 应用开发时最建议新手先搞懂的一套技术路线。它解决的问题非常具体大模型没有学过你的业务文档遇到私有知识、实时信息、长尾领域问题时要么答不出来要么一本正经地编答案。RAG 的思路是先把知识文档切块、向量化、存进知识库用户提问时先做检索把最相关的片段拼进上下文再让大模型生成回答。这样一来回答有依据、能追溯幻觉也会明显减少。这篇实战内容适合两类人一类是刚接触 AI 应用开发想给大模型接知识库的开发者另一类是已经跑过简单 Demo但发现“查得不准、答得不对”想深入了解高级检索策略的人。下面按从 0 到 1 的顺序把 RAG 的原理、最小系统、高级检索、切块策略和落地排查完整过一遍。1. 先搞清楚 RAG 到底解决了什么问题1.1 大模型“不知道”和“瞎编”是两回事很多人第一次做知识库问答时会把问题理解成“让模型变得更聪明”。实际上RAG 不是在训练模型而是在给模型提供参考资料。通用大模型的知识截止时间是固定的。你问它“上季度某产品线的销售数据”它大概率只能给一个通用回答因为这类数据不在公开语料里。更麻烦的是模型在找不到答案时会按照语言习惯生成一段看起来像答案的内容。这就是幻觉。RAG 的核心价值是把答案来源从“模型记忆”迁移到“检索证据”。模型需要回答什么都由检索结果说了算。所以RAG 最适合的场景是企业内部知识库、产品文档、技术手册、售后问答、客服辅助、研究资料查询。这些内容的共同点是专业、私有、需要准确引用。如果你的需求是让模型学会某种写作风格或者学会特定领域的术语表达那 RAG 不一定是最优解微调可能更合适。只要你有资料、有明确知识源RAG 就是一条非常稳妥的路线。它有索引、有检索、有引用出问题时能追查改资料后也能及时反映到答案里。1.2 RAG 和微调怎么选边界在哪里有些开发者一提到私有化部署就想着微调。这是最常见的误判。我一般会先问三个问题知识会不会经常更新如果每周都在变RAG 更合适。回答是否要求带出处如果业务上需要追责或核验RAG 更合适。模型能力是否根本不够比如需要把自然语言转成 SQL、需要掌握某种复杂任务流程微调或工具调用更合适。微调适合让模型“学会一种行为”比如特定格式输出、固定术语、语气风格。但它不适合用来记忆大量具体数据。把几千篇文档塞进模型参数成本高、更新难、还容易过拟合。RAG 则是把“知识库”放在模型外面相当于给模型开卷考试。真正的生产系统里RAG 和微调也不是互斥的。常见做法是先微调一个小模型让它更听话再通过 RAG 提供最新知识。如果你刚起步建议先把 RAG 跑通再判断是否需要微调。2. 一套最小 RAG 系统的完整流程2.1 从加载到生成的六个环节RAG 从外部看只是“提问-回答”两步内部其实是一条完整的流水线文档加载读取 PDF、Word、Markdown、HTML、纯文本等文件。切块把长文档切成适合检索和嵌入的小段。向量化用 embedding 模型把每一段转成向量。向量存储把向量和对应的原始文本存进向量数据库。检索用户提问时把问题转成向量在库里找最相似的片段。生成把检索到的片段和用户问题拼成提示词交给大模型生成回答。这个流程里最容易出问题的不是最后一步生成而是前五步。尤其是切块和检索直接决定模型拿到的上下文对不对。如果你用 LangChain、LlamaIndex、Dify 这类框架前几步都有现成封装。但封装不代表不用理解。框架默认的切块规则、检索逻辑不一定适合你的文档。真正做项目时你还是要回头检查数据。2.2 最小可运行示例下面是一个用 Python 常见开源框架跑通的示意流程。我只给核心代码片段具体依赖和接口以你本地的实际环境为准。# 示意代码以 LangChain 生态为参考 from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载文档 loader TextLoader(docs/rag_intro.md, encodingutf-8) documents loader.load() # 2. 切块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, ) chunks splitter.split_documents(documents) # 3. 向量化 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5 ) # 4. 构建向量库 vectorstore FAISS.from_documents(chunks, embedding_model) # 5. 检索 生成 retriever vectorstore.as_retriever(search_kwargs{k: 4}) query RAG 的核心流程是什么 docs retriever.invoke(query) for doc in docs: print(doc.page_content)跑完这段代码你会看到和问题最相关的几个文本片段。这代表检索环节已经通了。第一次跑的时候不要急着加很多参数。先用小文档、小切块把链路跑通再逐步替换成你自己的数据。如果这一步就报错优先检查依赖版本和模型下载是否成功。2.3 环境准备和前置条件在本地跑最小 RAG 系统一般需要Python 3.9 以上。一个能运行的 embedding 模型。可以用本地开源模型也可以调用云服务接口。一个向量存储方案。FAISS 适合学习和本地小规模验证Chroma 适合快速做原型正式生产再考虑更重的服务。一个可调用的 LLM。可以是本地模型也可以是 API 服务。如果机器配置一般不要一上来就加载大模型。先用系统自带的轻量模型或云 API 跑通逻辑后面再考虑本地部署。注意这里我建议先跑单条样例别急着处理整个目录。先确认加载、切块、向量化、检索四步都正常再处理批量文件。3. 高级检索的核心多路召回、混合检索和重排3.1 纯向量检索的局限很多入门项目只做“向量检索”问题转成向量跟库里所有向量算相似度取 top 几个。这在文档数量少、内容规范的时候够用但一旦数据量上来问题就暴露了专有名词匹配不准。比如产品型号、工单编号语义向量不一定能精确匹配。长文本泛化差。如果一个问题涉及多个概念向量检索可能只找到其中一个方面。关键词缺失。用户问“退款流程”文档里写的是“退费操作”向量检索可能能找到但关键词检索更稳。紧急信息、数字条件、日期范围向量检索很难精确控制。所以真正做高级检索时不能只依赖一种检索方式。你需要的是多路召回。3.2 多路召回里有哪些检索方式多路召回的意思是用多种检索器分别查一遍再把结果合并。常用组合包括向量检索处理语义相似适合同义改写、口语化表达。关键词检索使用 BM25、TF-IDF 或 Elasticsearch 的 query_string精确匹配专有名词和编号。知识图谱检索通过实体和关系处理“A 的员工有哪些”这类结构化问题。搜索语法检索在外部网页或文档库中通过 site:、filetype:、intitle: 等条件缩小范围。举个例子。用户问“BAAI/bge-small-zh-v1.5 模型在哪些场景下效果比较好”纯向量检索可能召回的片段不够完整。如果用多路召回关键词检索可以精确找到包含bge-small-zh-v1.5的段落向量检索可以找到语义相关但不一定包含型号的段落两路结果合并后再交给重排模型排序。多路召回不一定要复杂到微服务。刚开始可以用一个函数把多个检索结果去重合并。合并时要注意同一个文档可能被两路同时召回去重时要保留最完整、来源置信度最高的片段。3.3 重排怎么把结果变准多路召回之后结果会变多但未必按相关度排好。直接把这些结果全部塞给大模型提示词会变得很长信息也杂乱。重排rerank就是解决这个问题。重排模型的输入是“问题 候选文档”输出是一个相关度分数。常见做法是先用向量检索和关键词检索各取 20 到 50 条候选再用一个交叉编码器或 rerank 接口重新打分取 top 3 到 5 条给大模型。强调一下召回阶段可以便宜、快速、广撒网重排阶段再精打细算。不要把重排模型用在所有文档上那样速度会很慢。一个比较稳妥的策略是召回阶段BM25 和向量检索各取 top 20。合并去重得到 30 到 40 条候选。重排阶段用 rerank 模型取 top 5。生成阶段把 top 5 片段拼进上下文。重排模型的选择要看你的文档语言。中文场景下优先选在中文数据集上表现好的模型。不要只看开源榜单上的英文分数实际效果以你自己的测试集为准。3.4 网页检索语法也可以当作外部知识源如果你做的是公开知识类 RAG比如舆情整理、行业资料检索外部知识源可能来自网页搜索。网页搜索引擎自带的高级检索语法在某些场景下比向量检索更直接。以必应为例常见的几条site:example.com把结果限制在某个域名。filetype:pdf限定文件类型。intitle:关键词要求关键词出现在标题中。-关键词排除某个词。“完整短语”精确匹配连续词组。这些语法在普通浏览器里就能用不需要额外工具。它们适合用来筛选来源、排除噪音、定位特定格式文档。把这种检索结果作为 RAG 的外部知识来源时要注意网页内容质量参差不齐最好先做内容清洗再进入切块和向量化。注意搜索引擎的高级语法在不同产品线、不同地区、不同浏览器里支持程度并不一致。使用前先在你常用的搜索页面上验证一下避免把临时失效的语法写成固定代码。4. 切块策略是 RAG 效果的分水岭4.1 固定切块和递归切块的区别切块是 RAG 里最容易被低估的环节。很多人直接用默认配置结果检索出来的片段只有半句话、跨段落、上下文断裂最终回答自然不准确。固定切块就是按固定字符数切。比如每 500 字一块相邻两块重叠 50 字。实现简单但容易在句子中间截断。递归切块会按段落、句子、单词逐层拆分尽量让每一块在语义上完整。LangChain 里的RecursiveCharacterTextSplitter就是递归切块的常见实现。我建议优先使用递归切块不要用纯固定切块。至少保证每个片段是一个完整段落或几条连续句子。如果文档本身有结构化标题还要保留标题信息否则模型只看正文片段不知道它属于哪一节。4.2 语义切块和父子块切块不能只看字符长度还要看语义边界。语义切块是根据句子的语义变化来切比如某个话题结束后自动断开。实现上一般需要模型辅助成本比固定切块高。但如果你的文档是产品说明、论文、法律条款这种结构清晰的内容语义切块的效果会更明显。父子块是另一种解决上下文断裂的思路。子块比较小用于检索父块比较大用于生成。比如子块是 200 字父块是整节内容。检索时用子块找到精确片段再把子块对应的父块交给模型。这样模型能看到更完整的上下文召回精度和生成质量都能兼顾。这种方案适合长文档问答。如果你的文档是一篇篇论文、一份份合同子块可能太小导致信息不完整父块又太大导致检索不准。用父子块可以解决这个矛盾。4.3 切多长合适参数怎么定没有绝对的“最佳切块长度”因为不同文档、不同模型对上下文长度的要求不一样。但有一个通用的判断方法先把常见的问答提出来人工判断“答案大概在文档哪个位置覆盖多长”。根据答案长度设计chunk_size。如果答案往往是一整段chunk_size可以设 800 到 1000 字。如果答案是几个关键词或一句话chunk_size设 200 到 400 更灵活。chunk_overlap的作用是保留上下文边界。一般设置为chunk_size的 10% 到 20%。重叠太少跨块句子容易断重叠太多存储和检索的重复内容会变多效率下降。我通常会针对同一批文档测试多组切块参数(400, 80)(600, 100)(800, 120)每组都跑一遍同一批“测试问题”看检索结果的连贯性和答案准确度。不要只看一两个问题至少要准备 20 到 30 个代表性问题。5. 参数、框架和判断标准5.1 用哪些指标判断系统有没有变好很多人在 RAG 项目里只用“感觉回答变好了”来判断效果这不严谨。生产系统至少要看三个维度召回质量相关文档是否真的被找出来。生成质量回答是否忠实于检索到的片段。系统稳定性日志、耗时、失败率、数据更新是否可控。具体可以拆成这些指标指标说明判断方式召回率正确文档是否在 top k 中人工标注测试集查召回结果命中率检索结果是否包含关键信息看 top 3 片段与问题的相关性答案忠实度回答内容是否基于检索片段逐条核对引用看有没有“发挥”溯源一致性答案能否从检索片段中找到对应依据点击引用片段核验单次耗时从提问到回答的完整耗时压测和日志统计连续任务成功率批量跑 100 条不中断、不报错的比例看任务队列和日志我一般建议先建一个小的测试集20 到 50 个问题。不需要很重但每个问题要写明“期望答案来自哪几个片段”。这样每次改参数都能对比出是变好还是变坏。5.2 主流 RAG 框架怎么选LangChain、LlamaIndex、Dify 还是自研选框架之前先想清楚你是要快速验证还是要长期维护。LangChain 非常灵活生态大组件多适合想要高度自定义的开发者。但它的抽象层级比较多版本更新快接口变化也快。如果你刚入门不要一次学太多组件先用一个稳定版本跑通。LlamaIndex 更聚焦在“文档索引和检索”。如果你主要做知识库问答、文档问答LlamaIndex 的学习曲线会更舒服。它提供的索引类型和数据连接器很丰富。Dify 偏应用平台适合可视化搭建、快速演示、给非技术人员验证流程。它内置了知识库、工作流、 Agent 这些功能不需要写太多代码。但如果要深度定制检索逻辑平台型方案就不如代码方案自由。我的建议是学习阶段代码手写一遍理解流程做原型或内部工具可以用 Dify做正式产品再用 LangChain 或 LlamaIndex 这类可编程框架如果公司有特殊要求也可以直接自研核心链路。“要不要自研”这个问题关键看数据资产和数据接口。如果你的知识库只是几十个 Markdown 文件用向量数据库加一个检索函数就够了没必要引入重量级框架。如果数据源复杂包括数据库、对象存储、网页、工单系统再考虑用框架统一连接。5.3 Agentic RAG 和 Ontology RAG 是进阶不是默认搜索热词里经常出现 Agentic RAG 和 Ontology RAG。这两个概念可以知道但不要一上来就套。Agentic RAG简单来说就是把检索流程交给 Agent 动态决策。传统 RAG 是“每次提问都固定检索”。Agentic RAG 会让 Agent 先判断是否需要检索、该检索多少次、要不要改写问题、要不要调用外部工具。适合复杂任务比如多跳问题、需要多轮确认的业务查询。但它引入了更多不确定性需要设计好巡检和兜底逻辑。Ontology RAG 和“知识图谱与向量数据库”相关。它是把实体、关系、属性显式建图再结合向量检索。适合关系型问题比如“产品 A 的下游供应商有哪些”“某个组件影响了哪些模块”。纯向量检索很难回答这类问题知识图谱可以。但这些都不是学习 RAG 的第一站。先把基础链路跑通再逐步加入重排、多路召回、Agent 决策。不要一开始就把系统做成一个大而全的复杂体。6. 从 Demo 到生产批量、更新和排查6.1 批量文档处理和失败重试Demo 只处理几份文档时一切正常。一旦丢进去几千份 PDF问题就来了格式解析失败、文件编码错误、切块中断、向量库写入失败。批量处理不能只看“能不能跑”还要看失败重试和日志。我建议按这个顺序来做先处理一小批比如 50 份文档。记录每份文档的成功、失败、异常类型。修复解析和编码问题后再处理超过 500 份。给每个文件生成独立任务 ID日志中记录文件路径、耗时、切块数量、写入状态。失败任务不阻塞整个队列单独进入重试区。如果文档是 PDF最容易出现“文字能打开但复制不出来”的问题。这是扫描件需要 OCR。不要急着在 RAG 里做先用专门的工具把文字抽出来再进入切块流程。6.2 知识更新与版本管理RAG 不是建好索引就一劳永逸。文档更新后旧向量还在库中新知识又不能被检索到这是生产环境最常见的坑。比较稳妥的做法是给文档打版本号。每次更新时把变更文档对应的向量删除或标记失效再写入新版本。如果向量数据库不支持单条更新可以按批次重建索引。还要注意“同一份文档多个版本并存”的问题。比如用户上传了一份新的产品手册但旧手册没有被删除检索时就会同时召回新旧两版内容。回答就会出现自相矛盾。我建议在入库前增加一个去重逻辑按文件名、发布时间或者正文哈希判断是否重复。6.3 常见现象和排查顺序RAG 系统出问题时很多人第一反应是“换一个更大的模型”。但大部分问题不在模型而在检索链路。按下面的顺序排查通常能更快找到根因先看现象。是报错、超时、空答案、还是答案与文档不符。再看输入。文件格式、编码、路径、内容是否完整。再看检索。把问题单独拿去查向量库看召回的前几条是否相关。再看切块。召回片段是不是被截断了上下文是否完整。再看提示词。拼给模型的上下文是否被截断、是否包含无关片段。最后看模型。确认模型能力是否足够提示词是否清楚。举例来说如果用户问“退货政策是什么”模型答“根据文档退货需要在 30 天内”但文档里根本没有这句话那大概率是检索到了错误的片段或者切块时把不同章节拼在了一起。这时候检查搜索出来的片段比改模型参数更有效。还有一个容易被忽略的问题文档加载时没有保留标题层级。模型只拿到了正文片段不知道它属于“政策适用范围”还是“退换货流程”。这种情况下即使检索命中答案也可能不完整。6.4 落地顺序建议最后说下我比较推荐的落地顺序。第一步用 20 份文档建一个非常小的知识库跑通最小链路。 第二步准备 20 到 30 个测试问题人工标注答案来源。 第三步逐一调整切块参数和检索参数观察指标变化。 第四步加入多路召回和重排看效果是否有提升。 第五步扩展到批量环境处理日志、失败重试、向量库写入。 第六步接入生产问答入口设计权限、审计和数据更新流程。整个过程不要追求一步到位。很多团队失败不是因为技术不够而是因为一开始就上了复杂架构出了问题根本定位不到。我自己做 RAG 项目的习惯是先保证每个环节都能被观测到再谈优化。切块数量、检索耗时、命中片段、模型输出全部打印到日志里。短期看有点繁琐长期看救命的都是这些细节。如果你打算长期维护一个 AI 应用RAG 一定会是你最稳的知识底座。真正落地时要盯住的不是花哨的框架和概念而是数据清洗、切块质量、检索准确度和可观测性。把这四件事做踏实RAG 项目就成功了大半。