★ FEATURED ARTICLE 1. 为什么“检索增强”不是可选项而是必答题大模型落地到具体业务场景时最让人头疼的往往不是模型本身不够聪明而是它“一本正经地胡说八道”。你问它某个内部产品的参数它能编出一套看似合理但完全错误的数值你让它引用最新的政策条款它给出的内容可能停留在训练数据截止的那一天。这个问题的根源在于大模型的全部知识都压缩在静态的参数里一旦训练完成参数就冻结了它既不知道昨天发生的事也无法访问你私有的文档库。RAGRetrieval-Augmented Generation检索增强生成要解决的就是这个断层。它的核心思路非常朴素在模型生成答案之前先去一个外部知识库里把相关内容找出来然后把“找到的资料”和“用户的问题”一起塞给模型让模型基于这些资料来回答。打个比方原来的大模型像一个博学但记性停留在过去的教授闭卷考试RAG 相当于给这位教授配了一个随叫随到的资料员开卷考试答案自然更靠谱。我最初接触 RAG 的时候以为它只是“搜索拼接”这么简单真正动手搭了一套之后才发现从文档切分、向量化、检索排序到最终生成每一个环节都有大量细节决定成败。检索回来的内容不相关模型再强也白搭切分粒度不对关键信息被拦腰截断检索命中率直接崩盘。这套东西看起来门槛不高但要做到生产可用需要你对每个环节的边界条件有清醒认识。这篇文章适合几类人正在考虑给自家产品加知识库能力的开发者、已经用上了大模型但被幻觉问题困扰的团队、以及想理解 RAG 内部机制而不是只会调 API 的技术爱好者。我会从整体架构讲到每个模块的实操细节把踩过的坑和验证过的方案都摊开来说尽量让你少走弯路。2. RAG 的完整链路拆解从文档到答案到底经历了什么2.1 离线索引阶段把非结构化文档变成可检索的向量RAG 的链路分成两大部分离线索引和在线检索生成。离线索引是基础做不好后面全白费。这个阶段要做的事情是把你手里的 PDF、Word、Markdown、网页、数据库记录等各种格式的文档统一转化成向量数据库里的一条条记录。第一步是文档解析。不同格式的文档解析难度差异巨大。纯文本和 Markdown 最简单直接读取就行。PDF 是重灾区尤其是扫描件和复杂排版的文件普通的文本提取库经常把表格和正文混在一起或者把多栏排版读成乱序。我的经验是如果 PDF 里表格多优先用能保留版面结构的解析工具实在不行就上 OCR 方案但 OCR 的准确率需要实际测试别假设它一定靠谱。第二步是文本切分也就是常说的 chunking。这是整个 RAG 里最容易被低估的环节。切分粒度太粗一个 chunk 里混了好几个主题检索时向量表示被稀释命中率下降切分太细一个完整的论述被拆散模型拿到的是碎片生成质量受损。常见的做法是按固定字符数切分比如 500 到 1000 个字符一块块与块之间留 10% 到 20% 的重叠防止关键句子正好卡在边界上被切断。但固定长度切分有个明显问题它不理解语义。一个段落讲到一半被切开后半段跑到下一个 chunk 里检索时可能只命中前半段信息不完整。所以更讲究的做法是递归切分优先按段落切段落太长再按句子切句子还长才按字符切。还有一种做法是按语义相似度切分计算相邻句子的向量相似度在相似度骤降的地方断开这样每个 chunk 内部主题更集中。语义切分效果通常更好但计算开销也更大需要根据文档规模和更新频率来权衡。第三步是向量化也就是用 embedding 模型把每个 chunk 转成一个高维向量。这里的选择直接决定检索质量。中文场景下我实测过几个主流方案有些模型在通用语义相似度上表现不错但到了垂直领域比如法律条文或者医疗术语区分度就明显不够。选 embedding 模型时不能只看排行榜一定要拿你自己的业务数据做小规模测试看它能不能把真正相关的 chunk 排到前面。第四步是存入向量数据库。选型时考虑几个维度数据量级、查询延迟要求、是否需要混合检索、运维成本。小规模场景用本地文件型的向量库就够了数据量上到百万级、千万级就得考虑专门的向量数据库服务。存的时候除了向量本身还要把原始文本、来源文档、章节标题等元数据一起存进去后面检索和引用都要用到。2.2 在线检索阶段怎么从海量向量里捞出真正有用的那几条用户提问之后系统要做的第一件事是把问题也转成向量然后在向量数据库里做相似度搜索找出最接近的 top-k 个 chunk。这一步听起来简单但“相似”的定义很微妙。向量相似度高不代表内容真的能回答这个问题。比如用户问“这个功能怎么开启”检索回来的可能是“这个功能怎么关闭”两者在向量空间里距离很近但语义完全相反。为了解决这个问题实践中通常会加一层重排序。先用向量检索召回一批候选比如 top-20 或 top-50然后用一个更精细的交叉编码器模型对每个候选和问题做相关性打分重新排序取前几个最相关的送给生成模型。这个两阶段的做法比单纯向量检索效果好很多代价是增加了一次模型推理延迟会上升。如果对延迟敏感可以只在候选集较大时才启用重排序或者用轻量级的重排序模型。另一个提升检索质量的手段是混合检索也就是把向量检索和关键词检索结合起来。向量检索擅长语义匹配但有时候会漏掉那些关键词完全匹配但向量距离稍远的结果。关键词检索比如 BM25能补上这个短板。把两路结果融合通常能显著提升召回率。融合策略可以用加权求和也可以用倒数排名融合后者对不同检索器的分数尺度不敏感更省心。还有一个容易被忽略的点是查询改写。用户的问题往往很短信息量不足直接拿去检索效果不好。可以在检索前用大模型把问题扩展一下补充同义词、相关概念或者把口语化的问题转成更正式的表述。甚至可以让模型生成多个不同角度的查询分别检索后合并结果。这个做法对提升召回率很有效但会增加一次模型调用需要权衡成本和收益。2.3 生成阶段把检索结果变成靠谱答案的最后一步拿到相关 chunk 之后就要把它们和用户问题一起组装成 prompt送给大模型生成答案。这一步的 prompt 设计非常关键。最基本的要求是明确告诉模型只根据提供的资料回答资料里没有的信息不要编。但光说这句还不够模型有时候会“过度发挥”把资料里的内容引申到资料没说的方向。我的做法是在 prompt 里加几条硬约束第一答案必须能在资料里找到直接依据第二如果资料不足以回答问题直接说“根据现有资料无法回答”不要尝试推测第三引用资料时标注来源编号方便用户核查。这几条约束能显著降低幻觉率但也会让模型在某些边界情况下显得“保守”需要根据业务场景调整松紧程度。另一个实操细节是资料的组织顺序。把最相关的 chunk 放在 prompt 的开头或结尾模型利用的效率通常更高中间位置的内容容易被忽略这在长上下文场景下尤其明显。如果检索回来的 chunk 比较多可以考虑先做一轮压缩把每个 chunk 里和问题无关的部分去掉只保留关键句这样既能节省 token又能减少干扰。生成阶段还有一个常见问题是多跳推理。有些问题需要综合多个 chunk 的信息才能回答比如“A 产品的定价策略和 B 产品相比有什么不同”需要分别找到两个产品的定价信息再对比。如果检索时只召回了其中一个产品的资料模型就答不全。这种情况下可以考虑让模型先判断现有资料是否足够不够的话触发第二轮检索用补充查询再捞一次。这个迭代检索的机制能处理更复杂的问题但实现复杂度也更高。3. 文档切分与向量化那些文档里不会写的实操细节3.1 切分粒度到底怎么定从业务问题反推很多教程会直接告诉你“按 500 字符切分重叠 50 字符”但这个数字不是万能药。切分粒度应该由你的业务问题类型决定。如果用户的问题通常很具体比如“某条款的生效日期是哪天”那 chunk 应该小一些精确到条款级别这样检索命中后模型能直接找到答案。如果用户的问题比较宏观比如“这个政策对行业有什么影响”那 chunk 需要大一些包含完整的论述段落否则模型拿到的信息太碎片没法形成完整判断。我一般会先收集一批真实用户问题然后人工标注每个问题需要多长的上下文才能回答。如果大部分问题只需要一两句话就能回答chunk 就设小一点如果需要一整段甚至多段内容chunk 就设大一点。这个标注过程不需要很多样本几十条就能看出规律。还有一个技巧是分层切分。把文档先按章节切成大块再在大块内部按段落切成小块检索时先定位到章节再在章节内精细检索。这样既能保证宏观定位准确又能保证微观信息完整。实现上可以给每个 chunk 打上章节标签检索时先按标签过滤再算相似度。3.2 元数据设计别等到检索出问题才后悔元数据在 RAG 里的作用经常被低估。很多人只存向量和原始文本结果检索回来一堆内容却不知道哪条来自哪个文档、哪个章节引用的时候没法标注来源排查问题时也没法追溯。我的建议是在索引阶段就把能拿到的元数据都存上文档标题、章节路径、页码、创建时间、文档类型、业务标签等等。这些元数据在检索时能发挥大作用。比如用户可以限定只在某个业务分类下检索或者只检索最近三个月更新的文档。再比如当检索结果来自多个文档时可以按文档来源做去重避免同一个文档的多个 chunk 霸占结果列表。元数据还能用于权限控制不同用户只能检索到他们有权限查看的文档这在企业场景里是刚需。存储元数据时要注意格式统一。如果文档来源多样有的有章节标题有的没有有的有页码有的没有最好在索引前做一轮规范化把缺失的字段填上默认值避免检索时因为字段缺失导致过滤逻辑出错。3.3 向量化模型选型排行榜之外的考量选 embedding 模型时大家第一反应是看 MTEB 之类的排行榜。排行榜有参考价值但不能全信。排行榜上的评测数据集和你的业务数据分布可能差异很大一个在通用问答上得分很高的模型到了你的垂直领域可能表现平平。我的做法是从业务数据里抽几百条真实的问题-文档对人工标注相关性然后拿几个候选模型分别跑一遍看哪个模型的 top-5 命中率最高。这个测试成本不高但能避免选型失误。除了效果还要考虑几个工程因素。模型的向量维度直接影响存储成本和检索速度维度越高存储越大、检索越慢但通常效果也越好需要在效果和成本之间找平衡。模型的推理速度也很关键如果文档库很大索引阶段可能要处理几十万个 chunk模型太慢会导致索引时间不可接受。另外还要看模型是否支持批量推理、是否有 GPU 加速版本这些在实际部署时都会影响体验。还有一个容易被忽略的点是模型的更新策略。embedding 模型不是一劳永逸的业务数据分布会变化模型本身也会迭代。如果换了模型之前索引的向量全部作废需要重新索引。所以选型时要考虑模型的长期维护情况尽量选有持续更新、社区活跃的方案避免用了一个停更的模型后面想换成本很高。4. 检索策略进阶从“能搜到”到“搜得准”4.1 重排序的引入时机与模型选择重排序是提升检索精度的利器但不是所有场景都需要。如果向量检索的 top-5 已经足够准加一个重排序模型只会增加延迟。判断是否需要重排序可以看两个指标一是 top-5 里有多少条是真正相关的如果经常只有一两条相关说明向量检索的精度不够需要重排序来救二是用户对答案质量的反馈如果经常出现“答非所问”也说明检索环节需要加强。重排序模型的选择上交叉编码器效果最好但速度最慢适合对延迟不敏感的场景。如果延迟要求高可以考虑用轻量级的双编码器做粗排再用交叉编码器做精排两级配合。还有一种做法是用大模型本身来做重排序把问题和候选 chunk 一起送给模型让它打分。这个做法效果不错但成本高适合候选集不大的情况。重排序的候选集大小也需要调。候选集太小重排序没有发挥空间候选集太大延迟上升明显。我的经验是如果最终要选 3 到 5 条送给生成模型候选集设在 20 到 50 之间比较合适。具体数字可以拿业务数据做实验看召回率和延迟的平衡点在哪里。4.2 混合检索的权重调优别拍脑袋定参数混合检索里向量检索和关键词检索的权重怎么定是个需要实验的问题。权重偏向向量检索语义匹配能力强但可能漏掉关键词精确匹配的结果权重偏向关键词检索精确匹配好但语义泛化能力弱。我的做法是先用一个中间值比如各占一半然后拿标注数据跑评测看召回率的变化逐步调整。倒数排名融合是个省心的选择它不需要手动调权重而是根据每个检索器返回结果中的排名来计算融合分数。排名越靠前分数越高两路结果自然融合。这个方法的缺点是它假设两个检索器的排名质量相当如果其中一个检索器明显更准它的优势在融合时会被稀释。所以如果对某个检索器特别有信心还是手动加权更可控。还有一个实操细节是关键词检索的分词。中文分词对 BM25 的效果影响很大分词太粗会漏掉细粒度的匹配分词太细会产生大量无意义的词项。可以用领域词典来辅助分词把业务专有名词加进去避免被切碎。如果业务术语很多维护一个自定义词典是值得的。4.3 查询改写的边界什么时候该改什么时候不该改查询改写能提升召回率但不是所有问题都适合改写。对于简短、模糊的问题改写能补充信息帮助检索。但对于本身就很明确的问题改写可能引入噪声把原本清晰的查询意图搞乱。我的判断标准是如果原始查询的关键词已经能准确表达意图就不改写如果查询太短或者有歧义才启用改写。改写的方式也有讲究。简单的同义词扩展可以用词典做成本低但覆盖面有限。用大模型做改写更灵活可以让它生成多个不同角度的查询但要注意控制生成数量太多查询会导致检索次数增加、延迟上升。一般生成 2 到 3 个变体就够了再多收益递减。改写之后还要做一步过滤。模型生成的查询有时候会偏离原意或者引入不相关的概念。可以在改写后计算新查询和原查询的语义相似度如果相似度太低说明改写跑偏了就丢弃这个变体。这个过滤步骤能避免改写引入的负面效果。5. 生成质量把控让模型说真话、说全话5.1 引用标注的实现方式与常见问题引用标注是 RAG 系统里提升可信度的关键功能。用户看到答案旁边标着来源编号可以点开查看原文心里就有底。实现上可以在 prompt 里给每个 chunk 编号要求模型在生成答案时标注引用了哪几条。模型输出后再用正则表达式把编号提取出来映射回原始文档。但这里有个常见问题模型标注的引用不一定准确。它可能引用了某条资料但实际答案内容来自另一条或者答案综合了多条资料但只标了一条。要解决这个问题可以在 prompt 里明确要求“每个事实性陈述都要标注来源”并且在生成后做一轮校验检查标注的 chunk 里是否真的包含答案中的关键信息。如果发现标注不匹配可以重新生成或者人工介入。另一个问题是引用粒度。如果 chunk 比较大标注到 chunk 级别用户还是不知道具体是哪句话。可以在 chunk 内部再做一层句子级定位把答案中的关键句和原文句子做匹配精确定位到具体位置。这个做法实现复杂度高一些但对用户体验提升明显。5.2 处理“资料不足”的策略拒答比胡答更重要RAG 系统最怕的不是答不出来而是答错了还理直气壮。当检索回来的资料不足以回答问题时模型应该明确说“不知道”而不是硬编一个答案。但实际测试中模型往往倾向于给出一个看起来合理的回答哪怕资料里根本没有依据。要抑制这种行为prompt 里的约束要写得非常明确。不要只说“根据资料回答”而要说“如果资料中没有直接依据必须回答‘根据现有资料无法回答’不得推测”。同时可以在 few-shot 示例里放一个拒答的例子让模型模仿。另外可以在生成后做一轮检查看答案里的关键实体和数值是否都能在资料里找到找不到的就标记为可疑触发人工审核或重新检索。拒答率太高也不行用户会觉得系统没用。所以需要在拒答和回答之间找平衡。一个做法是分级处理如果资料完全无关直接拒答如果资料部分相关但不完整可以给出部分答案并说明“根据现有资料只能确认以下信息”。这样既诚实又有用。5.3 多轮对话中的检索策略别忘了上下文单轮问答的 RAG 相对简单但真实场景里用户往往会追问。比如先问“这个产品的定价是多少”接着问“那它的竞品呢”。第二轮问题里的“它”指代的是上一轮的产品如果直接把“那它的竞品呢”拿去检索肯定搜不到东西。所以多轮对话场景下需要先把当前问题结合历史对话改写成独立完整的查询再拿去检索。改写的方式可以是用大模型把历史对话和当前问题一起输入让它输出一个不依赖上下文也能理解的查询。这个改写步骤会增加一次模型调用但能显著提升多轮场景下的检索质量。改写后的查询还可以保留一些上下文关键词帮助检索定位。另一个多轮场景的细节是资料复用。如果第二轮问题和第一轮相关第一轮检索到的资料可能还有用可以保留在上下文里避免重复检索。但要注意上下文长度限制如果历史资料太多会挤占当前问题的空间。可以在每轮结束后对历史资料做压缩只保留和当前话题相关的部分。6. 效果评估与迭代怎么知道你的 RAG 到底行不行6.1 构建评估集的实操方法没有评估集RAG 的优化就是盲人摸象。评估集不需要很大但要有代表性。我的做法是从真实用户问题里抽样覆盖不同类型事实型问题、对比型问题、多跳推理问题、资料不足需要拒答的问题。每个问题人工标注标准答案和应该检索到的文档片段。构建评估集时要注意标准答案不能只写一个因为同一个问题可能有多种正确表述。可以标注关键信息点只要答案覆盖了这些信息点就算正确。检索评估则看 top-k 里是否包含标注的相关片段计算召回率和精确率。评估集要定期更新。业务在变化用户问题也在变化旧的评估集可能不再反映当前的真实情况。我一般每季度补充一批新问题同时淘汰那些已经不再出现的问题类型。评估集的质量直接决定优化方向是否正确值得花时间维护。6.2 检索与生成的分开评估RAG 的效果问题可能出在检索环节也可能出在生成环节必须分开评估才能定位。检索评估看召回率和 MRR平均倒数排名生成评估看答案的准确性和完整性。如果检索召回率高但生成质量差说明问题在生成环节可能是 prompt 设计不好或者模型能力不够。如果检索召回率低那生成再强也没用得先优化检索。分开评估的另一个好处是能快速定位回归。每次改动之后分别跑检索和生成的评估看哪个指标下降了就能知道改动影响了哪个环节。比如调整了切分粒度检索召回率变了但生成质量没变说明切分主要影响检索。如果换了生成模型生成质量变了但检索没变说明问题在模型侧。6.3 常见失败模式与对应优化方向RAG 系统上线后常见的失败模式有几种。第一种是检索不到相关内容用户问题里的关键词和文档里的表述差异太大。这种可以靠查询改写和混合检索来缓解。第二种是检索到了但排序不对相关的内容排在后面没被选中。这种需要加重排序或者调整相似度计算方式。第三种是检索对了但生成跑偏模型没有忠实于资料。这种要优化 prompt 约束和生成后的校验。还有一种隐蔽的失败模式是资料本身有问题。文档过期了、内容有误、或者多个文档之间有矛盾这些都会导致 RAG 输出错误答案。所以 RAG 系统需要配套的文档管理机制定期检查文档的新鲜度和一致性发现问题文档及时更新或下架。我在实际项目里遇到过一个典型案例用户问某个政策的适用条件检索回来的资料是旧版政策生成模型基于旧版给出了答案但新版政策已经改了条件。这个问题不是 RAG 链路本身的 bug而是文档更新没跟上。后来我们加了一个文档时效性检查对超过一定时间未更新的文档打上标记检索时优先返回新版本同时在答案里提示用户“该信息可能已更新请核实最新版本”。这个改动之后类似的投诉明显减少。7. 工程化落地中的性能与成本权衡7.1 索引更新的增量策略文档库不是静态的新文档不断加入旧文档需要更新或删除。如果每次变动都全量重建索引成本太高尤其是文档量大的时候。增量索引是必须的。实现上可以给每个文档打上版本号或更新时间戳索引时只处理新增和变更的文档删除的文档从向量库里移除对应记录。增量索引的难点在于变更检测。如果文档来源是文件系统可以监控文件的修改时间如果是数据库可以用变更数据捕获机制如果是外部 API可能需要定期拉取全量列表做对比。不管哪种方式都要保证变更检测的可靠性避免漏掉更新导致索引和实际文档不一致。还有一个细节是 chunk 级别的更新。如果一个文档只改了一小段理想情况下只重新索引受影响的 chunk而不是整个文档。这需要记录每个 chunk 和原文位置的映射关系实现起来复杂一些但对大文档来说能节省不少计算。如果文档更新不频繁可以先用文档级增量等规模上来了再考虑 chunk 级。7.2 缓存策略哪些结果值得缓存RAG 的每次查询都涉及向量检索和模型生成延迟不低。缓存能显著提升响应速度但不是什么都能缓存。向量检索的结果可以缓存因为相同查询的检索结果在一段时间内是稳定的。生成结果也可以缓存但要注意文档更新后缓存要失效否则会返回过时答案。缓存粒度上可以按查询缓存也可以按查询用户权限缓存。如果不同用户能访问的文档范围不同缓存要区分用户组避免越权返回。缓存失效策略可以用时间驱动比如设置一个合理的过期时间也可以用事件驱动文档更新时主动清除相关缓存。还有一个进阶做法是缓存中间结果。比如查询改写的结果、重排序的分数这些在相同查询下也是稳定的缓存起来能省掉重复计算。但缓存层数越多失效逻辑越复杂需要根据实际收益来决定缓存到哪一层。7.3 成本控制token 消耗在哪里怎么省RAG 的成本主要来自两块embedding 模型的推理成本和生成模型的 token 消耗。索引阶段embedding 成本取决于文档量和模型单价这部分是一次性投入但文档更新时会重复产生。查询阶段每次检索都要把查询转成向量成本不高生成阶段要把检索结果和问题一起送给模型token 消耗和检索结果的长度直接相关。省 token 的一个直接办法是压缩检索结果。不要把整个 chunk 原封不动塞给模型而是先提取和问题最相关的句子只把这些句子送给模型。这个提取可以用规则做也可以用模型做。规则做成本低但不够灵活模型做效果好但增加一次调用。可以根据对延迟和成本的敏感度来选择。另一个省 token 的办法是控制检索结果的数量。top-k 不是越大越好k 太大不仅增加 token 消耗还可能引入噪声干扰生成。我的经验是如果重排序做得好top-3 到 top-5 通常就够了。可以拿评估集测试不同 k 值下的生成质量找到质量和成本的平衡点。还有一个容易被忽略的成本是失败重试。如果生成结果校验不通过触发重新生成token 消耗翻倍。所以要尽量在第一次生成时就提高成功率prompt 设计要清晰约束要明确减少返工。8. 我踩过的几个坑和对应的解法第一个坑是切分粒度一刀切。刚开始做的时候所有文档都按 500 字符切结果发现技术文档里代码块被切得七零八落检索回来的是半截代码模型根本没法用。后来改成按文档类型分别设置切分策略代码类文档按函数或代码块切叙述类文档按段落切效果好了很多。这件事让我意识到RAG 的每个环节都要考虑数据的特殊性不能拿一个通用配置套所有场景。第二个坑是忽略了元数据过滤。早期版本检索时不带任何过滤条件结果用户问 A 产品的问题检索回来一堆 B 产品的资料因为两个产品的描述用词很像。后来在索引时给每个 chunk 打上产品标签检索时先按标签过滤再算相似度准确率立刻上来了。元数据看起来是配角但在多品类、多版本的场景里它往往是决定检索质量的关键。第三个坑是 prompt 约束不够硬。最初写 prompt 时只说“根据资料回答”结果模型经常把资料里的内容引申到资料没说的方向产生幻觉。后来改成“每个事实性陈述必须能在资料里找到原文依据找不到就拒答”并且加了 few-shot 示例幻觉率明显下降。这件事说明对模型的约束要具体、可执行不能指望它自己理解你的意图。第四个坑是评估集太单一。一开始只用事实型问题做评估系统在这类问题上表现很好但上线后发现对比型和推理型问题答得很差。后来补充了多种类型的问题才发现检索策略在多跳场景下需要特殊处理。评估集的覆盖面决定了你能发现多少问题评估集越丰富系统上线后的惊喜越少。第五个坑是忽略了文档时效性。有一次用户反馈答案和最新政策不符排查后发现是检索到了旧版文档。后来加了文档版本管理和时效性标记检索时优先返回最新版本同时在答案里提示用户核实。RAG 系统不只是技术链路文档治理同样重要没有好的文档管理再强的检索和生成也白搭。这些坑说到底都指向一个核心RAG 不是把几个组件拼起来就完事它需要对业务数据有深入理解对每个环节的边界条件有清醒认识并且持续用真实数据做评估和迭代。工具和框架能帮你快速搭起原型但要做到生产可用功夫在细节里。
阅读完成 · 觉得有帮助？
