MLOps архитектура для банка

Зачем банку MLOps

Banking models имеют higher stakes, чем marketing models: credit decisions ($), fraud blocks (UX), AML triggers (regulator). Без MLOps — модели стареют unnoticed, accuracy падает, regulator audit fails.

Структурные элементы

Feature store. Centralised, versioned. Online (inference) и offline (training) consistency.

Model registry. Versioned models, metadata, status (dev/staging/prod/archived).

Training pipeline. Reproducible — data → preprocessing → train → evaluate → registry.

Deployment. Standardised path: shadow → canary → full с auto-rollback.

Monitoring. Prediction distribution, feature drift, accuracy (ground truth), business KPI.

Governance. Approval workflow, audit trail, explainability, fairness monitoring.

Banking-specific requirements

Regulatory traceability. Каждое model decision должно быть reproducible на demand. Versioning critical.

Bias monitoring. Disparate impact analysis обязательно для credit, AML.

Explainability. SHAP / LIME для regulator inquiries.

Model risk management. Banks under Basel/IFRS9 имеют formal model validation requirements.

Champion/challenger. Active production model и continuously evaluated alternative.

Где обычно ломается

Train-serve skew. Features computed differently in train vs production.

Models в Jupyter — irreproducible.

Deployment через ticket — slow, irregular updates.

No monitoring — accuracy decay months unnoticed.

No registry — production model «вот тот файл».

Bias не checked — regulator complaint.

Operating model

Owner — Head of Model Risk / Head of Data Science с infra mandate.

Teams: ML platform, data science, ML engineering, model governance.

Routine — weekly production model review.

Связанное

• /architecture/banking-cdp-architecture/ — feature source
• /architecture/banking-realtime-decisioning/ — model consumer
• /insights/banking-model-risk-management/ — model risk
• /insights/banking-ai-governance/ — AI governance