当大模型应用从 Demo 走向生产，一个绕不开的架构决策是：哪些能力交给检索增强生成（RAG），哪些能力交给微调。两者并非互斥，但边界模糊会导致数据管道冗余、推理链路复杂、维护成本失控。本文从知识更新频率、数据私密性、推理成本与延迟约束四个维度，给出可操作的划分思路。
知识更新频率决定主路径
知识更新频率是区分 RAG 与微调最直接的信号。如果业务知识每天甚至每小时都在变化——例如商品价格、库存状态、新闻资讯、工单状态——微调几乎不可行。微调本质上是把知识固化到模型参数中，每次更新都需要重新准备数据、训练、评估、部署，周期以天或周计。RAG 则把知识外置到检索库，更新检索库即可生效，延迟可控制在分钟级。
反过来，如果知识相对稳定——例如领域术语定义、固定的话术风格、产品分类体系——微调可以把这些模式内化到模型中，减少对检索质量的依赖。但要注意：微调适合学习“模式”而非“事实”。让模型记住具体事实（如某条政策条款的原文）既不可靠也不经济，事实类知识仍应优先走检索。
工程上可以按“知识半衰期”做粗划分：半衰期短于一周的，走 RAG；半衰期长于一个季度且以模式为主的，考虑微调；介于两者之间的，优先 RAG，并观察检索命中率是否成为瓶颈。
数据私密性与合规约束
私密数据是否允许进入训练流程，是另一个硬约束。微调需要把样本数据送入训练管道，数据可能被固化进模型权重，存在泄露风险，且难以逐条撤回。RAG 的检索库可以做到行级权限控制、审计日志和即时删除，更适合处理用户隐私数据、合同条款、内部工单等敏感信息。
如果业务要求“数据可删除、可追溯”，RAG 是更安全的选择。微调则适合那些已经脱敏、可长期留存、且不涉及个体权益的领域语料。混合架构中，敏感数据应严格限制在检索侧，微调模型只学习通用的任务模式，不接触原始敏感内容。
推理成本与延迟的权衡
RAG 的推理成本包括检索服务、向量化、上下文拼接带来的额外 token 消耗。检索结果越长，输入 token 越多，单次调用成本越高，延迟也随检索链路增加。微调模型的推理成本通常更低——因为不需要拼接长上下文，但训练成本是一次性投入，且需要维护多个模型版本。
延迟敏感型场景（如实时对话、在线客服）需要谨慎评估 RAG 的检索耗时。如果检索库规模大、需要多路召回和重排，端到端延迟可能增加数百毫秒。此时可以考虑：对高频问题用微调模型直接回答，对长尾问题走 RAG；或者用微调模型做查询改写和结果压缩，减少检索轮次和上下文长度。
成本上还有一个隐性项：RAG 的检索质量依赖嵌入模型和索引维护，索引重建、分块策略调整、召回评估都需要持续投入。微调则依赖标注数据和训练管道，数据质量差会导致模型退化。两者都不是“一次上线就结束”的方案。
混合架构的接入方式
同一业务里，合理的划分是：把“稳定模式”放微调，把“动态事实”放检索。具体接入方式有三种常见形态。
第一种是路由式：用一个轻量分类器或规则判断用户请求类型，动态事实类请求走 RAG，模式类请求走微调模型。优点是链路清晰，缺点是路由错误会直接导致回答失败。
第二种是串联式：微调模型负责理解意图、生成检索查询、压缩检索结果，RAG 负责提供事实依据。这种方式把微调用在“调用检索”的能力上，而不是记忆知识，适合查询复杂、需要多轮检索的场景。
第三种是并联式：微调模型和 RAG 各自生成候选回答，再由一个融合模块（可以是规则、小模型或大模型）做一致性校验和择优。适合对准确性要求高、允许增加推理成本的场景。
无论哪种形态，数据管道都要保证检索库和微调数据同源可追溯。建议在数据层做统一的内容管理，检索侧和训练侧从同一份内容派生，避免两边知识不一致。
上线后的维护成本评估
维护成本常被低估。RAG 的维护重点是检索质量：分块策略、嵌入模型版本、召回率与准确率的持续评估、索引更新频率。微调的维护重点是数据版本和模型迭代：训练数据漂移、评估集更新、模型回滚机制。
一个实用的评估方法是列出两类方案在“知识更新、数据删除、效果回归、成本波动”四个事件上的响应成本。如果知识更新频繁且要求快速生效，RAG 的响应成本明显更低；如果任务模式稳定但要求低延迟低 token 消耗，微调的长期成本更优。
最终结论是：不要问“选 RAG 还是微调”，而要问“这个能力对知识新鲜度的要求有多高、数据能否进入训练、延迟和成本预算多少”。把每个能力按这三个问题打分，边界自然清晰。混合架构不是折中，而是按能力拆分后的工程结果。