Notebook-dan production-a

Train edilmiş model bir fayldır. Production-dakı model isə sistemdir: data pipeline-ları, serving yolu, monitoring, retraining dövrü və owner. Bu ikisinin arasındakı məsafə mühəndisliyin əsas hissəsinin yaşadığı yerdir.

Training pipeline koddur

Model-i yaradan notebook reproducible deyil. Cell-lər sıradan kənar işlədilib, dəyişənin üstünə yazılıb, data faylı o vaxtdan dəyişib. İlk production tapşırığı notebook-u pipeline-a çevirməkdir:

Versioned data. Model-i dəqiq hansı sətirlərin, hansı tarixə olan vəziyyəti ilə train etdiyini bilin. Training set-in snapshot-unu çəkin və ya hash-ini saxlayın.
Versioned kod. Feature məntiqi, model konfiqurasiyası və evaluation script-i repository-də yaşayır.
Versioned artifact-lər. Hər train edilmiş model metric-ləri, hyperparameter-ləri, data versiyası və kod commit-i ilə birlikdə saxlanılır. MLflow kimi alətlər də, manifest-li sadə object store da işə yarayır.
Deterministic run-lar. Random seed-ləri sabitləyin. Kitabxana versiyalarını pin edin. Pipeline-ı iki dəfə işlədin və eyni model-in alındığını yoxlayın.

Hazırkı production model-ini sıfırdan retrain edə bilmirsinizsə, o sizə məxsus deyil.

Serving: training/serving skew problemi

Feature-lər training-də bir cür (batch, tarixi data üzərində), inference-də isə başqa cür (real-time, hər request üçün) hesablanır. Bu ikisi arasındakı istənilən fərq model-i səssizcə zəiflədir. Tipik günahkarlar:

Kitabxana upgrade-i tokenization-ı dəyişir.
Batch job UTC istifadə edir; API isə yerli vaxt.
Null training-də sıfır, serving-də isə "skip" kimi emal olunur.
Inference-də cari event-i əhatə edən, training-də isə onu kənarda saxlayan history aggregate-i.

Çarə kodu paylaşmaqdır: training üçün feature-i hesablayan eyni funksiya onu serving üçün də hesablayır. Feature store-lar bunu rəsmiləşdirir: feature-ləri bir dəfə hesablayıb hər iki yola serve edir.

Serving pattern-ləri

Pattern	Necə	Nəyə uyğundur
Batch scoring	Gecə job-u prediction-ları cədvələ yazır	Recommendation-lar, risk score-ları, real-time lazım olmayan hər şey
Online API	HTTP/gRPC endpoint arxasında model	Fraud yoxlamaları, search ranking, hər request üzrə hər şey
Embedded	Model tətbiqin və ya cihazın içində ship edilir	Mobil, edge, oflayn
Streaming	Model event stream-i istehlak edir və prediction-lar verir	Monitoring, anomaly detection

Use case imkan verirsə, batch ilə başlayın. Qurmaq, test etmək və rollback etmək üçün ən sadəsi odur.

Monitoring: model birinci gündən çürüyür

Software səs-küylə sınır. Model-lər isə səssizcə: rəqəm qaytarmağa davam edirlər və rəqəmlər tədricən pisləşir. Üç layer-i izləyin.

System health. Latency, error rate, throughput. İstənilən service-dəki kimi.

Input drift. Hər feature-in production-dakı distribution-ını training set ilə müqayisə edin. Population stability index, KL divergence və ya sadə histogram müqayisəsi. Distribution-ı yerindən tərpənmiş feature fərziyyələri pozulmuş model deməkdir.

Output quality. Ən çətini, çünki label-lar gec gəlir və ya heç gəlmir. Label-ların gəldiyi yerdə (müştəri churn etdimi? transaction fraud idimi?) canlı metric-i hesablayın və validation score-u ilə müqayisə edin. Gəlmədiyi yerdə prediction distribution-ını izləyin: birdən-birə 10 dəfə çox transaction-ı flag edən fraud model-i ya fraud dalğası tapıb, ya da sınıb.

Alert-ləri yalnız error-lara deyil, drift-ə də qoşun.

Retraining

Əvvəlcədən qərar verin:

Trigger. Schedule üzrə (həftəlik), drift zamanı və ya metric düşəndə.
Data window. Son N ay? Recency weighting ilə bütün tarixçə?
Gate. Yeni model deploy olunmazdan əvvəl held-out təzə set üzərində cari model-i üstələməlidir. Müqayisəni avtomatlaşdırın.
Rollback. Əvvəlki model artifact-i bir əmrlə yenidən deploy edilə bilən vəziyyətdə qalır.

Gate-siz retraining bir pis data gününün bir pis model ayına çevrilmə yoludur.

Deployment təhlükəsizliyi

Shadow mode. Yeni model production trafikini alır və prediction-ları log edir, amma hərəkət etmir. Bir həftə canlı model ilə müqayisə edin.
Canary. Trafikin 5%-ni yeni model-ə yönləndirin; metric-ləri izləyin; genişləndirin.
A/B test. Biznes metric-i (conversion, gəlir) model metric-indən vacib olduqda onu controlled experiment ilə birbaşa ölçün.

Ownership

Production-dakı model-in service owner ilə eyni öhdəlikləri daşıyan owner-i olmalıdır: alert-ləri üçün on-call, retraining-inə görə məsul və qərarlarını onlardan təsirlənən insanlara izah edə bilən. Owner-siz model-lər heç kimin söndürməyə və heç kimin retrain etməyə cəsarət etmədiyi şeyə çevrilir.

Checklist

Model canlıya çıxmazdan əvvəl:

Training pipeline versioned datadan end-to-end işləyir
Feature kodu training və serving arasında paylaşılır
Baseline və model metric-ləri time-based test set-də qeyd edilib
Slice metric-ləri fairness və subgroup uğursuzluqları baxımından nəzərdən keçirilib
Input drift monitoring-i alert threshold-ları ilə qurulub
Prediction distribution-ı izlənilir
Rollback test edilib
Owner təyin edilib

Tapşırıqlar

Train etdiyiniz hər hansı model-i götürün. Onu təmiz maşında sıfırdan retrain edin. Eyni model-i aldınızmı?
Həmin model-dəki hər feature-i sadalayın və onun training üçün harada, serving üçün harada hesablandığını qeyd edin. Eyni koddurmu?
İlk növbədə almaq istədiyiniz drift alert-ini və onu trigger edəcək threshold-u müəyyən edin.