jeremymoo做 LLM 应用开发的朋友，肯定都被同一个问题折磨过：模型一本正经地胡说八道，或者拿三个月前的旧知识回答今天的问题。RAG（Retrieval-Augmented Generation，检索增强生成）就是目前行业内解决大模型幻觉和知识过时最主流的工程方案，没有之一。它的思路很直白——不指望模型记住所有知识，而是在回答前先从外部知识库检索相关内容，再把这些内容塞进 Prompt 让模型基于事实作答。这篇文章我会从架构设计、文档切分、向量检索、评测调优一路讲到线上维护的坑，全程按我在实际项目里跑通的路径来写，适合刚接触 RAG 的开发者，也适合已经搭了一版但效果不理想、想系统排查问题的人。
我最早接触 RAG 是在做一个内部知识库问答系统的时候，一开始想靠微调让模型学会所有内部文档，结果训练成本高、更新周期长，模型还经常把两篇相似文档的内容记串。后来切到 RAG 方案，一周内就把准确率从勉强能用拉到了业务可接受的水平。所以这篇文章不只是把概念讲一遍，会把每个环节为什么这么做、参数怎么定、失败了怎么排查都交代清楚。
1. 整体设计思路：RAG 凭什么能解决幻觉和知识过时
RAG 的核心逻辑其实特别朴素——把“记忆”从模型参数里搬到外部，让模型变成一个“带着资料答题的考生”。模型本身依然有知识盲区和幻觉倾向，但当你把相关文档片段直接放到它的上下文里，它就只能基于这些片段组织答案，编造的空间就被压缩到极小。这也是为什么 RAG 是当前解决幻觉类问题性价比最高的路线，不需要重新训练，不需要海量算力，只需要做好检索和提示词两件事。
1.1 大模型为什么会产生幻觉，RAG 怎么对症下药
要理解 RAG 为什么有效，先得理解幻觉的来源。大模型在训练时见过海量文本，但它的目标只是“预测下一个词”，并不是建立一个精确的事实数据库。训练数据里的错误信息、相互矛盾的表述、时间久远的内容，都会被模型以概率分布的形式记住。当你提问时，模型激活的是这些模糊记忆中最接近的部分，它自己也无法区分哪些是事实、哪些是拼接出来的合理文本。所以幻觉不是 bug，而是语言模型的固有属性。
RAG 的对症下药方式是在生成之前增加一道“证据注入”步骤。系统先从向量数据库中检索出与用户问题最相关的若干文档片段，把这些片段和用户问题一起拼进 Prompt，再让模型只依据这些片段作答。在回答关于某公司产品参数的问题时，如果 Prompt 里明确写入了该公司最新产品文档中的参数表格，模型就不太可能输出三个月前的旧参数，因为新参数已经出现在它的上下文里，而且 Prompt 中通常会声明“只能使用提供的文档内容，不能使用内部知识”。我在实践中发现，这条约束虽然不能 100% 消除幻觉，但可以把明显的事实错误降低一个数量级。
1.2 为什么不直接微调，RAG 和微调怎么搭档
很多团队一上来就考虑微调，这是一个高频误区。微调的本质是把知识写进模型权重，知识更新一次就要重训一次，周期以天甚至周计算。对知识变化快的场景，比如客服话术每两周调整一次、产品手册每周更新，微调根本跟不上节奏。RAG 的知识都放在外部索引里，文档更新后重新切片入库即可，分钟级生效，成本也低得多。
但这不意味着 RAG 要完全替代微调。我的习惯是先用 RAG 解决知识时效性和引用可追溯的问题，再用微调解决“风格和格式”问题。如果业务要求回答必须是特定语气、特定结构，比如客服回复必须包含工单号和致歉语，这时才考虑加一层轻量微调。也可以把两者结合：RAG 负责提供事实依据，微调负责让模型用统一的语气输出。两条路径并不是二选一的对立关系。
1.3 什么场景真正需要 RAG，什么场景用了反而麻烦
RAG 不是银弹。判断是否要上 RAG，核心看两点：知识是否高频变化，答案是否需要引用依据。企业知识库问答、客服辅助、内部文档检索、合规审查，这些场景高度依赖最新、准确的资料，RAG 天然合适。相反，如果任务本身是通用常识问答、创意写作、代码生成，模型内部知识已经足够好，引入 RAG 反而增加延迟和复杂度，还可能因为检索到低质量文本而降低生成质量。
还有一类场景需要谨慎：文档质量非常差的场景。RAG 的效果上限被文档质量卡死，如果源文档是大量扫描件、图片、格式混乱的表格，切分和解析会很难做，检索质量会大打折扣。我之前接过一个项目，客户的“知识库”里一半是模糊截图，另一半是 PDF 里嵌套的图片，这种情况下 RAG 上线前的第一件事根本不是选模型，而是先解决 OCR 和文档结构化的问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 索引构建与文档处理的细节，这一步决定整个系统的上限
RAG 的整体流程可以拆成两条链路：离线索引链路负责把文档切块、向量化、写入向量库；在线检索链路负责把用户问题转成向量、检索相关片段、拼装 Prompt、交给 LLM 生成答案。大多数新手把注意力放在在线链路，但实际上 80% 的效果问题都出在离线链路的文档处理上——切分粒度不对、格式信息丢失、Embedding 模型选错，后面的检索和生成再怎么调都白搭。
2.1 RAG 完整链路由哪些环节构成
我在给团队讲 RAG 架构时，习惯把整个系统画成一张流水线图，从左到右依次是：文档加载、文本清洗、切片、Embedding、索引存储、查询改写、召回、重排序、Prompt 组装、生成。很多简化版教程把中间几个环节省略了，但到了真实项目里，链路越长，可控的调优点越多。
文档加载不是简单地读文件，而是要按格式区别处理。PDF、Word、Markdown、HTML、扫描件，每种的解析方式都不一样。PDF 要区分文本型还是扫描型，文本型用解析库抽取文本，扫描型要先过 OCR。Word 文件要保留标题层级，HTML 要剥离标签但保留语义结构。我在项目里吃过亏：直接用通用解析库读 PDF，结果所有表格变成了乱序文本，后续切片时一格数据被切成两半，检索时查询“某产品价格”永远召回不全。后来换成按区块解析的方式，表格先转成结构化 Markdown 再切片，问题才解决。
2.2 文档切分策略怎么定，参数怎么调
切片是 RAG 里最容易被低估的环节。切片太粗，一块文本包含多个主题，向量化之后语义被稀释，检索精度下降；切片太细，语义被切断，一块内容表达不完整，同样影响召回效果。我的经验是：没有万能参数，但可以从一套基准值开始调。对中文技术文档，我常用 chunk_size=500（按字符数，中文大致对应 250~350 个 token）、overlap=50~100 的初始配置，然后根据效果微调。
关键技巧是 overlap 不能省。切片时相邻块之间保留一段重叠文本，能有效避免关键句刚好落在切片边界被截断。我见过很多新手把 overlap 设成 0，结果查询“系统支持哪几种登录方式”时，包含答案的那句话刚好被切成两段，两个向量块都不完整，top_k 检索时两条都不够相关。重叠文本会增加少量存储和计算成本，但能显著提升召回稳定性。
更进阶的做法是“语义切分”，也就是按 Markdown 标题、段落边界、列表项等结构信息来切，而不是死板按字符数。对带有清晰层级的长文档，我会先把文档解析成树状结构，在每个 H2 或 H3 标题下做段落整合，再结合 max_chunk_size 兜底。这样切出来的块在语义上天然完整，检索效果远好于纯字符切分。
2.3 Embedding 模型和向量库怎么选
Embedding 模型决定了文本在向量空间里的语义表现。判断一个模型合不合适，不能只看榜单分数，要在自己的业务数据上测试——把典型的业务问题和对应的答案片段分别向量化，看相似度排序是否合理。我常用的测试方法是：准备 20~30 条真实业务问题，每条问题手工标注一个正确答案片段和两个干扰片段，计算正确答案的召回排名。如果正确答案排不进前 5，说明模型对这类文本的语义理解不够，需要换模型或调整输入格式。
中文业务场景里，我建议优先考虑开源的中文 Embedding 模型，它们在中文长文本上的表现通常优于通用多语言模型，而且可以本地部署，数据不用出内网。选型时重点看三点：最大序列长度是否覆盖你的切片大小、是否针对中文优化、社区维护是否活跃。
向量库的选择，核心看数据规模和部署环境。数据量在百万条以内，单机版的开源向量库完全够用，部署简单，适合快速验证。数据量到了千万级或对延迟要求很高，才需要考虑分布式方案或者云厂商的向量检索服务。我个人的建议是：初期不要在这上面过度设计，先跑通流程，等数据量上来再迁移也不迟——向量库之间的数据迁移往往就是重新跑一遍索引流程，代价没有想象中那么大。
2.4 混合检索和重排序，什么时候需要加
纯向量检索有一个典型弱点：依赖语义相似度，但对关键词精确匹配不敏感。比如用户查询“RAID 卡故障代码 0x87”，如果文档里写的是“磁盘阵列卡报错代码 0x87”，向量检索可能因为语义接近而召回，但“0x87”这种精确代码如果被向量化后分散了注意力，排序就不一定靠前。这时候加入 BM25 关键词检索，把精确匹配结果和向量结果合并，能显著提升召回质量。
我通常在两种情况下加混合检索：一是业务问题里包含大量型号、编号、人名、专有名词；二是文档里存在大量术语变体，比如“召回率”和“Recall”在文档中混用。混合检索的合并策略，最简单的是给两种检索方式各取 top_k 结果，然后做去重合并。合并后如果直接用，效果可能还是不够稳定，因为 BM25 和向量的打分体系不一致，直接把两种分数相加没有意义。正确做法是再叠一层重排序（Rerank），用一个专门的排序模型对合并后的候选集重新打分。
重排序模型通常是交叉编码器，把查询和每个候选文档片段拼接后整体编码，直接输出相关度分数。相比普通 Embedding 的双塔结构，它能更精细地建模查询和文档之间的交互关系，效果明显更好，但缺点是计算开销大。所以重排序只对第一轮检索出的 top 20~50 条候选做精排，不会对整个向量库全量计算。加了这个环节之后，我项目的 top 5 命中率大概提升了 15%~20%，代价是每次查询多了几十毫秒的延迟。
3. 实操：从零搭一个 RAG 服务，关键步骤和参数配置
从架构到落地，中间隔着一堆细节。这一节我会按实际搭建的顺序，把每一步的关键代码和参数选择逻辑写清楚。整个流程跑通之后，你就有了一个可以继续迭代的基线版本，再去优化检索质量、生成质量时就有了对比对象。
3.1 环境准备和基础依赖
我建议用 Python 3.9 以上的版本，独立虚拟环境，先装三组依赖：文档解析类、向量和检索类、LLM 调用类。文档解析用常见的 PDF、DOCX、HTML 解析库；向量化用一个支持本地或 API 调用的 Embedding 模型；LLM 调用按你自己的模型服务接入，可以是本地部署的开源模型，也可以是云 API。向量库初期用一个轻量本地方案即可，先别上分布式架构。
部署方式上有一个容易忽略的点：Embedding 模型的加载和 LLM 推理要分开规划。如果 Embedding 模型和 LLM 都挤在同一块 GPU 上，文档批量索引时 GPU 会被 Embedding 计算占满，在线查询时 LLM 又被拖慢。我的做法是：Embedding 模型用 CPU 跑也不算慢（批量索引可以慢慢跑），在线服务的 LLM 占用 GPU；如果 Embedding 必须上 GPU，就单独开一个服务，和 LLM 服务分开部署。
3.2 文档解析与索引入库的全过程
第一步是解析。对文本型 PDF，用解析库把每页文本抽取出来，按页码保存。对 DOCX，用解析库抽取段落和表格，保留标题层级。对扫描型 PDF，只能先过 OCR 引擎，把图像转成文本，这个环节要检查识别准确率，尤其是表格和英文数字混合的内容，OCR 经常出错。
第二步是清洗。去掉页眉页脚、重复的水印文字、无意义的换行符，把全角半角做归一化。我记得在处理一个客户文档时，每页页眉都有公司名，结果切分后几乎所有 chunk 里都混入了相同的页眉文本，导致检索时大量相似结果干扰排序。清洗这一步在效果调优里被频繁低估，但真实项目的 dirty 数据远比想象中多。
第三步是切片，按前面说的基准参数来。代码结构的示意大致是：遍历章节结构，按标题划分一级块，超过长度上限就拆子块，子块之间保留 overlap。切片完成后，每个块记下它的来源文档、所在页码、章节路径，这些元信息在后续生成引用来源时非常关键——用户看到答案时必须能看到出处，这是 RAG 系统可信度的基石。
第四步是向量化入库。把每个切片送入 Embedding 模型，得到向量，连同文本内容和元信息一起写入向量库。入库时要注意字段设计：向量字段用于相似度检索，文本字段用于生成阶段直接取回原文，元数字段用于过滤和溯源。索引阶段如果文档量很大，建议分批入库并定期检查失败记录。
3.3 检索与生成链路的完整实现
在线查询的流程是：用户问题进来，先做查询改写，再转成向量，从向量库召回 top_k 候选（同时可以做关键词混合召回），合并后送入重排序模型精排，取 top_n 片段拼装 Prompt，最后调用 LLM 生成答案。
查询改写是一个常常被忽略但效果很好的环节。用户的原始问句往往口语化、带有指代词，例如“它的部署方式怎么样”，这里的“它”在前文里可能指某个系统，单独拿去检索效果会很差。我的做法是：先让 LLM 根据对话历史把问题改写为独立的、包含完整上下文的查询语句，再拿去检索。对单轮问答，还可以做一种轻量改写：抽取问题中的关键实体和术语，和原始问题拼接后一起检索。这个环节多加一次 LLM 调用，会增加几百毫秒延迟，但对多轮对话场景的提升非常明显。
Prompt 组装是生成质量的重要一环。我的 Prompt 模板结构通常是：系统指令声明“你是知识库助手，只根据提供的文档内容回答，如果文档中没有相关信息，请明确回答不知道”；然后是检索片段区，按相关度排序列出片段，每个片段前标注文档编号和来源；最后是用户问题。提示词里要把“不编造、不推测”写明确。生成参数上，temperature 我习惯设到 0.2 以下，因为知识问答场景追求的是准确一致，而不是发散创意；max_tokens 根据答案长度预期设定，避免超时或截断。
召回数量的设定也需要解释一下。向量召回 top_k 我常设 20~30，重排序后再取 top 3~5 送给 LLM。为什么不直接把 top 5 给 LLM？因为一轮向量检索的结果噪声较多，直接送入 Prompt 不但浪费上下文窗口，还可能让模型被不相关内容干扰。重排序的价值就是先扩大召回面、再用精排模型收窄。如果延迟敏感，可以把向量召回降到 10，重排序取 top 3，效果差距通常在可接受范围内。
3.4 Rerank 和参数调优的实操要点
加 Rerank 之后会发现一个新问题：重排序分数只能用来排序，不能直接当作置信度。两个候选片段分数分别是 0.9 和 0.88，并不代表前者比后者好多少，只能说明排序里前者在前。这意味着你不能简单地设一个分数阈值“低于 0.5 就拒答”，阈值策略通常不稳定，更好的做法是结合业务规则判断——比如所有候选分数都极低，就返回“知识库中暂无相关信息”，引导用户换种问法。
调优的顺序我很坚持一条原则：先调检索，再调生成。检索都召不回正确答案时，生成阶段无论怎么写 Prompt 都没用。所以效果不好时，先查 top 5 召回结果里有没有正确答案：有，说明生成或 Prompt 有问题；没有，说明检索链路有问题。这一条简单的自查原则，帮我在项目里省了大量排查时间。
4. 评测体系与知识更新机制，上线之后更要紧的事
RAG 系统上线之后不等于一劳永逸。文档会更新，用户问法会变化，模型也会换版，每一步都可能让效果浮动。如果只靠人工抽几个问题看效果，你根本不知道哪次改动把系统改坏了。有一套可量化的评测集和流程，是这个阶段最值得投入的事。
4.1 怎么量化评估 RAG 效果
我给 RAG 系统做评测，一般分两个维度：检索质量和生成质量。
检索质量用命中率来衡量：准备一组问题，每个问题标注正确的文档片段，跑检索流程，看正确答案是否出现在召回的 top n 列表里。常用指标是 Recall@k 和 MRR。注意评测集里的问题要覆盖各种类型：单点事实查询、多步推理查询、否定问法、带错别字的问法，每种类型分开统计，才能定位问题出在哪个方向。
生成质量方面，除了人工打分，我会重点看答案能否追溯到检索片段。如果生成的答案在检索片段里找不到依据，那这个答案再顺滑也是可疑的。在工程上，我一直要求系统在返回答案时同时返回引用来源。这不仅是用户体验问题，更是可调试性的前提——用户反馈某个答案不对，你可以立刻回溯是检索错了还是生成错了。
4.2 知识库更新与增量索引
知识过时的问题是 RAG 的强项，但也需要更新机制配合。文档一变，旧索引里的内容就失效了。我常用的更新策略是：文档级 diff——当一篇文档被修改，不是简单删除整篇重建，而是对比新旧版本，只对变化的部分重新切片和写入，删除旧版本对应的旧向量。这样能避免整库重建的高成本，也避免旧内容残留在索引里持续被检索到。
更麻烦的是“逻辑删除”的问题。涉及人员调整或产品线变更时，有些内容需要立即从检索范围里消失，但又不能直接从向量库物理删除，因为要将历史问答记录留档。我的做法是：入库时在元数据里写一个“生效状态”字段，检索时增加过滤条件，只查正在生效的片段。在降级或撤销的场景上，字段过滤比物理删除更安全，反悔了还能恢复。
4.3 线上监控与告警
RAG 线上服务要盯几个指标：检索延迟、生成延迟、Query 失败率、无结果率。无结果率是特别值得关注的指标——它表示用户问题经过检索后没有拿到足够的候选片段，这往往是新用户问法模式出现变化的前兆，也可能是知识库文档缺失的信号。我会对无结果的 Query 做定期聚类分析，找出现频率高的问法，再反推是文档没覆盖还是切片没处理好。
另一个容易被忽视的点是 Embedding 模型版本升级。Embedding 模型换代后，旧向量和新向量的向量空间不一定对齐，如果只换模型不重新索引，检索效果会莫名变差。所以每次升级 Embedding 模型，都要把所有文档重新向量化，同时做一次评测集回归测试，把效果差的地方对比出来。
5. 我实际踩过的问题和排查技巧，给你一张速查表
这一节整理我在几个真实项目里遇到的高频问题，每个问题都给排查思路，尽量短平快，方便你遇到同类问题时直接照做。
5.1 检索永远召不回正确答案
优先自查三件事：文档有没有正常入库，去向量库里查一下目标内容的向量是否存在；切片是否把关键信息切碎了，用原文搜一下看内容在哪个 chunk 里；Embedding 模型的领域适配性，换一个领域相关的模型再试。
很多情况下答案不是“召不回”，而是“召回了但排太靠后”。这时先看检索结果里有没有它，如果有但 top 5 之外，是排序问题，加 Rerank 或调查询改写；如果没有，是没入库或切片问题，回到文档处理阶段排查。
5.2 答案仍然像在幻觉
最常见原因是答案根本没有参考检索片段。Prompt 约束写得不够强时，模型会直接用自己的内部知识回答。我的处理方式是加一句强约束：“如果提供的文档片段中没有相关信息，请直接说‘知识库中暂无相关内容’，不要尝试回答。”同时把检索 top_n 从 5 降到 3，减少模型被无关片段带偏的机会。还要检查是不是召回的片段内容本身就是矛盾的，比如新旧两版文档同时在线，这时要更新索引或过滤失效版本。
5.3 延迟太高，用户等得不耐烦
RAG 链路本身比单次 LLM 调用多了检索和重排序，延迟肯定更高。性能瓶颈通常在重排序和 LLM 生成两个环节。如果重排序耗时过多，先减少候选集大小，再从 top 20 减到 top 10 试试。如果 LLM 生成太慢，检查是不是 Prompt 里塞的片段太多，减少片段数或换更快的模型。
还有一个隐藏性能问题：向量库查询没有走索引。小数据量时感受不明显，数据量大了没建索引会导致检索时间直线上升。建议数据量上来之后定期检查查询计划，确认向量索引类型和数据规模匹配。
5.4 跑通基线之后，下一步该往哪个方向迭代
最优先做的是收集真实用户问题，构建自己的评测集，代替用网上公开测试集评测的做法。真实问题的分布完全不一样，直接照搬公开测试集会给你一种“效果还行”的错觉。其次建议补上查询改写和多轮对话支持，这是感知提升最明显的一环。再往后，可以尝试引入结构化知识（比如把表格和大段文本分开存）、对常见问答对做缓存、对拒不回答类问题设计更好的兜底话术。
在实际项目里，我最大的体会是：RAG 的效果不是靠某一个环节的“神来之笔”，而是所有环节都在及格线以上的综合结果。文档处理干净一点，切分策略细致一点，检索排序合理一点，生成约束严格一点，每个环节加 5%，整体差距就非常大了。很多时候系统效果不理想，不是哪个模型不够强，而是基础环节有短板。希望这篇文章能帮你把短板找出来，先把基线跑稳，再谈优化。