监控、回归与持续改进闭环

上线后为什么还要评估

积木工坊助手上线试点后，服务看起来没有崩溃，但新版说明书改变了两种连接件名称，用户也开始用口语描述颜色。模型参数没变，输入分布却变了。监控既要发现系统有没有正常运行，也要发现它是否仍在完成原任务。运行成功率高只说明请求被处理，不代表步骤正确；用户点击满意也不一定代表实际搭建成功，可能只是语气亲切。持续评估需要把技术状态、任务成果与使用环境分开记录，再解释它们之间的关系，避免用一个总分掩盖不同问题。

建立三层指标表

第一层是服务运行：加载成功、请求错误、排队、首个词元等待、完整响应时间和峰值资源。第二层是任务质量：步骤正确、结构合格、资料引用是否对应以及信息不足时是否澄清。第三层是业务过程：人工复核耗时、重复提问和完成任务的比例。统计时给出样本量、时间窗口和版本，不把不同版本混成一个数字。延迟可同时报告中位数与较高分位数，例如百分之九十五请求以内的等待值，因为平均值可能掩盖少量很慢的体验。分位数反映样本排序位置，不是模型置信度。

用证据定位而不是立刻重训

某天错误变多，先抽取脱离个人身份的虚构或最小必要样本，检查资料、检索、提示、模型和服务配置分别发生了什么变化。正确段落没有进入上下文，就先修检索；上下文正确但新术语反复误解，才考虑数据与适配；请求超时导致答复不完整，应解决容量或输出限制，而不是补充训练数据。输入变化造成性能下降常被称为数据漂移，但并非每次指标波动都意味着漂移，也可能是样本构成变化或统计噪声。工坊按说明书类别拆分指标，避免把更多困难问题的出现误判为模型本身突然退步。

把反馈加工成受控更新

用户反馈不能直接自动进入训练库，因为可能含错误建议、重复内容或不应保存的信息。先核对授权与必要性，去重、核验、标注来源，再放入候选数据版本。新版本仍使用独立验证和测试，并运行一份稳定的回归题集，检查过去修好的问题有没有重现。回归题集可以随已确认故障增加，但最终泛化测试应保持隔离，不能把所有看过的失败都当作从未见过的测试。一次更新明确改动目的，保留旧版本，这样结果不好时可以回退并理解原因，而不是不断叠加无法解释的调整。

完成工坊的可靠性闭环

整合本模块，团队先确认提示和检索基线，再审查数据，试验低秩适配，比较压缩后的质量和资源，最后采用限定试点部署并设置监控与回滚。报告必须同时写改进、代价和未解决问题。例如三步结构更稳定，但罕见零件仍需人工说明，不能宣传成所有搭建问题都能处理。监控日志只保留必要字段，设置访问范围与保留期限，避免为了分析收集完整无关内容。课程中的图表与记录可以用手工模拟数据完成，它们展示如何做判断，不代表页面已经连接真实模型或自动监控服务。