企业模型卡片与版本治理实践

模型卡片与版本治理，指的是给每个在用的模型留一份结构化档案，并让每一次变更都能被追溯。这套东西的价值在平时体现不出来，在出事那天集中体现 —— 问题是那天往往没有时间从头整理

为什么需要模型卡片

企业使用的模型通常经历多个版本，训练数据、对齐策略与部署配置都可能不同。如果没有统一记录，后续会遇到三类说不清的问题：这次结果是用哪个版本产出的、当时为什么做了这个改动、要回退到哪一版才安全。

模型卡片的字段清单

• 用途与适用场景：这个模型用来做什么，以及明确不适用于什么。
• 数据来源与范围：训练、微调与检索分别用到了哪些数据，范围边界在哪里。
• 评测结果：用哪套评测集、在什么条件下测得，结论是什么。
• 已知限制：容易出错的题型、覆盖不到的业务口径、以及实验中发现的反例。
• 安全与合规考量：许可、数据边界、留痕要求与保留期限。
• 责任人：谁批准上线、谁负责日常维护、出问题时找谁。

字段不必一开始就齐全，但「用途与适用场景」「已知限制」「责任人」这三项建议从第一版就写。它们最难在事后补，也最能在争议时直接解决问题。

四类版本要分别留痕

• 权重版本：模型本身的版本与来源，包括量化或压缩后的产物。
• 配置版本：推理参数、提示模板与后处理规则，它们同样影响输出。
• 依赖环境：推理框架、驱动与相关组件的版本组合。
• 评测基线：每次变更时使用的评测集版本与结果，作为对比依据。

四类里最容易被忽略的是配置与依赖。很多「模型变差了」的判断，最后追溯到的是提示模板改了一句话，或者框架升级改变了默认参数。

业务版本：同一权重，不同口径

同一份权重在不同业务场景下可能采用不同的提示模板与后处理规则。这些组合也应当被记录，否则当同样的输入在不同场景得到不同答案时，没人能解释差异来自哪里。

审计场景怎么用

• 回答「当时用了哪个模型」：按时间点查版本记录，而不是靠回忆。
• 回答「基于什么数据」：从卡片的数据来源字段出发，再配合调用记录。
• 回答「做了什么判断」：把配置版本与评测基线一起看，还原决策依据。
• 回答「为什么改」：变更记录里的原因字段，是审计最常追问的内容。

常见缺口

• 只记权重不记配置：同一权重换了提示模板之后，输出差异会被误判为模型波动。
• 评测基线缺失：没有留档的对照结果，改完之后无法判断是变好还是变差。
• 已知限制长期为空：要么是没人记录，要么是把「没测过」写成了「没有限制」。

验收

• 每个在用模型都有卡片，且卡片有最近一次更新记录。
• 任意一次历史输出都能对应到具体的权重、配置与依赖版本。
• 变更记录包含原因，而不是只有时间和执行人。
• 回退路径被实际演练过，并记录了所需时间。