>上线不是终点，而是持续进化的起点——如何让模型越用越聪明？
前一篇我们聊了从0到1的第一步：选场景、组团队、整数据、配硬件、跑试点。模型上线了，能回答问题、能提建议了，是不是就大功告成了？
不是。上线，只是模型生命周期的开始。
一个私有大模型，就像一台精密的水泵、一套复杂的加药系统——它需要持续的“保养”。知识库要更新，模型要微调，效果要评估，迭代要有机制。否则，随着时间的推移，模型给出的答案会过时、会失准，员工用着用着就不愿意用了。
这一篇，我们就来讲讲：模型上线之后，怎么让它越用越好、越用越聪明。
01知识库更新：让模型的知识“保鲜”
模型的知识来源，主要是两个：一是训练时学进去的“静态知识”（行业底座+开源模型的基础能力），二是上线后通过RAG检索的“动态知识”（水司自有知识库）。
其中，自有知识库是最需要持续维护的部分。因为水司的业务在变：操作规程改了、设备换了、新的应急预案发布了、老师傅又积累了新的经验。
知识库需要更新什么？
制度文档：任何新增或修订的规程、制度、预案，都应该及时录入知识库。旧的版本可以归档保留，但模型检索时应该优先返回最新版本。
设备档案：新采购的设备、完成大修的设备、退役的设备——台账要同步更新，模型才能给出准确的设备信息。
运行记录：历史数据越丰富，模型做趋势分析、异常预警时就越准。定期把新增的运行日志、水质数据、维修记录导入知识库。
经验沉淀：这是最有价值也最容易被忽略的。每一次应急处理的复盘、每一次老师傅的“心得分享”、每一次疑难问题的解决过程，都应该被记录下来，变成知识库的一部分。
更新频率怎么定？
不需要“实时更新”，那样太累，也没必要。可以根据内容类型，设定不同的节奏：
制度类：有变更就更新（触发式）
设备档案：每周或每月批量同步
运行记录：每日自动导入
经验沉淀：随时发生、随时记录、定期整理入库
关键是：要有专人负责知识库的维护，不能“建完没人管”。这个人可以是数据专员，也可以是业务骨干兼任。职责包括：审核新入库内容的准确性、删除过期或错误的信息、优化知识的组织和标签。
02模型反馈微调：让模型从“错误”中学习
模型再强，也不可能第一次就完美。它可能会：
答非所问（理解错了问题）
给出不准确的建议（数据或逻辑有偏差）
漏掉关键信息（知识库没检索到）
过于“死板”或过于“随意”（没有把握好业务分寸）
这时候，就需要人的反馈。每次用户与模型的交互，都可以成为模型优化的素材。
反馈机制怎么设计？
最简单的：在每个模型回答的下方，设置两个按钮——“有用”和“没用”。用户点一下，就是一次反馈。如果“没用”，最好还能让用户简单说明原因（可选，不强制）。
更进一步：对于加药推荐、调度建议这类场景，可以记录“模型推荐值”和“最终采用值”之间的差异。如果值班人员每次都把模型推荐的加药量调高，说明模型可能“偏保守”；如果每次都调低，说明模型可能“偏激进”。这些差异可以积累下来，用于后续微调。
微调怎么做？
不是每次反馈都要重新训练模型。微调需要积累足够多的“问题正确答案”对，达到一定数量后，再启动一次小规模的微调训练。
启动阶段，建议一个季度或半年做一次微调。随着数据积累和场景成熟，可以缩短到每个月一次。
但有一条原则：微调一定要在隔离环境中先验证效果，确认改进后再上线到生产环境。不能让“试验品”直接面对用户。
03效果评估：不看“技术指标”，看“业务价值”
很多人评估模型好坏，喜欢看“准确率”“召回率”这类技术指标。这些指标对研发有用，但对水司管理者来说，意义不大。
管理者真正关心的是：模型有没有帮我们解决问题、创造价值？
所以，效果评估应该围绕业务价值来设计。可以从以下几个维度入手：
维度一：使用率
有多少员工在用这个模型？
每个员工平均每天提几个问题？
模型回答的“有用”点击率是多少？
使用率低，说明模型还没真正融入日常工作。可能是入口不好找、回答不靠谱、或者员工还没养成习惯。
维度二：效率提升
以前查一份规程要多久？现在要多久？
以前做一个报表要多久？现在要多久？
以前新员工培训要几个月才能独立上岗？现在呢？
这些对比不需要精确的数字，但可以通过访谈、问卷、小范围统计来获得定性或半定量的判断。
维度三：质量改善
全文见水之羿公众号
前一篇我们聊了从0到1的第一步：选场景、组团队、整数据、配硬件、跑试点。模型上线了，能回答问题、能提建议了，是不是就大功告成了？
不是。上线，只是模型生命周期的开始。
一个私有大模型，就像一台精密的水泵、一套复杂的加药系统——它需要持续的“保养”。知识库要更新，模型要微调，效果要评估，迭代要有机制。否则，随着时间的推移，模型给出的答案会过时、会失准，员工用着用着就不愿意用了。
这一篇，我们就来讲讲：模型上线之后，怎么让它越用越好、越用越聪明。
01知识库更新：让模型的知识“保鲜”
模型的知识来源，主要是两个：一是训练时学进去的“静态知识”（行业底座+开源模型的基础能力），二是上线后通过RAG检索的“动态知识”（水司自有知识库）。
其中，自有知识库是最需要持续维护的部分。因为水司的业务在变：操作规程改了、设备换了、新的应急预案发布了、老师傅又积累了新的经验。
知识库需要更新什么？
制度文档：任何新增或修订的规程、制度、预案，都应该及时录入知识库。旧的版本可以归档保留，但模型检索时应该优先返回最新版本。
设备档案：新采购的设备、完成大修的设备、退役的设备——台账要同步更新，模型才能给出准确的设备信息。
运行记录：历史数据越丰富，模型做趋势分析、异常预警时就越准。定期把新增的运行日志、水质数据、维修记录导入知识库。
经验沉淀：这是最有价值也最容易被忽略的。每一次应急处理的复盘、每一次老师傅的“心得分享”、每一次疑难问题的解决过程，都应该被记录下来，变成知识库的一部分。
更新频率怎么定？
不需要“实时更新”，那样太累，也没必要。可以根据内容类型，设定不同的节奏：
制度类：有变更就更新（触发式）
设备档案：每周或每月批量同步
运行记录：每日自动导入
经验沉淀：随时发生、随时记录、定期整理入库
关键是：要有专人负责知识库的维护，不能“建完没人管”。这个人可以是数据专员，也可以是业务骨干兼任。职责包括：审核新入库内容的准确性、删除过期或错误的信息、优化知识的组织和标签。
02模型反馈微调：让模型从“错误”中学习
模型再强，也不可能第一次就完美。它可能会：
答非所问（理解错了问题）
给出不准确的建议（数据或逻辑有偏差）
漏掉关键信息（知识库没检索到）
过于“死板”或过于“随意”（没有把握好业务分寸）
这时候，就需要人的反馈。每次用户与模型的交互，都可以成为模型优化的素材。
反馈机制怎么设计？
最简单的：在每个模型回答的下方，设置两个按钮——“有用”和“没用”。用户点一下，就是一次反馈。如果“没用”，最好还能让用户简单说明原因（可选，不强制）。
更进一步：对于加药推荐、调度建议这类场景，可以记录“模型推荐值”和“最终采用值”之间的差异。如果值班人员每次都把模型推荐的加药量调高，说明模型可能“偏保守”；如果每次都调低，说明模型可能“偏激进”。这些差异可以积累下来，用于后续微调。
微调怎么做？
不是每次反馈都要重新训练模型。微调需要积累足够多的“问题正确答案”对，达到一定数量后，再启动一次小规模的微调训练。
启动阶段，建议一个季度或半年做一次微调。随着数据积累和场景成熟，可以缩短到每个月一次。
但有一条原则：微调一定要在隔离环境中先验证效果，确认改进后再上线到生产环境。不能让“试验品”直接面对用户。
03效果评估：不看“技术指标”，看“业务价值”
很多人评估模型好坏，喜欢看“准确率”“召回率”这类技术指标。这些指标对研发有用，但对水司管理者来说，意义不大。
管理者真正关心的是：模型有没有帮我们解决问题、创造价值？
所以，效果评估应该围绕业务价值来设计。可以从以下几个维度入手：
维度一：使用率
有多少员工在用这个模型？
每个员工平均每天提几个问题？
模型回答的“有用”点击率是多少？
使用率低，说明模型还没真正融入日常工作。可能是入口不好找、回答不靠谱、或者员工还没养成习惯。
维度二：效率提升
以前查一份规程要多久？现在要多久？
以前做一个报表要多久？现在要多久？
以前新员工培训要几个月才能独立上岗？现在呢？
这些对比不需要精确的数字，但可以通过访谈、问卷、小范围统计来获得定性或半定量的判断。
维度三：质量改善
全文见水之羿公众号
