模型注册表：AI 团队的模型档案馆

可视化演示

展示ML模型注册流程、版本控制树与生命周期阶段管理，交互切换查看模型注册表核心功能。

注册表：模型的中央档案馆

走进一座几千册藏书的图书馆，管理员能在五分钟内找到任意一本书，靠的不是过人的记忆力，而是那套编目系统：每本书有唯一索书号、有状态牌、有借阅台账。AI 团队训练出的模型数量爆炸式增长后，靠「我记得文件在谁机器上」来管理，迟早要出大乱子。

模型注册表就是 AI 团队的编目系统，是 MLOps 中专门负责模型生命周期的中心化服务。它自己不训练模型，也不跑推理，只回答三个问题：团队有哪些模型？每个模型有哪些版本？某个版本现在处于什么阶段？把这三个问题答清楚，模型资产就不再是散落各处的孤岛。

「中心化」是注册表的灵魂。所有团队的模型制品统一交到注册表登记，版本号、元数据、状态全部有唯一事实源，避免了「线上用的模型在你电脑上」这种经典事故。注册表通常提供 REST API 与命令行工具，让 CI/CD 流水线可以像访问数据库一样编程读写。

用图书馆的话说：一本书只有「书本体、版次、编目卡、状态牌」四者齐备，才算真正入馆；一个模型只有 artifact、version、metadata、state 四要素都登记在册，才算被团队正式管理起来。

Artifact：一本书的完整构成

图书管理员眼中的「一本书」，从来不只是装订起来的那叠纸，还包括排版源文件、封面设计稿、印刷参数。AI 团队口中的「模型 artifact」同样是组合体——只有一个 .pkl 权重文件是远远不够的。

一个完整的模型 artifact 至少包含四部分：权重文件、配置文件、预处理逻辑、推理封装代码。权重文件是模型的「血肉」，配置文件记录了网络结构和超参数，预处理逻辑决定了输入数据如何被喂给模型，推理封装则定义了模型对外提供服务的接口。少了任何一块，模型都无法真正部署。

权重文件动辄几百 MB，不适合塞进 Git 仓库，通常放进对象存储，注册表只保存一个「指针」引用。而配置、预处理逻辑、推理代码这些文本型内容，应当像普通代码一样进入 Git 仓库做版本管理。Artifact 与代码同管，流水线才能从一次提交里复现出完整可用的模型。

这就像出版社要重印一本书，光有印刷正文还不够，还得有封面设计稿和排版参数。AI 工程师拿到一份权重却不知道预处理怎么写，模型就像一个没有排版稿的文稿，别人根本没法把它「印出来」跑上生产线。

版本：图书的版次规则

图书馆上架新书时，最怕遇到「书名相同、作者相同、内容却不一样」的两本书。图书靠版次区分，模型靠版本号区分。

业界通行的是语义化版本：MAJOR.MINOR.PATCH。主版本号在不兼容变更时递增——比如模型的输入输出协议改了，老代码调用会出错；次版本号在向后兼容的新功能增加时递增——比如新增了一个可选的预测接口；补丁版本号在向后兼容的缺陷修复时递增——比如修复了某些边界条件下的数值溢出。三个数字合起来，就是一个版本的「身份证号」。

版本还有一个更关键的纪律：不可变性。一旦某个版本被打上 PROD 状态并被线上使用，它的 artifact 和元数据就进入只读状态。发现模型有问题，正确的做法是训练一个新版本并递增版本号，而不是偷偷修改线上文件。这个纪律保证了「线上跑的东西」与「注册表登记的东西」永远一致，也是后续审计追溯的前提。

图书的版本纪律同样严格：一本再版的《史记》，出版社会在版权页清清楚楚标注「第 3 版第 2 次印刷」，绝不会悄悄把第 1 版的内容改掉再当新版卖。模型的版本号规则和不可变约束，守住的正是「凡是发布的，都可追溯」这条底线。

状态：一本书的借阅之旅

图书馆里的每本书都有流动状态：采编中、可借、在馆、下架。模型的旅程同样是一条状态链。

模型注册表定义了四个标准状态：DRAFT（起草）、STAGED（候选）、PROD（生产）、ARCHIVED（归档）。刚训练出来的模型进入 DRAFT，相当于初稿入库；通过离线评估后晋升为 STAGED，相当于候选图书进入待上架区；经过在线验证和业务审批后进入 PROD，正式对外提供服务；当新版本完全接管流量后，旧版本进入 ARCHIVED，只保留档案不再更新。

状态不是想跳就能跳的，每一次流转都必须满足门禁并经过授权。从 DRAFT 到 STAGED 需要评估报告达标；从 STAGED 到 PROD 需要人工审批和发布窗口；从 PROD 到 ARCHIVED 需要确认线上流量已全部切走。状态机把这些规则固化下来，任何非法跳转都会被系统拒绝。

书从采编到上架再到下架，每一步背后都有管理员的签收记录；模型从 DRAFT 到 ARCHIVED，每一步背后都有门禁结果和审批日志。状态机让模型的生命周期像图书借阅流程一样清晰可控。

元数据：图书的编目卡

图书馆的编目卡上写着索书号、作者、出版社、入库时间，管理员扫一眼就知道这本书的基本身份。模型注册表里的元数据就是模型的编目卡。

一份完整的模型元数据 schema 通常包含四大类。第一类基础信息：模型 ID、名称、版本号、所有者、创建时间，回答「这是什么模型」；第二类训练来源：训练数据集版本、特征工程代码提交号、训练脚本 commit、基础镜像，回答「这个模型怎么来的」；第三类评估指标：AUC、准确率、延迟、模型大小等，回答「这个模型好不好」；第四类治理属性：审批人、合规标签、数据敏感级、发布记录，回答「谁批准它上线的」。

Schema 设计要在团队早期就统一。字段命名、类型、必填约束一旦确定，各团队就按同一套规范登记。如果每个团队各写各的字段名，注册表就会退化成一堆无法检索的散乱标签，编目系统也就名存实亡了。

没有编目卡的书等于不在馆藏体系里，读者检索不到它；没有元数据的模型也等于不存在，别人无法检索、无法评估、无法放心使用。把编目卡写清楚，模型资产才能被整个组织共享。

CI/CD：自动还书流水线

现代图书馆的采购系统已经高度自动化：出版社的书目数据进入系统，自动查重、自动生成索书号、自动安排上架。模型注册表与 CI/CD 的集成，正是要把这种自动化复制到模型管理里。

在集成流水线中，训练任务跑完后会自动调用注册表 API 登记新版本，并自动上传评估指标，这就是自动注册。流水线的下一个阶段把 artifact 推进到 STAGED，触发预生产环境自动部署验证，这就是环境同步——部署平台不再手动拷贝文件，而是按注册表中的版本号拉取制品。最关键的是发布门禁：流水线只有在注册表确认「评估指标达标 + 审批通过」后，才允许版本晋级。

自动化流水线让「人找书」变成「书自动归位」。训练脚本一结束，注册表自动登记；指标一达标，状态自动流转；部署环境一就绪，版本自动拉取。每个环节都有自动记录，大大减少了人为传文件和口头通知带来的失误。

溯源：台账里的前世今生

档案馆最珍贵的往往不是书本身，而是那本记录了每册书来龙去脉的台账：这本书什么时候进馆、经谁手、被谁借阅过。模型注册表里的血缘关系，就是模型的台账。

血缘关系（lineage）记录了一个模型从数据到部署的完整依赖链：训练用的数据集版本、特征工程代码、训练脚本、评估报告、部署环境。一旦线上模型出现问题，工程师顺着血缘链就能快速定位是数据回流出错、特征代码变更还是训练配置漂移。可复现性则依赖元数据的完整程度——只要把血缘链上的每一个版本号和提交号重新拉出来，就能在另一个环境里复现出相同的模型。

权限与审计是治理的最后一环：谁能注册新版本、谁能批准晋级、谁能归档旧版本，都要有明确的权限控制；每一次状态变更和审批操作都要写入审计日志。无痕操作在模型治理里是不可接受的，因为审计需求往往来自外部合规而不是内部自觉。

台账越清晰，出问题时的排查就越快。模型注册表把血缘链条完整记录下来，相当于给每个模型建立了一份永不丢失的档案卷宗——谁来了、谁走了、谁改动过，白纸黑字，一目了然。

AI 应用场景

Python 演示

class ModelRegistry:    """极简模型注册表: 版本登记 + 元数据 + 状态流转 + 血缘记录."""     def __init__(self):        self.store = {}        self.gc_count = 0     def register(self, name, version, artifact_path, owner):        if name not in self.store:            self.store[name] = {}        if version in self.store[name]:            raise ValueError("version already exists: " + version)        self.store[name][version] = {            "artifact_path": artifact_path,            "owner": owner,            "state": "DRAFT",            "meta": {},            "lineage": [],        }     def add_source(self, name, version, data_key, data_version):        record = self.store[name][version]        record["lineage"].append((data_key, data_version))     def set_metric(self, name, version, metric, value):        record = self.store[name][version]        record["meta"][metric] = value     def promote(self, name, version, target_state):        record = self.store[name][version]        allowed = {            "DRAFT": ["STAGED"],            "STAGED": ["PROD"],            "PROD": ["ARCHIVED"],        }        if record["state"] not in allowed:            raise ValueError("unknown state: " + record["state"])        if target_state not in allowed[record["state"]]:            raise ValueError("illegal transition: " + record["state"] + " -> " + target_state)        record["state"] = target_state     def list_versions(self, name):        result = []        for version, record in self.store[name].items():            result.append((version, record["state"]))        return sorted(result)     def get_lineage(self, name, version):        record = self.store[name][version]        chain = " -> ".join(k + "@" + v for k, v in record["lineage"])        return chain or "(no lineage)"  if __name__ == "__main__":    reg = ModelRegistry()    reg.register("churn_cls", "v1.0.0", "artifacts/churn_v1.zip", "alice")    reg.add_source("churn_cls", "v1.0.0", "churn_train", "2024-01-10")    reg.set_metric("churn_cls", "v1.0.0", "auc", 0.871)    reg.promote("churn_cls", "v1.0.0", "STAGED")    reg.promote("churn_cls", "v1.0.0", "PROD")    print(reg.list_versions("churn_cls"))    print(reg.get_lineage("churn_cls", "v1.0.0"))

1. self.store[name][version] = { ... }每个版本对应一条馆藏记录，包含路径、负责人和初始状态。
2. "state": "DRAFT"新登记的版本一律从起草状态开始，不允许直接注册为生产状态。
3. record["lineage"].append((data_key, data_version))记录训练依赖的数据版本，构建血缘链的起点。
4. allowed[record["state"]]状态机以字典定义合法流转方向，DRAFT 只能到 STAGED。
5. raise ValueError("illegal transition")非法跳转直接拒绝，把状态纪律写进系统逻辑。
6. sorted(result)按版本号排序输出清单，模拟注册表的版本列表查询。

常见误区

面试题