implementing-mlops

Name: implementing-mlops
Author: ancoleman

52installs59forks

How to install implementing-mlops?

ancoleman/ai-design-components/implementing-mlops

$npx -y skills add ancoleman/ai-design-components --skill implementing-mlops

Installs into the current project.

Summary

Strategic guidance for operationalizing machine learning models from experimentation to production. Covers experiment tracking (MLflow, Weights & Biases), model registry and versioning, feature stores (Feast, Tecton), model serving patterns (Seldon, KServe, BentoML), ML pipeline

Files · 1

View on GitHub

SKILL.md

1	# MLOps Patterns
2
3	Operationalize machine learning models from experimentation to production deployment and monitoring.
4
5	## Purpose
6
7	Provide strategic guidance for ML engineers and platform teams to build production-grade ML infrastructure. Cover the complete lifecycle: experiment tracking, model registry, feature stores, deployment patterns, pipeline orchestration, and monitoring.
8
9	## When to Use This Skill
10
11	Use this skill when:
12
13	- Designing MLOps infrastructure for production ML systems
14	- Selecting experiment tracking platforms (MLflow, Weights & Biases, Neptune)
15	- Implementing feature stores for online/offline feature serving
16	- Choosing model serving solutions (Seldon Core, KServe, BentoML, TorchServe)
17	- Building ML pipelines for training, evaluation, and deployment
18	- Setting up model monitoring and drift detection
19	- Establishing model governance and compliance frameworks
20	- Optimizing ML inference costs and performance
21	- Migrating from notebooks to production ML systems
22	- Implementing continuous training and automated retraining
23
24	## Core Concepts
25
26	### 1. Experiment Tracking
27
28	Track experiments systematically to ensure reproducibility and collaboration.
29
30	Key Components:
31	- Parameters: Hyperparameters logged for each training run
32	- Metrics: Performance measures tracked over time (accuracy, loss, F1)
33	- Artifacts: Model weights, plots, datasets, configuration files
34	- Metadata: Tags, descriptions, Git commit SHA, environment details
35
36	Platform Comparison:
37
38	MLflow (Open-source standard):
39	- Framework-agnostic (PyTorch, TensorFlow, scikit-learn, XGBoost)
40	- Self-hosted or cloud-agnostic deployment
41	- Integrated model registry
42	- Basic UI, adequate for most use cases
43	- Free, requires infrastructure management
44
45	Weights & Biases (SaaS, collaboration-focused):
46	- Advanced visualization and dashboards
47	- Integrated hyperparameter optimization (Sweeps)
48	- Excellent team collaboration features
49	- SaaS pricing scales with usage
50	- Best-in-class UI
51
52	Neptune.ai (Enterprise-grade):
53	- Enterprise features (RBAC, audit logs, compliance)
54	- Integrated production monitoring
55	- Higher cost than W&B
56	- Good for regulated industries
57
58	Selection Criteria:
59	- Open-source requirement → MLflow
60	- Team collaboration critical → Weights & Biases
61	- Enterprise compliance (RBAC, audits) → Neptune.ai
62	- Hyperparameter optimization primary → Weights & Biases (Sweeps)
63
64	For detailed comparison and decision framework, see [references/experiment-tracking.md](references/experiment-tracking.md).
65
66	### 2. Model Registry and Versioning
67
68	Centralize model artifacts with version control and stage management.
69
70	Model Registry Components:
71	- Model artifacts (weights, serialized models)
72	- Training metrics (accuracy, F1, AUC)
73	- Hyperparameters used during training
74	- Training dataset version
75	- Feature schema (input/output signatures)
76	- Model cards (documentation, use cases, limitations)
77
78	Stage Management:
79	- None: Newly registered model
80	- Staging: Testing in pre-production environment
81	- Production: Serving live traffic
82	- Archived: Deprecated, retained for compliance
83
84	Versioning Strategies:
85
86	Semantic Versioning for Models:
87	- Major version (v2.0.0): Breaking change in input/output schema
88	- Minor version (v1.1.0): New feature, backward-compatible
89	- Patch version (v1.0.1): Bug fix, model retrained on new data
90
91	Git-Based Versioning:
92	- Model code in Git (training scripts, configuration)
93	- Model weights in DVC (Data Version Control) or Git-LFS
94	- Reproducibility via commit SHA + data version hash
95
96	For model lineage tracking and registry patterns, see [references/model-registry.md](references/model-registry.md).
97
98	### 3. Feature Stores
99
100	Centralize feature engineering to ensure consistency between training and inference.
101
102	Problem Addressed: Training/serving skew
103	- Training: Features computed with future knowledge (data leakage)
104	- Inference: Features computed with only past data
105	- Result: Model performs well in training but fails in production
106
107	Feature Store Solution:
108
109	Online Feature Store:
110	- Purpose: Low-latency feature retrieval for real-time inference
111	- Storage: Redis, DynamoDB, Cassandra (key-value stores)
112	- Latency: Sub-10ms for feature lookup
113	- Use Case: Real-time predictions (fraud detection, recommendations)
114
115	Offline Feature Store:
116	- Purpose: Historical feature data for training and batch inference
117	- Storage: Parquet files (S3/GCS), data warehouses (Snowflake,

People who liked this also viewed

6 picks

Type

implementing-mlops

52installs59forks

View on GitHub

How to install implementing-mlops?

ancoleman/ai-design-components/implementing-mlops

$npx -y skills add ancoleman/ai-design-components --skill implementing-mlops

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# MLOps Patterns
2
3	Operationalize machine learning models from experimentation to production deployment and monitoring.
4
5	## Purpose
6
7	Provide strategic guidance for ML engineers and platform teams to build production-grade ML infrastructure. Cover the complete lifecycle: experiment tracking, model registry, feature stores, deployment patterns, pipeline orchestration, and monitoring.
8
9	## When to Use This Skill
10
11	Use this skill when:
12
13	- Designing MLOps infrastructure for production ML systems
14	- Selecting experiment tracking platforms (MLflow, Weights & Biases, Neptune)
15	- Implementing feature stores for online/offline feature serving
16	- Choosing model serving solutions (Seldon Core, KServe, BentoML, TorchServe)
17	- Building ML pipelines for training, evaluation, and deployment
18	- Setting up model monitoring and drift detection
19	- Establishing model governance and compliance frameworks
20	- Optimizing ML inference costs and performance
21	- Migrating from notebooks to production ML systems
22	- Implementing continuous training and automated retraining
23
24	## Core Concepts
25
26	### 1. Experiment Tracking
27
28	Track experiments systematically to ensure reproducibility and collaboration.
29
30	Key Components:
31	- Parameters: Hyperparameters logged for each training run
32	- Metrics: Performance measures tracked over time (accuracy, loss, F1)
33	- Artifacts: Model weights, plots, datasets, configuration files
34	- Metadata: Tags, descriptions, Git commit SHA, environment details
35
36	Platform Comparison:
37
38	MLflow (Open-source standard):
39	- Framework-agnostic (PyTorch, TensorFlow, scikit-learn, XGBoost)
40	- Self-hosted or cloud-agnostic deployment
41	- Integrated model registry
42	- Basic UI, adequate for most use cases
43	- Free, requires infrastructure management
44
45	Weights & Biases (SaaS, collaboration-focused):
46	- Advanced visualization and dashboards
47	- Integrated hyperparameter optimization (Sweeps)
48	- Excellent team collaboration features
49	- SaaS pricing scales with usage
50	- Best-in-class UI
51
52	Neptune.ai (Enterprise-grade):
53	- Enterprise features (RBAC, audit logs, compliance)
54	- Integrated production monitoring
55	- Higher cost than W&B
56	- Good for regulated industries
57
58	Selection Criteria:
59	- Open-source requirement → MLflow
60	- Team collaboration critical → Weights & Biases
61	- Enterprise compliance (RBAC, audits) → Neptune.ai
62	- Hyperparameter optimization primary → Weights & Biases (Sweeps)
63
64	For detailed comparison and decision framework, see [references/experiment-tracking.md](references/experiment-tracking.md).
65
66	### 2. Model Registry and Versioning
67
68	Centralize model artifacts with version control and stage management.
69
70	Model Registry Components:
71	- Model artifacts (weights, serialized models)
72	- Training metrics (accuracy, F1, AUC)
73	- Hyperparameters used during training
74	- Training dataset version
75	- Feature schema (input/output signatures)
76	- Model cards (documentation, use cases, limitations)
77
78	Stage Management:
79	- None: Newly registered model
80	- Staging: Testing in pre-production environment
81	- Production: Serving live traffic
82	- Archived: Deprecated, retained for compliance
83
84	Versioning Strategies:
85
86	Semantic Versioning for Models:
87	- Major version (v2.0.0): Breaking change in input/output schema
88	- Minor version (v1.1.0): New feature, backward-compatible
89	- Patch version (v1.0.1): Bug fix, model retrained on new data
90
91	Git-Based Versioning:
92	- Model code in Git (training scripts, configuration)
93	- Model weights in DVC (Data Version Control) or Git-LFS
94	- Reproducibility via commit SHA + data version hash
95
96	For model lineage tracking and registry patterns, see [references/model-registry.md](references/model-registry.md).
97
98	### 3. Feature Stores
99
100	Centralize feature engineering to ensure consistency between training and inference.
101
102	Problem Addressed: Training/serving skew
103	- Training: Features computed with future knowledge (data leakage)
104	- Inference: Features computed with only past data
105	- Result: Model performs well in training but fails in production
106
107	Feature Store Solution:
108
109	Online Feature Store:
110	- Purpose: Low-latency feature retrieval for real-time inference
111	- Storage: Redis, DynamoDB, Cassandra (key-value stores)
112	- Latency: Sub-10ms for feature lookup
113	- Use Case: Real-time predictions (fraud detection, recommendations)
114
115	Offline Feature Store:
116	- Purpose: Historical feature data for training and batch inference
117	- Storage: Parquet files (S3/GCS), data warehouses (Snowflake,

People who liked this also viewed

6 picks

Type