qModel 算法模型平台开源版 v1.3.0 发布：上线模型审批功能，构建安全规范的模型接入机制
qModel算法模型平台开源版v1.3.0正式发布！新增模型审批功能，API模型和Python模型提交发布后，将进入模型审核列表，由相关人员执行通过或驳回操作，使模型创建与正式上线之间增加一个明确的审核节点。
---
## 从“创建后直接发布”，到“审核后再上线”
在模型数量较少、使用范围有限时，模型开发、验证和发布可能由同一位人员完成。
这种方式流程较短，但当模型类型和使用人员逐渐增加后，一些问题也会随之出现：
- 模型是否完成必要验证缺少统一确认；
- 发布申请和审核结果没有集中入口；
- 模型上线原因依赖口头沟通；
- 模型被拒绝后，申请人不清楚具体原因；
- 后续核查时，难以快速确认申请人和申请时间；
- 开发与发布缺少相对独立的流程节点。
从模型管理角度看，真正需要控制的并不只是模型文件或接口本身，还包括：
**由谁提交、为什么发布、何时申请、是否通过，以及未通过的原因是什么。**
模型审批功能的作用，就是在模型新增与正式上线之间增加一个审核环节，使发布过程更加清晰。
---
## 01 新增模型审批列表，集中查看发布申请
qModel算法模型开源版新增模型审批功能，为待发布模型提供集中审核入口。
在模型审核列表中，可以查看：
- 模型名称；
- 模型编码；
- 申请人；
- 申请时间；
- 审核状态；
- 申请理由；
- 拒绝理由；
- 通过与驳回操作。
这些信息分别对应模型发布过程中的几个关键问题：
| 审批信息 | 主要作用 |
|------------------|------------------------------------|
| 模型名称、模型编码 | 确认本次申请对应的具体模型 |
| 申请人、申请时间 | 了解模型由谁提交、何时提交 |
| 审核状态 | 查看当前申请所处阶段 |
| 申请理由 | 说明模型上线的背景和使用需求 |
| 拒绝理由 | 记录申请未通过的具体原因 |
| 通过、驳回 | 对当前发布申请进行处理 |
通过独立的审核列表，相关人员不需要在多个页面之间反复查找，即可集中查看模型发布申请及其处理情况。
---
## 为什么需要记录申请理由？
模型名称和编码只能说明“申请发布的是哪个模型”，但无法说明“为什么需要发布”。
例如，同一个模型可能用于：
- 新业务功能验证；
- 原有模型版本替换；
- 内部算法服务调用；
- API接口能力接入；
- Python模型运行测试；
- 阶段性项目交付。
如果申请人只点击发布而不说明用途，审核人员就很难结合实际场景判断当前申请是否合理。
申请理由可以帮助审核人员了解模型上线背景，为审批判断提供基础信息。
需要注意的是，申请理由本身不能替代模型测试报告、性能验证结果或安全检查材料。对于要求较高的模型应用场景，仍需要结合企业内部制度补充相应的验证依据。
---
## 02 模型创建与模型上线分开管理
新增模型审批功能后，模型创建和模型上线不再是同一个动作。
在当前流程中，用户可以先在模型中心新增模型，完成基础信息配置；需要正式发布时，再提交上线申请。
这种方式将模型生命周期中的两个阶段区分开来：
- **模型创建阶段**：主要完成模型信息登记、API接入或Python模型新增等工作。
- **模型发布阶段**：模型准备进入正式使用前，提交发布申请，并等待审核结果。
这样可以避免“模型已经创建”被直接理解为“模型已经可以上线使用”。
从流程上看，模型中心负责模型的新增和管理，模型审核列表则负责发布申请的处理，两者共同形成从模型接入到上线的基本链路。
---
## 03 哪些模型会进入审批流程？
根据当前功能说明，在模型中心新增以下两类模型后，点击发布按钮，模型将进入审核列表：
- **API模型；**
- **Python模型。**
也就是说，模型新增完成后不会因为保存操作直接上线，而是需要由用户主动提交发布。
提交后，审核人员可以在模型审核列表中查看对应申请，并根据模型信息和申请理由决定通过或驳回。
当前功能所覆盖的具体模型类型、字段和操作范围，应以正式版本页面及产品文档为准。
---
## 04 模型审批如何操作？
qModel开源版的模型审批流程可以概括为：
**新增模型 → 提交发布 → 进入审核列表 → 执行审核 → 通过后上线或驳回后退回**
下面按照实际操作顺序展开。
### 第一步：在模型中心新增模型
用户进入模型中心，根据实际需求**新增API模型或Python模型**。
在这一阶段，主要完成模型基础信息和相关配置。
模型创建完成后，可以先进行必要检查，确认模型信息、接口参数或运行配置是否符合当前使用要求。
### 第二步：点击发布，提交审核申请
模型准备上线时，用户在模型中心点击发布按钮。
提交后，该模型会出现在模型审核列表中。
此时，模型已经进入发布审核流程，但尚未完成正式上线。
审核人员可以在**列表中查看模型名称、模型编码、申请人、申请时间、审核状态和申请理由等信息**。
### 第三步：查看模型申请信息
审核人员进入模型审核列表，找到需要处理的申请。
审核时可以重点确认：
- 当前申请对应的是哪个模型；
- 模型由谁提交；
- 提交时间是否与项目计划一致；
- 申请理由是否完整；
- 模型是否已完成内部要求的验证；
- 当前模型是否适合进入使用环境。
模型审批页面提供的是审核入口和基础申请信息。具体审核标准仍需要结合企业内部的模型管理要求确定。
### 第四步：选择通过或驳回
审核人员可以在操作列中选择：
- **通过**
- **驳回**
两种操作分别对应不同的处理结果。
### 第五步：通过后完成二次确认
审核人员点击通过后，系统会弹出二次确认窗口。
确认无误后点击确定，模型即可完成上线。
增加二次确认，可以减少因误操作直接通过申请的情况。不过，二次确认主要属于操作层面的提醒，并不能替代上线前的模型验证。
### 第六步：驳回时填写具体原因
当审核人员认为当前模型暂不适合上线时，可以点击驳回。
系统会弹出驳回窗口，审核人员需要填写拒绝原因。提交后，本次模型上线申请将被阻止。
驳回原因可以用于说明：
- 模型信息不完整；
- 接口或运行配置需要调整；
- 申请理由不清晰；
- 模型尚未完成必要验证；
- 当前版本不适合上线；
- 需要补充其他审批材料。
对于申请人而言，明确的驳回理由比简单显示“未通过”更便于后续修改和重新提交。
---
## 05 审批功能带来的流程变化
模型审批功能并没有改变模型本身的开发方式，而是调整了模型从创建到上线的过程。
- **让模型发布有独立入口**
过去，模型创建和发布可能集中在同一个操作流程中。
增加审批后，发布申请会进入独立列表，由审核人员集中处理，使“模型管理”和“上线审核”形成相对清晰的分工。
- **让申请信息更容易核查**
模型审核列表展示申请人、申请时间、申请理由和审核状态等信息，为后续了解发布过程提供基础记录。
当需要确认某个模型为何上线、由谁发起申请时，可以先从审核列表中查找相关信息。
这里所说的可核查，主要基于当前列表展示的申请和审核字段，并不等同于完整的模型审计体系。
- **让驳回结果更加明确**
只显示审批未通过，往往无法帮助申请人判断下一步应该修改什么。
驳回时填写具体原因，可以将审核意见反馈给申请流程，减少申请人与审核人员之间的重复沟通。
- **让模型创建与正式使用之间增加缓冲**
模型完成接入后，可以先保持在未正式上线的阶段。
当模型信息、使用场景和验证结果准备完成后，再提交发布申请。这为测试、调整和正式使用之间增加了一个流程缓冲区。
---
## 写在最后
qModel开源版新增模型审批功能，在API模型和Python模型的创建与正式上线之间增加了审核环节。
这项功能解决的主要不是模型如何训练或运行，而是模型如何经过一个相对清晰的流程进入使用环境。
它不能替代模型测试、安全检查和效果评估，但可以将原本依赖人工沟通的发布确认过程，转化为可查看、可处理的审核流程，为后续模型管理提供基础。
---
原文链接：[点击查看](https://www.oschina.net/news/478332)
---
## 从“创建后直接发布”，到“审核后再上线”
在模型数量较少、使用范围有限时，模型开发、验证和发布可能由同一位人员完成。
这种方式流程较短，但当模型类型和使用人员逐渐增加后，一些问题也会随之出现：
- 模型是否完成必要验证缺少统一确认；
- 发布申请和审核结果没有集中入口；
- 模型上线原因依赖口头沟通；
- 模型被拒绝后，申请人不清楚具体原因；
- 后续核查时，难以快速确认申请人和申请时间；
- 开发与发布缺少相对独立的流程节点。
从模型管理角度看，真正需要控制的并不只是模型文件或接口本身，还包括：
**由谁提交、为什么发布、何时申请、是否通过，以及未通过的原因是什么。**
模型审批功能的作用，就是在模型新增与正式上线之间增加一个审核环节，使发布过程更加清晰。
---
## 01 新增模型审批列表，集中查看发布申请
qModel算法模型开源版新增模型审批功能，为待发布模型提供集中审核入口。
在模型审核列表中，可以查看：
- 模型名称；
- 模型编码；
- 申请人；
- 申请时间；
- 审核状态；
- 申请理由；
- 拒绝理由；
- 通过与驳回操作。
这些信息分别对应模型发布过程中的几个关键问题：
| 审批信息 | 主要作用 |
|------------------|------------------------------------|
| 模型名称、模型编码 | 确认本次申请对应的具体模型 |
| 申请人、申请时间 | 了解模型由谁提交、何时提交 |
| 审核状态 | 查看当前申请所处阶段 |
| 申请理由 | 说明模型上线的背景和使用需求 |
| 拒绝理由 | 记录申请未通过的具体原因 |
| 通过、驳回 | 对当前发布申请进行处理 |
通过独立的审核列表，相关人员不需要在多个页面之间反复查找，即可集中查看模型发布申请及其处理情况。
---
## 为什么需要记录申请理由？
模型名称和编码只能说明“申请发布的是哪个模型”，但无法说明“为什么需要发布”。
例如，同一个模型可能用于：
- 新业务功能验证；
- 原有模型版本替换；
- 内部算法服务调用；
- API接口能力接入；
- Python模型运行测试；
- 阶段性项目交付。
如果申请人只点击发布而不说明用途，审核人员就很难结合实际场景判断当前申请是否合理。
申请理由可以帮助审核人员了解模型上线背景，为审批判断提供基础信息。
需要注意的是，申请理由本身不能替代模型测试报告、性能验证结果或安全检查材料。对于要求较高的模型应用场景，仍需要结合企业内部制度补充相应的验证依据。
---
## 02 模型创建与模型上线分开管理
新增模型审批功能后，模型创建和模型上线不再是同一个动作。
在当前流程中，用户可以先在模型中心新增模型，完成基础信息配置；需要正式发布时，再提交上线申请。
这种方式将模型生命周期中的两个阶段区分开来：
- **模型创建阶段**：主要完成模型信息登记、API接入或Python模型新增等工作。
- **模型发布阶段**：模型准备进入正式使用前，提交发布申请，并等待审核结果。
这样可以避免“模型已经创建”被直接理解为“模型已经可以上线使用”。
从流程上看，模型中心负责模型的新增和管理，模型审核列表则负责发布申请的处理，两者共同形成从模型接入到上线的基本链路。
---
## 03 哪些模型会进入审批流程？
根据当前功能说明，在模型中心新增以下两类模型后，点击发布按钮，模型将进入审核列表：
- **API模型；**
- **Python模型。**
也就是说，模型新增完成后不会因为保存操作直接上线，而是需要由用户主动提交发布。
提交后，审核人员可以在模型审核列表中查看对应申请，并根据模型信息和申请理由决定通过或驳回。
当前功能所覆盖的具体模型类型、字段和操作范围，应以正式版本页面及产品文档为准。
---
## 04 模型审批如何操作？
qModel开源版的模型审批流程可以概括为：
**新增模型 → 提交发布 → 进入审核列表 → 执行审核 → 通过后上线或驳回后退回**
下面按照实际操作顺序展开。
### 第一步：在模型中心新增模型
用户进入模型中心，根据实际需求**新增API模型或Python模型**。
在这一阶段，主要完成模型基础信息和相关配置。
模型创建完成后，可以先进行必要检查，确认模型信息、接口参数或运行配置是否符合当前使用要求。
### 第二步：点击发布，提交审核申请
模型准备上线时，用户在模型中心点击发布按钮。
提交后，该模型会出现在模型审核列表中。
此时，模型已经进入发布审核流程，但尚未完成正式上线。
审核人员可以在**列表中查看模型名称、模型编码、申请人、申请时间、审核状态和申请理由等信息**。
### 第三步：查看模型申请信息
审核人员进入模型审核列表，找到需要处理的申请。
审核时可以重点确认：
- 当前申请对应的是哪个模型；
- 模型由谁提交；
- 提交时间是否与项目计划一致；
- 申请理由是否完整；
- 模型是否已完成内部要求的验证；
- 当前模型是否适合进入使用环境。
模型审批页面提供的是审核入口和基础申请信息。具体审核标准仍需要结合企业内部的模型管理要求确定。
### 第四步：选择通过或驳回
审核人员可以在操作列中选择：
- **通过**
- **驳回**
两种操作分别对应不同的处理结果。
### 第五步：通过后完成二次确认
审核人员点击通过后，系统会弹出二次确认窗口。
确认无误后点击确定，模型即可完成上线。
增加二次确认，可以减少因误操作直接通过申请的情况。不过，二次确认主要属于操作层面的提醒，并不能替代上线前的模型验证。
### 第六步：驳回时填写具体原因
当审核人员认为当前模型暂不适合上线时，可以点击驳回。
系统会弹出驳回窗口，审核人员需要填写拒绝原因。提交后，本次模型上线申请将被阻止。
驳回原因可以用于说明：
- 模型信息不完整；
- 接口或运行配置需要调整；
- 申请理由不清晰；
- 模型尚未完成必要验证；
- 当前版本不适合上线；
- 需要补充其他审批材料。
对于申请人而言，明确的驳回理由比简单显示“未通过”更便于后续修改和重新提交。
---
## 05 审批功能带来的流程变化
模型审批功能并没有改变模型本身的开发方式，而是调整了模型从创建到上线的过程。
- **让模型发布有独立入口**
过去，模型创建和发布可能集中在同一个操作流程中。
增加审批后，发布申请会进入独立列表，由审核人员集中处理，使“模型管理”和“上线审核”形成相对清晰的分工。
- **让申请信息更容易核查**
模型审核列表展示申请人、申请时间、申请理由和审核状态等信息，为后续了解发布过程提供基础记录。
当需要确认某个模型为何上线、由谁发起申请时，可以先从审核列表中查找相关信息。
这里所说的可核查，主要基于当前列表展示的申请和审核字段，并不等同于完整的模型审计体系。
- **让驳回结果更加明确**
只显示审批未通过，往往无法帮助申请人判断下一步应该修改什么。
驳回时填写具体原因，可以将审核意见反馈给申请流程，减少申请人与审核人员之间的重复沟通。
- **让模型创建与正式使用之间增加缓冲**
模型完成接入后，可以先保持在未正式上线的阶段。
当模型信息、使用场景和验证结果准备完成后，再提交发布申请。这为测试、调整和正式使用之间增加了一个流程缓冲区。
---
## 写在最后
qModel开源版新增模型审批功能，在API模型和Python模型的创建与正式上线之间增加了审核环节。
这项功能解决的主要不是模型如何训练或运行，而是模型如何经过一个相对清晰的流程进入使用环境。
它不能替代模型测试、安全检查和效果评估，但可以将原本依赖人工沟通的发布确认过程，转化为可查看、可处理的审核流程，为后续模型管理提供基础。
---
原文链接：[点击查看](https://www.oschina.net/news/478332)
评论
暂无评论。