RAG 系统拆解与模型选型:别让一个模型毁掉整条链路
检索增强生成(RAG)是当前落地最多的 AI 应用形态,从企业知识库、智能客服到内部文档助手,大量项目都采用 RAG 架构。但很多团队在实际建设中发现一个扎心的事实:不是模型不够强,而是不同模型在 RAG 链路里的表现差异,远比跑分榜单上那几分差距大得多。本文把 RAG 系统拆开,逐环节分析它的技术要点和模型选型逻辑。
一、RAG 不是"一个模型"的事,是"一串模型"的事
这是理解 RAG 的第一个关键认知:一个完整的 RAG 系统至少涉及三个模型角色,每个角色的能力要求完全不同。
查询改写模型。用户的原始提问往往口语化、指代不清,直接拿它去检索效果很差。查询改写模型的职责是把用户问题改写成适合检索的形式——提取关键词、补充上下文、拆解复合问题。它需要的是语义理解精准、指令跟随稳定,对推理能力要求不高。
向量化模型(Embedding Model)。负责把文本块和查询转换成向量,语义相似度计算的质量直接决定召回效果。它需要的是长文本压缩不丢关键信息、对领域词汇敏感。不同语种的文本、不同领域的术语,对向量模型的要求差异很大。
生成模型。这是最后组织答案的环节,才真正轮到推理能力和上下文窗口说话。它需要准确理解"问题 + 检索片段"的组合,忠实于给定材料作答,同时具备一定的归纳和组织能力。
很多团队踩的第一个坑,就是拿一个通用大模型"包打天下"——既做查询改写,又做向量化,还负责生成。通用模型在单项任务上未必输,但成本和延迟全部被拉高,而且链路耦合导致无法单独优化某一环。正确的做法是把链路拆开,每个环节单独选型:查询改写用轻量级模型控制延迟,生成环节再上高推理模型。好消息是,多数 API 网关支持统一 OpenAI 兼容接口换模型,业务侧切换时只改模型名、请求结构不动,做链路内多模型组合验证的成本很低。
二、上下文策略:不是越长越好
关于上下文窗口,行业里有一个被反复验证的经验:迷信 128K、200K 的超长上下文,结果往往适得其反。塞进去的文档越多,模型"迷失中间"越严重——注意力分散在无关内容上,关键信息反而被淹没。
真实场景里,RAG 的检索结果通常控制在 3 到 5 个片段,总共几千 token,这才是模型发挥最佳的信息区间。测试时要关注的不是"能不能塞进去",而是"塞进去之后能不能准确引用":用同一套检索结果,横向对比不同模型的答案忠实度——是否严格依据材料回答、是否编造材料里没有的内容、引用是否准确。答案忠实度是 RAG 场景下比"答题正确率"更重要的指标,因为它直接关系到企业场景里最致命的问题:幻觉。
另一个容易被忽略的维度是上下文顺序。检索片段、系统提示词、对话历史的排列顺序会影响注意力分配,相关度最高的片段应该放在离问题最近的位置。细节虽小,但对答案质量的提升往往立竿见影。
三、成本模型:输入远大于输出的特殊结构
RAG 的 token 消耗结构和普通对话完全不同:输入远大于输出。检索片段、系统提示词、对话历史都是输入 token,一次查询可能消耗几千输入 token,而输出只有几百。假设每次查询输入 3000 token、输出 300 token,单次成本看似只有几厘钱,但日均 10 万次查询就是一笔不小的开销。
成本优化的关键在于缓存命中率。RAG 的系统提示词和固定知识片段高度重复,如果网关支持前缀缓存,命中后的价格可以低一个数量级。选型时一定要把缓存命中率纳入成本模型:系统提示词固定、知识片段复用率高的 RAG 场景,缓存收益非常可观。
此外还有两个常被忽视的省钱手段:一是对检索结果做去重和截断,避免把重复内容重复计入 token;二是对高频固定问题启用"意图路由"——命中标准问答库的直接返回答案,不用每次都走完整的检索-生成链路。
四、检索质量:混合检索与重排序
检索环节是整个 RAG 系统的质量下限——检索不到,模型再强也白搭。目前公认最稳的方案是混合检索:关键词稀疏检索(BM25)负责精确匹配术语,向量稠密检索负责语义泛化,两者结果融合后交给重排序模型。
为什么需要重排序?向量检索返回的候选集通常按粗略的相似度排序,Top 结果里混着不少"语义相近但无关"的噪声。重排序模型(如 cross-encoder 结构)对"问题-文档"对做精细的相关性打分,把真正相关的片段提到前面。业界实践中,重排序通常能把答案质量提升一个明显的档次,尤其是长文档切块场景。
文档切块策略同样影响检索质量:切块太大,单个块内主题混杂,向量化后语义模糊;切块太小,上下文不完整,答案缺乏依据。经验做法是先按文档结构(标题、段落)切分,再对过长的块做二次切分,并为每个块保留文档标题和父级上下文作为补充信息。
五、幻觉治理:让模型"有据可依"
RAG 的核心价值就是约束大模型的幻觉——用自有知识库让回答更专业、更可信。但幻觉不会自动消失,需要主动治理。工程上有三层防线:
第一层,提示词约束。明确告诉模型"只依据检索材料回答,材料中没有的内容要直接说明不知道"。看似简单,却是成本最低、见效最快的一层。
第二层,引用溯源。要求模型输出时带上引用来源(文档 ID、段落位置),让每条结论都可以点击回溯到原始信息源。这既是质量保障,也是信任建设——业务方看到"每句话都有出处",才敢把 RAG 应用到关键决策场景。
第三层,自动化评估。定期用评测集检查答案与检索材料的一致性,发现"答案写了材料里没有的内容"即判定为幻觉,反馈到提示词或检索策略的优化中。这层防线把幻觉治理从"人工抽检"升级为"持续监控"。
六、检索效果评估:用指标驱动优化
检索链路调优最大的难点是"没有反馈"——你改了切块参数或换了向量模型,凭感觉很难判断是变好了还是变坏了。因此,RAG 项目从第一天起就要建立检索评估体系,用指标说话。
业界通用的检索指标有三个:Recall@K(召回率)衡量"正确答案是否出现在前 K 个结果里",MRR(平均倒数排名)衡量"第一个正确答案排得有多靠前",NDCG(归一化折损累积增益)衡量"整体排序质量"。对 RAG 场景,还有两个专属指标更贴近业务:答案忠实度,即生成答案的内容有多少能在检索材料中找到依据;以及引用准确率,即模型标注的引用是否真的支撑了对应结论。
建立评估集的步骤是:从真实用户问题中抽样(覆盖高频问题、疑难问题、边界情况),为每个问题标注"理想检索结果集合"和"标准答案",形成评测基准;每次调整切块参数、更换向量模型、修改重排序策略后,全量跑一遍基准集,对比指标变化。这项工作初看耗时,但它能系统性地回答三个关键问题:这次的改动是优化还是回退?瓶颈在检索还是生成?该把精力投到哪个环节?
实践中的一个常见误区是只看"最终答案好不好"。答案好可能是生成模型能力强,掩盖了检索的不足;答案差也可能是生成环节的问题,检索其实已经命中了。把检索指标和生成指标分开统计,才能准确定位瓶颈,避免头痛医脚。另一个误区是评测集一次建完就再也不更新——随着业务发展和用户问题演化,评测集必须持续扩充,否则系统会悄悄退步而不自知。
七、模型选型决策清单
最后给出一份可直接使用的选型决策清单:
- 查询改写:优先轻量模型,重点看指令跟随稳定性,延迟控制在百毫秒级;
- 向量化:按语种和领域实测召回率,用领域内的查询-文档对做评测,不要只看公开榜单;
- 重排序:对比有无重排序的答案质量提升,提升明显则必选;
- 生成:优先看答案忠实度和小窗口内的信息提取精度,而不是长上下文能力;
- 成本:把缓存命中率、输入输出比例计入总成本,按日均查询量估算月费用。
RAG 的技术栈这几年演进很快,但底层逻辑始终没变:让模型在"小窗口、高质量材料"上做精确推理。把这条链路拆清楚、每个环节选对模型、用评估闭环持续优化,你就不会被任何单个模型的更新绑架,也能让 RAG 真正成为企业里可信赖的知识基础设施。
- 成本:把缓存命中率、输入输出比例计入总成本,按日均查询量估算月费用。
