模型发布页上最醒目的内容常是参数量、榜单名次和几个很高的分数。真正准备把模型接进客服、文档处理或内容审核时，这些数字还缺几块说明。它用什么数据训练，测试题是什么语言，哪些人群和场景测过，出错时通常怎样错，都要有人写下来。
我把 2019 年提出 Model Cards 的论文和 Hugging Face 当前的模型卡文档对了一遍。模型卡是一份随模型发布的短文档。论文作者希望它说明预期用途、评测过程和不同条件下的表现，尤其关注与实际应用有关的人群子组与交叉子组。这样的写法会让一个平均分多出上下文。
一张总分会藏掉差异
假设一个文本分类模型在英文测试集上得分很高，公司准备拿它处理中文售后记录。总分没有回答中文是否参加测试，也没有说明口语、错别字和行业缩写会怎样影响结果。模型卡若把数据集、语言、任务和分组结果列出来，使用者能很快看见证据缺在哪儿。
分组结果在高影响场景更要紧。原始论文把文化、地域、性别和肤色等条件列为例子，也建议在相关时检查年龄与性别这类交叉组合。这里没有一张放之四海而皆准的表。做语音识别的人会关心口音和噪声，做图片检测的人会关心光线与设备，企业自己的验收项还要跟任务走。
Hugging Face 的文档把模型卡落成了模型仓库中的 README.md。正文应写模型说明、预期用途、限制与偏差、训练参数、所用数据集和评测结果。顶部的 YAML 元数据还能标记许可证、语言、数据集和基础模型，让使用者知道这个文件由哪个模型微调、量化或合并而来。
这些字段也有边界。模型卡由发布者填写，缺少一栏不会自动阻止模型运行，一份写得很满的文档也不能替代独立测试。团队仍要拿自己的输入跑一遍，并保存模型版本、提示词、判定标准和失败样本。模型更新以后，旧卡片里的结果也要跟着复查。
采购和上线时怎样看
先看预期用途是否覆盖眼前工作。一个为摘要训练的模型，不能因为通用榜单高，就直接承担合同条款判断。再看评测数据与真实输入有多远。语言、长度、格式和行业内容只要换了一项，原有分数的解释范围就会缩小。
限制部分要能导向动作。写着“可能产生不准确信息”太宽，团队很难据此验收。更有用的说明会指出哪些输入没有充分测试、哪些输出需要人工复核、许可证允许怎样使用，以及模型继承了哪个基础版本。发现空白以后，把它们变成上线前的小样本测试。
我的判断很朴素。模型卡适合当成一次技术交接。它把发布者已经知道的条件摆在一页里，让后来的人少猜几次。采购方仍要补自己的验收记录，并把模型卡与实际版本一起保存。以后有人问当时为何选这个模型，至少能找到当时看过什么、哪些风险已经知道。