被你的采购团队当成数据表的模型卡片

模型卡（model card）是一件研究产物。而数据表（datasheet）是一份合同。采购团队通常会像阅读后者一样阅读前者，而交付它的 AI 厂商现在正受限于其工程团队原以为只是叙述性的声明。

这是丢掉续约最干脆利落的方式：你转发了发布在模型索引页上的同一个 PDF，客户的法务团队将其中四句话摘录到了附件 B（Schedule B）中，十二个月后你发现“预期用途：通用问答”已变成关于服务范围的合同陈述。你的团队用 BLEU 分值来衡量这些句子，而他们的团队现在正用违约代价来衡量。

错误不在于模型卡写错了。在编写的那一刻，它几乎肯定是准确的。错误在于两种不同的专业文化在阅读同一份文档时，对“一个句子是什么”有着两种截然不同的看法。研究人员编写模型卡是为了告知下游关于行为的决策。采购评审人员则将任何厂商提供的文档视为承诺界面——在未经协商修改之前，每一项声明都是一个条款。双方都没有注意到体裁上的错配，因为在页面上，这份产物看起来确实像文档。

为什么模型卡不适合交给采购部门

模型卡在 2018 年被提出，作为机器学习社区的一种透明度工具。最初的构想非常明确：模型卡的存在是为了让决定是否部署模型的从业者了解模型的优缺点、评估所用的人群，以及作者预期模型会失效的地方。该文档是一种研究规范，而非厂商陈述，其受众被假定为具备足够技术背景，能将“预期用途”理解为作者对行为的思考，而非厂商承诺提供的服务。

这种构想在接触到企业销售时土崩瓦解。一旦模型卡成为厂商对安全调查表回复的一部分，受众就变了。现在的读者是拿着检查清单的第三方风险评审员、拿着模板的采购官，或者——最危险的——按小时计费专门寻找约束性语言的客户外部法律顾问。他们中没有一个人会像作者预期的那样阅读模型卡。他们像阅读任何其他厂商文档一样阅读它：作为一种陈述，如果被附加到主协议中或被主协议引用，它就具有法律效力。

这种体裁错配之所以重要，是因为编写模型卡的初衷是诚实地披露局限性，而不是为了精确地限制责任。模型卡中的“局限性”是研究披露。而厂商合同中的“局限性”则是除外条款。同一个词承担着两种不同的功能，而从未见过模型卡的采购评审员每次都会默认采用第二种理解。

你在不经意间做出的合同承诺

浏览一份典型的模型卡，问问哪些句子会被采购评审员标记出来。这份清单会让你感到不安。

“预期用途”被解读为服务范围。如果模型卡上写着该模型旨在用于英语问答，下游客户可能会辩称，你已经陈述了其对该用途的适用性——而除此之外的不适用性就成了你需要去声明免责的问题，而不是他们需要承担的风险。“训练数据”被解读为数据来源，这涉及版权赔偿，而你的工程团队并不会追踪这些内容。“评估结果”被解读为性能陈述，在任何传统的厂商合同中，这都会受到 SLA 的限制并有相应的信用赔付。你的模型卡两者都没有。“已知局限性”被解读为你已经承认模型会出错的清单，客户的法律顾问会将其视为你对风险的承认以及你监控的义务。

这些解读都不是作者的本意。但对于一个从工程文化跨越到采购文化且没有翻译层的文档来说，这些解读都是合理的。模型卡的编写是为了告知研究人员关于行为的信息。而合同现在的编写则是针对模型卡的。两个团队都没有为这种交接做设计，且两个团队都会在各自的文档上签字，而没有意识到他们已经束缚了对方。

最令人痛苦的版本是基准测试结果。三月份发布的一份列出某项评估套件得分为 92% 的模型卡，到了十二月份就不再是同一个产物了——模型已经重新训练了两次，基准测试也更新了，得分不再具有可重复性。但合同仍然引用最初的模型卡，客户仍然基于一个从未打算作为保证的数字在运作。当他们的审计员要求提供你达到所述性能的证据时，工程团队诚实的回答——“我们在六个月前就更换了那个评估指标”——听起来就像是在逃避。

双交付物规范

解决方法是停止让研究交付物承担合同职能，并将合同性质的工作作为一份独立文档来编写。

一份技术模型卡（Model Card）应留在它该在的地方：放在模型索引中，置于开发者门户之后，以构建该模型的团队口吻编写。它为工程受众描述行为、局限性、评估方法、训练数据摘要以及已知的失败模式。它的职责是帮助下游开发者做出正确的集成决策。它被允许诚实地反映局限性，因为它的读者知道如何阅读研究性文章。

一份独立的供应商尽职调查包才是提交给采购部门的交付物。其中的声明由法务编写或由法务共同编写。其中的每一项承诺都有明确定义的范围、通知机制、补救路径，并在适当情况下设有责任上限。它解决了采购评审人员真正关心的问题：数据保留窗口、处理区域、审计权、子处理者名单、安全认证、弃用通知期、事件通知 SLA，以及包括输出内容在内的补偿范围和退出协助。除非基准测试分数配有保证达标的条件以及未达标时的补救措施，否则它不应包含这些分数。

加载中…