model-card

模型卡：记录用途、限制、训练数据、评估结果和许可证

补充说明

模型卡（Model Card）是模型的“说明书 + 风险披露”，让使用者知道模型能做什么、不能做什么、在什么数据上训练、评估结果如何、有哪些偏见和限制、许可证和联系方式。它不是营销页，也不是技术报告；重点是让下游能判断“这个模型是否适合我的场景”。

模型卡应随模型版本更新，并和模型注册表/制品库关联。对外发布的模型卡还要写清楚禁止用途、已知失败模式、评估数据分布和人类监督建议。系统卡（System Card）则描述包含模型在内的完整应用，两者不要混。

常用示例

模型卡模板：
1. 模型概览：名称、版本、类型、参数量、输入/输出
2. 预期用途：适用场景、目标用户、部署形态
3. 非预期用途：明确禁止/不推荐的场景
4. 训练数据：来源、规模、时间范围、语言、许可、清洗
5. 评估：基准、业务评测、指标、评测集版本、局限
6. 限制与风险：幻觉、偏见、领域外、长上下文、多语言
7. 伦理与安全：敏感数据、内容安全、人工监督
8. 许可与联系方式：许可证、使用条款、责任方
9. 变更记录：版本、日期、变更点

# 在模型注册表中保存结构化元数据
model_version = {
    "name": "support-llm",
    "version": "1.3.0",
    "base_model": "Qwen2.5-7B-Instruct",
    "intended_use": ["internal-support-qa"],
    "not_for": ["medical-diagnosis", "legal-advice"],
    "eval": {"dataset": "support-eval-v2", "score": 0.82},
    "license": "internal-only",
    "owner": "ai-platform",
    "card_url": "https://internal/models/support-llm/1.3.0/card",
}

发布检查：
- 模型卡是否和当前权重/配置一致？
- 评估数据是否含训练集泄漏？
- 限制和禁止用途是否写清楚？
- 许可证是否允许目标部署方式？
- 是否有负责人和问题反馈渠道？

易错点与排错

• 写成营销文案：只写“性能领先”，不写限制和失败模式；模型卡的价值在风险披露。
• 评估结果没有出处：不写评测集、版本、指标和运行日期；结果不可复现。
• 训练数据一笔带过：来源、许可、语言、时间范围和清洗策略都要写；否则无法判断合规风险。
• 不更新版本：模型更新了但模型卡没变；版本、评估和限制要同步。
• 混淆模型卡和系统卡：模型卡描述模型，系统卡描述完整应用；RAG/Agent 的风险要在系统卡里写。
• 禁止用途写成空话：要具体到场景和判断标准，否则无法执行。
• 许可证与实际部署冲突：研究许可、非商用许可、数据许可都要核对。
• 没有责任人：出问题时找不到维护者；写 owner 和反馈渠道。

相关命令

• model-registry — 模型版本与别名管理。
• mlflow — 实验跟踪与模型注册。
• huggingface-cli — 模型卡与仓库元数据。
• dvc — 数据与模型版本。
• eval-dataset — 评估数据与结果。

参考链接

• Model Cards 论文
• Hugging Face 模型卡文档
• Google Model Card Toolkit

读完自测

合上页面，先回答，再展开对照。

1. 模型卡和系统卡的区别是什么？
2. 模型卡里为什么必须写“非预期用途”和限制？
3. 评估结果需要记录哪些信息才可复现？