Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 4 Current »

This article describes how ModelOp Center enables model versioning for all types of models.

Table of Contents

Introduction

ModelOp Center provides comprehensive versioning for all models under management, inclusive of versioning of all items that compose a model. For each version of a model, ModelOp Center takes a snapshot of all the elements that are part of the Standard Model Definition within ModelOp Center’s Production Model Inventory, such that you have long-term audibility and reproducibility.

Details

All of the elements of the Standard Model Definition are versioned using ModelOp Center’s Model Manager micro service, and for external artifacts (e.g. Model Source Code), are backed by your preferred enterprise-standard versioning tooling.

For example:

  • Model Source Code → backed by Git (all git-compliant systems: Github, Bitbucket, Gitlab, etc.)

  • Model Attachments → backed by standard artifact repositories (such as S3, Artifactory, etc.)

  • Metadata & Other Elements → backed and versioned by ModelOp Center’s Model Manager

Model Snapshots

Behind the scenes, ModelOp Center’s data model creates a new model snapshot that is an immutable copy of all the elements (or references to the elements) that compose that model at a given point in time. These snapshots are persisted in perpetuity for long term auditability. For more details about the ModelOp Center metadata and data model, see Model Metadata Details.

To Create a New Model Snapshot

A new model version is created when a User “submits” a model for productionization. This can be done via the ModelOp Center UI or the Jupyter or RStudio plugins.

Create Version via the ModelOp Center UI

  1. From the Production Model Inventory, open the specific model that you would like to snapshot. Select the “Create Snapshot” button from the top right.

2. Optionally, add a Name and Description for the snapshot. Most important, add the same “Model Service Tag” that was added to the requisite Runtimes (see above). This will ensure that the MLC will know the correct Runtimes to which the model should be deployed throughout the life cycle.

  1. Example: add a “cc-fraud” Model Service Tag to the snapshot.

3. Optionally suggest the Runtime Type OR the specific Runtimes that will be used by the model during its life cycle, or simply allow the MLC to find the best runtime for the model.

4. Optionally add any monitors (called “associated models”)

5. Review the Snapshot details. When ready, select “Create Snapshot”.

6. The snapshot details page will be opened with all of the details provided during the create snapshot process.

7. Additionally, the requisite Model Life Cycle will automatically begin orchestrating all of the steps necessary to operationalize the model. This includes deployment of the model as REST into the designated ModelOp runtimes or the best matching available ModelOp runtime. The details of the model life cycle can be seen in the “Model Life Cycle” section of the snapshot page.

8. Note, model life cycle updates and any errors in the model life cycle execution will be populated in the “Notifications” pane of the home page. As well, depending on the environment configuration, Jira and/or ServiceNow tickets may also be raised in the event of an issue. Granular logs can be found in the “MLC Manager” docker logs, which typically are configured to write to ELK or a similar enterprise log aggregation and visualization capability.

Create Version via the Jupyter Plugin

To create a new version via the Jupyter Plugin, please see the “Submit a Model” section of the Submit Model Version using Jupyter.

Create Version via the RStudio Plugin

To create a new version via the RStudio Plugin, please see the “Submit a Model” section of the Submit Model Version using RStudio.

Related Articles

  • No labels