RAG 与微调怎么选：用更新频率和延迟预算做决策
讨论检索增强和参数微调的选型时，最容易滑向「哪个效果更好」。但对一个已经有可用基座模型、只是不知道知识该放在哪里的团队来说，效果差异往往不是第一约束。真正决定架构的是三个可以先量出来的工程变量：知识多久变一次、在线接口的延迟预算是多少、以及标注和运维人力能不能长期跟上。
下面讨论的是通用工程方法，不绑定任何具体产品或模型实现。文中提到的拆分方式和检查项需要在真实链路上实测后才有数值。
先量知识变更速率，而不是先看效果
把业务知识按变更速率分档，比按「是事实还是风格」分档更接近成本结构。
- 高频：报价、库存、政策口径、工单状态、活动规则。变更以小时或天计。
- 中频：产品文档、SOP、内部规范、条款解释。变更以周计。
- 低频：领域术语、表达风格、输出格式、任务拆解路径。变更以季度或更久计。
一个可用的判断是：变更频率高、且需要给出处和可追溯来源的知识，交给检索承载；变更频率低、影响的是输出风格、格式或推理路径的知识，才考虑固化进参数。这条规则来自成本结构，不是来自某个产品的能力声明：检索的更新成本主要在数据管道和索引重建，微调的更新成本会随变更次数被反复放大，因为每次都要重跑训练、回归验证和灰度发布。
评估更新成本时，不要只算训练或索引这一步。完整的单位更新成本大致等于：数据清洗与去重、索引构建或训练执行、回归验证、发布与回滚准备。微调链路里后两项通常被低估，而它们恰恰是最难自动化、最依赖人的部分。
把延迟预算拆到可测量的段
端到端延迟不要只看一个总数，拆到能单独打点的粒度才有优化空间：
T_total = T_net + T_auth + T_retrieve + T_rerank
+ T_prompt + T_ttft + T_gen + T_post
其中检索段还可以继续拆：查询改写或向量化、候选召回、多路合并、重排。需要注意的是，T_ttft（首 token 时间）和 T_gen（生成耗时）通常与输出长度强相关，而检索段与知识库规模、候选数量强相关，两者的扩容方式完全不同。
从工程角度看，这里真正值得先做的是分段打点，而不是先做优化。只有拿到各段实际占比，才能判断叠加检索是否会挤穿延迟预算。如果生成段已经占据大头，压缩检索候选数带来的收益有限；如果检索段占比高，缓存、预取、缩短上下文往往比换模型更直接。
还有一个容易被忽略的点：微调并不能自动降低延迟。它减少的是提示长度和检索段开销，但如果为了维持效果而把输出拉长，生成段反而会变慢。延迟和知识更新成本之间存在权衡，这个权衡必须实测，不能用直觉替代。
标注人力是微调的隐藏成本
微调不是一次训练，而是一条持续维护的产线。需要持续投入的环节包括：标注规范定义、样本去重、难度分层、回归集维护、训练版本管理、回滚策略。任何一项缺失，都会让后续迭代变成不可控的重训。
一个实用的做法是，在决定微调之前先估算两件事：一是每月新增多少条需要标注的样本，二是回归集需要多少人时来维护。如果这两项无法稳定供给，微调路线的长期成本会被显著低估。
混合链路的三种拼接位置
当团队已经确定两类知识都需要承载时，混合链路是常见选择。常见的拼接位置有三种：
- 提示级拼接：检索结果作为上下文注入，模型只负责生成。知识可即时更新，链路可观测，出处容易保留。
- 路由级拼接：按意图或置信度决定走检索增强分支还是微调分支。链路更短，但对路由准确率依赖高，错分会直接体现在答案上。
- 输出级拼接：结构化字段由检索或规则填充，自然语言部分由微调模型生成。适合模板化程度高的场景，可解释性好，但需要两部分保持一致的字段约定。
工程判断上，提示级拼接最容易先上线，也最容易做灰度；路由级和输出级拼接对评测要求更高，因为需要分别评估各分支，还要评估拼接处的边界情况。上线顺序通常是先提示级、再按错误归因决定是否引入路由。
微调之后知识又变了，怎么回退
高频事实一旦被写进参数，后续变更就只能靠重训覆盖，代价高且难以追溯。几种通用做法可以降低这类风险：
- 不把高频事实作为微调目标，只把风格、格式和推理路径作为目标；
- 检索命中时优先采用检索内容，并在提示中显式声明优先级，避免模型用自己的参数知识覆盖；
- 为微调版本保留关闭开关，出现冲突时可切回纯检索链路；
- 记录「模型版本 + 知识快照」的组合标识，便于定位问题来自哪一侧。
这几条本质上是把回退能力做进架构，而不是等冲突发生后再补救。回退成本应该和更新成本一起进入选型判断。
用少量标注样本验证选型
不需要大规模标注也能做出初步判断。一个可执行的小规模验证流程如下：
- 建 50 到 200 条评测样本，按知识时效分层，同时保留一部分「知识已更新后」的样本。这部分样本是区分检索与微调的关键。
- 设置三组对照：纯检索、纯微调、混合链路。控制变量，尽量使用同一批输入。
- 记录的不只是答案正确率，还包括：出处一致性、该拒答时是否拒答、P95 端到端延迟、单次请求的成本量级。
- 按时间维度切分评测集，观察知识变更后各方案的指标衰减曲线。检索方案在知识更新后通常能较快恢复，微调方案需要重训周期，衰减曲线的形状比单点分数更有决策价值。
需要注意的是，样本量小意味着结论置信度有限。它适合用来排除明显不成立的路线，不适合用来做精确的能力排序。
一页检查清单
- 业务知识按小时、周、季度分档后，各占比多少？
- 每类知识的单位更新成本能否估算？主要卡在哪一步？
- 端到端延迟预算是否已分段打点？检索段和生成段各占多少？
- 每月可稳定投入的标注人时是多少？回归集谁维护？
- 混合链路准备接在哪一层？拼接处的一致性如何验证？
- 微调版本能否一键回退到纯检索链路？
- 评测集是否包含知识更新后的样本？
选型不必一次定死。一个务实的路径是先用检索上线，把知识变更频率、各段延迟和错误归因数据收集起来，再决定哪些稳定不变的部分值得固化进参数。当更新频率、延迟预算和人力投入这三个数字都能被测量时，架构决策会比任何效果对比都更有依据。