1. 从大模型胡说八道说起RAG到底在解决什么问题但凡真正把大模型接入过业务系统的人大概率都经历过这样一个阶段模型在演示环境里对答如流一旦上线面对真实用户提问就开始一本正经地编造事实。问它某份内部文档里的具体条款它能给你编出一条根本不存在的规则语气还特别笃定。这个现象在业内叫幻觉它不是模型坏了而是大模型的工作机制决定的——它本质上是在做下一个词的概率预测而不是在查数据库。我最早接触RAG这个概念的时候也走过一段弯路。当时第一反应是那我直接把文档内容塞进提示词不就行了结果发现文档一长模型要么开始忽略中间部分的内容要么直接超出上下文长度限制。后来才明白RAGRetrieval-Augmented Generation检索增强生成要解决的核心矛盾就是大模型的参数化知识是静态的、模糊的、有截止日期的而真实业务需要的知识是动态的、精确的、私有的。打个比方大模型像一个博览群书但记性不太靠谱的专家你问他问题他能聊得头头是道但具体到我们公司上个月那份合同第三页写了什么他只能靠猜。RAG做的事情就是给这位专家配一个随叫随到的资料员你提问的时候资料员先去档案室把最相关的几页资料找出来递给专家专家再基于这几页真实资料来回答。这样既保留了大模型的语言组织和推理能力又把事实依据锚定在了真实文档上。这套思路的价值在于它绕开了两个成本极高的方案一是重新训练或微调模型贵、慢、每次知识更新都要重来二是把全部知识硬塞进上下文受长度限制、贵、效果随长度衰减。RAG用检索这个外挂让知识更新变成了更新文档库这么一件低成本的事。那么这套教程适合谁看我的判断是三类人第一类是想把大模型落地到具体业务、但被幻觉问题卡住的开发者第二类是手里有一堆文档资料、想让它们活起来可被问答的产品或运营同学第三类是想系统理解RAG全链路、而不是只会调一个API的进阶学习者。接下来我会按照原理—构建—检索—评估这条主线把每个环节里真正会踩的坑和背后的逻辑讲透。2. RAG的功能原理拆开看它到底由哪几块拼成2.1 检索与生成的分工为什么不能只做其中一半很多人对RAG的理解停留在先搜再答但真正决定效果的是这两步的分工边界。检索模块负责从海量文档里找出和问题最相关的片段生成模块负责把这些片段组织成通顺、准确的回答。这两件事的能力要求完全不同检索要的是召回率和排序精度生成要的是语言组织和指令遵循。如果只做检索不做生成用户拿到的是几段原文还得自己读、自己拼体验很差如果只做生成不做检索就是前面说的幻觉问题。所以RAG的本质是一个流水线任何一环掉链子最终答案都会崩。我见过不少项目检索出来的内容其实是对的但生成阶段模型没用好这些内容答案依然跑偏也见过检索阶段就找错了文档后面生成再强也救不回来。理解这个分工对后面调优特别重要。当你发现答案不对时第一件事不是去改提示词而是先确认检索出来的片段到底对不对。这个判断顺序能帮你省下大量瞎调的时间。2.2 向量化把意思变成可以计算距离的数字RAG能实现按意思搜索而不是按关键词搜索靠的是向量化Embedding。简单说就是把一段文本映射成一个高维空间里的点语义相近的文本它们的点距离就近。比如如何申请退款和退款流程是什么字面上没几个字重合但向量距离会很近。这里有个容易被忽略的细节向量化模型和生成模型是两回事。你可以用A模型做向量化用B模型做生成它们各自独立选型。向量化模型决定了检索的语义理解能力生成模型决定了回答的表达能力。很多新手会以为用了某个大模型检索也就自动变强了其实不是。向量的维度通常从几百到几千不等。维度越高能表达的语义细节越多但存储和计算成本也越高。实际选型时不是越高越好要看你的文档规模和检索精度要求。我一般建议先用主流的中等维度模型跑通再根据评估结果决定要不要换。2.3 向量数据库为什么不能用普通数据库存向量向量检索的核心操作是找和查询向量最接近的K个向量这叫近似最近邻搜索ANN。普通关系型数据库擅长的是精确匹配和范围查询做这种高维向量的相似度计算效率极低。向量数据库如Milvus、Qdrant、Chroma、FAISS等专门为这类操作做了索引优化能在海量向量里快速找到近邻。选向量数据库时我关注三个维度规模几万条还是上亿条、部署方式本地嵌入式还是独立服务、过滤能力能不能在向量检索的同时按元数据过滤。小规模场景用Chroma或FAISS这种轻量的就够了规模上来之后再考虑独立部署的方案。别一上来就上重型方案运维成本会让你怀疑人生。2.4 完整链路串讲一次问答背后发生了什么把上面几块拼起来一次完整的RAG问答大致经历这些步骤用户提出问题用向量化模型把问题转成查询向量向量数据库检索出最相关的N个文档片段把这些片段和原始问题一起组装成提示词生成模型基于提示词产出回答返回给用户。看起来简单但每一步都有大量可调参数和隐藏陷阱。比如第3步取几个片段Top-K取太多会引入噪声、稀释重点取太少可能漏掉关键信息。第4步怎么组织提示词片段之间怎么分隔要不要加如果资料里没有就说不知道这类约束这些细节直接决定最终效果。后面几章我会逐个展开。3. 构建一个能用的RAG系统从文档到可检索知识库3.1 文档加载与清洗垃圾进必然垃圾出构建RAG的第一步不是写代码而是搞清楚你手里有什么文档。PDF、Word、Markdown、网页、数据库记录格式五花八门。加载环节最常见的坑是PDF解析扫描版PDF需要OCR双栏排版的PDF解析出来顺序会乱表格会被拆得七零八落。我踩过最深的坑是一份双栏学术PDF解析出来的文本左右栏交错检索出来的片段语义完全错乱。清洗环节要做的事包括去掉页眉页脚、去掉重复的导航文字、修复断行、统一标点。这些看起来琐碎但对检索质量影响巨大。一份没清洗干净的文档向量化之后会引入大量噪声检索时这些噪声片段可能挤掉真正有用的内容。提示文档清洗没有一劳永逸的方案建议针对每一类文档源单独写清洗规则并且保留原始文档和处理后文档的对照方便排查问题。3.2 分块策略切得好不好直接决定检索准不准分块Chunking是RAG里最被低估、也最影响效果的环节。为什么要分块因为整篇文档太长向量化后会丢失细节而且检索时你希望返回的是精确的相关片段而不是一整篇文档。分块的核心矛盾是块太大语义被稀释检索不精准块太小上下文不完整生成时信息不足。常见的分块方式有几种分块方式适用场景优点缺点固定长度切分结构松散的文本实现简单容易切断语义按段落/标题切分结构化文档语义完整块大小不均递归字符切分通用场景兼顾结构与长度需要调参语义分块高精度要求语义边界准计算成本高我个人的经验是递归字符切分是性价比最高的起点先按段落切段落太长再按句子切同时设置一个最大长度上限比如500-1000字符和一个重叠区间比如50-100字符。重叠区间的存在是为了防止关键信息正好落在切分边界上被割裂。这里有个反直觉的点分块不是越细越好。我试过把块切得很小200字符结果检索出来的片段虽然精准但生成时因为上下文太少模型经常答不完整。后来把块调到500-800字符配合适度的重叠效果明显更稳。3.3 向量化与入库批量处理的工程细节分块完成后就要把每个块向量化并存入向量数据库。这一步的工程细节不少批量处理不要一条一条调向量化接口要批量提交否则速度慢且容易触发限流失败重试网络抖动、接口超时是常态要有重试机制元数据绑定每个向量块要绑定来源文档、页码、章节等元数据方便后续过滤和溯源增量更新文档更新时要能定位到对应的旧向量并替换而不是全量重建。元数据这块特别值得强调。很多新手只存向量和原文结果用户问这份资料是哪来的你答不上来。把来源信息绑上去不仅能做引用溯源还能在检索时按来源过滤比如只在某类文档里搜。3.4 提示词组装把检索结果喂给模型的正确姿势检索出片段后怎么组装提示词是最后一道关卡。一个常见的模板结构是这样的你是一个严谨的问答助手。请仅根据下面提供的资料回答问题。 如果资料中没有相关信息请明确说明资料中未提及不要编造。 资料 [片段1] [片段2] [片段3] 问题{用户问题}这个模板里有几个关键设计角色设定让模型进入状态**仅根据资料约束它不要自由发挥没有就说不知道**是防幻觉的兜底。我实测下来加上这句兜底之后模型编造答案的概率明显下降。片段之间要有清晰的分隔符并且最好标注来源这样模型在回答时能引用。另外片段的顺序也有讲究把最相关的放前面因为模型对开头内容的注意力通常更强。4. 检索环节的调优让找得准成为常态4.1 纯向量检索的局限它并不是万能的向量检索擅长语义匹配但有几个明显短板。第一对精确匹配不敏感用户问一个具体的编号、型号、人名向量检索可能找不准因为它关注的是整体语义而不是字面精确度。第二对否定和细节区分弱支持A功能和不支持A功能向量距离可能很近。第三领域术语如果向量化模型没见过你所在领域的专业术语语义理解会打折扣。认识到这些局限很重要因为它决定了你不能只靠一种检索方式。4.2 混合检索向量加关键词取长补短混合检索的思路是把向量检索和关键词检索如BM25结合起来各取所长。向量负责语义召回关键词负责精确召回最后把两路结果融合排序。融合的常见方法是倒数排名融合RRF它不依赖两路分数的绝对大小只看排名鲁棒性比较好。我实测下来混合检索在既有语义问题又有精确查询的混合场景里召回率比纯向量检索有明显提升。代价是实现复杂度上升需要维护两套索引。所以我的建议是先用纯向量跑通评估发现召回不足时再上混合检索不要一开始就过度设计。4.3 重排序在召回之后再做一次精挑细选检索流程通常是先召回一大批再精排取前几。召回阶段追求的是不漏所以Top-K会取大一些比如20-50但直接把这几十个片段全喂给生成模型噪声太多。这时候就需要重排序Rerank用一个更精细的模型对这几十个候选重新打分排序取最相关的几个比如3-5个给生成模型。重排序模型通常比向量化模型更重、更慢但精度更高。它和向量检索的关系有点像海选和决赛海选要广决赛要准。加了重排序之后我观察到生成答案的准确率有比较明显的提升尤其是当文档库里有大量相似内容时。4.4 查询改写用户问得不好你得帮他问好用户的提问往往很口语、很模糊甚至带着错别字。直接拿这种问题去检索效果自然差。查询改写就是在检索前对用户问题做一次加工常见手段包括同义扩展把口语化表达转成更规范的表述多查询生成让模型基于原问题生成几个不同角度的查询分别检索后合并结果指代消解多轮对话里它这个指代的是什么要还原清楚。多查询生成是我用得比较多的一招。比如用户问这个怎么退模型可以生成退款流程退货申请方式如何办理退款几个查询分别检索后合并召回率会好很多。代价是检索次数增加延迟上升需要权衡。5. 检索评估怎么知道你的RAG到底行不行5.1 为什么感觉还行是最危险的评估方式我见过太多项目上线前靠几个人手动问几个问题觉得答得还不错就上线了。结果真实用户一用各种奇葩问题冒出来效果一塌糊涂。手动抽查的样本量太小覆盖不了真实问题的分布而且抽查的人往往知道答案、会不自觉地往对的方向引导。科学的评估需要一套测试集一批有代表性的问题配上标准答案或标准来源。测试集要覆盖不同类型的问题——事实型、推理型、多跳型、无法回答型。特别是无法回答型问题专门用来测模型会不会硬编。5.2 检索质量的核心指标命中率与排序质量检索环节的评估核心看两个维度找没找到和排得对不对。命中率RecallK标准答案所在的片段有没有出现在前K个结果里排序质量MRR、NDCG正确片段排得越靠前越好。这两个指标要分开看。如果命中率低说明召回有问题要调分块、换向量模型、上混合检索如果命中率高但排序差说明重排序环节需要优化。把问题定位到具体环节才能对症下药。5.3 生成质量的评估忠实度比流畅度更重要生成环节的评估很多人只看答案读起来顺不顺这是本末倒置。RAG场景下**忠实度Faithfulness**才是第一位的答案里的每一句话是不是都能在检索到的资料里找到依据有没有编造评估忠实度的常见做法是逐句核对把答案拆成句子逐句判断是否有资料支撑。这个工作可以人工做也可以用模型辅助做。除了忠实度还要看答案相关性有没有答到点上和完整性该说的有没有说全。5.4 端到端评估与持续迭代评估不是一次性工作把检索和生成合起来看就是端到端评估用户拿到最终答案满不满意。这一步最好用真实用户反馈来驱动比如点赞点踩、追问率、人工标注。评估不是上线前做一次就完事而是要持续做。因为文档库在变、用户在变、模型也可能升级。我一般会维护一个回归测试集每次改动换模型、调分块、改提示词都跑一遍确保没有把之前好的case改坏。这个习惯帮我避免了好几次修了一个bug引入三个新bug的惨剧。6. 那些文档里不会写的实战经验6.1 分块大小没有标准答案只有适合你的答案网上到处是分块建议500字符重叠建议10%这类说法但这些都是经验值不是定律。真正靠谱的做法是用你的评估集去测。同一份文档切成300、500、800三种粒度分别跑评估看哪个命中率和忠实度最好。我做过这个对比实验结论是不同文档类型的最优分块差异很大——技术文档适合小一点叙述性文档适合大一点。6.2 别忽视无法回答这个场景的设计很多RAG系统最大的问题不是答错而是该说不知道的时候硬答。用户问一个文档库里根本没有的问题模型为了显得有用编一个答案出来这比直接说不知道危害大得多。所以在提示词里、在评估集里都要专门为无法回答设计。我甚至会在检索后加一道判断如果最高相似度低于某个阈值直接返回未找到相关资料不进入生成环节。6.3 向量模型换了整个库都要重建这是个容易被忽略的运维细节向量化模型一旦更换之前入库的所有向量都失效了因为不同模型生成的向量空间不兼容。所以换向量模型不是改一行配置的事而是要全量重新向量化。做技术选型时要把这个成本考虑进去别频繁换。6.4 延迟和成本是绕不开的现实约束RAG链路长每一步都有延迟向量化、检索、重排序、生成。用户等超过几秒就会不耐烦。优化延迟的手段包括缓存高频问题的结果、并行化检索和重排序、用更轻量的模型做召回。成本方面向量化调用和生成调用都是按量计费的文档库越大、查询越频繁成本越高。这些现实约束会反过来影响你的技术选型比如是否值得上重排序、Top-K取多大。6.5 从Demo到生产中间隔着的是工程化跑通一个Demo可能一个下午就够了但要让它在生产环境稳定运行需要补的东西很多错误处理、限流、监控、日志、灰度发布、A/B测试。我见过太多Demo很惊艳、上线就崩的案例。建议在Demo阶段就把日志和监控埋好记录每次检索的结果和生成的答案这样出问题时才有据可查。7. 关于RAG学习路径的一点个人体会如果让我给刚入门的人排一个学习顺序我会建议先理解检索生成这个基本框架然后动手跑通一个最小可用的Demo哪怕只有几十个文档接着重点啃分块和评估这两块——它们是最影响效果、也最容易被跳过的。向量数据库和重排序这些等基础跑通了再逐步加。RAG这个方向变化很快新工具、新方法层出不穷但底层的那套逻辑——怎么把知识准确地找出来、怎么让模型忠实地用起来——是相对稳定的。把这条主线吃透工具换了一茬你也能快速上手。我自己从最早的手搓检索到现在用各种框架最大的感受就是框架会过时但对检索质量和生成忠实度的判断力不会过时。这套判断力只能靠一次次实测和评估慢慢养出来。 
长河君 · 2026/10/26 3:49:56 · 阅读 1.2k RAG检索增强生成实战：从原理到评估，解决大模型幻觉的完整指南
1. 从大模型胡说八道说起RAG到底在解决什么问题但凡真正把大模型接入过业务系统的人大概率都经历过这样一个阶段模型在演示环境里对答如流一旦上线面对真实用户提问就开始一本正经地编造事实。问它某份内部文档里的具体条款它能给你编出一条根本不存在的规则语气还特别笃定。这个现象在业内叫幻觉它不是模型坏了而是大模型的工作机制决定的——它本质上是在做下一个词的概率预测而不是在查数据库。我最早接触RAG这个概念的时候也走过一段弯路。当时第一反应是那我直接把文档内容塞进提示词不就行了结果发现文档一长模型要么开始忽略中间部分的内容要么直接超出上下文长度限制。后来才明白RAGRetrieval-Augmented Generation检索增强生成要解决的核心矛盾就是大模型的参数化知识是静态的、模糊的、有截止日期的而真实业务需要的知识是动态的、精确的、私有的。打个比方大模型像一个博览群书但记性不太靠谱的专家你问他问题他能聊得头头是道但具体到我们公司上个月那份合同第三页写了什么他只能靠猜。RAG做的事情就是给这位专家配一个随叫随到的资料员你提问的时候资料员先去档案室把最相关的几页资料找出来递给专家专家再基于这几页真实资料来回答。这样既保留了大模型的语言组织和推理能力又把事实依据锚定在了真实文档上。这套思路的价值在于它绕开了两个成本极高的方案一是重新训练或微调模型贵、慢、每次知识更新都要重来二是把全部知识硬塞进上下文受长度限制、贵、效果随长度衰减。RAG用检索这个外挂让知识更新变成了更新文档库这么一件低成本的事。那么这套教程适合谁看我的判断是三类人第一类是想把大模型落地到具体业务、但被幻觉问题卡住的开发者第二类是手里有一堆文档资料、想让它们活起来可被问答的产品或运营同学第三类是想系统理解RAG全链路、而不是只会调一个API的进阶学习者。接下来我会按照原理—构建—检索—评估这条主线把每个环节里真正会踩的坑和背后的逻辑讲透。2. RAG的功能原理拆开看它到底由哪几块拼成2.1 检索与生成的分工为什么不能只做其中一半很多人对RAG的理解停留在先搜再答但真正决定效果的是这两步的分工边界。检索模块负责从海量文档里找出和问题最相关的片段生成模块负责把这些片段组织成通顺、准确的回答。这两件事的能力要求完全不同检索要的是召回率和排序精度生成要的是语言组织和指令遵循。如果只做检索不做生成用户拿到的是几段原文还得自己读、自己拼体验很差如果只做生成不做检索就是前面说的幻觉问题。所以RAG的本质是一个流水线任何一环掉链子最终答案都会崩。我见过不少项目检索出来的内容其实是对的但生成阶段模型没用好这些内容答案依然跑偏也见过检索阶段就找错了文档后面生成再强也救不回来。理解这个分工对后面调优特别重要。当你发现答案不对时第一件事不是去改提示词而是先确认检索出来的片段到底对不对。这个判断顺序能帮你省下大量瞎调的时间。2.2 向量化把意思变成可以计算距离的数字RAG能实现按意思搜索而不是按关键词搜索靠的是向量化Embedding。简单说就是把一段文本映射成一个高维空间里的点语义相近的文本它们的点距离就近。比如如何申请退款和退款流程是什么字面上没几个字重合但向量距离会很近。这里有个容易被忽略的细节向量化模型和生成模型是两回事。你可以用A模型做向量化用B模型做生成它们各自独立选型。向量化模型决定了检索的语义理解能力生成模型决定了回答的表达能力。很多新手会以为用了某个大模型检索也就自动变强了其实不是。向量的维度通常从几百到几千不等。维度越高能表达的语义细节越多但存储和计算成本也越高。实际选型时不是越高越好要看你的文档规模和检索精度要求。我一般建议先用主流的中等维度模型跑通再根据评估结果决定要不要换。2.3 向量数据库为什么不能用普通数据库存向量向量检索的核心操作是找和查询向量最接近的K个向量这叫近似最近邻搜索ANN。普通关系型数据库擅长的是精确匹配和范围查询做这种高维向量的相似度计算效率极低。向量数据库如Milvus、Qdrant、Chroma、FAISS等专门为这类操作做了索引优化能在海量向量里快速找到近邻。选向量数据库时我关注三个维度规模几万条还是上亿条、部署方式本地嵌入式还是独立服务、过滤能力能不能在向量检索的同时按元数据过滤。小规模场景用Chroma或FAISS这种轻量的就够了规模上来之后再考虑独立部署的方案。别一上来就上重型方案运维成本会让你怀疑人生。2.4 完整链路串讲一次问答背后发生了什么把上面几块拼起来一次完整的RAG问答大致经历这些步骤用户提出问题用向量化模型把问题转成查询向量向量数据库检索出最相关的N个文档片段把这些片段和原始问题一起组装成提示词生成模型基于提示词产出回答返回给用户。看起来简单但每一步都有大量可调参数和隐藏陷阱。比如第3步取几个片段Top-K取太多会引入噪声、稀释重点取太少可能漏掉关键信息。第4步怎么组织提示词片段之间怎么分隔要不要加如果资料里没有就说不知道这类约束这些细节直接决定最终效果。后面几章我会逐个展开。3. 构建一个能用的RAG系统从文档到可检索知识库3.1 文档加载与清洗垃圾进必然垃圾出构建RAG的第一步不是写代码而是搞清楚你手里有什么文档。PDF、Word、Markdown、网页、数据库记录格式五花八门。加载环节最常见的坑是PDF解析扫描版PDF需要OCR双栏排版的PDF解析出来顺序会乱表格会被拆得七零八落。我踩过最深的坑是一份双栏学术PDF解析出来的文本左右栏交错检索出来的片段语义完全错乱。清洗环节要做的事包括去掉页眉页脚、去掉重复的导航文字、修复断行、统一标点。这些看起来琐碎但对检索质量影响巨大。一份没清洗干净的文档向量化之后会引入大量噪声检索时这些噪声片段可能挤掉真正有用的内容。提示文档清洗没有一劳永逸的方案建议针对每一类文档源单独写清洗规则并且保留原始文档和处理后文档的对照方便排查问题。3.2 分块策略切得好不好直接决定检索准不准分块Chunking是RAG里最被低估、也最影响效果的环节。为什么要分块因为整篇文档太长向量化后会丢失细节而且检索时你希望返回的是精确的相关片段而不是一整篇文档。分块的核心矛盾是块太大语义被稀释检索不精准块太小上下文不完整生成时信息不足。常见的分块方式有几种分块方式适用场景优点缺点固定长度切分结构松散的文本实现简单容易切断语义按段落/标题切分结构化文档语义完整块大小不均递归字符切分通用场景兼顾结构与长度需要调参语义分块高精度要求语义边界准计算成本高我个人的经验是递归字符切分是性价比最高的起点先按段落切段落太长再按句子切同时设置一个最大长度上限比如500-1000字符和一个重叠区间比如50-100字符。重叠区间的存在是为了防止关键信息正好落在切分边界上被割裂。这里有个反直觉的点分块不是越细越好。我试过把块切得很小200字符结果检索出来的片段虽然精准但生成时因为上下文太少模型经常答不完整。后来把块调到500-800字符配合适度的重叠效果明显更稳。3.3 向量化与入库批量处理的工程细节分块完成后就要把每个块向量化并存入向量数据库。这一步的工程细节不少批量处理不要一条一条调向量化接口要批量提交否则速度慢且容易触发限流失败重试网络抖动、接口超时是常态要有重试机制元数据绑定每个向量块要绑定来源文档、页码、章节等元数据方便后续过滤和溯源增量更新文档更新时要能定位到对应的旧向量并替换而不是全量重建。元数据这块特别值得强调。很多新手只存向量和原文结果用户问这份资料是哪来的你答不上来。把来源信息绑上去不仅能做引用溯源还能在检索时按来源过滤比如只在某类文档里搜。3.4 提示词组装把检索结果喂给模型的正确姿势检索出片段后怎么组装提示词是最后一道关卡。一个常见的模板结构是这样的你是一个严谨的问答助手。请仅根据下面提供的资料回答问题。 如果资料中没有相关信息请明确说明资料中未提及不要编造。 资料 [片段1] [片段2] [片段3] 问题{用户问题}这个模板里有几个关键设计角色设定让模型进入状态**仅根据资料约束它不要自由发挥没有就说不知道**是防幻觉的兜底。我实测下来加上这句兜底之后模型编造答案的概率明显下降。片段之间要有清晰的分隔符并且最好标注来源这样模型在回答时能引用。另外片段的顺序也有讲究把最相关的放前面因为模型对开头内容的注意力通常更强。4. 检索环节的调优让找得准成为常态4.1 纯向量检索的局限它并不是万能的向量检索擅长语义匹配但有几个明显短板。第一对精确匹配不敏感用户问一个具体的编号、型号、人名向量检索可能找不准因为它关注的是整体语义而不是字面精确度。第二对否定和细节区分弱支持A功能和不支持A功能向量距离可能很近。第三领域术语如果向量化模型没见过你所在领域的专业术语语义理解会打折扣。认识到这些局限很重要因为它决定了你不能只靠一种检索方式。4.2 混合检索向量加关键词取长补短混合检索的思路是把向量检索和关键词检索如BM25结合起来各取所长。向量负责语义召回关键词负责精确召回最后把两路结果融合排序。融合的常见方法是倒数排名融合RRF它不依赖两路分数的绝对大小只看排名鲁棒性比较好。我实测下来混合检索在既有语义问题又有精确查询的混合场景里召回率比纯向量检索有明显提升。代价是实现复杂度上升需要维护两套索引。所以我的建议是先用纯向量跑通评估发现召回不足时再上混合检索不要一开始就过度设计。4.3 重排序在召回之后再做一次精挑细选检索流程通常是先召回一大批再精排取前几。召回阶段追求的是不漏所以Top-K会取大一些比如20-50但直接把这几十个片段全喂给生成模型噪声太多。这时候就需要重排序Rerank用一个更精细的模型对这几十个候选重新打分排序取最相关的几个比如3-5个给生成模型。重排序模型通常比向量化模型更重、更慢但精度更高。它和向量检索的关系有点像海选和决赛海选要广决赛要准。加了重排序之后我观察到生成答案的准确率有比较明显的提升尤其是当文档库里有大量相似内容时。4.4 查询改写用户问得不好你得帮他问好用户的提问往往很口语、很模糊甚至带着错别字。直接拿这种问题去检索效果自然差。查询改写就是在检索前对用户问题做一次加工常见手段包括同义扩展把口语化表达转成更规范的表述多查询生成让模型基于原问题生成几个不同角度的查询分别检索后合并结果指代消解多轮对话里它这个指代的是什么要还原清楚。多查询生成是我用得比较多的一招。比如用户问这个怎么退模型可以生成退款流程退货申请方式如何办理退款几个查询分别检索后合并召回率会好很多。代价是检索次数增加延迟上升需要权衡。5. 检索评估怎么知道你的RAG到底行不行5.1 为什么感觉还行是最危险的评估方式我见过太多项目上线前靠几个人手动问几个问题觉得答得还不错就上线了。结果真实用户一用各种奇葩问题冒出来效果一塌糊涂。手动抽查的样本量太小覆盖不了真实问题的分布而且抽查的人往往知道答案、会不自觉地往对的方向引导。科学的评估需要一套测试集一批有代表性的问题配上标准答案或标准来源。测试集要覆盖不同类型的问题——事实型、推理型、多跳型、无法回答型。特别是无法回答型问题专门用来测模型会不会硬编。5.2 检索质量的核心指标命中率与排序质量检索环节的评估核心看两个维度找没找到和排得对不对。命中率RecallK标准答案所在的片段有没有出现在前K个结果里排序质量MRR、NDCG正确片段排得越靠前越好。这两个指标要分开看。如果命中率低说明召回有问题要调分块、换向量模型、上混合检索如果命中率高但排序差说明重排序环节需要优化。把问题定位到具体环节才能对症下药。5.3 生成质量的评估忠实度比流畅度更重要生成环节的评估很多人只看答案读起来顺不顺这是本末倒置。RAG场景下**忠实度Faithfulness**才是第一位的答案里的每一句话是不是都能在检索到的资料里找到依据有没有编造评估忠实度的常见做法是逐句核对把答案拆成句子逐句判断是否有资料支撑。这个工作可以人工做也可以用模型辅助做。除了忠实度还要看答案相关性有没有答到点上和完整性该说的有没有说全。5.4 端到端评估与持续迭代评估不是一次性工作把检索和生成合起来看就是端到端评估用户拿到最终答案满不满意。这一步最好用真实用户反馈来驱动比如点赞点踩、追问率、人工标注。评估不是上线前做一次就完事而是要持续做。因为文档库在变、用户在变、模型也可能升级。我一般会维护一个回归测试集每次改动换模型、调分块、改提示词都跑一遍确保没有把之前好的case改坏。这个习惯帮我避免了好几次修了一个bug引入三个新bug的惨剧。6. 那些文档里不会写的实战经验6.1 分块大小没有标准答案只有适合你的答案网上到处是分块建议500字符重叠建议10%这类说法但这些都是经验值不是定律。真正靠谱的做法是用你的评估集去测。同一份文档切成300、500、800三种粒度分别跑评估看哪个命中率和忠实度最好。我做过这个对比实验结论是不同文档类型的最优分块差异很大——技术文档适合小一点叙述性文档适合大一点。6.2 别忽视无法回答这个场景的设计很多RAG系统最大的问题不是答错而是该说不知道的时候硬答。用户问一个文档库里根本没有的问题模型为了显得有用编一个答案出来这比直接说不知道危害大得多。所以在提示词里、在评估集里都要专门为无法回答设计。我甚至会在检索后加一道判断如果最高相似度低于某个阈值直接返回未找到相关资料不进入生成环节。6.3 向量模型换了整个库都要重建这是个容易被忽略的运维细节向量化模型一旦更换之前入库的所有向量都失效了因为不同模型生成的向量空间不兼容。所以换向量模型不是改一行配置的事而是要全量重新向量化。做技术选型时要把这个成本考虑进去别频繁换。6.4 延迟和成本是绕不开的现实约束RAG链路长每一步都有延迟向量化、检索、重排序、生成。用户等超过几秒就会不耐烦。优化延迟的手段包括缓存高频问题的结果、并行化检索和重排序、用更轻量的模型做召回。成本方面向量化调用和生成调用都是按量计费的文档库越大、查询越频繁成本越高。这些现实约束会反过来影响你的技术选型比如是否值得上重排序、Top-K取多大。6.5 从Demo到生产中间隔着的是工程化跑通一个Demo可能一个下午就够了但要让它在生产环境稳定运行需要补的东西很多错误处理、限流、监控、日志、灰度发布、A/B测试。我见过太多Demo很惊艳、上线就崩的案例。建议在Demo阶段就把日志和监控埋好记录每次检索的结果和生成的答案这样出问题时才有据可查。7. 关于RAG学习路径的一点个人体会如果让我给刚入门的人排一个学习顺序我会建议先理解检索生成这个基本框架然后动手跑通一个最小可用的Demo哪怕只有几十个文档接着重点啃分块和评估这两块——它们是最影响效果、也最容易被跳过的。向量数据库和重排序这些等基础跑通了再逐步加。RAG这个方向变化很快新工具、新方法层出不穷但底层的那套逻辑——怎么把知识准确地找出来、怎么让模型忠实地用起来——是相对稳定的。把这条主线吃透工具换了一茬你也能快速上手。我自己从最早的手搓检索到现在用各种框架最大的感受就是框架会过时但对检索质量和生成忠实度的判断力不会过时。这套判断力只能靠一次次实测和评估慢慢养出来。