微调什么时候值得做：多数企业其实不该先微调

微调听起来像「拥有自己的模型」。销售话术也常把它当成必选项。对多数企业，先微调是错序：内容未理顺、题集不存在、权限未做时，微调只是把混乱学得更像官方语气。

更合理的顺序是：场景与题集、检索与权限、提示与流程，最后才是是否微调。前面三步能解决的问题，不要用微调硬盖。

什么情况才认真评估微调

例如极度稳定的分类或抽取、大量高质量标注、且检索无法提供的风格或格式硬约束。即使如此，也要算清：标注成本、评估成本、版本升级后是否重训。

若目标是「回答必须来自公司文档」，优先 RAG。微调不自动具备最新文档，文档一变就要新数据与新评估。

私有化部署关心数据驻留与控制面。微调关心参数是否更新。两者可组合，但采购时不要混成一个勾选框。混谈会导致预算与验收错位。

微调是强工具，不是默认起步动作。

泛友在立项评审里，会要求先出示题集与基线分。基线不存在时，不支持把微调写入第一期必选项。

让对方用未微调方案跑你的题。若已经接近可用，微调就不是急救。若差距巨大，再分析是检索问题还是格式问题。格式问题可能用约束解码或后处理更便宜。

即使做了微调，也要保留可回退到基座加检索的路径。没有回退，一次训坏就会停摆。

有人说「先上线再收集数据微调」。若上线质量差，收集到的是怨气与脏标注。飞轮前提是基线可用。基线不可用时，应继续打磨检索与流程。

标注规范要先于标注规模。没有规范的一万人天标注，只会训练出稳定的错误。

评估集要与训练集隔离。隔离做不到，微调解成了背答案，上线仍会崩。

围绕「微调什么时候值得做：多数企业其实不该先微调」，建议先写一页落地清单：目标用户、入口位置、冻结题数量、红线问题、周会指标与负责人。清单进项目章程后，讨论才不会反复回到功能点罗列。AI 科普类文章尤其要把「不做什么」写进清单，避免范围在实施中膨胀。

内容治理与系统治理分开。页面、制度或案例更新后，题集与检索同步更新；只改提示词，解决不了结构问题。建议建立双周变更窗：窗口内集中更新，窗口外保持稳定，便于对比「微调什么时候值得做：多数企业其实不该先微调」相关指标是否真的变好。

试点宁小勿大。先在一个团队证明指标可改善，再复制到下一团队。复制时连同红线、题集和负责人一起复制，而不是只复制界面。若第一队都跑不通，加模型规格很少能拯救「微调什么时候值得做：多数企业其实不该先微调」所描述的那类问题。

与供应商沟通时固定题集。题可以难，但必须可重复。用同一批题看版本差异，比每次换新题刷分更能反映真实进度。合同附件里写明题集保管人与及格线，能减少上线后的扯皮。

上线前四周把失败样例当成主要输入。平均分好看但同一类失败重复出现时，优先改文档、入口或权限。把失败样例归类为：内容缺失、权限过严、入口不便、模型越界。四类对应不同负责人，避免所有问题都甩给算法。

对外表述保持可验证。能写成「在某某条件下完成某某检查」的句子，就不要写成「全面赋能」。宣传与验收用语分离后，「微调什么时候值得做：多数企业其实不该先微调」才不会在客户处被理解成无限承诺。

安全、法务或合规同事应在方案阶段介入，而不是上线前一天。涉及对外口径或数据驻留时，早期否决比事后补救便宜。介入产出应是一页约束，而不是一本看完即搁置的手册。

为关键资产指定主责与备责。文档、题集、索引、话术都要有第二负责人，避免请假或离职后「微调什么时候值得做：多数企业其实不该先微调」相关能力停摆。名单贴在周报抬头，比放在通讯录深处更有效。