交付物：知识 vs 模型
RAG 交付切分规则、索引、检索服务与评测集；微调交付数据集、训练配置、模型版本与回归报告。验收时要看文件与版本号，而不是看演示；缺评测集的交付无法证明效果，也无法判断是否退化。怎么验收，逐项核对文件与版本号，不看演示。
工期：前快后慢 vs 前慢后快
RAG 的链路两三周能跑通，但调优召回会持续数周；微调前期要攒样本与标注，训练本身不慢，慢在评测与回归。排期应把调优期单独列出，否则容易被当成延期，双方对进度的理解会越来越远。为什么排期要分开，因为调优与回归都不产生新功能。
维护：更新索引 vs 重训
制度改了，RAG 更新文档与索引即可当天生效；微调要重新训练、评测、灰度，周期以周计。业务更新频繁时，维护方式本身就是选型依据，不只是技术细节，也直接影响谁值班、多久能改一次。怎么降低更新成本，把知识与表达分开维护。
成本：检索存储 vs 训练算力
RAG 的经常性支出在检索服务、向量存储与文档处理；微调在训练算力、标注与版本管理。两者都要算人力，尤其是评测与复核，往往比工具费用更高，预算里最容易被漏掉的也是这一块。怎么估算这块人力，按每周复核条数与抽检比例折算。
失败：答不出 vs 答得像
RAG 失败多是检索不到或引用错段，用户能看出没答上来；微调失败常是流畅但内容偏了，更难发现。后者必须靠评测集与抽检拦截，不能只靠人工感觉，否则问题会以低成本的方式扩散。怎么拦截答得像的错误，用引用命中与抽检双保险。
适用与不适用
适合谁
- 需要向决策层解释两条路线差异的负责人
- 正在排期并做三年预算的项目经理
- 已有一版 RAG、在评估是否微调的团队
不适合谁
- 只比较单次报价、不看维护方式的采购
- 没有真实问答样本、无法评测的项目
典型场景
某检测机构要在两个月内上线报告辅助撰写。团队先用 RAG 做条款检索与引用，两周跑通、四周稳定；报告格式仍不统一，于是二期用三百份历史报告做轻量微调，固定章节顺序与措辞。两期分开验收，评测集沿用同一套，避免二期把一期的效果改坏。
可执行步骤
- 列出两条路线各自的交付物、版本管理方式与验收人及时间清单表格
- 按周排期，把调优期与回归期单独列出，各留一成缓冲，并写进甘特图
- 估算经常性支出与人力，而不是只看一次性开发投入与报价单金额，慎估
- 写明各自的失败形态与拦截手段，并指定抽检比例与责任人签字名单
- 分两期验收，共用一套评测集，并在二期保留回退入口与旧版本编号
常见坑
- 只比开发报价，忽略索引维护与版本回归，第二年预算不够，系统停更，业务被迫回退。旧版。
- 把调优期算进开发期，进度表看起来正常，实际每周都在赶，最后砍掉评测与异常处理。环节。
- 两期各建一套评测集，二期上线后无法判断是否损伤一期效果，只能凭感觉，争吵也没有依据。
- 验收只看演示问答，不看引用是否正确，答得流畅但引错条款，风险留到使用阶段，届时很难补救。
自检与验收清单
- 两条路线的交付物是否列成文件清单并指定验收人
- 调优期与回归期是否单独排期，各留缓冲时间
- 经常性支出与人力是否按年度估算过并纳入预算
- 失败形态与拦截手段是否写明，抽检比例多少
- 两期是否共用一套评测集，并保留回退入口开关
常见问题
能不能只做微调不做 RAG？
可以，但要看知识是否常变。知识稳定、任务是固定格式生成时，微调足够；一旦涉及条款查询与溯源，仍需要检索。只做微调的项目，后期常被迫补一套检索，架构要预留位置。接口。
RAG 的调优期为什么那么长？
因为召回问题分散在切分、词表、解析与权限上，每修一处都要重跑评测。经验是把调优拆成小步、每周看一次命中率，比一次性大改更容易收敛，也便于判断哪一步起了作用。
两期之间要不要停机？
不需要。二期用灰度流量验证，与一期并行；确认格式与准确率稳定后再切主流量，并保留回退开关。停机切换的风险通常高于并行一段时间，尤其是对外服务时段。风险更高。