1 篇博文 含有标签「model-provenance」

审计员的问题听起来很简单。她翻开你的申诉日志，指着八个月前的一行，询问是哪个模型决定了那个案例。你的工程师调出了 Schema：有一个 model 列，审计窗口内的每一条决策都显示为 v1。接着，平台团队的一位成员随口提到，在审计期间，v1 背后的别名（alias）轮换了四次——一次基础模型升级、一次微调刷新、一次供应商侧的容量迁移，以及一次在事故期间持续了六个小时的回滚。诚实的回答是，你无法确定是哪一个 Checkpoint 产出了那个决策。审计员记录下了一些内容。那个回答不是监管机构能接受的答案，而你刚刚意识到，你交付的系统未能满足一项它从未被设计去满足的审计要求。

这里的差距不在于缺失了一行日志，而在于对“模型”含义的两种不同理解。对于交付系统的工程师来说，v1 是一个 Endpoint——一个稳定的契约，调用者可以指向它，而其背后的东西则可以免费升级。对于审计员来说，“产生此决策的模型”是一个特定的 Artifact：一个权重 Checkpoint、一个哈希值，一个原则上你可以在相同的输入上重新运行并获得具有辩护一致性输出的东西。Endpoint 别名是为了向调用者隐藏 Checkpoint 的轮换而发明的。而审计级的溯源要求恰恰相反——每一项决策都必须能追溯到产出它的确切 Checkpoint。这两个想法从一开始就处于碰撞轨道上；审计只是它们相遇的地方。