RAG翻车翻得多了才明白Advanced RAG不是锦上添花是保命手段。今天不聊概念直接拆一套我自己搭过、调过、上线后还在持续优化的高级RAG方案把链路里的关键节点、取舍逻辑和踩坑记录都摊开讲。1. 先搞清楚普通RAG到底死在哪里很多团队一开始都是从最朴素的RAG起步文档切块、向量化、塞进向量库用户提问后召回TopK拼成上下文喂给大模型。这种方案在演示环境跑通很容易demo一演示老板觉得“成了”。但一上真实业务各种问题就冒出来了。最典型的翻车现场有三个。第一个是召回内容不够准。用户问“今年Q3华东区的营收受哪些因素影响”你检索回来的可能是财报PDF里“营收”这个词出现频率高的段落但那些段落可能在讲历史数据、政策背景或者风险提示真正讲Q3华东区影响因素的那段反而排在第三、第四位。TopK截断之后上下文里塞的都是相关性不高的内容模型就成了巧妇难为无米之炊。第二个是上下文被无关信息污染。切块粒度不合理一块包含几个不同主题或者一块本身内容太短携带的信息量不足召回回来之后大模型既要处理有用信息又要消化干扰信息生成质量自然下降。第三个是回答深度不够。用户的问题往往不是单一知识点而是需要跨多个段落、多个文档综合推断。简单的TopK召回很难做到这一点模型拿到的上下文要么不完整要么结构混乱回答只能浮于表面。Advanced RAG要解决的其实就是这三件事让召回更准、让上下文更干净、让生成更有依据。我在实际项目中反复验证过与其在模型层死磕提示词不如先花力气把RAG链路的数据处理和召回策略做好。数据链路干净了模型的能力才能真正发挥出来。2. 链路总览我在生产环境里用的这套方案长什么样我搭建的这套Advanced RAG方案分成六个环节每个环节都可以独立替换、单独调优这也是我推荐的设计方式——不要一开始就追求某个“炫技”模块先把每个环节做到及格线以上再针对短板专项优化。六个环节分别是数据清洗与预处理把原始文档里的格式噪声、广告、页眉页脚清理掉统一文档格式。语义切块按语义边界切分文档而不是粗暴按字符数切分。切块质量和RAG效果强相关值得投入最多精力。向量化与索引构建选择合适的嵌入模型建立向量索引必要时配合BM25关键词索引走混合检索。召回与重排序第一轮召回可以牺牲一些精度换召回率召回范围适当放宽第二轮用重排序模型精排把最相关的上下文选出来。上下文管理与提示词组装控制上下文长度、去重、过滤无关片段把重排后的内容组合成结构化提示词。生成与溯源大模型基于精排后的上下文生成回答同时保留溯源信息方便后续核对和审计。这里有个容易被忽略的点链路中每个环节都可能成为瓶颈。有时候检索结果质量不好根因不在检索环节而是切块策略不对有时候生成效果差根因不在模型而是上下文组装时把关键信息截断了。所以排查问题要从整条链路的角度看不要一上来就怀疑某一个环节。对比一下普通RAG和这套方案的核心差异会更直观维度普通RAGAdvanced RAG方案切块方式固定字符数切分语义边界切分 结构化处理索引方式纯向量检索向量 BM25混合检索召回精度TopK直接返回扩大召回 重排序精排上下文管理简单拼接去重、过滤、重组、动态控制长度溯源能力无或不完整保留文档级引用信息这个表不是让大家照抄而是提供一个检查清单——你可以对照自己的链路看到底是在哪个环节做得不够。3. 切块策略影响RAG效果的第一变量切块是Advanced RAG里最容易被低估的环节。很多人把切块当作“把文档按段落拆开就行”但实际上切块策略直接决定了后续检索的上限。切块太粗块内主题混杂召回命中但信息不纯切块太细块内信息量不足召回精确但上下文不完整。3.1 固定长度切块的局限固定长度切块比如按256字符、512字符切分实现简单但缺陷非常明显。它不考虑文本语义和结构经常把完整的一句话、一个段落、一个表格从中间截断。截断后的片段在向量化时语义不完全检索时相关性评估自然不准确。举一个真实例子。某产品说明书里有一条用户操作注意事项当系统提示“密钥已过期”时请务必在成功登录后的30分钟内完成密钥更新操作否则需要联系管理员重新激活。如果按512字符切块这个段落可能和前后文粘连在一起。用户在问“密钥过期了怎么办”时召回结果可能包含这一大段的中间部分模型看到了“30分钟内完成密钥更新”但实际上缺少了“联系管理员重新激活”的完整流程。固定长度切块并不是不可用而是需要匹配具体的文档形态。如果文档是结构规整的短句、FAQ、产品短描述固定长度切块表现还可以。但只要文档包含长段落、表格、多层标题固定长度切块就会开始露馅。3.2 按语义边界切块更好的方式是按语义边界切块。语义边界检测的常见信号包括标题层级H1、H2、H3等每个三级标题下的内容通常是一个语义块。空行与段落段落的分隔往往意味着主题的切换。列表与表格独立的列表、表格应该尽量作为一个整体保留不要从中间拆开。自定义规则例如按句子边界切分、按章节编号切分“第1章”“第2章”“1.1”“1.2”。在实际操作中我通常用一个分块器先按文档结构提取标题层级然后以标题为单位做粗切分如果某个标题下内容过长再按段落、句子边界细切。这样既保留语义完整性又能控制块的大小。一个简单的伪代码思路如下def split_document(doc): # 第一步按标题层级粗切 sections split_by_heading(doc) # 第二步对过长section按语义边界细切 chunks [] for section in sections: if len(section) MAX_CHUNK_SIZE: sub_chunks split_by_paragraph_and_sentence(section) chunks.extend(sub_chunks) else: chunks.append(section) return chunks实际项目中切块器还会加一些启发式规则比如代码块单独保留、表格单独保留、引用内容单独保留等。3.3 切块参数的选取逻辑切块块大小和重叠率的选择没有绝对的“最佳参数”而是取决于文档类型和查询特征。文档类型建议块大小字符建议重叠字符新闻类短文300-50030-50技术文档/说明书600-80060-80论文/长文800-100080-100FAQ/问答对不按块切按“问题答案”整体处理0块大小的选择思路是保证每个块包含一个完成语义的最小单元。太短会让语义不完整太长又会引入噪声。重叠率的作用是缓解切块边界处的语义断裂让需要跨边界的查询有更多机会命中。还有一个隐藏的经验如果后续有重排序模块块大小可以适当调大一些。因为重排序模型比向量检索更擅长处理长文本中的相关性判断块大一点能保留更多完整上下文重排时会更有优势。反之如果没有重排序模块块大小要保守一些避免引入噪声。4. 混合检索向量检索不够必须加上BM25向量检索擅长处理语义相似但字面不匹配的情况比如用户问“如何退款”文档里写的是“退费流程”。但向量检索有一个天然弱点对专有名词、代码片段、产品型号、缩写词汇很容易翻车。举个例子用户问“ESP32-C3支持哪些通信协议”如果文档里大量出现“ESP32-C3”和“WiFi”“BLE”“Zigbee”等词汇向量检索可能因为“通信协议”这个词的语义匹配程度不够漏掉关键块。而BM25这种传统关键词匹配反而能精准命中包含“ESP32-C3”和“协议”字样的文本。混合检索的核心思路是用词法匹配和语义匹配两条腿走路召回范围更全面然后借助重排序把两条路的候选结果统一精排。4.1 混合检索的实现方式我用的实现方式比较朴素但稳定向量检索召回Top50。BM25关键词检索召回Top50。合并两个结果集按文档ID去重。送入重排序模型精排取Top5到Top10作为上下文。去重这一步极易忽视。向量检索和BM25检索结果往往有部分重叠去重后候选集大小可能只有70到80个。如果不去重就送入重排序会浪费重排序的预算还可能因重复内容干扰排序。4.2 权重怎么设计混合检索的融合方式多种多样有线性加权、有RRFReciprocal Rank Fusion倒数排名融合、有基于分数的归一化融合。我的经验是RNN-based融合方式在天真的做法里首先排除——不是说它不成熟而是复杂的融合策略在数据量不大的场景下带来的提升远不如简简单单的加权融合。实际项目里我推荐从最简配置起步最终得分 α * 归一化向量得分 β * 归一化BM25得分α和β初始都取0.5然后根据验证集调。如果业务里专有名词多、代码多适当加大β如果业务里“用大白话问专业问题”的场景居多适当加大α。RRF的另一个好处是不需要归一化把每个结果集的排序序号直接做倒数计算实现简单而且对分数分布不敏感。RRF公式是score(doc) Σ 1 / (k rank_in_list(doc))其中k是经验常数通常取60。实际效果在很多场景下不弱于加权融合而且省去了调权重的过程。要么用最简单的人工调权要么直接用RRF二者都靠谱。切忌一开始就上复杂模型融合。4.3 检索召回范围为什么要放宽普通RAG经常只召回Top5或Top3直接作为上下文。这在信息密度高、文档质量有保障的场景下还能用但一旦文档结构复杂、噪声多Top5召回很容易漏掉关键信息。Advanced RAG在候选阶段应该适当放宽召回范围比如Top30到Top50再通过重排序把真正有用的Top5到Top10选出来。这个“先宽召回、再精排”的思路是整套方案的骨架。放宽召回范围之后的“副作用”是候选集中噪声增多但这不是问题只要重排序模型够稳噪声会被压下去。重排后的结果才是最终进入大模型上下文的内容。5. 重排序为什么必须单独做这一步很多分享里把重排序当成“可选优化项”但我在实践里的感受是重排序是Advanced RAG里性价比最高的环节。甚至可以说加了重排序的RAG才谈得上Advanced。为什么向量检索不够向量检索的目标是“语义相似”不是“针对这个具体问题有多有用”。有一些候选片段它们和问题的向量相似度很高但实际信息含量不足——比如重复描述、泛泛而谈、背景介绍——这些片段在向量相似度排序里可能排得很靠前但放到答案生成里帮不上忙。重排序模型的目标是判断“这段文本对回答这个问题有多大的直接帮助”和向量检索的目标有本质区别。5.1 重排序模型的选型在中文场景下我常用的是BGE重排序模型和ColBERT架构的重排模型。以BGE重排序模型为例它的做法是直接把查询和候选文本拼接成一个长序列二分类模型输出一个相关性分数。相关代码大致长这个样子from transformers import AutoModelForSequenceClassification, AutoTokenizer tokenizer AutoTokenizer.from_pretrained(BAAI/bge-reranker-v2-m3) model AutoModelForSequenceClassification.from_pretrained(BAAI/bge-reranker-v2-m3) query ESP32-C3支持哪些通信协议 passage ESP32-C3支持WiFi、BLE 5.0以及Zigbee通信协议同时兼容Thread协议。 inputs tokenizer(query, passage, return_tensorspt, truncationTrue, max_length512) score model(**inputs).logits.item() print(score)实际使用时会对每个候选片段重复这个过程。候选集有50个就推理50次。这个开销在CPU上可能稍慢在GPU上可以接受。如果候选数量大、延迟敏感可以考虑用矩阵批处理、异步推理来优化。5.2 重排序的一个核心陷阱窗口截断重排序模型一般有输入长度限制常见的是512个token。如果候选片段太长超过限制直接截断可能导致关键信息丢失模型给出偏低的分数。我踩过这个坑某个候选片段是一段完整的操作步骤长度超过了512个token重排序模型只看到了前半部分给出较低分数结果这段本来是关键答案的内容被排到了后面。解决思路有两个控制上游切块大小切块时尽量保证块长在重排序模型窗口内。这也是前文说“有重排序模块时块可以适当调大”的原因——调大也是有限度的不能突破重排序窗口。使用滑窗二次切分对超长片段分段重排取最高分作为该片段分数。这种方法稍微复杂但能避免信息丢失。我的建议是方案一优先因为更简单、更稳定。如果实在避免不了超长文档再考虑方案二。5.3 重排序后的上下文数量怎么定重排序之后取多少个上下文进入大模型这个参数对生成质量影响也很大。上下文太少信息不足上下文太多噪声增多大模型注意力分散还可能超出上下文窗口。我的经验做法是先根据token上限反推假设上下文窗口是8192个token系统提示词占1000历史会话占2000留给检索上下文的是5192个token。如果平均每个块800个字符约等于400个token那么可以取10到12个块。然后看实际效果微调如果回答经常缺细节多放几个块如果回答“前言不搭后语”、被无关内容带偏减少块数。具体取几个不是公式能算出来的它和切块大小、文档质量、问题复杂度强相关。在实践中我通常从Top5开始测试每次2直到回答质量出现下降拐点。6. 上下文组装让大模型看得懂、用得上的关键重排之后的片段理论上都是高相关的但如果直接按顺序拼接成一大段文本扔给大模型效果往往不如预期。上下文组装的目标是在大模型有限的注意力预算里把最有用的信息放在最容易触发正确推理的位置并用清晰的结构引导模型使用。6.1 上下文去重与冗余过滤向量检索和BM25混合召回后即使做了一次文档ID去重仍然可能存在内容层面的重复。比如同一章节在不同切块里被重复切出、同一信息在不同文档里重复出现。如果不做内容级去重模型会被冗余信息干扰还可能无法判断以哪份内容为准。我在生产里处理过一种典型情况一份内部说明书有“总述”和“FAQ”两个章节同一段操作说明在“总述”里详细讲了一遍在“FAQ”里又压缩减了一版。召回时两段都命中了重排序也都给了高分。如果不做去重大模型就要同时处理两份存在出入的内容答案容易自相矛盾。轻量去重的做法是计算相邻候选块之间的文本重叠率比如用n-gram重叠重叠率超过阈值的只保留其中一个。更重的做法是引入语义向量相似度去重但计算开销更大。我建议优先用文本重叠去重阈值设在0.7左右。如果效果还不满足再考虑向量去重。6.2 赋予上下文结构而不是简单拼接简单拼接的上下文看起来是“问题 一堆文本”。大模型虽然能理解但无结构的输入会增加模型提炼信息的难度尤其是在上下文里同时存在多个潜在答案的时候。我给检索结果加结构之后效果有明显提升。这种结构化上下文的格式大概是context doc id1 source产品手册-v3.2 title密钥更新 相关段落1内容 /doc doc id2 sourceFAQ-2024版 title密钥过期处理 相关段落2内容 /doc /context模型能在上下文中快速识别“这一段来自哪里、是什么主题、内容是什么”。更重要的是当问题需要引用多个来源时结构化信息能帮模型理清信息来源。这种格式不一定要用XML标签用简单易读的Markdown格式也可以来源1产品手册-v3.2 标题密钥更新 内容... 来源2FAQ-2024版 标题密钥过期处理 内容...6.3 动态控制上下文长度上下文长度不是一成不变的。问题越具体需要的上下文越少问题越开放需要的上下文越多。我在实践里采用一个轻量的“动态长度调节策略”在进入提示词组装之前先判断问题的特征决定上下文块数。如果问题只涉及单一实体或单一术语比如“公司数据安全政策中的最小权限原则是什么”取5到7块足够。如果问题涉及多个实体和多个文档比如“对比公司数据安全政策中不同规则对权限管理的要求”取8到12块。如果问题明显是“基于长问答的开放型咨询”比如“有哪些方式可以防止不同部门的权限重叠”建议12块以上。这个策略不要做得很重简单规则判断即可。重点在于避免给模型塞过多无用信息同时保证开放问题有足够素材。7. 提示词与生成策略把上下文变成高质量回答上下文组装好之后提示词的设计决定了模型会不会正确使用这些上下文。这个环节经常被一笔带过实际上很多RAG效果不佳问题出在模型“读”了上下文但没有“用”上下文。7.1 提示词里最重要的三个指令我总结的RAG提示词核心是三个明确指令只能基于提供的上下文回答不得使用外部知识。这条指令非常关键可以有效减少模型“编”答案的概率。有些模型在遇到不熟悉的领域时会习惯性调用内部知识补全导致答案和文档内容偏离。如果上下文无法回答明确说“我不知道”。允许模型承认未知会让答案更诚实也更接近业务预期。引用来源。要求模型在回答中标注引用如“根据来源1的说明”方便人工核对。实际使用时的提示词大致是这个样子你将对用户的问题做出回答请严格遵循以下原则 1. 只基于context标签内提供的内容回答不得使用内部知识。 2. 如果context中的内容不足以回答问题请明确回复“根据现有文档无法回答”不要编造。 3. 回答时在相关语句后标注来源序号便于核对。 4. 用中文回答结构清晰优先使用分点方式。这套提示词在多个项目里是通用基础碰上特别复杂的任务再叠加额外约束。7.2 关于“自言自语”的坑CoT未必适合RAG让大模型“先思考再回答”这一招在RAG场景下要小心使用。像“请你一步一步分析并回答”这类指令在模型内部知识不相关或上下文不足时反而会促使模型用自己掌握的先验知识“脑补”出一套推理过程然后给出并未真正基于上下文的答案。我的经验是RAG生成阶段优先要求模型“直接从上下文中寻找并组织信息”而不是“从推理开始”。如果业务确实需要多步推理可以在提示词里切换为“基于上下文逐条核实再回答”。这里有个很实用的技巧给模型一个固定的“输入结构”要求它输出时先列出参考来源再给结论这样它不得不先看一眼上下文不容易凭空发挥。7.3 温度与采样参数的参考值生成阶段需要控制参数我给出一个经过调试的参考范围参数推荐值说明temperature0.1-0.3RAG场景要降低随机性偏高会让模型自由发挥top_p0.8-0.9在随机性和多样性之间折中max_tokens按需设置通常300-800控制在一次回答的长度范围内presence_penalty0避免抑制模型引用上下文中的重复信息frequency_penalty0同上RAG场景和单纯对话场景的最大不同在于模型的目标是忠实呈现上下文里的信息而不是展现自身创造力。参数设置应该向确定性倾斜。8. 评估与调优不评估根本不知道哪里出问题RAG系统上线之后最怕的不是效果差而是不知道差在哪里的效果差。所以评估体系是Advanced RAG方案里不能省的一环。8.1 评估指标怎么定我一般把评估指标分成两层检索层指标RecallK真实相关文档是否出现在了召回结果中。NDCGK相关的文档是否排在了前面。MRR首个正确答案的排名。生成层指标回答内容与上下文的一致性是否忠实于上下文。回答是否完整覆盖问题要点。回答中是否有明显的事实性错误。引用是否可信、可核对。对于检索层可以用自动化评估。准备一个“问题 - 标准答案所在文档ID”的测试集然后跑一遍检索流程算指标。对于生成层纯自动化评估难度大建议结合人工评测。8.2 构建和优化时的最小测试集我一般手工构建一个50到100条的目标查询测试集覆盖以下类型常见业务问题用户提问频率最高的问题。长尾问题提问方式不规范的问题。跨文档问题需要从多个文档中综合分析的问题。否定性问题“什么不能做”这类。“不知道”类问题文档里没有答案的问题。有了测试集之后每次改切块策略、换嵌入模型、调重排阈值都可以跑一遍回归对比用数据说话而不是靠感觉。8.3 一次真实问题的排查案例有一次在某个问答产品上模型回答质量突然下降。排查过程很有意思先看生成层回答看起来结构完整但内容出现明显失真。再看上下文上下文里确实包含了正确答案的片段但排在很后面。再往前排查发现重排序后的Top10里混入了大量语义相似但信息重复的片段真正的标准答案片段被压到第9位。根因定位切块时把长文档按固定长度切了标准答案片段和无关信息混在同一块里向量检索和重排都判断这块“不那么相关”。后来把切块改成按标题层级粗切长段落内部按语义边界细切问题才彻底解决。这个案例说明排查RAG问题时千万不要停在“上下文里面没有答案”这个结论上要一路追到切块和索引那一层。9. 向量库选型与数据索引的实践建议向量库的选型在早期容易被忽略一旦数据量上来、并发上来麻烦就不小。我现在的习惯是一开始就明确向量库需要具备的能力——快速检索、可水平扩展、支持混合检索、具备元数据过滤。别只盯着“谁的速度快”要看“我换了一版嵌入模型后重建索引的成本高不高”。在实践里如果团队已经有Elasticsearch或者OpenSearch可以优先复用它们的向量检索能力在大多数场景下够用。如果从零起步专门的向量数据库在运维上会更顺手。索引参数里有一个容易被忽视的点是HNSW的M参数和efConstruction参数。M值影响召回精度和内存开销M越大图越稠密检索精度越高但内存占用也越大。efConstruction影响索引构建期的质量太低会导致索引质量变差。我一般这样设初始值参数初始值调整方向M16数据量大且精度要求高时调到32efConstruction100构建时间长一点没关系建议不要小于100efSearch50检索时动态调高会提升精度但延迟也升嵌入模型换一次索引重建是必经之路。所以嵌入模型的选型要慎重尽量定下来再大规模建索引。10. 高级策略的扩展站在巨型项目角度再看RAG最后说几个在实际业务中经常要用到的扩展能力。10.1 查询改写与意图扩展用户提问五花八门直接拿原始问题去检索不一定效果最好。查询改写是一个高性价比的扩展点。比如用户问“怎么申请报销”可以改写为“报销申请流程”“报销条件”“报销材料”等多个检索子查询。也可以用一个轻量的LLM来实现改写但对延迟有影响。我用的策略是简单问题不改写复杂问题才触发改写。判断“复杂”的规则可以参考查询长度、是否包含多个主题词、是否有模糊语义。10.2 结构化数据与表格怎么融入RAG文档里的表格处理不好就是灾难。向量化一张完整表格模型不理解行和列的关系把表格拆成文本又丢失结构化信息。我的做法是表格先用文本形式保留行、列关系在切块阶段单独切出来并在前后各加一段“表格说明”文本说明这张表是什么、用于什么场景。这样向量检索能命中表格生成时模型也更容易理解表格的含义。10.3 多轮对话中的RAG多轮对话场景下用户的第二个问题往往依赖第一个问题的上下文。比如“密钥过期后怎么办”第一轮——“那30分钟内没更新呢”第二轮。如果直接拿第二轮的问题去检索很难命中正确文档。我的做法是把历史对话中的关键信息抽取出来合并到当前问题中再去做检索。常见策略是当前轮检索query 当前用户问题 上一轮的核心实体与结果这里的“上一轮核心实体与结果”不需要全部对话压缩只需要抽取关键词或摘要。实现不重但能明显改善多轮检索命中率。关于Advanced RAG最大的体会其实是提升一个RAG系统的质量很多时候不靠某个“大招”而是靠把每个环节都做到位并知道如何诊断链路中的短板。切块切得合理混合召回才有效果重排做得扎实上下文才会干净提示词写得到位生成质量才有下限保障。这个项目系列后面我还会继续写查询改写、评估体系、上线运维这些更细的方向把实践中验证过的方案逐个展开。
