Z3.06.4Takeover logging设计研究
接管操作应被系统记录用于改进后续判断
别名: 接管记录 · feedback logging · 反馈日志
概念解释
接管事件应当被系统记录：谁、何时、什么情境下、中止了什么、中止后系统做了什么。这份记录身兼两职——向前是改进的数据源（什么情境下用户会接管，正是推断模型最该改进的区域），向后是用户可查的证据链（「它为什么上周开始那样做」——因为周二你三次跳过了那个提醒）。
与「覆盖应该被学习」的分工：那条讲学习的原则（覆盖是训练信号），这条讲记录的基础设施（学习要有账可查）。没有记录的学习两头落空：改进侧没有数据可学，审计侧用户不知道系统从自己身上学走了什么——暗中学人比不学更糟。
机制
**接管是高价值训练样本。**用户接管的那一刻，正是推断与现实分歧显形的一刻——系统以为该做，用户说不该。分歧样本比顺从样本信息量大：顺从只说明「也许对」，接管明确指出「这里错了」。把接管事件的结构化记录（情境、动作、方式、后续）喂回改进回路，等于让用户无偿完成了最难收集的标注。
**记录同时是信任的账本。**系统行为变化若能追溯回具体接管记录（「因为你多次跳过早晨提醒，该提醒已停用」），行为变化就从「无常」变成「有因」，归因链完整是信任的硬通货；追溯不到的变化只能被当成漂移，按最坏情况理解。
**记录自带隐私张力。**接管记录含行为信息（何时在家、在意什么、对什么不耐烦），记录本身成为敏感数据——保存位置、保留期限、谁可读，这些属性与记录的价值同等重要，要一起设计而不是事后补。
怎么研究
- 交互式机器学习中的反馈价值研究：人类反馈样本的价值分布不均——纠正类反馈（跳过、打断、重做）比顺从类反馈信息密度高，是被反复验证的共识；接管记录属于典型的纠正类反馈。
- 消费级系统的实践证据：智能音箱与助手的跳过、打断、重复指令已被广泛用作不满意信号改进产品（该领域的通行做法，泛写）。
- 方法：对照部署——有接管记录反馈回路 vs 无——度量后续接管率与误判断率的变化；记录可读性对信任影响的实验（用户能否查看「学到了什么」两组对比）。
边界
- **记录的价值前提是改进回路真的存在。**记录了但从不用于改进的日志只是合规摆设；反过来，只用于改进、从不给用户看的记录是暗中学人。两个失败形态都要避开——记录、改进、可查三件套缺一不可。
- **接管不总是不满意。**有些接管是协作（「今天先不开空调」）、有些是对故障的反应——把所有接管一律当负样本学习会学错方向；记录里要保留足够的情境让改进环节区分。
- **多用户家庭的归属问题。**共享设备的接管记录归谁、改进谁的模型——归属不明时学习会把所有人平均化，谁也不满意。
怎么落地
- 记录结构化：每次接管记全六元组——时间、触发情境、被中止的动作、中止方式、中止后系统行为、是否恢复——足以完整重放这次接管。
- 记录可读可删：用户侧能看到「系统从我的操作中学到了什么」清单，逐条可删除（「别再用我晚上关灯学任何东西」）。
- 改进闭环可见：接管模式导致的行为调整要通告（「由于你多次在工作日早上跳过，工作日早晨的提醒已停用」）。
- 验证办法：抽样接管事件，检查能否仅凭记录完整重放当时的情境与决策；抽查每项学习变更，能否追溯回具体接管记录——追溯链断在暗处的改进不许上线。