立场：当前模型卡片不足以支持开放权重基础模型的下游治理

# 当前模型卡片不足以支持开放权重基础模型的下游治理
来源：https://arxiv.org/html/2608.18086

###### 摘要
开放权重基础模型（OWFMs）的增长促使人工智能界重新评估有效的下游治理策略。尽管模型卡片已广泛作为模型仓库中的透明性工具，但现有框架往往未能充分告知下游开发者和用户关于OWFMs所带来的独特安全挑战。本文分析了Hugging Face上托管的500张模型卡片，认为有效的OWFMs治理需要一种多层次方法，整合三个互补组件：（i）模型卡片，（ii）可接受使用政策（AUPs），和（iii）许可协议。为支持这一观点，我们通过分析包含安全关键信息的模型卡片，识别了现有监管方法（包括模型来源、对齐来源和经观察的行为）留下的安全缺口。我们进一步认为，标准开源许可（OSLs）并不完全适用于OWFMs，并可能削弱AUPs的可执行性。基于这些观察，我们概述了将模型卡片、AUPs和许可协议演进为集成安全工具的方向，以实现更全面的治理框架，连贯整合信息、规范和法律维度。AI治理、基础模型、模型文档、开源AI、安全

## 1 引言
大多数开放基础模型属于开放权重模型而非开源模型，因为只有模型权重而非训练代码和数据被公开提供。开放权重基础模型（OWFMs）通常通过模型仓库（如Hugging Face）发布和分发，从而支持广泛的下游开发和部署。虽然开放性可以提高透明度、可复现性和创新，但它也扩大了超出上游开发者控制的下游滥用风险面，包括非国家行为者滥用等公共安全威胁（国家电信和信息管理局，2024年）。

应对这些挑战最重要的进展之一是Mitchell等人（2019年）在Google开发的模型卡片框架。他们加入Hugging Face后，该平台将模型卡片实现为一个带有包含模型元数据的YAML头的Markdown文件（Hugging Face，2025年）。实践中，模型卡片的实现主要强调性能特征的透明度，而涉及偏见、风险和局限性的部分，即使包含在标准模板中，也通常是可选的，并且往往不够完善（Mitchell等人，2019年；Oreamuno等人，2024年；Liang等人，2024年；Jiang等人，2023年）。此外，虽然欧盟AI法案（欧盟，2024年）和加利福尼亚州前沿人工智能透明法案（加利福尼亚州，2025年）等监管框架要求披露安全风险，但它们主要适用于超过特定训练计算阈值（分别为10^25 FLOPs和10^26整数OPs/FLOPs）的“前沿AI”模型。

图1：开放权重基础模型下游治理的三层方法。（左）现状：当前碎片化的系统，其中模型卡片侧重于性能而非安全性，AUPs经常缺失或无约束力，模型许可证通常与声明的使用限制相冲突。（右）目标：提出的统一框架整合三个互补层以实现更具弹性的下游安全控制：信息层（安全卡片）、规范层（标准化AUPs）和法律层（OWFM定制许可证）。然而，当前版本的模型卡片并不足够。虽然它们可以促进信息流动，但无法建立规范边界或在上游和下游行为者之间分配责任。为此，一些开发者引入了可接受使用政策（AUPs）来定义禁止或限制的下游用途。然而，文献质疑其实际有效性和合法性，指出（i）标准碎片化，（ii）私人行为者单方面制定规范，以及（iii）缺乏明确法律纳入时的可执行性弱（Klyman，2024年）。此外，AUPs通常缺失或在模型文档中规定不足，并且通常不具有法律约束力，除非纳入具有约束力的许可条款。AUPs的这一局限性因其与模型许可的潜在冲突而加剧。虽然大多数开发者在模型卡片中披露适用许可，但广泛使用的开源许可（OSLs），如Apache和MIT许可，在结构上并不适合OWFMs：它们既不适应基于使用的限制，也不反映模型重用、微调和重新分发的技术现实（Duan等人，2025年；McDuff等人，2024年；Contractor等人，2022年）。通过授予使用、修改和重新分发模型的广泛、无条件权利，宽松的OSLs几乎没有为下游使用限制留下理论空间。

基于此背景，本文提出以下问题：*OWFM开发者如何实施下游治理？现有机制表现出哪些局限性？当前框架应如何改革？*作为回应，本文提出通过三个层面加强OWFMs的下游治理：模型卡片（信息治理）、AUPs（规范治理）和模型许可（法律治理）。每一层通过不同的下游控制机制运作。将这些概念视为可互换的，或简单地将它们归入“透明度”之下，隐藏了它们的重要差异，并可能削弱有效治理。因此，本文呼吁：（i）在模型卡片中纳入明确的安全相关组件；（ii）开发标准化的AUP模板和实践；（iii）将现有OSLs演进为OWFM定制的许可方案，如图1所示。

本文做出以下贡献：
1.  调查现有模型文档实践，识别其安全缺口和局限性。
2.  为开放仓库引入安全卡片模板，整合来源披露、对齐来源和操作安全评估。
3.  提出一种替代的模型许可方案，将OWFM定制许可与AUPs整合，作为OSLs的替代方案。

## 2 模型文档实践
### 2.1 概述
在开放模型仓库中，模型卡片已成为向下游传递模型属性的主要工具。其主要作用是描述模型的能力、局限性和风险，支持透明度和标准化的研究交流。为了描述OWFM生态系统中普遍存在的文档实践，我们分析了Hugging Face上下载量最高的500个模型及其相关的模型卡片（截至2026年1月11日）。我们的分析特别检查了三个核心治理组件：（i）基于NIST（2024年）定义的分类法（完整列表见附录II）的模型卡片中安全相关关键词的出现情况，（ii）AUPs，和（iii）许可结构。尽管阿里巴巴（2025年）宣布了Qwen的使用政策，但我们将它排除在AUP计数之外，因为它在模型卡片或许可条款中未被引用。表1总结了这些工具在数据集中的普遍存在情况。

表1：顶级500个OWFMs中的治理工具存在情况。
| 工具类型 | 数量 | 百分比 |
| :--- | :--- | :--- |
| 模型卡片（任何形式） | 498 | 99.6% |
| 安全特定字段 | 376 | 75.2% |
| AUPs | 106 | 21.2% |
| 明确许可 | 425 | 85.0% |

图2：前500个下载量最高的模型中安全相关关键词的普遍性。每条柱代表文档中包含对应安全类别中至少一个关键词的模型数量，基于NIST生成式AI风险管理框架分类法。
图3：按供应商划分的安全相关关键词覆盖度（按模型数量排名前12的供应商）。堆叠柱显示每个关键词计数范围（0、1-5、6-10、11-20、21+）的模型数量。像meta（包括Llama和facebook OPT模型）和google这样的供应商表现出更高的关键词密度，而Qwen模型集中在较低频率范围，突出了披露实践的系统性差异。
图4：模型卡片嵌入的供应商级聚类。每个点代表一个模型，使用模型卡片文本的句子嵌入的PCA定位。颜色表示开发者所属，点的大小反映与治理相关的关键词总数。k-means聚类产生了几个不同的开发者级文档模式，而一组异构的其他开发者则广泛分散在嵌入空间中。

我们的研究揭示了当前OWFMs治理的几个缺陷：
- 普遍不完整：虽然99.6%的模型提供了模型卡片，但文档的质量和结构高度不均。只有75.2%包含安全特定字段，并且安全信息通常埋在通用的README文件中，而非作为结构化的、独立的披露呈现。
- AUPs：尽管明确许可很常见（适用于85.0%的模型），但AUPs仍然基本缺失，仅存在于21.2%。大多数模型依赖标准的、通常是宽松的OSLs，没有伴随的规范使用约束。
- 许可冲突：许可条款经常完全忽略安全考虑。

### 2.2 模型卡片
图2量化了每个安全关键词类别在模型卡片中的普遍性。三个最常见的类别是（i）信息安全（288个模型），（ii）CBRN信息或能力（256个模型），和（iii）有害偏见或同质化（183个模型）。这些安全关键词的存在与模型开发者身份的相关性比与流行度或技术特性的相关性更强。图3说明了不同供应商在安全和责任披露方面的系统性差异。来自特定开发者的模型，如Meta（Grattafiori等人，2024年）和Google，表现出更高的关键词密度，而其他如Qwen（Yang等人，2025年）则集中在较低频率范围。图4将模型卡片的句子嵌入投影到降维空间中进行可视化，揭示了由开发者归属而非模型采用或使用规模驱动的明显聚类模式。这些聚类表明文档风格是由供应商特定的实践、惯例和内部治理规范塑造的。

如图5所示，在多个回归规范中，模型流行度与文档深度没有有意义的关联（R² < 0.01）。值得注意的是，广泛采用的模型，如DeepSeek（Guo等人，2025年）、Mistral（Jiang等人，2023年）和gpt-oss（OpenAI，2025年），分布范围广泛，既出现在文档稀疏的模型中，也出现在文档更详尽的模型中。这种结构性的脱节表明，下载量无法为治理文档的完整性提供预测信号。

图5：模型流行度与治理文档深度之间的关系。每个点代表一个模型，x轴为总下载量（百万），y轴为与治理相关的关键词计数。多种函数形式的回归线均无解释力（R² < 0.01），暗示生态效用并不能预测文档质量。

在开放权重下游治理的背景下，当前模型卡片实践的两个局限性尤为突出：
- 非操作性安全声明：安全部分经常依赖高层次的免责声明（例如，“可能生成有害内容”），而没有指定评估协议、观察到的故障模式或安全性在对抗性条件下退化的情形。因此，这些声明难以复现或操作化，限制了它们在涉及现实滥用场景（如角色扮演框架或多轮升级）的风险评估中的效用。
- 缺失来源和影响披露：许多OWFMs通过合成数据生成、偏好模仿、蒸馏或AI中介反馈机制（例如，来自AI反馈的强化学习）受到上游系统的影响。然而，这些影响路径很少以标准化方式披露。这种遗漏产生了一个隐藏的*来源*问题：下游行为者无法判断模型的安全行为、拒绝风格或规范框架是否来自上游系统。他们也无法评估来自上游生成数据的依赖性或污染风险。

这些发现表明，治理文档目前既不是需求驱动的，也不是有机标准化的。相反，披露实践是由任意的开发者级选择决定的，导致生态系统中的信号碎片化且不可比。这种碎片化阻碍了下游行为者评估风险的能力，促使需要无论模型流行度或供应商身份如何，都能强制执行基本披露要求的机制。

### 2.3 AUPs
图6：前500个OWFMs中的治理工具流程。桑基图追踪每个模型在下载排名、安全关键词覆盖、开发者、许可证和AUP状态之间的流程。流程宽度表示模型数量，显示宽松的OSLs，特别是Apache 2.0和MIT，导致“无AUP”，而自定义许可证如Llama和Gemma则与AUP的存在相关。

虽然模型卡片作为下游用户的信息渠道，但AUPs通过规定模型可以或不可以如何使用来建立规范约束。如表2总结，主要OWFMs的AUPs通常分为两类：
- 整合条款：嵌入自定义许可证的政策，例如（i）集成到社区许可证中的AUPs（例如，Llama AUP），（ii）负责任AI许可证（RAILs）（例如，BigScience的BLOOM RAIL和OpenRAIL-M），和（iii）Cohere在其定制的CC-BY-NC 4.0下的可接受使用附录。
- 独立政策：规范性指南，