深夜的值班同事收到一条内部问答系统的回复：流程已经更新，旧版本停止使用。第二天核对才发现，知识库里新旧两份文档并存，模型只是把过期的那份组织得更像答案。系统没有宕机，也没有报错，但一次误答已经进入了工作流。这时再问“模型能力够不够”，已经有点晚。
开源模型把“能跑”这件事变简单了，却没有把“敢用”一起解决。权重文件下载到本地，推理服务可以放在自己的机柜里，数据不必离开内网；与此同时，更新、评测、解释和回滚也都留在了自己手里。便利和责任，通常是一起搬进来的。
从“能下载”到“敢上线”的距离
部署开源模型的团队，常把注意力放在参数量和推理速度上。这些指标当然要关注，但上线前更该问的是：这个模型回答错了，系统能不能发现？发现之后，能不能定位到是权重版本、提示词、检索结果还是知识库本身的问题？如果答案含糊，参数讨论就容易变成纸面上的安心。
“开放权重”也不等于“没有约束”。许可证可能涉及商业使用、署名、再分发或修改后的义务，具体条款需要逐项核对。工程侧可以维护一份模型清单：权重版本、来源、许可证、微调记录、依赖组件。它不解决所有问题，但能让后来接手的人知道，机柜里跑的到底是什么。
误答之后，先看哪张纸
模型输出带有不确定性，单次演示很难代表日常质量。比较务实的做法，是准备一套窄而具体的评测问题，覆盖高频任务和容易混淆的边界；每次更换权重、调整提示词或更新知识库，都跑一遍并留下记录。评测集不必庞大，但要能回答“这次改动有没有把原来能答对的问题弄坏”。
日志同样重要。输入、输出、引用来源、模型版本和时间戳，能在误答发生后还原现场。这里要兼顾隐私和访问权限，不是把所有内容无限期保存。更关键的是回滚路径：新版本出问题时，能否在短时间内切回旧版本；知识库变更由谁批准；人工复核放在哪一步。模型不负责事实核验，系统设计得替它兜底。
许可证不是附录
许可证不是开源模型的附录，而是部署说明书的一部分。不同许可证对分发、修改和商用的要求并不一样，团队不必把法务判断全压在工程师身上，但应该让工程记录和法务审查有交集。至少，模型来源、版本变更和对外服务方式要能对应起来。涉及具体条款时，谨慎咨询专业人士，比凭印象判断更稳妥。
把“可替换”做成日常能力
开源模型的一个实际价值，是让团队有机会审查、修改和替换。但“可替换”不是口号，它需要接口抽象、评测回归和版本管理一起支撑。小团队可以从窄场景开始：先让模型做草稿、检索或分类，把最终确认留给人工；等评测和日志稳定后，再逐步扩大范围。
真正难的不是把模型跑起来，而是把它的不确定性放进流程里。机房里的那台推理服务不会自己解释误答，责任也不会因为权重开放就自动转移。上线之前，先把谁来看、谁来改、谁来关说清楚，可能比再调一轮参数更接近问题的中心。