第一步：基线与拆解
先记录人工处理的方式、耗时与错误类型作为基线，再把任务拆成理解、生成、校验三段。没有基线的项目，上线后无法说明改善了哪里，预算续批时也缺少依据。
第二步：知识与检索
整理领域文档、术语与常见问题，建立检索与引用机制。检索质量决定回答是否有依据，优先级高于换更大模型；检索没做好，模型越大只会让错误更流畅。
第三步：模型方案选择
先用通用模型加检索跑基线，再判断是否需要微调或私有化。微调适用于格式固定、术语特殊的任务，且要预留重新训练与评测的成本，不能一次投入就锁定。
第四步：上线与版本运营
接入业务入口，锁定版本，建立回归评测与错误归类机制。模型、检索与提示词的每次改动都应留记录，便于回溯质量变化，也便于交接给后续维护团队。
验收：可用率与稳定性
建议以评测集可用率、真实业务接管率、响应时间与错误类型分布作为验收依据，并约定回归门槛。指标需由业务负责人确认，避免只有技术指标而无法说明业务价值。
适用与不适用
适合谁
- 准备做模型选型的企业技术团队
- 已有试点需要进入生产的项目组
- 需要向管理层说明阶段成果的负责人
不适合谁
- 希望跳过知识建设直接微调的团队
- 没有真实业务样本的探索性项目
典型场景
某制造企业的设备维修知识分散在手册与老师傅经验中。团队先记录当前排障耗时与误判类型，再把手册与案例做成检索库，用通用模型跑基线，最后只对术语识别做小范围微调。
可执行步骤
- 记录人工处理基线：方式、耗时、错误类型
- 整理领域文档并建立检索与引用
- 用通用模型跑评测基线
- 按评测结果决定是否微调或私有化
- 锁定版本，建立回归与错误归类机制
常见坑
- 跳过基线直接上线，无法证明改善，预算续批时缺乏依据。
- 检索库只放整篇文档不做切分，召回内容过长，回答抓不住重点。
- 一开始就做微调，样本不足导致过拟合，泛化能力下降。
- 改动不留记录，质量下降时无法定位是模型还是知识问题。
自检与验收清单
- 是否记录人工处理基线
- 检索内容是否做了切分与标注
- 是否先用通用模型跑基线
- 微调是否有足够样本与评测
- 版本与改动是否有记录
常见问题
什么时候必须微调？
当任务需要固定输出格式、专业术语识别或特定语气，且检索加提示词无法稳定达到要求时再考虑。微调前应先确认样本量与评测方案。
私有化部署值得吗？
取决于数据敏感度与使用强度。数据不能出内网或有稳定高并发需求时更合适；否则接口调用在维护成本上更有优势。
评测集要多大？
以覆盖主要任务类型与错误模式为准，通常从几十条高质量样本起步，随场景扩展补充。质量比数量重要。