如果你的团队正在把模型、RAG 或 Agent 工作流交给客户、内部业务方或合规团队评审，先不要只交一份 README。按 2026-05-29 NVIDIA Developer Blog 对 Model Card Generator（MCG）toolkit 的说明，发布材料至少要覆盖用途、数据来源、评测、限制和安全等方向（后文逐一展开）。
先用本文清单整理现有仓库和产品文档；如果团队能进入 NVIDIA MCG 早期采用路径，再用 MCG 从 GitHub、GitLab、Hugging Face、网页或上传文件中生成 Model Card++ 草稿；如果暂时不能使用 MCG，就用同样字段做人工发布审查。本文只覆盖模型和 AI 应用发布前的文档准备，不判断你的产品是否满足某项法律要求。
先判断你是否真的需要模型卡
满足下面任一条件，就应该在发布前准备模型卡，而不是等客户或法务来追问：
| 场景 | 为什么需要模型卡 |
|---|---|
| 对外发布模型、插件、RAG 服务或 Agent 能力 | 下游用户需要知道用途、限制、数据边界和风险 |
| 用 Dify 或 OpenClaw 编排多个模型和工具 | 单个 prompt 已经解释不了系统行为，得写清楚每个环节谁负责什么 |
| 用 Qdrant 等向量库接入私有知识库 | 检索数据来源、更新时间和权限边界会影响输出可信度 |
| 面向企业采购、安全评审或受监管行业 | 采购、风险和合规角色通常不会只看 demo 效果 |
| 模型或工作流会影响用户决策 | 需要写清适用范围、失败场景和人工复核点 |
不需要把模型卡写成论文。它的任务是让评审者能回答三个问题：这个 AI 系统应该用在哪里，不应该用在哪里，出问题时谁能复查依据。
按 MCG 的结构准备输入材料
NVIDIA 在 2026-05-29 的技术博客中把 MCG 描述为一个容器化流水线：接收 URL 或文件，经过 Ingestion → Extraction → Rendering 三步，生成 Model Card++ 格式的模型卡草稿。它支持的输入包括 GitHub、GitLab、Hugging Face、公开网页，以及 ZIP、PDF、DOCX、Markdown 文件。
在写发布材料前，先把输入按下面方式整理。即使不用 MCG，整理过的材料人工审查时不用反复翻仓库。
| 输入材料 | 应该放什么 | 不要混进什么 |
|---|---|---|
| README / 产品说明 | 模型用途、非目标场景、快速开始、依赖条件 | 宣传口号、未核验 benchmark、泛泛愿景 |
| 配置文件 | 模型名、版本、检索库、工具权限、环境变量名 | 密钥、token、客户数据样例 |
| 评测记录 | 数据集名称、日期、指标定义、失败样例分类 | 只写“效果很好”的结论 |
| 数据说明 | 训练、微调、检索或示例数据的来源和更新时间 | 无授权数据、无法追溯的临时文件 |
| 风险记录 | 已知误用、拒答边界、人工升级条件 | 只把风险写成“用户自行负责” |
如果仓库里没有这些材料，先不要指望任何生成器“自动补齐事实”。NVIDIA 的同一篇博文明确提到，文档稀疏时，MCG 会标出 “not found” 或 “information not available”，让团队自己补。
写第一版模型卡：先覆盖 10 个字段
第一版不追求漂亮，先让每个字段能被复查。建议在发布 PR、客户试点或模型替换前，用下面 10 个问题逐项填写。
| 字段 | 必须回答的问题 | 示例写法 |
|---|---|---|
| 对象 | 这是模型、RAG 应用、Agent，还是其中一个组件？ | “客服工单分类 Agent 的意图识别组件” |
| 版本 | 当前发布对应哪个模型、prompt、索引或工作流版本？ | “workflow v0.8，检索索引 2026-05-28 快照” |
| 预期用途 | 允许用于什么任务？ | “把内部工单初分到 12 个队列，供人工客服确认” |
| 禁止用途 | 不应该用于什么任务？ | “不得自动关闭投诉，不得生成退款承诺” |
| 许可与使用条款 | 模型、数据、权重和输出内容受哪些许可证或内部条款限制？ | “基础模型按供应商条款使用；内部检索资料禁止外部分发” |
| 输入数据 | 会读取哪些用户数据、企业数据或公开数据？ | “仅读取工单正文、标签和最近 3 条客服回复” |
| 输出边界 | 输出是建议、草稿、标签还是自动动作？ | “只输出建议队列和置信度，不直接改状态” |
| 评测指标 | 用哪些数据集、日期和指标证明当前版本可用？ | “2026-05-28 抽样 500 条工单，记录准确率、召回率和人工改判率” |
| 失败模式 | 什么时候容易错？ | “短文本、混合语言、含附件但正文很少的工单” |
| 复核责任 | 谁审、看什么、如何回滚？ | “客服主管每周抽样 100 条；错分超过阈值暂停自动分流” |
这里的示例是示意写法，不代表真实测试结果。真正上线时，版本、数据集、阈值和复核频率必须来自你的内部记录。
把 Bias、Explainability、Privacy、Safety 单独拆开
NVIDIA 博文说 MCG 会在 overview 之外生成四类 Model Card++ subcards：Bias、Explainability、Privacy、Safety & Security。这四块不要合并成一句“我们重视安全”，因为不同角色会看不同问题。
| 子卡 | 发布前要填的最低信息 | 停止发布信号 |
|---|---|---|
| Bias | 哪些用户群体、语言、地区或业务类别可能覆盖不足 | 评测集中没有目标用户，但页面宣称适用于所有用户 |
| Explainability | 用户或审核员能看到哪些依据、引用或日志 | 只能看到最终答案，无法复查检索来源或工具调用 |
| Privacy | 输入、日志、向量库和导出文件的保留范围 | 用真实个人数据做 demo，但没有删除和权限方案 |
| Safety & Security | 工具权限、拒答规则、越权防护和人工升级点 | Agent 可以调用高风险工具，却没有审批或回滚 |
对 AI 工具站读者来说，最常见的坑是只给最终效果截图，不给失败和限制说明。模型卡的价值正好相反：它让销售、采购、开发和风控能在同一份材料里看到边界。
用生成器时，把“未找到”当作待办，不当作错误
根据 NVIDIA 2026-05-29 博文，MCG 在标准测试中会读取文档、配置和代码，用检索增强生成流程抽取字段；当没有足够依据时，它会直接暴露缺口。原文给出的对照是：移除 .pdf、.md、.txt 文档后，平均 completion rate 从 91% 降到 61%；在更严格的可核验字段口径下，准确率为 28%，低于标准测试中的 76% accuracy。
- 不要把生成稿直接发布：生成结果只能进入人工审查队列。
- 优先修源文档：如果字段缺失，先补 README、评测记录、数据说明，而不是只改生成后的 Markdown。
- 保留“不知道”：无法核验的字段宁可写“未验证”，不要改成确定结论。
- 记录生成时间：模型卡应该写明基于哪个仓库版本、文档日期和审查日期。
- 把缺口变成发布门槛：隐私、权限、数据来源、人工复核缺一项时，不进入客户试点。
如果你使用的是 Dify、OpenClaw 这类编排工具，也可以把同样逻辑放到工作流发布 checklist 里：每次更新 prompt、工具权限、检索库或模型版本，都要重新扫一遍模型卡字段。
什么时候不该急着引入 MCG
截至 2026-05-30，NVIDIA 博文中的 MCG 路径更像早期采用或合作接入，而不是所有团队立即可用的公开 SaaS 按钮。文章的 “Getting started” 部分让有意者联系 Trustworthy AI 团队；同时提到可先使用 Trustworthy AI GitHub 仓库中的开源 Model Card++ templates 和 AI transparency cards。
因此，下面几种情况先用人工清单更合适：
- 你的模型或 Agent 还在一天几次改 prompt，版本还没定下来。
- 团队没有统一的评测记录，生成器只能反复产出 “information not available”。
- 仓库里混有密钥、客户材料或不该交给文档生成流程读取的文件。
- 合规目标还没定义清楚，模板字段可能很快重写。
- 当前任务只是内部原型，风险边界可以通过小范围人工复核控制。
等到输入材料稳定、评测口径固定、权限和数据边界清楚，再接入自动生成器——到时候生成器能填准的字段明显更多。
发布前 30 分钟复核清单
在模型、RAG 或 Agent 工作流交给外部评审前，逐项检查：
- 模型卡写明了核验日期、模型/工作流版本、文档来源。
- 预期用途和禁止用途都能被非开发同事读懂。
- 数据来源、更新时间、权限边界、许可限制没有留空。
- 输出动作和人工复核责任分开写清楚。
- Bias、Explainability、Privacy、Safety & Security 四块都有最低说明。
- 所有数字、指标和效果描述能追溯到真实评测或官方来源。
- “未找到”“未验证”“不适用”的字段没有被包装成确定结论。
- 客户、销售或运营材料没有做出模型卡无法支持的承诺。
如果这 8 项有 2 项以上无法回答，发布准备还没完成——先补材料，不是先补文档格式。
FAQ
MCG 能替团队完成合规审查吗？
不能。NVIDIA 的博文把 MCG 定位为自动化和标准化模型文档的 toolkit，可以帮助生成 Model Card++ 草稿和暴露缺失信息。法律、行业合规和客户合同仍需要你的法务、安全和业务负责人审查。
没有训练自己的模型，只做 RAG 或 Agent，也要写模型卡吗？
如果只是个人原型，可以不用完整模型卡。但只要它会读取企业数据、影响用户决策，或交给客户试点，就应该至少写一份简化版。RAG 的检索库、工具权限和人工复核点同样会影响风险。
生成器输出了很多 “not found”，是不是工具不好用？
不一定。按 NVIDIA 2026-05-29 博文的描述，MCG 在资料不足时不会猜，会直接把缺失信息暴露出来。对发布流程来说，这是有用信号——你应该补源文档，别粉饰输出。
模型卡应该放在哪里？
对开发团队，建议放在仓库的 docs/ 或发布目录，并在 PR 模板里要求更新。对客户评审，可以导出为 Markdown、PDF 或内部知识库页面。关键是和模型版本、数据快照、prompt 或工作流版本绑定。