1. RAG系统到底在解决什么问题第一次接触RAG这个概念是在一个内部知识库项目里。当时团队想把一堆产品文档、会议纪要、客服记录做成一个能问答的系统第一反应是直接丢给大模型。结果很快就撞墙了模型对内部信息一无所知问它某个产品的具体参数它要么编一个看起来很像但完全错误的答案要么干脆说“我不知道”。更麻烦的是即使模型在训练时见过类似知识也没法保证它用的是最新版本的内容。这就是RAG要解决的核心矛盾大模型的参数化知识是静态的、封闭的、有截止日期的而真实业务里的知识是动态的、私有的、持续更新的。RAG的全称是Retrieval-Augmented Generation检索增强生成。拆开看就是三个动作先检索、再增强、后生成。检索是从外部知识库里找到和问题相关的内容片段增强是把这些片段作为上下文塞进提示词里生成是让模型基于这些上下文来回答。很多人会把RAG和微调混为一谈觉得要让模型懂私有知识就得去训练。实际上这两条路解决的问题不一样。微调改变的是模型的“行为方式”比如让它学会某种输出格式、某种语气风格RAG改变的是模型的“信息来源”让它能引用外部事实。打个比方微调像是送一个人去进修改变他的思维方式RAG像是给他配了一个随时能查的图书馆改变他能接触到的资料。对于知识频繁更新的场景RAG的性价比远高于反复微调。这套系统适合谁来参考如果你手头有一批结构或半结构化的文档想让它们变得可问答如果你已经在用大模型但被幻觉问题困扰如果你想做一个客服助手、内部知识助手、文档分析工具RAG都是当前最务实的起点。它不需要你从头训练模型也不需要标注大量数据核心工作量集中在知识库构建和检索质量调优上。2. 整体架构设计与核心模块拆解2.1 为什么选择“检索生成”而不是纯生成纯生成方案的问题在于不可控。模型的知识来自训练语料你没法知道它到底记住了什么、记错了什么。在需要准确性的场景里这种不可控是致命的。RAG的思路是把“知道什么”和“怎么表达”分开知识库负责“知道什么”模型负责“怎么表达”。这样一来更新知识只需要更新知识库不用动模型。另一个考虑是成本。微调一个大模型需要GPU资源、训练时间、调参经验而且每次知识更新都要重新训练。RAG的知识更新就是往向量库里加几条记录几分钟就能完成。对于中小团队来说这个差距是决定性的。还有一个容易被忽略的点可追溯性。RAG系统在回答时可以附带引用来源用户能看到答案是从哪段文档里来的。这在企业场景里非常重要因为没人会完全信任一个说不出依据的答案。2.2 核心模块的职责划分一个完整的RAG系统通常包含四个核心模块文档处理模块负责把各种格式的原始文档PDF、Word、Markdown、HTML解析成纯文本然后按照一定策略切分成片段。这个模块的质量直接决定了后续检索的上限因为如果切分把一段完整的意思切断了检索出来的片段就是残缺的。向量化模块负责把文本片段转换成向量表示。这里用的是嵌入模型它把一段文字映射到一个高维空间里的点语义相近的文字在空间里的距离也相近。嵌入模型的选择很关键不同模型对中文、英文、代码的语义捕捉能力差异很大。检索模块负责接收用户问题把问题也向量化然后在向量库里找最相近的片段。这里涉及相似度度量方式的选择、检索数量的设定、是否加关键词检索做混合召回等问题。生成模块负责把检索到的片段和用户问题组装成提示词调用大模型生成最终回答。提示词的设计直接影响回答质量包括怎么组织上下文、怎么约束模型不要编造、怎么处理检索结果为空的情况。2.3 数据流转的全链路从用户输入一个问题到拿到回答数据经历的路径大致是这样的问题先被嵌入模型转成向量然后在向量数据库里做相似度搜索返回Top-K个最相似的片段。这些片段连同原始问题一起被填入提示词模板发送给大模型。大模型生成回答后返回给用户。如果开启了引用功能还需要把片段对应的原文位置信息一并返回。这条链路里每个环节都有优化空间。嵌入模型可以换、切分策略可以调、检索数量可以改、提示词可以迭代。实际项目中大部分调优工作都花在切分策略和检索质量上因为这两块对最终效果的影响最大。3. 知识库构建的关键细节3.1 文档切分策略的取舍切分是RAG系统里最容易被低估的环节。很多人直接按固定字数切比如每500字一段结果就是经常把一句话切成两半或者把紧密相关的两段内容分到不同片段里。检索的时候用户问一个问题命中的片段可能只有半句话模型拿到这种残缺上下文回答质量自然好不了。我试过几种切分策略各有适用场景。固定长度切分最简单实现成本最低适合格式统一的文档比如日志、结构化报告。按段落切分尊重文档的自然结构适合文章、说明文档这类有明确段落的材料。按语义切分用嵌入模型判断相邻句子的语义相似度在语义断层处切分效果最好但计算成本最高。递归切分是折中方案先按大分隔符切如果某段还是太长再按小分隔符切依次递归。实际项目里我通常用递归切分加一个重叠窗口。重叠窗口的意思是相邻片段之间保留一部分重叠内容比如每个片段500字相邻片段重叠100字。这样做的好处是即使切分点落在关键信息中间重叠部分也能保证信息不丢失。代价是存储和检索时会有些冗余但相比信息丢失的代价这点冗余完全可以接受。切分长度没有万能值。中文场景下300到800字是比较常见的范围。太短了语义不完整太长了检索精度下降。建议先用300字试根据实际问答效果再调整。3.2 嵌入模型的选择考量嵌入模型决定了文本被映射到向量空间后的语义表达能力。选模型时我主要看几个维度语言支持、维度大小、推理速度、是否支持长文本。中文场景下有些模型对中文语义的捕捉明显好于其他模型。如果知识库里中英文混杂就要选多语言能力均衡的。维度方面常见的有384维、768维、1024维、1536维。维度越高表达能力越强但存储和计算成本也越高。对于几万条片段的知识库768维通常够用如果知识库很大或者语义区分度要求高可以考虑1024维以上。推理速度经常被忽略。如果知识库有几十万条片段每次新增文档都要重新嵌入模型太慢会严重影响迭代效率。我一般会先用小模型快速验证流程确认没问题后再换大模型做最终效果。还有一个实际问题是嵌入模型和生成模型最好来自同一体系或者经过兼容性验证。有些嵌入模型产出的向量和某些生成模型的语义空间不匹配会导致检索出来的片段虽然向量距离近但实际语义相关性差。3.3 向量数据库的选型对比向量数据库的选择取决于数据规模、查询频率、部署方式和预算。我整理了一个对比表覆盖几种常见方案方案适用规模部署方式优势局限内存向量库万级以下本地零依赖启动快重启丢数据不适合生产轻量嵌入式库十万级本地文件无需独立服务够用并发能力有限专用向量数据库百万级以上独立服务性能强功能全运维成本高关系库扩展十万级复用现有库不引入新组件向量功能较弱小规模验证阶段我通常用内存向量库快速跑通流程。到了生产环境如果数据量在十万级以内轻量嵌入式库基本够用。超过百万级或者有高并发需求才需要考虑专用向量数据库。选型时不要一上来就追求最重的方案很多项目根本到不了需要专用数据库的规模。3.4 元数据设计的重要性很多人只存文本和向量忽略了元数据。元数据是附加在每条片段上的结构化信息比如来源文档名、章节标题、创建时间、文档类型、权限标签等。这些信息在检索时可以用于过滤在展示时可以用于引用。举个例子如果知识库里有多个产品线的文档用户问的是A产品的问题检索时就可以用元数据过滤掉B产品的片段避免干扰。再比如如果文档有版本区分可以用时间元数据只检索最新版本。没有元数据的话这些过滤都做不了检索结果里会混入大量无关内容。元数据设计的原则是凡是可能用于过滤或展示的字段都提前存进去。存储成本很低但后期想补就很麻烦因为要重新处理所有文档。4. 检索与生成环节的实操要点4.1 相似度检索的参数调优检索环节最核心的参数是Top-K也就是返回多少个最相似的片段。K太小可能漏掉关键信息K太大会引入无关内容干扰模型还会增加提示词长度和生成成本。我的经验是先从K5开始试。如果发现回答经常缺少某些信息说明K太小逐步加到8或10。如果发现回答里混入了不相关的内容说明K太大减到3或4。这个值没有标准答案取决于知识库的密度和问题的复杂度。相似度度量方式也有讲究。余弦相似度是最常用的它只看向量方向不看长度适合大多数文本场景。欧氏距离看的是绝对距离对向量长度敏感。内积计算最快但要求向量归一化。实际用哪种取决于向量库的支持和嵌入模型的训练方式。大多数情况下余弦相似度是安全选择。还有一个技巧是设置相似度阈值。如果所有返回片段的相似度都低于某个值说明知识库里可能没有相关内容这时候应该让模型回答“没有找到相关信息”而不是硬编一个答案。阈值设多少需要根据实际数据分布来定可以先观察一批问题的相似度分布找一个明显的分界点。4.2 混合检索的实践纯向量检索有个短板对精确匹配不敏感。比如用户问一个特定的错误码“ERR-4032”向量检索可能返回一堆语义相近但错误码不同的片段。这时候关键词检索BM25就能派上用场它对精确词项匹配很敏感。混合检索的思路是同时跑向量检索和关键词检索然后把两路结果融合。融合方式有几种加权求和是最简单的给两路结果各一个权重按加权分数排序倒数排名融合不看具体分数只看排名把两路结果的排名做加权对分数尺度不一致的情况更鲁棒先过滤再向量检索是用关键词检索做粗筛再在粗筛结果里做向量精排。我在实际项目里用得最多的是倒数排名融合因为它不需要调分数权重对两路检索器的分数差异不敏感。实现上也不复杂就是把两路结果的排名取倒数后加权相加再重新排序。4.3 提示词模板的设计提示词是RAG系统里唯一直接约束模型行为的环节。设计得不好模型可能忽略检索内容自己编或者把检索内容原封不动抄一遍。我常用的提示词结构是这样的先给模型一个角色设定比如“你是一个基于给定资料回答问题的助手”然后明确约束“只使用提供的资料回答资料中没有的信息不要编造”接着是检索到的上下文片段每个片段标注来源最后是用户问题。关键约束有几条。必须明确说“只使用提供的资料”否则模型会混入自己的训练知识。必须说“资料中没有就说不知道”否则模型会硬编。上下文片段要有清晰的分隔和编号方便模型引用也方便排查问题。问题放在最后因为模型对末尾内容的注意力通常更强。还有一个细节是上下文长度控制。如果检索回来的片段总长度超过了模型的上下文窗口就要截断。截断策略可以是按相似度排序后取前几个也可以是对每个片段做摘要。我一般优先保证片段数量因为多个片段比单个长片段更能覆盖不同角度的信息。4.4 生成参数的影响调用大模型时的几个参数也会影响RAG效果。**温度temperature**控制输出的随机性RAG场景通常设低一些0.1到0.3之间因为需要的是准确引用而不是创意发挥。最大输出长度要设够避免回答被截断但也不要太大以免浪费。重复惩罚可以防止模型反复说同一句话。有些模型支持引用返回功能可以让模型在回答里标注哪句话来自哪个片段。这个功能对可追溯性很有帮助但需要模型支持而且会增加输出长度。如果模型不支持也可以在提示词里要求模型用方括号标注来源编号。5. 常见问题与排查技巧实录5.1 检索不准的排查思路检索不准是最常见的问题表现是回答里缺少关键信息或者引用了不相关的片段。排查时我按这个顺序走先看切分。把检索到的片段原文打印出来看它是不是完整的语义单元。如果片段被切断了说明切分策略有问题调整切分长度或重叠窗口。再看嵌入模型。拿几个典型问题手动算一下问题和正确片段的相似度看是不是真的低。如果低可能是嵌入模型不适合这个领域考虑换模型或者对领域数据做微调。然后看检索参数。K值是不是太小相似度阈值是不是设得太高有没有加元数据过滤把正确片段滤掉了。最后看知识库覆盖。有些问题知识库里根本没有对应内容检索自然找不到。这时候要补充文档而不是调检索参数。5.2 模型不按资料回答的处理模型不按资料回答有两种表现一种是忽略资料自己编另一种是过度依赖资料把无关内容也抄进去。忽略资料的情况通常是提示词约束不够强。可以加强约束语句比如把“只使用提供的资料”改成“必须且只能使用提供的资料任何资料之外的信息都是不允许的”。也可以在资料前后加分隔标记让模型更清楚哪部分是资料。过度依赖资料的情况通常是检索回来的片段里有噪音。解决方法是提高检索精度比如加相似度阈值、减少K值、加元数据过滤。也可以在提示词里加一句“如果资料与问题无关忽略该资料”。5.3 性能瓶颈的定位RAG系统的延迟主要来自三个环节嵌入、检索、生成。嵌入和检索通常很快几十到几百毫秒生成是大头取决于模型大小和输出长度可能几秒到十几秒。如果整体延迟高先分别测三个环节的耗时。嵌入慢就换小模型或做批量处理检索慢就加索引或减少数据量生成慢就换小模型或限制输出长度。还有一个容易被忽略的点是首次加载。嵌入模型和向量库首次加载可能很慢如果服务是冷启动的第一个请求会特别慢。解决办法是服务启动时预热或者保持常驻进程。5.4 常见问题速查表问题现象可能原因排查方向回答缺少关键信息切分不当、K值太小、相似度阈值太高检查片段完整性调大K值降低阈值回答引用无关内容K值太大、无元数据过滤、嵌入模型不匹配减小K值加过滤条件换嵌入模型模型编造答案提示词约束不足、检索结果为空加强提示词约束处理空检索情况回答重复啰嗦温度太高、重复惩罚不够降低温度增加重复惩罚响应时间过长生成模型太大、输出太长、无缓存换小模型限制输出加缓存新增文档后效果下降新旧文档冲突、元数据不一致检查文档版本统一元数据格式5.5 几个踩过的坑第一个坑是忽略文档预处理。PDF里的表格、图片、页眉页脚如果不清掉会变成噪音进入知识库。我现在的做法是解析后先做一轮清洗去掉短于一定长度的行、去掉纯符号行、合并被换行打断的句子。第二个坑是嵌入模型和生成模型不匹配。有一次换了嵌入模型但没换生成模型结果检索出来的片段语义相关性明显下降。后来发现两个模型的语义空间不一致检索器认为相关的片段生成器觉得不相关。换回配套模型后问题消失。第三个坑是没有处理空检索。用户问了一个知识库里完全没有的问题检索返回的片段相似度都很低但系统还是把它们塞给模型模型就硬编了一个答案。后来加了相似度阈值判断低于阈值就直接返回“没有找到相关信息”幻觉率大幅下降。第四个坑是元数据格式不统一。不同来源的文档用了不同的字段名有的叫“source”有的叫“来源”导致过滤时匹配不上。后来定了一套统一的元数据规范所有文档入库前都按规范转换。6. 效果评估与持续迭代6.1 怎么判断RAG系统好不好评估RAG系统不能只看“回答看起来对不对”要有可量化的指标。我通常从两个层面评估检索层面和生成层面。检索层面看召回率和精确率。召回率是正确片段被检索到的比例精确率是检索到的片段中正确的比例。这两个指标需要人工标注一批问题和对应的正确片段然后跑检索看结果。召回率低说明检索不到精确率低说明检索回来太多噪音。生成层面看忠实度和相关性。忠实度是回答是否完全基于检索内容没有编造相关性是回答是否切题。这两个指标可以用人工评分也可以用另一个模型来打分。人工评分更准但成本高模型打分快但需要校准。6.2 迭代优化的优先级拿到评估结果后优化要有优先级。我的经验是先修检索再修生成。因为检索是生成的上游检索不准生成再优化也没用。检索优化的顺序是切分策略 嵌入模型 检索参数 混合检索。切分是基础切分不对后面都白搭。嵌入模型是核心模型不行检索质量上不去。检索参数调优成本最低可以先试。混合检索是锦上添花前面都做好了再考虑。生成优化的顺序是提示词 模型选择 生成参数。提示词调整成本最低效果也最直接。模型选择取决于预算和延迟要求。生成参数微调空间有限通常放在最后。6.3 持续维护的要点RAG系统上线不是终点知识库需要持续维护。我一般会做几件事定期检查检索日志看哪些问题检索效果差针对性补充文档或调整策略。监控相似度分布如果整体相似度下降说明知识库和用户问题的匹配度在降低可能需要更新文档。收集用户反馈用户标记的错误回答是最直接的优化线索。定期重新嵌入如果换了嵌入模型所有文档都要重新处理。还有一个实际问题是文档版本管理。同一份文档可能有多个版本旧版本如果不清理会和新版本一起被检索到造成冲突。我的做法是给每个文档加版本号和生效时间检索时只取最新版本。7. 一些个人体会RAG系统看起来架构简单但真正做好需要关注的细节非常多。我最大的体会是检索质量决定上限生成质量决定下限。检索做得好即使生成模型一般回答也能用检索做得差生成模型再强也救不回来。另一个体会是不要追求一步到位。先用最简单的方案跑通全流程哪怕切分是固定长度、嵌入是小模型、检索是纯向量只要能跑起来就能看到问题在哪。然后针对最痛的点逐个优化比一开始就设计复杂架构要高效得多。最后说一个容易被忽略的点RAG不是万能的。有些问题适合RAG比如事实查询、文档问答有些问题不适合比如需要推理、计算、多步规划的任务。判断一个需求适不适合RAG就看它是不是“查资料能解决”。如果是RAG大概率有效如果不是可能需要其他方案配合。