Model Cards / Datasheets：AI 文档化与治理证据
Model Cards 和 Datasheets 的原理，是把模型和数据从黑箱资产变成有上下文的治理对象。Model Card 说明模型用途、限制、评估和风险边界；Datasheet 说明数据集的动机、组成、收集、标注、预处理、授权、维护和禁用范围。二者共同回答：这个 AI 资产是在什么条件下构造和验证的。
Model Cards / Datasheets for Datasets / AI Documentation 解读
本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Model Cards for Model Reporting | https://arxiv.org/abs/1810.03993 | 理解模型用途、限制、指标、伦理考虑和透明度报告（论文 2018-10） |
| Datasheets for Datasets | https://arxiv.org/abs/1803.09010 | 理解数据集动机、组成、收集、预处理、用途、分发和维护（论文 2018-03） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将文档化放入 trustworthy AI governance（AI RMF 1.0 发布 2023-01） |
| NIST GenAI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 将 GenAI 系统的模型、数据、评测、风险证据组织成治理闭环（NIST AI 600-1，2024-07） |
核心导读
Model Cards 和 Datasheets 的原理，是把模型和数据从黑箱资产变成有上下文的治理对象。Model Card 说明模型用途、限制、评估和风险边界；Datasheet 说明数据集的动机、组成、收集、标注、预处理、授权、维护和禁用范围。二者共同回答：这个 AI 资产是在什么条件下构造和验证的。
它们的价值不是多写两张合规模板，而是把模型、数据、用途、限制、评估和责任边界变成可审查证据。未来的团队需要知道一个系统适合什么、不适合什么、评估过哪些场景、没覆盖哪些群体、版本升级后要重跑哪些 eval、事故发生时如何追溯当时的模型、数据、prompt、RAG index、工具和人工操作。
在企业 AI 架构中，文档化应扩展为 evidence graph：Dataset Card、Model Card、System Card、Eval Report、Release Memo、Monitoring Report 和 Incident Report 相互连接。金融零售系统尤其不能把文档当上线前补材料；它必须随数据、模型、政策、评测、监控和退役策略持续更新。文档的边界也要明确：它记录和暴露治理证据，不会替代实际控制、评测门禁或责任人决策。
1. 这两篇工作的共同问题
AI 系统经常以“模型效果不错”进入讨论，但严肃业务真正需要知道的是：
- 这个模型是为哪些用途设计的？
- 哪些用途明确不适合？
- 用什么数据训练和评估？
- 对哪些群体、语言、渠道、场景表现不好？
- 谁负责维护？
- 版本变化后需要重新评估什么？
- 出问题时如何追溯当时的模型、数据和配置？
Model Cards 解决模型说明问题。Datasheets 解决数据集说明问题。它们共同反对一种低成熟度状态：模型和数据像黑箱资产一样流转，使用者只看到名字和指标，看不到边界。
在金融零售 AI 中，这不是文档洁癖，而是生产系统的基本条件。模型和数据如果没有用途边界、评估证据和维护责任，就无法支撑上线、审计、监管问询、事故复盘和未来替换。
2. Model Card 的本质：模型的使用说明书和风险边界
Model Card 不是宣传页，也不是模型注册表里的一行 metadata。它应该回答“这个模型在什么条件下被证明过、还没被证明过、不能被使用”。
核心内容可以组织为：
| 模块 | 要回答的问题 |
|---|---|
| Model details | 模型名称、版本、供应商、架构、许可证、部署形态 |
| Intended use | 允许的业务用途、用户、输入输出 |
| Out-of-scope use | 明确禁止的用途 |
| Training / adaptation | 基础模型、微调、偏好优化、RAG 或工具增强 |
| Evaluation | 用哪些场景、数据、指标评估过 |
| Limitations | 已知失败模式、适用边界和未知风险 |
| Ethical / legal considerations | 公平性、隐私、歧视、消费者保护、IP、合规 |
| Operational requirements | 监控、fallback、人审、版本升级、退出策略 |
对 foundation model 来说，Model Card 说明模型本身。对企业系统来说，更重要的是 System Card：模型只是系统的一部分，还要说明 RAG、prompt、工具、policy engine、guardrail、human review 和监控。
3. Datasheet 的本质：数据资产的来龙去脉
Datasheets for Datasets 的关键思想是：数据集不是自然存在的真理集合，而是人以某种目的、方式和限制构造出来的资产。
一个 dataset datasheet 应覆盖：
| 模块 | 要回答的问题 |
|---|---|
| Motivation | 为什么创建这个数据集 |
| Composition | 包含什么样本、标签、字段、群体和时间范围 |
| Collection process | 如何收集，谁参与，是否有同意或合同 |
| Preprocessing | 清洗、去重、脱敏、过滤、标注和转换方式 |
| Labeling | 标注指南、标注员、仲裁机制、一致性 |
| Recommended use | 适合训练、评估、监控还是分析 |
| Prohibited use | 哪些用途不应使用 |
| Distribution | 访问权限、许可、地域、共享限制 |
| Maintenance | 更新频率、owner、版本、废弃策略 |
在 GenAI 时代，还要扩展到：
- eval dataset card。
- prompt dataset card。
- preference dataset card。
- red-team dataset card。
- synthetic data card。
- RAG corpus card。
如果没有 datasheet，团队很难解释为什么某次模型升级后特定客户群体表现变差，也难以证明测试集是否覆盖真实风险。
4. 为什么文档化是架构能力
很多团队把 Model Card 和 Datasheet 看成上线前补材料。这个理解太浅。
高成熟度 AI 文档化应该嵌入系统生命周期：
Use Case Definition
-> Data Discovery
-> Dataset Card
-> Model/System Design
-> Model/System Card
-> Evaluation Evidence
-> Release Decision
-> Monitoring
-> Incident Review
-> Version Update / Retirement
文档不是最后生成的 PDF，而是贯穿生命周期的 evidence graph。
| 文档资产 | 连接对象 |
|---|---|
| Dataset card | 数据来源、标签、授权、偏差、覆盖范围 |
| Model card | 模型版本、用途、限制、评估结果 |
| System card | RAG、工具、prompt、guardrail、人审和监控 |
| Eval report | 场景、指标、结果、失败模式 |
| Release memo | 风险接受、限制范围、上线条件 |
| Monitoring report | 生产表现、drift、投诉、override、成本 |
| Incident report | 触发条件、根因、影响、修复和再验证 |
如果这些资产彼此脱节，文档越多反而越难维护。好的架构会让证据自动从 registry、CI/CD、eval runner、observability 和 workflow 中流出，而不是靠人工复制粘贴。
5. 金融零售案例：Credit Policy RAG System Card
一个“信贷政策助手”不应只有模型名称。它至少需要一张 System Card。
| 部分 | 内容示例 |
|---|---|
| Intended use | 帮助员工解释当前信贷政策、准备客户沟通和内部审批材料 |
| Not intended | 不得自动审批贷款，不得承诺结果，不得替代 adverse action notice |
| Data / corpus | 政策文档、产品手册、操作流程、法务批准话术 |
| Retrieval boundary | 只检索当前有效版本；过期政策只用于历史解释 |
| Model behavior | 必须引用来源；政策冲突时拒答并升级 |
| Evaluation | 政策问答、版本冲突、拒答边界、客户解释清晰度 |
| Human oversight | 外发内容必须由员工确认，高风险问题升级合规 |
| Monitoring | 无引用回答率、过期引用率、员工覆盖、投诉信号、成本 |
| Retirement | 政策库重大变更或模型供应商变更时重新认证 |
这张卡的价值不是好看，而是把“这个助手能做什么、不能做什么、依据什么、如何失效”说清楚。
6. 金融零售案例：AML Eval Dataset Card
AML Copilot 的 eval set 如果没有 datasheet，很容易被误用。
一张高质量 eval dataset card 应说明：
| 部分 | 内容示例 |
|---|---|
| Motivation | 评估 AML case summarization、typology reasoning 和 evidence completeness |
| Composition | SAR cases、non-SAR cases、不同产品、地区、客户类型、typology |
| Source | 历史脱敏 case、synthetic cases、专家构造 edge cases |
| Labeling | typology labels、required evidence、narrative quality rubric |
| Sensitive handling | PII 脱敏、访问控制、最小化字段 |
| Known gaps | 新型诈骗、低频 typology、跨境复杂网络样本不足 |
| Recommended use | regression eval、model comparison、prompt change gate |
| Prohibited use | 不得作为生产 SAR 决策训练的唯一依据 |
| Maintenance | 每季度加入新 typology 和 incident-derived samples |
这能防止 eval 被误读。例如模型在这个 dataset 上得分高，只能说明它覆盖了这些 typology 和数据分布，不能证明它能处理所有金融犯罪模式。
7. 文档化如何影响产品和架构决策
Model Cards 和 Datasheets 的最大价值，是把隐藏假设变成显性决策。
| 文档发现 | 可能触发的决策 |
|---|---|
| 训练数据没有覆盖某地区客户 | 限制上线地区或增加评估样本 |
| 模型不稳定处理政策版本冲突 | 增加版本过滤、拒答和人工升级 |
| eval set 缺少投诉语气复杂样本 | 补充 golden set 后再 release |
| 供应商不披露关键数据来源 | 降低用途风险等级或选择替代方案 |
| 数据保留期不支持当前用途 | 修改产品流程或不落地长期记忆 |
| 监控无法捕获某类危害 | 增加 telemetry 和人工抽检 |
这也是为什么它们适合系统学习：它们不是模板，而是发现系统边界和风险假设的工具。
8. 常见误读
| 误读 | 更准确的理解 |
|---|---|
| Model Card 是模型供应商提供就够了 | 企业还需要自己的 System Card，说明组合架构和业务用途 |
| Datasheet 只适合训练数据 | eval set、RAG corpus、preference data、synthetic data 都需要说明 |
| 文档写完就完成治理 | 文档必须随版本、数据、评估和监控持续更新 |
| 指标高就不需要说明限制 | 指标越高越要说明在哪些场景高，在哪些场景未知 |
| 文档化会拖慢交付 | 缺少边界说明会让上线、审计、事故复盘和模型替换更慢 |
9. 学习验证
读完这两篇后，最好的练习不是背模板，而是为一个真实 AI 系统写一套 evidence pack。
建议整理三份轻量文档：
| 文档 | 重点 |
|---|---|
| Dataset Card | 数据来源、覆盖范围、标签、限制、维护 |
| System Card | 用途、禁用范围、模型/RAG/工具、人审、监控 |
| Release Evidence Summary | eval 结果、失败模式、风险接受、上线限制 |
判断自己是否真正掌握，可以问三句话：
- 未来另一个团队能否只看文档就知道这个系统不能用于什么？
- 出现事故时，能否追溯当时使用的模型、数据、prompt、工具和评估证据？
- 模型或数据版本升级时，能否判断哪些场景必须重新评估？
如果答案是否定的，文档还只是静态说明，不是可治理的 AI 系统证据。
SOTA 检查 (2026-07-01)
- Model Card 框架本身仍成立，但主流实践已升级为 System Card：Mitchell et al.（2018-10）定义的模块结构（intended use / out-of-scope / evaluation / limitations）仍是行业模板底座；前沿实验室现役文档已是系统级——Anthropic Claude 4 System Card 与 OpenAI GPT-5.5 System Card（2026-04-24 更新版）均覆盖部署上下文、usage policy、安全缓解、人类监督要求和上线后监控承诺，与本篇第 2 节「企业更需要 System Card」的判断完全一致。
- 文档从自愿最佳实践变成了监管强制项：EU AI Act 的 GPAI 义务已于 2025-08-02 开始适用；GPAI Code of Practice 终版 2025-07-10 发布（含标准化 Model Documentation Form，即事实上的官方 Model Card 模板），欧盟 AI Office 的训练数据公开摘要模板 2025-07-24 发布（存量 GPAI 模型宽限至 2027-08-02）。注意：Annex III 高风险系统义务经 Digital Omnibus（2026-05-07 确认）已推迟至 2027-12-02，不要再用旧的 2026-08 时间线。
- 2025-2026 合规评估暴露的典型缺口正是本篇强调的点：只报聚合指标、不做按人群/语言/场景的分解（第 7 节），以及文档上线后不再随模型/政策/安全发现更新的「静态文档」（第 4 节 evidence graph）——post-market monitoring 义务实质上要求 living documentation，自动化生成 model card（从 registry/CI/eval runner 流出证据）成为 2026 年落地方向。
- Datasheet 正在机器可读化：Croissant（JSON-LD 元数据格式，论文 arXiv 2403.19546，2024-03）已被 Hugging Face、Kaggle、OpenML 三大仓库集成（合计 40 万+ 数据集自动生成 Croissant 元数据），并成为 NeurIPS 等会议新数据集投稿的提交要求——本篇第 3 节的 datasheet 模块正从「人读文档」变为「可校验的数据打包契约」。
- NIST 线仍是现役治理框架且在扩展：AI RMF 1.0（2023-01）+ GenAI Profile NIST AI 600-1（2024-07 定稿，12 个 GenAI 风险类、200+ 建议行动）未被替代；NIST 于 2026-04-07 又发布了关键基础设施 AI RMF Profile 的概念说明，框架族在按领域扩 profile 而非推倒重来。
- 不随版本过时的框架性结论：intended use / out-of-scope / 已知缺口 / 维护责任四要素、「数据集是被构造的资产而非自然真理」、以及「文档是贯穿生命周期的 evidence graph 而非上线前补的 PDF」——这三点在 2026 年的监管文本和实验室实践中只被强化，没有被替代。