RAG检索增强生成几乎是「把大模型接进自己业务」的第一站。但很多团队上线后才发现效果不行往往不是检索差而是模型选型和链路工程设计出了问题。本文梳理 RAG 工程化的关键决策尤其是「为什么 RAG 链路里通常需要不止一个模型」。一、RAG 链路里到底有几个模型一个完整的 RAG 系统至少有三类模型角色它们对能力的要求完全不同角色干什么关键诉求嵌入模型Embedding把文档和 query 转成向量召回准、长文本支持好重排模型Reranker对召回结果精排相关性强、跨语言生成模型LLM基于检索内容作答指令遵循、引用准确、长上下文很多团队一开始用「一个模型包打天下」结果要么召回差嵌入不行要么回答飘生成不行。分角色选型是 RAG 工程化的第一步。二、嵌入与重排决定召回上限RAG 的「天花板」在检索。一个常见误区是用了向量库就万事大吉。实际上嵌入模型选错语义召回直接崩只靠向量相似度容易漏掉关键词强匹配不加重排Top-K 里混着不相关文档LLM 会被带偏。工程上推荐「向量召回 关键词召回BM25 重排」的混合链路# rag/retrieve.py def hybrid_retrieve(query: str, top_k: int 8): vec_hits vector_search(query, top_k20) # 向量召回 bm25_hits bm25_search(query, top_k20) # 关键词召回 merged dedupe(vec_hits bm25_hits) reranked rerank(query, merged, modelbge-reranker-v2) # 重排精筛 return reranked[:top_k]重排模型通常小而专单独部署成本很低但收益极高。三、生成模型按场景分流生成阶段同样不必死磕一个模型。举例开放问答 / 复杂推理用旗舰模型如gpt-5、claude-4-sonnet保证质量短答案抽取 / 摘要用轻量模型如gpt-5-mini、gemini-3-flash控成本中文长文档deepseek-v4这类在中文与性价比上表现突出。RAG 的调用量通常很大每次问答一次生成高并发下 QPS 可观生成侧的成本敏感度比 chat 场景更高所以分流意识要更强。四、统一接入让多模型切换变简单RAG 一旦分角色、分流式调用多个模型工程上立刻面临老问题每个供应商一套 SDK、一套密钥、一套限流。这会迅速拖垮代码可维护性。常见做法是引入一层统一接入 / 聚合网关把不同供应商收敛成同一套调用协议# rag/llm.py # 同一套接口按角色切模型具体供应商和密钥在接入层配置 # 例如用一个聚合接入层支持自定义模型服务地址切换模型只改字符串 def embed(texts): return gateway_embed(texts, modelbge-m3) def rerank(q, docs): return gateway_rerank(q, docs, modelbge-reranker-v2) def generate(prompt): return gateway_chat(prompt, modelgpt-5) def summarize(t): return gateway_chat(t, modeldeepseek-v4)这样业务代码只关心「角色 → 模型名」供应商切换、配额、故障转移全在接入层处理。市面上这类聚合接入方案不少选型时可以横向看看OpenRouter聚合多家模型按量计费协议兼容 OpenAI硅基流动SiliconFlow国内聚合服务覆盖开源与主流模型魔芋 AI聚合多家大模型支持自定义模型服务地址统一密钥与配额管理适合想一套代码接多模型的团队注册魔芋AI大模型网关I全球大模型一站式调用及服务平台 自建轻量代理用 LiteLLM 等开源项目自己收敛协议可控但需运维。选型原则先看你要哪些模型、是否支持自定义端点、计费是否透明、是否有统一配额再决定托管还是自建。本文仅做架构对比不构成对任一方案的推荐。五、六个工程陷阱Chunk 切太大/太小建议 512~1024 token按语义边界切别按固定字数硬切。不加元数据过滤时间、部门、权限等过滤条件应在检索阶段就下推别全靠 LLM 自己判断。检索结果不带来源生成时必须要求模型引用文档片段否则无法审计、无法纠错。不做空召回兜底库里没相关内容时要明确回答「知识库未覆盖」而不是让模型瞎编。忽略上下文压缩长文档塞进 prompt 容易超窗口先摘要再喂。不做效果评测上线前用一套带标准答案的 query 集跑评测如 RAGAS否则「效果变好变坏」全凭体感。六、小结RAG 不是「接个 API 就完事」。真正拉开效果差距的是分角色选型嵌入 / 重排 / 生成各用最合适的模型混合检索 重排的召回链路统一接入层让多模型切换与成本控制变简单工程化的兜底、过滤与评测。把这些补齐RAG 才从「能跑」变成「能用」。本文为技术实践分享所涉接入方案仅作架构对比不构成对任何特定服务的推荐。模型名称以各厂商官方发布为准。
RAG检索增强生成几乎是「把大模型接进自己业务」的第一站。但很多团队上线后才发现效果不行往往不是检索差而是模型选型和链路工程设计出了问题。本文梳理 RAG 工程化的关键决策尤其是「为什么 RAG 链路里通常需要不止一个模型」。一、RAG 链路里到底有几个模型一个完整的 RAG 系统至少有三类模型角色它们对能力的要求完全不同角色干什么关键诉求嵌入模型Embedding把文档和 query 转成向量召回准、长文本支持好重排模型Reranker对召回结果精排相关性强、跨语言生成模型LLM基于检索内容作答指令遵循、引用准确、长上下文很多团队一开始用「一个模型包打天下」结果要么召回差嵌入不行要么回答飘生成不行。分角色选型是 RAG 工程化的第一步。二、嵌入与重排决定召回上限RAG 的「天花板」在检索。一个常见误区是用了向量库就万事大吉。实际上嵌入模型选错语义召回直接崩只靠向量相似度容易漏掉关键词强匹配不加重排Top-K 里混着不相关文档LLM 会被带偏。工程上推荐「向量召回 关键词召回BM25 重排」的混合链路# rag/retrieve.py def hybrid_retrieve(query: str, top_k: int 8): vec_hits vector_search(query, top_k20) # 向量召回 bm25_hits bm25_search(query, top_k20) # 关键词召回 merged dedupe(vec_hits bm25_hits) reranked rerank(query, merged, modelbge-reranker-v2) # 重排精筛 return reranked[:top_k]重排模型通常小而专单独部署成本很低但收益极高。三、生成模型按场景分流生成阶段同样不必死磕一个模型。举例开放问答 / 复杂推理用旗舰模型如gpt-5、claude-4-sonnet保证质量短答案抽取 / 摘要用轻量模型如gpt-5-mini、gemini-3-flash控成本中文长文档deepseek-v4这类在中文与性价比上表现突出。RAG 的调用量通常很大每次问答一次生成高并发下 QPS 可观生成侧的成本敏感度比 chat 场景更高所以分流意识要更强。四、统一接入让多模型切换变简单RAG 一旦分角色、分流式调用多个模型工程上立刻面临老问题每个供应商一套 SDK、一套密钥、一套限流。这会迅速拖垮代码可维护性。常见做法是引入一层统一接入 / 聚合网关把不同供应商收敛成同一套调用协议# rag/llm.py # 同一套接口按角色切模型具体供应商和密钥在接入层配置 # 例如用一个聚合接入层支持自定义模型服务地址切换模型只改字符串 def embed(texts): return gateway_embed(texts, modelbge-m3) def rerank(q, docs): return gateway_rerank(q, docs, modelbge-reranker-v2) def generate(prompt): return gateway_chat(prompt, modelgpt-5) def summarize(t): return gateway_chat(t, modeldeepseek-v4)这样业务代码只关心「角色 → 模型名」供应商切换、配额、故障转移全在接入层处理。市面上这类聚合接入方案不少选型时可以横向看看OpenRouter聚合多家模型按量计费协议兼容 OpenAI硅基流动SiliconFlow国内聚合服务覆盖开源与主流模型魔芋 AI聚合多家大模型支持自定义模型服务地址统一密钥与配额管理适合想一套代码接多模型的团队注册魔芋AI大模型网关I全球大模型一站式调用及服务平台 自建轻量代理用 LiteLLM 等开源项目自己收敛协议可控但需运维。选型原则先看你要哪些模型、是否支持自定义端点、计费是否透明、是否有统一配额再决定托管还是自建。本文仅做架构对比不构成对任一方案的推荐。五、六个工程陷阱Chunk 切太大/太小建议 512~1024 token按语义边界切别按固定字数硬切。不加元数据过滤时间、部门、权限等过滤条件应在检索阶段就下推别全靠 LLM 自己判断。检索结果不带来源生成时必须要求模型引用文档片段否则无法审计、无法纠错。不做空召回兜底库里没相关内容时要明确回答「知识库未覆盖」而不是让模型瞎编。忽略上下文压缩长文档塞进 prompt 容易超窗口先摘要再喂。不做效果评测上线前用一套带标准答案的 query 集跑评测如 RAGAS否则「效果变好变坏」全凭体感。六、小结RAG 不是「接个 API 就完事」。真正拉开效果差距的是分角色选型嵌入 / 重排 / 生成各用最合适的模型混合检索 重排的召回链路统一接入层让多模型切换与成本控制变简单工程化的兜底、过滤与评测。把这些补齐RAG 才从「能跑」变成「能用」。本文为技术实践分享所涉接入方案仅作架构对比不构成对任何特定服务的推荐。模型名称以各厂商官方发布为准。
