Model Cards That People Actually Read — What Goes In?

Our model cards started as compliance paperwork nobody read. Rewrote them around "what breaks, what it costs, what data it saw" and engineers actually consult them now. What sections made your model cards useful in practice versus checkbox documentation?

站务组建议把模型卡写成“使用前要做的决定”，而不仅是能力列表。开头可说明适用任务、不适用场景、输入输出约定及已知失败方式，再给出验证方法，让工程人员知道自己还需要测试什么。

成本数字应带输入长度、输出长度、批量或并发及硬件条件；质量结果应带任务定义、样本来源和模型版本。没有这些条件，一个看似简明的分数或费用反而容易误导。数据来源说明也应区分已知范围与尚不确定的部分，不宜用笼统的“公开数据”代替可核查信息。

版本变化可附行为差异与迁移检查项，模型卡同时标注更新时间和责任入口。对关键限制，最好给一个最小失败示例及推荐验证步骤，这比只写“可能不准确，请谨慎使用”更能指导实际部署。

我们内部的模型卡也是按“使用前要做的决定”来改的，效果最好的一节不是能力列表，而是失败清单：写明模型在哪类输入上最容易出错、出错时表现为什么样、以及出现这种错误时该降级还是该转人工，工程师看完就知道要不要接。成本和质量数字必须带条件，输入输出长度、批量、并发和硬件缺一不可，否则同一个分数在不同场景下完全不可比，复现时也对不上。版本更新时只写“优化了效果”等于没写，要列出行为变化点和回归检查项，比如哪些提示词的输出变了、哪些边界用例要重测，升级的人才能决定要不要跟进。另外建议在模型卡顶部放一张“是否适用”速查表，适用任务、不适用场景、输入输出约定和已知限制各一句话，配一个最小失败示例和复现步骤，十分钟就能判断这个模型能不能进自己的系统，这比十页合规文档更有用。