PromptWake
← Blog
·14 min

Makine Öğrenmesi Mühendisliği: Üretim ML Sistemleri Kurmak

Üretim ML sistemleri kurmak için pratik bir rehber — MLOps, özellik depoları, model eğitim boru hatları, sunum altyapısı, sürüklenme izleme ve ML mühendisliğini geleneksel yazılım mühendisliğinden ayıran iş akışları hakkında kapsamlı bir kaynak.

Makine öğrenmesi mühendisliği, bir Python importu eklenmiş yazılım mühendisliği değildir. İş akışları, hata modları, test stratejileri ve dağıtım desenleri, geleneksel mühendislik ekiplerini hazırlıksız yakalayacak kadar temel farklılıklar gösterir. Bir özellik flag'i, model rollout'u değildir. Bir birim test takımı, veri sürüklenmesini yakalamaz. Bir REST API, eğitim dağılımı kaydığında zarif bir şekilde bozulmaz. ML mühendisliği kendi disiplinini — kendi araçlarını, kendi boru hatlarını ve kendi mühendislik kültürünü — gerektirir.

Bu makale, uçtan uca ML mühendisliği iş akışını haritalandırır: özellik boru hatları ve deney takibinden model eğitimi, sürümleme, CI/CD, sunum, izleme ve ML ekiplerini üretken kılan organizasyonel desenlere kadar. Her bölüm, araçları, kararları ve sık yapılan hataları kapsar. Hedef, ister tek başına çalışan bir ML mühendisi olun ister düzinelerce modeli destekleyen bir platform ekibinin parçası, üretim ML sistemleri kuran ekipler için pratik bir başvuru kaynağı sunmaktır.

ML mühendisliği ve geleneksel yazılım mühendisliği

Geleneksel yazılım mühendisliği, deterministik kodu öngörülebilir çıktılara dönüştürür. Aynı girdiler verildiğinde, aynı kod her seferinde aynı sonucu üretir. Test basittir: iddialar yaz, çalıştır ve sonuca güven. Dağıtım, bir deterministik yapıtı bir başkasıyla değiştirme meselesidir. Risk yüzeyi, mantık hataları, entegrasyon başarısızlıkları ve altyapı yanlış yapılandırmaları ile sınırlıdır.

ML mühendisliği temelde farklı bir rejimde çalışır. Kod — model mimarisi, eğitim betiği, ön işleme mantığı — sistemin yalnızca bir bileşenidir. Diğer bileşenler ise veri ve verinin ürettiği eğitilmiş parametrelerdir. Veri dağılımındaki bir değişiklik, hiçbir kod değişikliği olmadan modeli bozabilir. Birim testlerini yüzde 95 doğrulukla geçen bir model, üretim verileri eğitim verilerinden farklı göründüğü için üretimde felaket bir şekilde başarısız olabilir. Bu hata modlarının geleneksel mühendislikte bir karşılığı yoktur.

Pratik sonuçları önemlidir. Geleneksel mühendislik ekipleri, birleştirme işlemiyle dağıtım yapabilir. ML mühendisliği ekiplerinin, yalnızca kod doğruluğunu değil, veri doğruluğunu, model kalitesini ve sunum özelliklerini kontrol eden doğrulama boru hatlarına ihtiyacı vardır. Geleneksel geri almalar kod dönüşleridir. ML geri almaları, önceki bir model sürümüne dönmeyi gerektirebilir; bu da dağıtılan her modelin eğitim çalıştırmasına, eğitim çalıştırmasının da eğitim verisine ve hiperparametrelere kadar izlenebilir olması gerektiği anlamına gelir. Bu izlenebilirlik gereksinimi, ML mühendisliği disiplininin temelidir.

Geleneksel mühendislikte kod, doğrunun kaynağıdır. ML mühendisliğinde kod, veri ve eğitilmiş parametrelerin birleşimi doğrunun kaynağıdır. Üçü de birlikte sürümlenmeli, test edilmeli ve dağıtılmalıdır.

Üç sistem sorunu

ML sistemleri, bağımsız olarak yönetilmesi gereken üç etkileşimli sistemi içerir. Veri sistemi, alımı, doğrulamayı, dönüşümü ve depolamayı yönetir. Eğitim sistemi, deney düzenlemesini, hiperparametre ayarını ve model değerlendirmesini yönetir. Sunum sistemi, çıkarımı, gecikme yönetimini ve model yaşam döngüsünü yönetir. Her sistemin kendi hata modları, kendi izlemesi ve kendi CI/CD boru hattı vardır. Değişiklikleri her üç sistemde koordine etmek, ML mühendisliğinin temel zorluğudur.

Geleneksel mühendislik ekipleri genellikle ML'yi bir kütüphane çağrısı gibi ele alma hatasına düşer — bir not defterinde model eğit, bir dosyaya kaydet ve bir web sunucusunda yükle. Bu yaklaşım prototipler için işe yarar ancak üretimde başarısız olur çünkü veri sistemini tamamen göz ardı eder. Üretim ML'si, ortasında bir model eğitim adımı olan bir veri boru hattı problemidir; sonradan akla gelen bir veri ile beslenen model eğitimi problemi değildir.

MLOps temelleri ve araç ekosistemi

MLOps, DevOps prensiplerini makine öğrenmesine uygular. Temel uygulamalar — sürüm kontrolü, CI/CD, test, izleme ve tekrarlanabilirlik — aynıdır ancak uygulama, yapıtlar farklı olduğu için değişir. MLOps, yalnızca kaynak kodu değil, kod, veri, model parametreleri, hiperparametreler ve değerlendirme metriklerini sürümler. Yalnızca mantığı değil, veri kalitesini, model performansını ve sunum davranışını test eder.

MLOps araç ekosistemi hızla olgunlaştı. Düzenleme tarafında Kubeflow, MLflow ve Airflow, her biri farklı ödünleşimlerle boru hattı yönetimi için rekabet ediyor. Kubeflow, Kubernetes-native'dir ve halihazırda Kubernetes'e yatırım yapmış kuruluşlar için uygundur. MLflow, deney takibi ve model kaydı için daha basit bir API sağlar ve çoğu ML çerçevesiyle entegre olur. Airflow, ML eğitimine beslenen karmaşık DAG tabanlı veri boru hatları için en güçlü seçenek olmaya devam ediyor.

Altyapı tarafında, temel kararlar bilgi işlem yönetimi etrafında döner. Eğitim GPU örnekleri pahalı ve kıttır; verimli kullanım, kuyruk yönetimi, spot örnek işleme ve otomatik ölçekleme gerektirir. Hakim desen, GPU düğüm havuzları ve iş kuyrukları ile Kubernetes'te eğitim çalıştırmak ve GPU zamanlaması için Volcano veya Run:AI gibi araçları kullanmaktır. Kubernetes uzmanlığı olmayan ekipler için SageMaker, Vertex AI ve Azure ML gibi yönetilen hizmetler, daha az operasyonel yük ile eğitim altyapısı sağlar.

Araç seçimleri, uyguladıkları prensiplerden daha az önemlidir. Tekrarlanabilirlik, her eğitim çalıştırmasının tamamen yakalanmasını gerektirir: tam kod sürümü, tam veri anlık görüntüsü, tam hiperparametre seti ve eğitim ortamı bağımlılıkları. Altı ay sonra aynı sonucu üretmek için bir model yeniden eğitilemiyorsa, ML boru hattı üretime hazır değildir. Bu prensip, her araç kararına rehberlik etmelidir.

  • Düzenleme: Kubernetes-native boru hatları için Kubeflow, deney takibi ve model kaydı için MLflow, karmaşık veri DAG'ları için Airflow.
  • Eğitim altyapısı: Esneklik için GPU düğüm havuzlarıyla Kubernetes, yönetilen basitlik için SageMaker ve Vertex AI.
  • Özellik depoları: Açık kaynak özellik yönetimi için Feast, kurumsal ölçekli özellik platformları için Tecton.
  • Model sunumu: Yüksek verimli GPU sunumu için TorchServe ve Triton, Python-native sunum için BentoML ve Ray Serve.
  • İzleme: Veri ve model sürüklenmesi için WhyLabs ve Evidently, sunum altyapısı metrikleri için Prometheus ve Grafana.

Özellik depoları ve veri boru hatları

Özellik deposu, ML özellikleri için merkezi bir depodur — modellerin çıkarım için kullandığı girdi değişkenleri. Özellik depoları standart hale gelmeden önce, her ekip aynı özellikleri bağımsız olarak inşa ediyor, bu da tekrarlanan işlere, tutarsız özellik tanımlarına ve eğitim-sunum uyuşmazlığına yol açıyordu. Aynı veri üzerinde model kuran iki ekip, aynı toplamaları farklı şekillerde hesaplıyor, farklı sonuçlar üretiyor ve özellikleri modeller arasında yeniden kullanmayı imkansız hale getiriyordu.

Özellik depoları bunu, özellik tanımları için tek bir doğruluk kaynağı, düşük gecikmeli özellik erişimi için bir sunum katmanı ve eğitim için zamansal olarak doğru bir geçmiş özellik görünümü sağlayarak çözer. Zamansal doğruluk gereksinimi ince ama kritiktir: bir model eğitilirken, her eğitim örneği yalnızca tahmin anında bilinen özellik değerlerini içermeli, etiketten bilgi sızdıran gelecek değerleri içermemelidir. Özellik depoları bunu, özellikleri doğru zaman damgası semantiğini kullanarak etiketlere birleştirerek otomatik olarak halleder.

Özellik boru hattı mimarisi tipik olarak toplu-iş ve akış desenini izler. Toplu iş boru hatları, günlük veya saatlik olarak veri ambarı tablolarından toplu özellikleri hesaplar ve eğitim için çevrimdışı özellik deposuna yazar. Akış boru hatları, olay akışlarından gerçek zamanlı özellikleri hesaplar ve sunum için çevrimiçi özellik deposuna yazar. Çevrimdışı depo, büyük taramalar için optimize edilmiş sütunlu depolama kullanır; çevrimiçi depo, düşük gecikmeli aramalar için optimize edilmiş anahtar-değer depolama kullanır.

Feast, önde gelen açık kaynak özellik deposu olarak ortaya çıkmıştır. YAML veya Python'da özellik tanımları yapmak için bildirimsel bir API sağlar, hem çevrimdışı hem de çevrimiçi sunumu destekler ve BigQuery, Snowflake, Redshift ve Spark dahil yaygın veri kaynaklarıyla entegre olur. Feast, çift yazma sorununu — aynı özellik değerinin eğitim ve sunum için tutarlı bir şekilde kullanılmasını sağlama — yapılandırılabilir aralıklarla özellikleri çevrimdışı depodan çevrimiçi depoya malzemeleyerek çözer.

Model eğitimi ve deney takibi

Bir modeli üretimde eğitmek araştırma faaliyeti değil, bir mühendislik sürecidir. Amaç, bir lider panosunda mümkün olan en yüksek doğruluğa ulaşmak değil, iş gereksinimlerini güvenilir ve tekrarlanabilir bir şekilde karşılayan bir model üretmektir. Keşiften üretime bu geçiş, eğitim boru hatlarının nasıl tasarlandığını değiştirir.

Bir üretim eğitim boru hattı, birbirine bağlı birkaç aşamadan oluşur. Veri alımı, eğitim veri setini özellik deposundan veya veri ambarından yükler. Veri doğrulama, şema uygunluğunu kontrol eder ve önceki eğitim çalıştırmasına kıyasla dağılım kaymalarını tespit eder. Özellik hesaplama, dönüşümleri ve birleştirmeleri uygular. Eğitim, belirtilen hiperparametrelerle model eğitim işini yürütür. Değerlendirme, metrikleri ayırma ve test setlerine karşı hesaplar. Kayıt, model yapıtını ve metaveriyi model kaydına kaydeder.

Deney takibi, tekrarlanabilir eğitimin bel kemiğidir. Her eğitim çalıştırması, kod sürümünü, veri sürümünü, hiperparametreleri, değerlendirme metriklerini ve eğitim ortamını kaydetmelidir. MLflow Tracking ve Weights and Biases bunun için en yaygın araçlardır. Takip sunucusu, eğitim betiğinin parametreleri ve metrikleri günlüğe kaydetmek için çağırdığı bir API ve mühendislerin çalıştırmaları karşılaştırıp en iyi modeli seçmesi için bir kullanıcı arayüzü sunar. Takip verileri, üretim verisi olarak ele alınmalıdır — yedeklenmeli, erişim kontrollü olmalı ve süresiz olarak saklanmalıdır.

import mlflow
import xgboost as xgb
from sklearn.metrics import accuracy_score, precision_score

mlflow.set_experiment("fraud-detection-v2")

with mlflow.start_run() as run:
    params = {
        "max_depth": 8,
        "learning_rate": 0.05,
        "n_estimators": 500,
        "subsample": 0.8,
        "colsample_bytree": 0.7,
        "min_child_weight": 3,
    }
    mlflow.log_params(params)

    model = xgb.XGBClassifier(**params)
    model.fit(
        X_train, y_train,
        eval_set=[(X_val, y_val)],
        verbose=False,
    )

    y_pred = model.predict(X_test)
    metrics = {
        "accuracy": accuracy_score(y_test, y_pred),
        "precision": precision_score(y_test, y_pred),
    }
    mlflow.log_metrics(metrics)

    mlflow.xgboost.log_model(
        model,
        artifact_path="model",
        registered_model_name="fraud-detection-xgb",
    )

Yukarıdaki eğitim betiği, eğitim başlamadan önce parametreleri günlüğe kaydeder, değerlendirme tamamlandıktan sonra metrikleri günlüğe kaydeder ve modeli MLflow'un model kaydına kaydeder. Kaydedilen model adı, aşağı akış sunum boru hatları tarafından kullanılan tanımlayıcı haline gelir. MLflow, eğitim kodunun Git commit hash'ini otomatik olarak yakalayarak her çalıştırmayı kaynağına kadar tamamen izlenebilir kılar.

Hiperparametre ayarı, düzenleme karmaşıklığı ekler. Standart yaklaşım, paralel deneme yürütmelerini yönetmek için Optuna veya Ray Tune kullanır. Her deneme, farklı bir hiperparametre setiyle tam bir eğitim boru hattı çalıştırır. Ayar çerçevesi, denemeleri izler, umut vermeyenleri erken budar ve en iyi yapılandırmayı seçer. Üretim sistemleri için, ayar işi, en iyi sonucunu üretim eğitim boru hattına besleyen ayrı bir boru hattı olmalı, ayarı eğitim betiğinin içine gömmemelidir.

Model sürümleme ve kayıt

Model sürümleme, yazılım kütüphaneleri için anlamsal sürümlemenin ML karşılığıdır. Her model sürümü, benzersiz bir tanımlayıcı ile — tipik olarak model yapıtının hash'i veya monoton olarak artan bir tam sayı — tanımlanır ve nasıl üretildiğini açıklayan metaveri taşır. Model kaydı, model sürümlerini depolayan, yaşam döngüsü aşamalarını yöneten ve sunum altyapısının modelleri almak için kullandığı API'yi sağlayan sistemdir.

MLflow Model Registry, en yaygın benimsenen açık kaynak model kaydıdır. Modelleri, her adın bir model türüne karşılık geldiği isimlere göre düzenler. Her isim altında, bireysel sürümler, ilişkili çalıştırma ID'si, kaynak çalıştırma ve model yapıt konumu ile izlenir. Her sürüm, yaşam döngüsü aşamalarından geçer: doğrulama altındaki modeller için staging, canlı trafik sunan modeller için production ve kullanımdan kaldırılan sürümler için archived. Aşamalar arası geçişler onay gerektirebilir ve otomatik dağıtım gibi aşağı akış eylemlerini tetikleyebilir.

Model yapıtının kendisi, model ağırlıklarını, ön işleme mantığını ve bağımlılık manifestosunu içeren kendi kendine yeten bir formatta paketlenmelidir. MLflow Models ve BentoML'in her ikisi de standartlaştırılmış paketleme biçimleri sağlar. Yapıt, bir nesne deposunda — S3, GCS veya Azure Blob Storage — saklanır ve kayıt yalnızca metaveri işaretçisini depolar. Bu ayrım, model yapıtlarının (derin öğrenme modelleri için gigabaytlar) kayıt veritabanını ezmeden büyük olabilmesini sağlar.

  • Her model sürümü, eğitim çalıştırmasına kadar izlenebilir olmalıdır; eğitim çalıştırması da eğitim verisi anlık görüntüsüne ve kod sürümüne kadar izlenebilir olmalıdır.
  • Yaşam döngüsü aşamaları (staging, production, archived), yazılım sürüm yönetimini yansıtan kontrollü model promosyonları için bir iş akışı sağlar.
  • Model yapıtları, ortamlar arasında tutarlı çıkarım sağlamak için ön işleme mantığı ve bağımlılık manifestoları ile paketlenmelidir.
  • Kayıt metaverisi, değerlendirme metriklerini, eğitim tarihini, özellik seti sürümünü ve adalet veya yanlılık denetim sonuçlarını içermelidir.

Makine öğrenmesi için CI/CD

ML için CI/CD, geleneksel CI/CD'yi modele özgü doğrulama aşamalarıyla genişletir. Standart yazılım CI boru hattı — lint, birim test, derleme, dağıtım — gerekli ancak ML için yetersizdir. Bir model üretime yükseltilmeden önce ek aşamalar, veri kalitesini, model performansını ve sunum altyapısı uyumluluğunu doğrulamalıdır.

ML CI boru hattı tipik olarak kod değişiklikleri ve veri değişiklikleriyle başlar. Eğitim kodunu, özellik tanımlarını veya model yapılandırmasını değiştiren bir pull request, doğrulamayı tetikler. İlk aşamalar standarttır: lint, tip kontrolü ve eğitim ve sunum kodu için birim testler. ML'ye özgü aşamalar bunlar geçtikten sonra başlar. Bir veri doğrulama aşaması, önerilen özellik tanımlarını en son veri anlık görüntüsüne karşı çalıştırır ve şema ihlalleri, eksik değerler ve dağılım değişikliklerini kontrol eder. Bir model doğrulama aşaması, küçük bir veri alt kümesinde aday bir model eğitir ve metriklerin minimum bir çıtayı karşıladığını kontrol eder. Bir entegrasyon testi, modeli bir staging ortamına dağıtır ve uçtan uca çıkarım testleri çalıştırır.

ML modelleri için CD boru hattı, iki farklı dağıtım senaryosunu ele almalıdır. Birincisi model güncellemesidir: halihazırda sunum yapan bir modelin yerini alan yeni bir model sürümü dağıtmak. Bu, geleneksel hizmetlerle aynı dağıtım stratejilerini gerektirir — blue-green, canary, rolling — ancak modele özgü sağlık kontrolleriyle. CD boru hattı, rollout tamamlanmadan önce HTTP 200 yanıtlarını kontrol etmek yerine, çıkarım gecikmesini, tahmin dağılımını ve ayrılmış bir referans setine karşı doğruluğu kontrol eder.

İkinci senaryo altyapı güncellemesidir: modelin kendisini değiştirmeyen sunum altyapısına değişiklikler dağıtmak. Bu, güncellenmiş bağımlılıkları, yeni özellik dönüşümlerini ve ölçekleme yapılandırma değişikliklerini içerir. Bu dağıtımlar geleneksel CI/CD uygulamalarını takip eder ancak uyumluluğu sağlamak için mevcut üretim modeline karşı test edilmelidir. Bir ön işleme adımında sayısal hassasiyeti değiştiren bir bağımlılık yükseltmesi, geleneksel testlerin hiçbirini başarısız etmeden model kalitesini sessizce düşürebilir.

Model dağıtımlarını, kod sürümleri olarak değil, veriye bağlı rollout'lar olarak ele alın. Soru, yeni modelin statik bir test setinde doğru olup olmadığı değil, gerçek dünya koşullarında iş sonuçlarını iyileştirip iyileştirmediğidir.

Model sunum altyapısı

Model sunumu, eğitilmiş modellerin çıkarım isteklerini işlediği çalışma zamanı ortamıdır. Sunum mimarisi, gecikme gereksinimlerine, verim beklentilerine, donanım kısıtlamalarına ve model türüne bağlıdır. Toplu çıkarım, büyük veri setlerini bir programa göre işler — dakikalarca gecikmeyi tolere edebilen öneri sistemleri ve dolandırıcılık tespiti için tipiktir. Çevrimiçi çıkarım, bireysel istekleri gerçek zamanlı olarak sunar — arama, kişiselleştirme ve gerçek zamanlı dolandırıcılık önleme için gereklidir.

Kubernetes'te çevrimiçi model sunumu endüstri standardı haline gelmiştir. Model, başlangıçta model yapıtını yükleyen ve çıkarım için bir HTTP veya gRPC API'si sunan bir konteyner görüntüsü olarak paketlenir. Kubernetes, ölçekleme, rolling güncellemeler ve kaynak tahsisini yönetir. GPU hızlandırmalı modeller için NVIDIA Triton Inference Server, dinamik toplu işleme, model eşzamanlılığı ve tek bir sunum sürecinde birden çok çerçeve desteği ile optimize edilmiş sunum sağlar.

Sunum konteyneri, çıkarımın ötesinde birkaç konuyu ele almalıdır. İstek ön işleme, ham girdiyi modelin beklediği özellik vektörüne dönüştürür. Yanıt son işleme, model çıktılarını işle ilgili tahminlere dönüştürür. Geri dönüş mantığı, modelin düşük güvenli tahminler döndürdüğü veya çıkarım isteğinin zaman aşımına uğradığı durumları ele alır. Gözlemlenebilirlik ara katmanı, her model sürümü için istek gecikmesini, tahmin dağılımını ve hata oranlarını raporlar.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import mlflow.pyfunc
import numpy as np

app = FastAPI()
model = mlflow.pyfunc.load_model("models:/fraud-detection-xgb/production")

class Features(BaseModel):
    transaction_amount: float
    user_age_days: int
    device_risk_score: float
    ip_country_risk: float
    hour_of_day: int
    is_new_device: bool

class Prediction(BaseModel):
    fraud_probability: float
    is_fraudulent: bool
    model_version: str

@app.post("/predict", response_model=Prediction)
async def predict(features: Features) -> Prediction:
    try:
        input_array = np.array([[
            features.transaction_amount,
            features.user_age_days,
            features.device_risk_score,
            features.ip_country_risk,
            features.hour_of_day,
            float(features.is_new_device),
        ]])
        proba = model.predict_proba(input_array)[0, 1]
        return Prediction(
            fraud_probability=float(proba),
            is_fraudulent=proba >= 0.5,
            model_version=model.metadata.run_id,
        )
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Yukarıdaki sunum kodu, modeli başlangıçta MLflow kaydından yükler, girdi özelliklerini bir Pydantic şeması aracılığıyla ayrıştırır ve model sürümü tanımlayıcısıyla birlikte tahminleri döndürür. Yanıttaki model_version alanı, sürüm bazında izleme ve izlenebilirlik sağlar: her tahmin, onu üreten tam model sürümüne atfedilebilir, bu da üretim sorunlarını hata ayıklamak için çok önemlidir.

Çevrimiçi sunum için gecikme optimizasyonu, dikkatli mühendislik gerektirir. Dinamik toplu işleme, eşzamanlı istekleri GPU çıkarımı için gruplar halinde toplar, gecikme pahasına verimi artırır. Model niceleme, hassasiyeti float32'den float16 veya int8'e düşürür, model boyutunu küçültür ve çıkarımı hızlandırır, ancak küçük doğruluk kayıpları pahasına. Gecikmeye duyarlı uygulamalar için model damıtma, daha büyük bir öğretmen modelini yaklaşık olarak tahmin eden daha küçük bir öğrenci modeli eğitir, doğruluğun çoğunu korurken çıkarım süresini önemli ölçüde azaltır.

Modeller için A/B testi ve canary dağıtımları

ML modelleri için A/B testi, geleneksel A/B testinden kritik bir şekilde farklıdır: tedavi ve kontrol grupları zaman içinde istikrarlı olmalıdır. Geleneksel A/B testleri kullanıcıları rastgele atar ve sonuç farklılıklarını ölçer. ML A/B testleri, modelin tahminlerinin kullanıcı davranışını etkilediğini ve bunun da gelecekteki modeller için eğitim verilerini etkilediğini hesaba katmalıdır. Kullanıcı davranışını değiştiren bir model, veri dağılımını değiştirir, bu da bir sonraki modelin ne öğrendiğini değiştirir. Bu geri bildirim döngüsü, uzun süreli ML deneylerini doğası gereği karışık hale getirir.

Standart hafifletme, model A/B testlerini kısa sürelerle — tipik olarak haftalar yerine günler — çalıştırmak ve tedavi atamasından bağımsız ayrılmış doğrulama setleri kullanmaktır. Deneysel tasarım ayrıca, yeni modelin trafiğin küçük bir yüzdesine hizmet verirken sunum altyapısının gecikme, hata oranları ve tahmin dağılımlarının beklenen aralıklarda olduğunu doğruladığı bir kademeye alma süresi içermelidir. Bu altyapı doğrulamasından sonra deney, iş metriklerini ölçmeye geçmelidir.

Modeller için canary dağıtımları benzer bir deseni izler. Yeni bir model sürümü, trafiğin yüzde biriyle başlar. Gecikme bozulması, hata oranı artışı veya tahmin dağılımı kayması olmayan bir doğrulama süresinden sonra, canary yüzde beşe, sonra yirmi beşe, sonra yüze çıkar. Her adımda, otomatik kontroller hem sunum sağlığını hem de tahmin kalitesini doğrular. Tahmin dağılımı önemli ölçüde kayarsa — örneğin, yeni model eskisinin on katı oranında dolandırıcılık tahmin ediyorsa — doğruluk metrikleri iyi görünse bile dağıtım manuel inceleme için durdurulmalıdır.

Gölge dağıtımlar ek bir güvenlik katmanı sağlar. Bir gölge dağıtımda, yeni model üretim trafiği alır ancak tahminleri kararlar için kullanılmaz. Gölge model, üretim modeliyle yan yana çalışır ve ekip, çıktılarını günler veya haftalar boyunca karşılaştırır. Gölge dağıtımlar, yeni bir modeli doğrulamanın en güvenli yoludur çünkü üretim davranışını etkileyemezler. Ödünleşim maliyettir: her gölge dağıtım, değerlendirme süresi boyunca sunum altyapısını etkin bir şekilde ikiye katlar.

Model sürüklenmesi ve veri kalitesinin izlenmesi

Model sürüklenmesi, altta yatan veri dağılımındaki değişiklikler nedeniyle model performansının zaman içinde bozulmasıdır. Üretim ML başarısızlıklarının en yaygın nedenidir ve geleneksel izlemeye görünmez olduğu için tespit edilmesi en zor olanıdır. Bir model, sıfır hata ve sıfır gecikme bozulmasıyla her saniye tahmin sunarken giderek daha yanlış sonuçlar üretebilir. Sürüklenme izleme, üretim ML sistemleri için isteğe bağlı değildir.

İki tür sürüklenme vardır. Veri sürüklenmesi, girdi özelliklerinin dağılımı değiştiğinde meydana gelir. Model ortalama elli dolarlık işlemler üzerinde eğitildiyse ve üretim işlemleri ortalama iki yüz dolar ise, modelin tahminleri güvenilmez hale gelir. Kavram sürüklenmesi, özellikler ve hedef arasındaki ilişki değiştiğinde meydana gelir. Dolandırıcılık desenleri hesap ele geçirmeden sentetik kimlik dolandırıcılığına kayarsa, tarihsel desenler üzerinde eğitilmiş model, özellik dağılımları değişmese bile yeni dolandırıcılık türlerini kaçıracaktır.

Sürüklenme tespiti, bir referans penceresi ile bir izleme penceresi arasında dağılımların karşılaştırılmasını gerektirir. Referans penceresi tipik olarak eğitim verileri veya üretim verilerinin ilk N günüdür. İzleme penceresi, son tahminlerin kayan bir penceresidir. İstatistiksel testler — sürekli özellikler için Kolmogorov-Smirnov, kategorik özellikler için ki-kare ve skor dağılımları için popülasyon istikrar indeksi — iki pencereyi karşılaştırır ve önemli farklılıkları işaretler.

Evidently ve WhyLabs, izleme yığınlarıyla entegre olan açık kaynak sürüklenme tespit kütüphaneleri sağlar. Her iki araç da veri sürüklenmesi, model sürüklenmesi ve veri kalitesi metriklerini otomatik olarak hesaplar ve uyarı sistemleri tarafından tüketilebilen yapılandırılmış raporlar çıktılar. Uyarı eşiği, modelin iş etkisine bağlıdır. Kedi videoları öneren bir model, kredi başvurularını onaylayan bir modelden daha fazla sürüklenmeyi tolere edebilir. Eşikleri yalnızca istatistiksel anlamlılığa değil, yanlış tahminlerin maliyetine göre belirleyin.

  • Girdi özellik dağılımlarını, eğitim dağılımına karşı istatistiksel testler kullanarak veri sürüklenmesi için izleyin.
  • Girdi özellikleri sabit görünse bile, kavram sürüklenmesi için tahmin dağılımlarını ve tahmin güven skorlarını izleyin.
  • Etiketler gecikmeli olarak geldiğinde gerçek değerleri izleyin — gecikmeli geri bildirim, model bozulmasının önde gelen bir göstergesidir.
  • Sürüklenme tespitinde değil, sürüklenme şiddetinde uyarı verin. İş metriklerini etkilemeyen istatistiksel olarak anlamlı bir sürüklenme, eylem gerektirmeyebilir.
  • Kök neden analizini hızlandırmak için sürüklenme metriklerini model sürümüne, özelliğe ve zaman penceresine göre gösteren panolar oluşturun.

Veri doğrulama ve şema zorunluluğu

ML sistemlerinde veri kalitesi, yazılım mühendisliğinde tip güvenliğinin eşdeğeridir. Bir üretim özellik vektöründeki null değer, null pointer dereference gibidir — daha önce yakalanması gereken bir hataya neden olur. Ancak ML veri kalitesi sorunları, null'lardan daha incedir. Eğitimde bir tamsayı olan bir özellik, üretime bir dize olarak gelebilir. Kategorik bir özellik, eğitim sırasında hiç görülmemiş değerlere sahip olabilir. Sürekli bir özellik, modelin gördüğü her şeyden bir büyüklük sırası daha büyük bir değer aralığına sahip olabilir.

Şema zorunluluğu, bu sorunları modele ulaşmadan yakalar. TensorFlow Data Validation ve Great Expectations, veri şemalarını tanımlamak ve doğrulamak için standart araçlardır. Bir şema, her özellik için beklenen veri türlerini, değer aralıklarını, izin verilen kategorileri ve varlık kısıtlamalarını tanımlar. Doğrulama boru hattı, veri alımı sırasında, eğitimden önce ve sunumdan önce çalışarak veri kalitesi kontrollerinin sorunları her aşamada yakalamasını sağlar.

İyi tasarlanmış bir veri doğrulama boru hattı, hem geçti-kaldı kontrolleri hem de dağılım istatistikleri üretir. Geçti-kaldı kontrolleri — bu sütun null mu? bu değer izin verilen aralıkta mı? — veri kalitesi olayları için anlık uyarılar sağlar. Dağılım istatistikleri — bu özelliğin ortalaması, standart sapması ve yüzdelik dağılımı nedir? — sürüklenme izlemeyi besler ve üretim verilerini eğitim verileriyle karşılaştırmak için temel sağlar.

Üretim sistemlerinde en yaygın veri doğrulama hatası, sessiz şema sürüklenmesidir: bir veri kaynağının çıktı biçimini ML ekibinin bilgisi olmadan değiştirmesi. Bir iş arkadaşı, bir kaynak tabloya bir sütun ekler. Bir satıcı, API yanıt biçimini değiştirir. Bir veri boru hattı geçişi, bir sütun türünü tamsayıdan float'a değiştirir. Bu değişikliklerin her biri, ML boru hattını sessizce bozabilir. Sessiz dönüştürme yerine beklenmeyen değişikliklerde açık başarısızlık ile şema zorunluluğu, bu hataların üretime ulaşmasını önler.

Ekipler için ML platformları oluşturmak

Kuruluşlar ML kullanımını ölçeklendirdikçe, darboğaz model geliştirmeden platform altyapısına kayar. Beş ML mühendisinden oluşan bir ekip kendi boru hatlarını yönetebilir. Elli model kuran elli ML mühendisinden oluşan bir ekip, standartlaştırılmış boru hatları, yeniden kullanılabilir bileşenler ve self-servis altyapı sağlayan paylaşımlı bir platforma ihtiyaç duyar. Bu platformu oluşturmak, ölçekte ML mühendisliğinin tanımlayıcı zorluğudur.

ML platform ekibi, paylaşılan altyapıya sahiptir: özellik deposu, model kaydı, eğitim bilgi işlem kümesi, sunum ağı ve izleme yığını. Bireysel model ekipleri, modele özgü mantığa sahiptir: özellik tanımları, eğitim betikleri, model mimarisi ve değerlendirme kriterleri. Bu sorumluluk ayrımı, model ekiplerinin modellemeye odaklanmasını sağlarken platform ekibi, her modelin her ekip tarafından sıfırdan inşa edilmeden üretim kalitesinde altyapıdan yararlanmasını sağlar.

Platform, tek bir iş akışını zorlamak yerine standartlaştırılmış şablonlar ve soyutlamalar sağlamalıdır. Toplu çıkarım boru hatları için bir şablon, veri yükleme, özellik hesaplama, model çıkarımı, çıktı yazma ve izleme günlüğe kaydetmeyi birleştirilebilir adımlar olarak içermelidir. Çevrimiçi sunum için bir şablon, konteynerleştirme, sağlık kontrolleri, ölçekleme yapılandırması ve canary dağıtım mantığını yapılandırılabilir parametreler olarak içermelidir. Model ekipleri, altyapıyı yeniden yazmadan kendi model türleri ve iş gereksinimleri için şablonu özelleştirir.

Backstage gibi iç geliştirici portalları veya özel ML platform kullanıcı arayüzleri, self-servis arayüzü sağlar. Model ekipleri, portalı yeni modeller kaydetmek, sunum uç noktaları yapılandırmak, eğitim çalıştırmaları başlatmak ve izleme panolarını görüntülemek için kullanır. Portal, altta yatan Kubernetes yapılandırmasını, CI/CD boru hattı tanımlarını ve izleme kurulumunu soyutlayarak model ekiplerinin modelleri üretime dağıtmak için altyapı uzmanı olmalarını gerektirmez.

  • Sunum altyapısının tüm model türlerinde tutarlı olması için bir model paketleme biçiminde (MLflow Models veya BentoML) standartlaşın.
  • GPU kuyruk yönetimi, otomatik kontrol noktası oluşturma ve yerleşik deney takibi ile self-servis eğitim altyapısı sağlayın.
  • Dağıtılan her model için sürüklenme metriklerini, sunum gecikmesini ve hata oranlarını otomatik olarak toplayan paylaşımlı bir izleme katmanı oluşturun.
  • Kod incelemesini yansıtan model inceleme süreçleri oluşturun: her model dağıtımı, özellik tanımları, eğitim yapılandırması ve değerlendirme sonuçlarının akran incelemesini gerektirir.
  • ML mühendisleri için geliştirici deneyimine yatırım yapın: hızlı iterasyon döngüleri, tekrarlanabilir hata ayıklama ve üretimi yansıtan yerel geliştirme ortamları.

Etik hususlar ve yanlılık tespiti

ML mühendisliği kararlarının, geliştirme yaşam döngüsü boyunca — dağıtım zamanında sonradan akla gelen bir düşünce olarak değil — dikkate alınması gereken etik sonuçları vardır. Kredi değerliliğini tahmin eden bir model, belirli demografik grupları sistematik olarak dezavantajlı duruma düşürebilir. Bir öneri sistemi, kullanıcı davranışındaki mevcut yanlılıkları güçlendirebilir. Bir dolandırıcılık tespit modeli, belirli coğrafi bölgelerden gelen meşru işlemleri orantısız derecede yüksek oranlarda işaretleyebilir. Bu sonuçlar hata değildir — eğitim verisinin ve model tasarımının özellikleridir.

Yanlılık tespiti, doğruluk ve kesinlik metrikleri gibi eğitim ve doğrulama boru hattına entegre edilmelidir. AIF360 ve SHAP gibi araçlar, nicel yanlılık ölçümleri sağlar: demografik eşitlik, eşit fırsat ve orantısız etki oranları. Bu metrikler, her aday model sürümü için hesaplanmalı ve halihazırda dağıtılmış modelle karşılaştırılmalıdır. Yeni bir model genel doğruluğu artırıyor ancak adalet metriklerini kötüleştiriyorsa, ödünleşim, dağıtımdan önce açıkça belgelenmeli ve incelenmelidir.

Etik inceleme süreci, ML ekibinin ötesindeki paydaşları içermelidir. Ürün yöneticileri, hukuk danışmanları, alan uzmanları ve etkilenen kullanıcı gruplarının temsilcileri, hassas kullanım durumlarına dağıtımdan önce model incelemesine katılmalıdır. İnceleme, temsil yanlılığı için eğitim verilerini, vekil ayrımcılık için özellik setini, gruplar arasında farklı performans için değerlendirme metriklerini ve sürekli adalet değerlendirmesi için izleme planını kapsamalıdır.

Google'ın Model Kartları ve Veri Setleri için Veri Sayfaları gibi dokümantasyon standartları, model amacını, performans özelliklerini ve sınırlamaları belgelemek için yapılandırılmış biçimler sağlar. Bir model kartı, kaydedilen her model sürümüne eşlik eder ve modelin amaçlanan kullanımını, demografik gruplar arasındaki değerlendirme sonuçlarını, bilinen sınırlamaları ve etik hususları içerir. Model kartı, model geliştikçe ve yeni adalet değerlendirme teknikleri ortaya çıktıkça güncellenmelidir.

Uzun vadeli inşa etmek

Üretim ML mühendisliği hala genç bir disiplindir. Bu makalede açıklanan araçlar, desenler ve en iyi uygulamalar, alan olgunlaştıkça gelişecektir. Ancak bunların altında yatan prensipler — tekrarlanabilirlik, izlenebilirlik, her aşamada doğrulama ve veriyi birinci sınıf bir yapıt olarak ele alma — temel olmaya devam edecektir. Bu prensiplere yatırım yapan ekipler, zarif bir şekilde bozulan, hızlıca toparlanan ve sürekli iyileşen sistemler kurar.

En başarılı ML mühendisliği organizasyonları ortak özellikler taşır. ML boru hatlarını projeler olarak değil ürünler olarak ele alırlar — bir kere inşa edip geçmek yerine sürekli olarak araçlara, dokümantasyona ve geliştirici deneyimine yatırım yaparlar. Boru hattının her aşamasında titiz doğrulama uygularlar, veri sorunlarını eğitime ulaşmadan ve model sorunlarını üretime ulaşmadan yakalarlar. Her şeyi izlerler: veri dağılımları, tahmin dağılımları, sunum gecikmesi, hata oranları ve iş metrikleri. Ve model ekiplerinin modellemeye odaklanmasını sağlarken platformun altyapıyı ele aldığı platformlar kurarlar.

Makine öğrenmesi mühendisliği, yazılım mühendisliğinden daha zordur. Sistemler daha karmaşık, hata modları daha çeşitli ve hata ayıklama döngüsü daha yavaştır. Ancak temel mühendislik disiplini aynıdır: yapıtlarınızı sürümleyin, varsayımlarınızı test edin, sistemlerinizi izleyin ve yineleyin. Araçlar değişebilir, ancak disiplin kalıcıdır.