★ FEATURED ARTICLE 先收藏再看RAG 系统做个 Demo 不难做到能用、能上线、准确率稳得住才是真功夫。这篇聊的是我自己在知识库问答项目上反复折腾后沉淀下来的一套组合策略。标题里说的“准确率飙升 60%”不是营销话术而是我在固定评测集上跑出来的真实数字基线准确率 45.7%组合策略落地后到了 73.5%相对提升约 60.8%。如果你正在被“检索增强生成效果不佳”折磨这篇值得看完。1. RAG 效果差的根源不在模型在检索链路先说一个很多人的误区RAG 效果不好大家第一反应是“换更强的大模型”。我在早期也这么干过换来换去回答质量并没有质变。后来把问题拆开才发现80% 的失败场景发生在检索链路而不是生成环节。模型只是“拿着什么材料说什么话”材料都找不对生成端再强也救不回来。1.1 先分清是“检索不到”还是“答不对”RAG 的流程可以简单分成两段第一段是检索把用户问题映射到知识库里的候选文档第二段才是生成让大模型基于检索结果组织答案。如果答案是“模型根本没用到该用的内容”那大概率是检索端的问题——召回率低相关文档压根没进 Top K。如果答案是“模型看到了相关内容但总结错了”那才是生成端的问题。这两者必须分开诊断不然你做的所有优化都可能打到空气上。我自己的做法是先不改任何生成参数把检索回来的 Top 3 文档直接打出来人工看。文档里有答案那就是生成端要调整文档里没有就死死盯检索链路。这个动作听起来简单但很多人跳过它直接在提示词里反复折腾浪费大量时间。1.2 我见到最多的三类翻车现场多轮问答系统落地之后我总结了三个出现频率最高的失败场景现象根因修复方向用户问产品型号系统答非所问向量检索对精确词匹配不敏感混合检索关键词通道长文档中答案被切碎上下文不完整固定长度切分踩中语义边界语义切分父子文档映射检索结果看着相关但排在首位的不是真正答案双塔向量相似度排序能力弱交叉编码器重排这三个场景覆盖了我在项目里遇到的绝大多数准确率损失。它们的共同点很扎眼问题都不在大模型本身而在“文档怎么切”“怎么召回”“怎么排序”这三件事上。2. 第一刀切分与索引工程决定准确率的天花板很多人对 RAG 的第一步“切分文档”不屑一顾觉得不就是按字数截断吗。恰恰相反切分质量直接决定整个系统的准确率上限。检索再怎么优化都不可能找回本来就被切碎的答案。2.1 固定长度切分为什么会“拦腰切断”我最早的做法很粗暴按 512 个字符硬切。结果是什么呢一段产品故障说明可能在第三句话中间被切断向量化之后前半段和后半段各自变成了“语义孤儿”。用户问“故障恢复后是否需要重启”模型只检索到前半段“故障发生原因”完全答非所问。固定长度切分最大的问题是完全无视语义边界。句子被切断、段落被拆散、标题和正文分离。embedding 模型再强也只能把“残肢”编码成和完整语义相差甚远的向量。这相当于你让图书管理员只看书页碎片去检索管理员本事再大也白搭。2.2 现在我会怎么切语义边界优先兼顾块大小现在的切分策略我遵循三个原则第一尽量保证每个 chunk 内部是完整的语义单元。优先按 Markdown 标题、段落、列表项这样的结构边界切。没有明显结构时优先在句号、问号、感叹号处断开让一个 chunk 至少包含 2 到 3 个完整句子。第二控制 chunk 大小和重叠量。我实测下来中文场景下 256 到 512 token 是一个比较稳的区间。太小的 chunk 语义不完整太大则向量表征会被信息稀释检索精度下降。重叠部分我通常设为 chunk 大小的 10% 到 20%主要用来避免跨 chunk 的语义被切断。第三引入父子 chunk 映射。检索时用小 chunk 提高命中精度取到之后通过映射找到它所属的父 chunk作为大模型的输入上下文。父 chunk 可以是整个章节也可以是一段 1000 到 2000 字的完整内容。这一步对“答案需要多段内容拼合”的场景帮助极大实测能显著提升回答的完整性。2.3 索引元数据与父文档映射怎么落地具体落地的时候我会给每个 chunk 打上几类元数据文档 ID、章节路径、chunk 序号、父 chunk ID。这样在检索阶段不仅能知道“这一段文字”还能知道它属于哪一章、哪个产品线。父文档映射的实现不复杂。切分时先把文档按语义结构切成段落级别的候选块如果块太大再递归细分。每个子块记录父块 ID检索命中子块后直接取父块内容拼进上下文。这里有一个我踩过的坑父 chunk 的引入会让 LLM 输入上下文急剧膨胀。如果不做长度控制一次问答可能把上千字内容全塞进去响应速度和准确率同时下降。我的经验是父 chunk 取 1500 字以内且当多个检索结果指向同一父块时先做去重。3. 第二刀混合检索补上向量检索的天然短板切分做好之后接下来是召回通道的问题。只用向量检索是 RAG 系统当前最大的性能瓶颈之一。这跟我标题里说的“效果不佳”关系极大。3.1 向量检索擅长“语义”但丢“关键词”向量检索的本质是语义相似度匹配你问“怎么处理服务加载失败”它能把“服务启动异常排查”这篇文档捞出来哪怕里面没有一个字和查询相同。这是它的优势。但代价是它对精确词的匹配能力很弱。用户问“型号 ABC-1024 的固件版本”如果文档里明确写了“ABC-1024”向量检索却很可能因为整体语义向量与问题对不上而排在很后面。原因很简单向量空间里一个产品型号只占 1024 维向量里很小的一部分信息很容易被其他语义信息淹没。这在实际问答里非常致命因为知识库检索里有大量查询恰恰是以编号、人名、日期、产品名、错误码为核心的。它们不需要语义理解只需要精确匹配。3.2 BM25 加向量的双通道召回怎么搭建解决思路不是二选一而是双通道并行召回。一条通道是关键词检索使用 BM25 这类经典评分算法。它擅长精确词匹配对缩写、代号、错误码特别敏感。另一条通道是向量检索负责语义泛化召回。我见过不少团队觉得关键词检索太“低级”而不屑于用但事实证明在知识库场景里BM25 的价值比很多人想象的大得多。它不需要训练不需要 GPU部署成本低而且对冷门词、专有名词的命中几乎是不可替代的。实现上可以基于开源搜索引擎或 Lucene 这类底层库来搭建倒排索引也可以直接用成熟的全文检索组件。如果是从零做的项目我建议第一版就用关键词检索加向量检索各自取 Top 50别搞太复杂后面再调融合逻辑。3.3 融合排序用 RRF别用分数相加两个通道召回回来之后怎么合并排序是个关键点。最直接的思路是把两边的相似度分数归一化后相加但我实测这个方案非常不稳定。不同模型的向量分数分布差异巨大关键词检索分数又是另一套分布直接相加等于让某一方凭“分数体量”霸榜。更稳的做法是RRFReciprocal Rank Fusion倒数排名融合。它的核心思想是不比较绝对分数只看每个候选在不同通道里的排名位置。排名越靠前贡献值越大。公式很简单每个候选文档的融合得分等于它在各通道中“排名倒数”之和通常写作 1/(k rank)。def rrf_fusion(result_lists, k60): scores {} for rank_list in result_lists: for rank, doc_id in enumerate(rank_list): scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)k 是平滑常数经验上取 60 比较通用。这个公式的好处是鲁棒性强不受各通道分数分布影响实现起来也简单。我把双通道 Top 50 合并后走 RRF再取前 20 做后续重排。关于权重如果你发现场景里关键词查询特别多可以适当提升 BM25 通道的候选数量而不是直接修改融合公式。保持公式简单把复杂度放到通道参数里后面调试会轻松很多。4. 第三刀交叉编码器重排把 Top K 改造成真正的前 K双通道召回解决的是“找得到”的问题重排解决的是“排得准”的问题。这一步对 RAG 准确率提升的作用经常被低估。4.1 双塔召回为什么排序不准向量检索本质上是双塔结构query 和 document 分别过编码器产出两个向量然后用内积或余弦相似度打分。这种结构的优势是可以把文档向量预计算并建索引线上检索快。但它的劣势也很明显query 和 document 在编码过程中完全没有交互。这种“先分别理解、再算距离”的模式对排序任务来说太粗糙。两个文档可能都和 query 语义接近但其中一个才是真正回答问题的关键内容双塔模型很难区分这种细微差异。4.2 重排候选集的选取交叉编码器模型会在编码前就把 query 和 document 拼在一起让模型能够看到两者的词级交互相当于逐词比对。它不追求“语义相似”而是直接学习“这段文档是否回答了这个查询”。这正好补上双塔模型的短板。但交叉编码器有个代价它不能提前预计算文档向量每个候选对都要实时编码。这意味着不能让它对全部知识库跑一遍只能对召回阶段返回的候选集进行“精排”。候选集大小怎么定我实测的经验是召回阶段从 BM25 和向量通道各取 Top 50RRF 融合后取 Top 20 到 30 进入重排最后让大模型看到重排后的 Top 3 到 5 个结果。候选集太小重排发挥空间有限候选集太大延迟和算力成本飙升。Top 30 以内的重排在常规硬件上单次查询增加的时间在几十毫秒到一两百毫秒之间可控性很好。4.3 重排阶段的延迟与算力控制如果线上对响应时间敏感可以在重排阶段做个小优化先用 RRF 融合得分淘汰掉明显不相关的候选项只对剩余候选做交叉编码器重排。另外一个经验是重排结果的分数对 LLM 生成很有帮助。我会把重排分数做归一化后拼进上下文让模型知道哪些文档是强相关、哪些只是参考。配合提示词中的“优先依据高相关分块作答”生成内容的准确度又会高一个台阶。还有一个容易忽略的点重排模型的输入长度有限。如果父 chunk 太长需要先截断或者优先保留开头部分。不要等送到了重排模型里才发现超长被截断白白丢信息。5. 第四刀查询改写与上下文组织解决“问不对”和“答非所问”这一刀处理的是 RAG 链路里更前端的问题用户问题本身可能就不适合直接拿去检索。5.1 查询压缩多轮对话指代回填多轮对话场景中用户经常说“那它怎么配置”这里的“它”指代上一轮里提到的模块。如果直接把“那它怎么配置”拿去检索必然什么都搜不到。解决方案是加一层查询压缩用轻量级语言模型把当前问题结合对话历史改写成一个独立可检索的完整问题。比如“它怎么配置”会被改写成“XX模块的配置步骤是什么”。这一步的成本很低但对多轮场景的检索质量提升非常明显。我最初没有做这层优化多轮对话跑到第三轮就开始明显“失忆”。加上查询压缩之后效果立刻改善准确率提升甚至让我一度误以为是其他模块的作用。5.2 轻量查询改写与别名扩展除了多轮指代还有一类常见问题是用户表达习惯和知识库用词不一致。比如知识库里写的是“权重更新策略”用户问的是“参数调整方法”。对这种问题改写的同时还应该做别名扩展。可以维护一个同义词表把产品名、简称、口语叫法都映射到规范术语上。规则覆盖不了的部分再交给轻量模型改写。但这里要说一个反面教训查询改写不是越多越好。我试过把单轮查询也强制用大模型“润色”结果改写后的查询偏离了用户本意检索效果反而下降。正确做法是只对必要场景做改写多轮对话、口语化表达、缺少上下文时触发查询本身清晰时原样直接用。5.3 输入上下文的组织方式与幻觉兜底检索端优化到位后生成端的组织方式也值得打磨。我会把重排后的文档按分数从高到低排列并在每段开头标注来源编号。同时提示词里明确两点第一回答必须基于提供的文档内容禁止编造第二如果文档中没有相关信息明确回答不知道。这个兜底策略非常关键。很多 RAG 系统的“胡言乱语”不是因为大模型能力不行而是它发现自己没有答案时倾向于强行“发挥”。只要给出“不知道”的选项并明确这是允许的回答幻觉比例会显著下降。这也直接影响评测分数。6. 效果评估与落地顺序 60% 的提升怎么算出来的最后聊聊评测和落地顺序。任何没有量化评测的 RAG 优化都只是在自嗨。6.1 建一个真实评测集别问“你觉得行不行”我维护的这套知识库问答系统固定评测集是 200 条真实业务问题覆盖产品故障、配置步骤、接口参数、代码示例、概念解释等高频类型。每条问题都标注了标准答案和最少需要命中的关键知识点。评测时分三级打分完全正确算 1 分关键信息部分命中算 0.5 分完全错误或答非所问算 0 分。这个口径比简单二分类更细腻能反映优化方向是否真的补齐了信息。6.2 分阶段 AB 验证与我的真实数字强烈建议每次只改一个变量并把每一步的评测分数记录下来。我在项目里的数据是这样的阶段方案说明准确率基线固定长度切分 纯向量检索45.7%优化1语义切分 父子文档映射53.2%优化2加入 BM25 双通道 RRF61.8%优化3加入交叉编码器重排68.4%优化4查询压缩 上下文组织 兜底73.5%从 45.7% 到 73.5%相对提升约 60.8%这就是标题里 60% 的来源。每一步的增量有大有小但每一步都能归因到具体模块。这样就算后面出现回退也能快速定位是哪次变更引起的。6.3 如果只做一步先做重排还是先做切分经常有人问我优化优先级怎么排。我的建议是这样第一优先是固定长度切分改成语义切分加父子映射因为它是天花板后面所有环节都以它为基础。第二优先是加混合检索因为它是召回层最容易见效的提升。第三才是重排因为它依赖前面两步把候选集做好。查询改写什么时候加都行但它解决的是特定场景问题不是全局瓶颈。如果条件有限只能选两步我会选切分优化和混合检索。这两步做完大部分项目的准确率已经能从不忍直视的水平提升到可交付状态。最后说一个体会RAG 优化的本质不是追逐更贵的模型而是把“文档处理、检索召回、排序精排、上下文组织”这条链路里的每一环都做到不拖后腿。每一刀下去都要有评测数据支撑改一步验一步最终的效果是叠加出来的而不是靠某个单一技巧一鸣惊人。
阅读完成 · 觉得有帮助？
