qModel算法模型平台开源版v1.3.0正式发布！新增模型审批功能，API模型和Python模型提交发布后，将进入模型审核列表，由相关人员执行通过或驳回操作，使模型创建与正式上线之间增加一个明确的审核节点。

从“创建后直接发布”，到“审核后再上线”

在模型数量较少、使用范围有限时，模型开发、验证和发布可能由同一位人员完成。

这种方式流程较短，但当模型类型和使用人员逐渐增加后，一些问题也会随之出现：

• 模型是否完成必要验证缺少统一确认；
• 发布申请和审核结果没有集中入口；
• 模型上线原因依赖口头沟通；
• 模型被拒绝后，申请人不清楚具体原因；
• 后续核查时，难以快速确认申请人和申请时间；
• 开发与发布缺少相对独立的流程节点。

从模型管理角度看，真正需要控制的并不只是模型文件或接口本身，还包括：

模型审批功能的作用，就是在模型新增与正式上线之间增加一个审核环节，使发布过程更加清晰。

01 新增模型审批列表，集中查看发布申请

qModel算法模型开源版新增模型审批功能，为待发布模型提供集中审核入口。

在模型审核列表中，可以查看：

• 模型名称；
• 模型编码；
• 申请人；
• 申请时间；
• 审核状态；
• 申请理由；
• 拒绝理由；
• 通过与驳回操作。

这些信息分别对应模型发布过程中的几个关键问题：

通过独立的审核列表，相关人员不需要在多个页面之间反复查找，即可集中查看模型发布申请及其处理情况。

为什么需要记录申请理由？

模型名称和编码只能说明“申请发布的是哪个模型”，但无法说明“为什么需要发布”。

例如，同一个模型可能用于：

• 新业务功能验证；
• 原有模型版本替换；
• 内部算法服务调用；
• API接口能力接入；
• Python模型运行测试；
• 阶段性项目交付。

如果申请人只点击发布而不说明用途，审核人员就很难结合实际场景判断当前申请是否合理。

申请理由可以帮助审核人员了解模型上线背景，为审批判断提供基础信息。

需要注意的是，申请理由本身不能替代模型测试报告、性能验证结果或安全检查材料。对于要求较高的模型应用场景，仍需要结合企业内部制度补充相应的验证依据。

02 模型创建与模型上线分开管理

新增模型审批功能后，模型创建和模型上线不再是同一个动作。

在当前流程中，用户可以先在模型中心新增模型，完成基础信息配置；需要正式发布时，再提交上线申请。

这种方式将模型生命周期中的两个阶段区分开来：

• 模型创建阶段：主要完成模型信息登记、API接入或Python模型新增等工作。
• 模型发布阶段：模型准备进入正式使用前，提交发布申请，并等待审核结果。

这样可以避免“模型已经创建”被直接理解为“模型已经可以上线使用”。

从流程上看，模型中心负责模型的新增和管理，模型审核列表则负责发布申请的处理，两者共同形成从模型接入到上线的基本链路。

03 哪些模型会进入审批流程？

根据当前功能说明，在模型中心新增以下两类模型后，点击发布按钮，模型将进入审核列表：

• API模型；
• Python模型。

也就是说，模型新增完成后不会因为保存操作直接上线，而是需要由用户主动提交发布。

当前功能所覆盖的具体模型类型、字段和操作范围，应以正式版本页面及产品文档为准。

04 模型审批如何操作？

qModel开源版的模型审批流程可以概括为：

下面按照实际操作顺序展开。

第一步：在模型中心新增模型

用户进入模型中心，根据实际需求新增API模型或Python模型。

在这一阶段，主要完成模型基础信息和相关配置。

模型创建完成后，可以先进行必要检查，确认模型信息、接口参数或运行配置是否符合当前使用要求。

第二步：点击发布，提交审核申请

模型准备上线时，用户在模型中心点击发布按钮。

提交后，该模型会出现在模型审核列表中。

此时，模型已经进入发布审核流程，但尚未完成正式上线。

审核人员可以在列表中查看模型名称、模型编码、申请人、申请时间、审核状态和申请理由等信息。

第三步：查看模型申请信息

审核人员进入模型审核列表，找到需要处理的申请。

审核时可以重点确认：

• 当前申请对应的是哪个模型；
• 模型由谁提交；
• 提交时间是否与项目计划一致；
• 申请理由是否完整；
• 模型是否已完成内部要求的验证；
• 当前模型是否适合进入使用环境。

模型审批页面提供的是审核入口和基础申请信息。具体审核标准仍需要结合企业内部的模型管理要求确定。

第四步：选择通过或驳回

审核人员可以在操作列中选择：

• 通过
• 驳回

两种操作分别对应不同的处理结果。

第五步：通过后完成二次确认

审核人员点击通过后，系统会弹出二次确认窗口。

确认无误后点击确定，模型即可完成上线。

增加二次确认，可以减少因误操作直接通过申请的情况。不过，二次确认主要属于操作层面的提醒，并不能替代上线前的模型验证。

第六步：驳回时填写具体原因

当审核人员认为当前模型暂不适合上线时，可以点击驳回。

系统会弹出驳回窗口，审核人员需要填写拒绝原因。提交后，本次模型上线申请将被阻止。

驳回原因可以用于说明：

• 模型信息不完整；
• 接口或运行配置需要调整；
• 申请理由不清晰；
• 模型尚未完成必要验证；
• 当前版本不适合上线；
• 需要补充其他审批材料。

对于申请人而言，明确的驳回理由比简单显示“未通过”更便于后续修改和重新提交。

05 审批功能带来的流程变化

模型审批功能并没有改变模型本身的开发方式，而是调整了模型从创建到上线的过程。

• 让模型发布有独立入口

过去，模型创建和发布可能集中在同一个操作流程中。

增加审批后，发布申请会进入独立列表，由审核人员集中处理，使“模型管理”和“上线审核”形成相对清晰的分工。

• 让申请信息更容易核查

模型审核列表展示申请人、申请时间、申请理由和审核状态等信息，为后续了解发布过程提供基础记录。

当需要确认某个模型为何上线、由谁发起申请时，可以先从审核列表中查找相关信息。

这里所说的可核查，主要基于当前列表展示的申请和审核字段，并不等同于完整的模型审计体系。

• 让驳回结果更加明确

只显示审批未通过，往往无法帮助申请人判断下一步应该修改什么。

驳回时填写具体原因，可以将审核意见反馈给申请流程，减少申请人与审核人员之间的重复沟通。

• 让模型创建与正式使用之间增加缓冲

模型完成接入后，可以先保持在未正式上线的阶段。

当模型信息、使用场景和验证结果准备完成后，再提交发布申请。这为测试、调整和正式使用之间增加了一个流程缓冲区。

写在最后

这项功能解决的主要不是模型如何训练或运行，而是模型如何经过一个相对清晰的流程进入使用环境。

它不能替代模型测试、安全检查和效果评估，但可以将原本依赖人工沟通的发布确认过程，转化为可查看、可处理的审核流程，为后续模型管理提供基础。