Modeller ve promptlar yayına çıkar umutla değil, kontrol kapısından geçerek.
Notebookları ve prompt denemelerini yönetişim altındaki sürüm hatlarına dönüştüren MLOps mühendisleri: sürümlenmiş veri, CI içinde değerlendirme setleri, terfi yolu tanımlı bir kayıt defteri ve canlıya alındıktan sonra drift izleme.
- MLflow
- Ragas
- PyTorch
- Airflow
- DVC
- KServe
Makine öğrenmesi işleri çoğu zaman model kurulmadan önce değil, kurulduktan sonra başarısız olur.
Notebook bir kez çalışmıştır; eğitim verisi birinin dizüstü bilgisayarındaki bir CSV dosyasıdır; prompt, demo düzgün görünene kadar elle ayarlanmıştır. Altı ay sonra hangi sürümün canlı ortamda olduğunu, doğruluğun neden düştüğünü ya da geçen haftaki değişikliğin işleri iyileştirip iyileştirmediğini kimse söyleyemez. MLOps, bu hikâyenin tekrarlanmasını önleyen mühendisliktir — sıradan servislere uyguladığımız CI/CD, sürümleme ve gözlemlenebilirlik disiplininin veriye, modellere ve promptlara genişletilmiş hâlidir.
İşin merkezinde değerlendirme vardır. Klasik bir model için bu, ayrılmış bir test kümesi ve iş kararıyla örtüşen metrikler demektir; bir LLM özelliği için ise gerçek, etiketlenmiş örneklerden oluşan dondurulmuş bir küme ve CI içinde çalışan bir puanlayıcı demektir. Her iki durumda da kural aynıdır: değerlendirilmemişse bitmemiştir. Kendi ürünlerimizdeki modeller ve promptlar bir referans değer ve bir kapıyla birlikte yayına alınır — Loyalty & Retention içindeki kademe tahmini ve sonraki en iyi teklif modelleri, müşteri ekibinin inceleyebileceği model sürümleri ve değerlendirme metrikleri taşır; müşterilerimiz için geliştirdiğimiz yapay zeka özellikleri de aynı şekilde teslim edilir.
Tek modeli olan bir şirket için MLOps platformu kurmayız. Sürümleri yeniden üretilebilir, değerlendirmeleri otomatik hâle getiren en küçük hattı ekibinizin zaten kullandığı araçlar üzerinde kurar, ikinci ve üçüncü model geldiğinde büyütürüz.
MLOps başlığı altında teslim ettiğimiz altı şey.
LLM özellikleri için değerlendirme setleri
Gerçek trafiğinizden çıkarılmış etiketli örnek kümeleri; doğruluk, kaynağa dayalılık, ret davranışı ve biçim için puanlayıcılar ve bir prompt ya da model değişikliği puanı kayıtlı referans değerin altına çektiğinde derlemeyi başarısız kılan bir CI işi.
Eğitim ve yeniden eğitim hatları
Sürümlenmiş veriyi çeken, eğiten, değerlendiren ve bir adayı zamana ya da bir tetiğe bağlı olarak kayda geçiren Airflow veya Kubernetes tabanlı hatlar — hafızadan değil, bir commit hash’inden yeniden üretilebilir.
Deney takibi ve kayıt defteri
Her koşuda parametreler, metrikler ve artefaktlar için MLflow ve bir modelin adaylıktan hazırlık ortamına, oradan canlı ortama yalnızca kayıt altına alınmış, kapıdan geçen bir terfiyle ilerlediği bir kayıt defteri.
Model sunumu
İstek doğrulama, toplu işleme, zaman aşımları, canary sürümler ve geri alma içeren FastAPI veya KServe uç noktaları — model, kümedeki diğer servisler gibi sürümlenerek devreye alınır.
İzleme ve drift tespiti
Model sürümü başına girdi dağılımı, skor dağılımı, gecikme ve maliyet; canlı veri eğitim verisine benzemeyi bıraktığında uyarılar — ve buna yanıt veren bir yeniden eğitim tetiği.
Veri ve öznitelik sürümleme
Veri kümeleri, öznitelikler ve etiketler DVC ya da lakehouse tablolarıyla kodun yanında sürümlenir; böylece her tahmin, onu üreten tam veriye ve modele kadar geri izlenebilir.
Ne zaman tercih etmeli.
Bir model ya da LLM özelliği önemli kararlar veriyorsa — fiyatlama, dolandırıcılık, uygunluk, müşteriye dönük yanıtlar — ve hangi sürümün ne yaptığını kanıtlamanız gerekiyorsa MLOps yatırımını tercih edin. Promptları ya da modelleri birden fazla kişi değiştiriyorsa, yeniden eğitim tek seferlik değil tekrar eden bir olaysa ya da bir düzenleyici, denetçi veya kendi risk ekibiniz bir kararın nasıl verildiğini soracaksa tercih edin. Boyutu ne olursa olsun her LLM özelliği için önce değerlendirme yaklaşımını tercih edin; değerlendirme kümesi, olayın kendisinden daha ucuzdur.
Ayda bir çalışan ve bir kişinin gözden geçirdiği tek bir toplu iş modeli için eksiksiz bir platform seçmeyin — sürümlenmiş bir betik, takip edilen bir koşu ve bir pano yeterlidir. Referans mimaride öyle görünüyor diye öznitelik deposunu, iş akışı düzenleyicisini ve sunum katmanını aynı anda benimsemeyin; her birini, çözdüğü sıkıntı gerçekten ortaya çıktığında benimseyin. Ve değerlendirmeyi lansman haftasına ait bir iş gibi görmeyin — ya birleştirme kapısıdır ya da gösteriden ibarettir.
Bir prompt değişikliğinin birleşip birleşmeyeceğine karar veren bir değerlendirme kapısı.
name: eval
on: { pull_request: { paths: ["prompts/**", "models/**", "evals/**"] } }
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: uv run evals/run.py --suite extraction-v3 --out result.json
# frozen, labelled set of real invoices; baseline stored with the suite
- run: >-
uv run evals/compare.py result.json --baseline evals/baseline.json
--min-accuracy 0.94 --max-cost-delta 0.10 --max-p95-ms 1800
- uses: actions/upload-artifact@v4
with: { name: eval-report, path: result.json }Bir değişiklikten canlı ortamdaki modele giden yol.
Teslim ettiğimiz model hatları şöyle görünür.
- Bir commit’ten yeniden üretilebilir. Kod, veri sürümü, parametreler ve ortam her koşuda kaydedilir. Canlı ortamdaki modeli, kayıt defteri girdisinden herkes yeniden oluşturabilir.
- Birleştirme kapısı olarak değerlendirme. Kayıtlı bir referans değer, CI içinde çalışan bir puanlayıcı ve iş sahibiyle üzerinde anlaşılmış eşikler. Gerileme yaratan bir değişiklik birleştirilmez — promptlar için de modeller için de.
- Kararla örtüşen metrikler. Gerçekten kullandığınız eşikteki kesinlik, yanlış pozitif başına maliyet, müşterilerin gerçekten sorduğu sorularda kaynağa dayalılık — önemli olan hatayı gizleyen genel bir doğruluk sayısı değil.
- Terfi kayıt altına alınır. Aday, hazırlık, canlı: her geçişin ekinde bir kim, bir ne zaman ve bir değerlendirme sonucu vardır. Kayıt defteri, denetim izidir.
- Bir servis gibi devreye alınır. Bir kez derlenen konteynerler, canary yayılım, sağlık kontrolleri, tek komutla geri alma ve kümedeki diğer her şeyle aynı nöbet runbook biçimi.
- Modelin hata biçimlerine göre izlenir. Girdi drifti, çıktı drifti, sürüm başına gecikme ve maliyet, ret ve insan incelemesi oranları — yalnızca bir pano değil, uyarılar ve bir sahip ile.
- Maliyet birinci sınıf bir metriktir. Koşu başına eğitim harcaması ve bin istek başına çıkarım harcaması bir bütçeye karşı izlenir; kalitede kazanıp maliyette kaybeden bir değerlendirme kaza değil, bir karardır.
- Kişisel veri, veri mühendisliği işi olarak ele alınır. Eğitim kümeleri asgariye indirilir ve belgelenir, PII loglarda ve izlerde maskelenir, KVKK ve GDPR yükümlülükleri ilk veri çekiminden önce gözden geçirilir ve veri kümesiyle birlikte kaydedilir.
Genellikle yanında teslim edilenler.
- Her model ya da LLM özelliği için bir değerlendirme seti: etiketli küme, puanlayıcılar, kayıtlı referans değer ve bunu zorunlu kılan CI işi
- Bir commit hash’inden yeniden üretilebilen, her koşuda deney takibi yapılan bir eğitim ya da ayarlama hattı
- Belgelenmiş bir terfi yolu ve Kubernetes üzerinde sürüm mekanikleri — canary, geri alma — içeren bir model kayıt defteri
- Model başına bir izleme panosu: drift, kalite, gecikme, maliyet, insan incelemesi oranı; uyarı yönlendirmesi ve bir sahip ile
- Gerçekten yaşanan olaylar için runbook’lar: kalite düşüşü, sağlayıcı kesintisi, maliyet sıçraması, yeniden eğitim hatası
Sık sorulan sorular
Komşu teknolojiler ve bunları kullanan hizmet.
Modellerinizi yayına hazır hâle getirecek mühendisler mi gerekiyor?
Bugün ne kullandığınızı — notebooklar, barındırılan LLM’ler, bir eğitim hattı — ve nerede zorlandığınızı anlatın. Size adları belli bir ekip önerir ya da kendi ekibinize MLOps uzmanları yerleştiririz.