Değerlendirmede iyi sonuç verip üretimde başarısız olan bir model, nadiren yanlış model olduğu için başarısız olur. Yukarı akışta bir sütunun adı değiştiği için, cevaplarının ne zaman sapmaya başladığını kimse söyleyemediği için, geri dönüş yolu olmayan bir sürüm yayınlandığı için veya onu kuran kişi başka projeye geçtiği ve sistemin sahibi kalmadığı için başarısız olur.
Bunlar makine öğrenmesi problemleri değildir. Veriye bağımlı yazılım işletmenin sıradan mühendislik problemleridir - ve "çalışan" bunca pilotun neden ikinci bir faaliyet çeyreğine ulaşamadığının sebebi budur. Model, etrafındaki sistemin en küçük ve en kolay değiştirilebilir parçasıdır.
Bu yazı hayatta kalmayı gerçekten belirleyen parçaları ele alıyor: yukarı akış veriyle yapılan sözleşme, sürümlerin nasıl kontrol edileceği, yakalanacak bir hata yokken izlemenin neyi tespit etmesi gerektiği, yayına aldıktan sonra sistemin sahibinin kim olduğu ve ilk olaydan sonra değil öncesinde nelerin kurulması gerektiği.
Yukarı Akış Veriyle Yapılan Sözleşme
Üretimdeki neredeyse her model, modelin varlığından haberi olmayan bir ekibin ürettiği veriyi tüketir. O ekip bir alanın adını değiştirecek, birimi değiştirecek, kategori listesini genişletecek veya daha önce hiç olmayan yerlerde null yazmaya başlayacaktır - hepsi kendi sistemleri açısından meşru değişiklikler, hepsi sizin sisteminiz açısından sessiz bir kırılma.
Veri sözleşmesi bu bağımlılığı açık hale getirir. Modelin ihtiyaç duyduğu alanları, tiplerini ve birimlerini, kabul edilen aralığı veya kategori kümesini, null toleransını ve beklenen tazeliği belirtir. Bir belge değil, test edilebilir bir yapıdır: hat, gelen veriyi buna göre doğrular ve gerçeklik saptığında yüksek sesle hata verir.
Asıl mesele yüksek sesle hata vermektir. Doğrulama olmadan model yine çıktı üretir - sadece artık başka bir şey ifade eden bir sütundan hesaplanmış çıktı üretir. Bu arızanın yığın izi, uyarısı ve belirgin bir başlangıç tarihi yoktur. Haftalar sonra, rakamların tuhaf göründüğünü fark eden biri tarafından keşfedilir.
Şemayı sürümleyin ve kırıcı bir değişikliği, bir API değişikliği gibi önceden duyurulan bir sürüm olayı olarak ele alın. Yukarı akış ekiple sözleşme üzerinde anlaşılamıyorsa geri çekilme savunmacıdır: yine de doğrulayın, başarısız kayıtları karantinaya alın ve karantina oranını kaynak sistem hakkında bir sinyal olarak izleyin.
Sürümler Geri Alınabilir Olmalı
Üretimdeki bir model, dağıtılmış bir yapıdır. Başka herhangi bir dağıtımla aynı kontrollere ihtiyaç duyar ve genellikle daha azını alır.
Her tahmin; model sürümüne, kod sürümüne, öznitelik veya ön işleme sürümüne ve o andaki yapılandırmaya kadar izlenebilir olmalıdır. Bu olmadan aylar sonraki bir inceleme, belirli bir sonucu neyin ürettiğini belirleyemez.
Yeniden üretilebilirlik, belirli bir sürümü girdilerinden yeniden kurabilmek demektir: eğitim verisinin anlık görüntüsü, kod, parametreler ve ortam. "Yeniden eğittik, yakın bir şey çıktı" yeniden üretilebilirlik değildir ve regresyon analizini imkânsız kılar.
Yeni sürümler kademeli açılmalıdır. Gölge dağıtım - aday model canlı trafikte çalışırken kararı hâlâ mevcut modelin vermesi - hiçbir şey ona bağımlı hale gelmeden önce gerçek dağılımlardaki davranışı ortaya çıkarır. Bu mümkün değilse kademeli yayılım maruziyeti sınırlar. Tek adımda tam değişim, en kötü olayları üreten kalıptır.
Geri alma tek ve prova edilmiş bir işlem olmalıdır. Gerçekçi arıza bir çökme değil, girdilerin bir alt kümesinde sessiz bir bozulmadır; sistemi kurmamış biri tarafından uygunsuz bir saatte keşfedilir. Geri almak orijinal mühendisi gerektiriyorsa, sistem işletilebilir değildir.
Ortada Hata Yokken İzleme
Geleneksel izleme, servisin yanıt verip vermediğini yanıtlar. Model izleme, yanıtın hâlâ anlamlı olup olmadığını yanıtlamak zorundadır - daha zor bir soru; çünkü bozulmuş bir model, 200 durum koduyla kendinden emin, düzgün biçimlendirilmiş ve yanlış bir cevap döndürür.
Dört katman gerekir ve çoğu ekip birincisinden sonra durur.
Servis sağlığı - gecikme, hata oranı, kapasite, kaynak kullanımı. Gerekli ama yetersiz.
Girdi dağılımı. Canlı öznitelik dağılımını eğitim penceresiyle karşılaştırın. Ani kaymalar genellikle yukarı akıştaki bir değişikliği, yavaş kaymalar genellikle dünyanın değiştiğini gösterir. Null oranlarını ve kategori sayısını da izleyin; modelin hiç görmediği yeni bir kategori sessiz bir arızadır.
Çıktı dağılımı. Tahmin edilen sınıf dengesini, skor dağılımını ve düşük güvenli çıktı oranını izleyin. Pozitif oranı bir gecede ikiye katlanan bir sınıflandırıcı ya gerçek bir değişimle karşılaşmıştır ya bozulmuştur; her iki durumda da birinin o gün haberi olmalıdır.
Sonuç kalitesi. Sistemin hâlâ doğru olup olmadığını ölçen tek katman ve gerçek referans (ground truth) gerektiren tek katman. Etiketler doğal olarak geliyorsa - sonradan onaylanan bir hasar dosyası, sonradan hatalı bulunan bir parça, sonradan kabul edilen bir öneri - bunları geri birleştirin ve doğruluğu zaman içinde izleyin. Gelmiyorsa, haftada sabit sayıda vakayı örnekleyip inceleyin. Küçük ve tutarlı bir denetim örneklemi, arkasında gerçek referans olmayan gösterişli bir panodan iyidir.
Uyarıyı anlam taşıyan katmanlara kurun. Girdi kaymasına kurulan uyarı eyleme dönüştürülebilir. CPU kullanımına kurulan uyarı, yanlış bir cevabı nadiren açıklar.
Kontrollü Bir Olay Olarak Yeniden Eğitim
Takvimli yeniden eğitim yaygın ve zayıf bir varsayılandır. Aylık bir iş ya bozulmamış bir modeli yeniden eğitir ya da ikinci haftada bozulanı eğitmekte gecikir.
Kanıtla tetikleyin: sonuç kalitesinde ölçülen düşüş, eşiği aşan sürekli girdi kayması, tanımlı hacimde yeni etiketli verinin gelmesi veya yeni bir ürün hattı ya da tedarikçi gibi bilinen bir yukarı akış değişikliği.
Tetikleyici ne olursa olsun sonucu bir sürüm olarak ele alın. Sabit bir kıyas setiyle değerlendirin, önceki eğitim çalışmasıyla değil mevcut üretim sürümüyle karşılaştırın, performansı yalnızca toplamda değil segment bazında kontrol edin ve mevcut modeli devreye alınabilir tutun. Küçük ama önemli bir segmentteki bozulmayı gizleyen genel bir iyileşme, manşet metrik yükselirken yeniden eğitimin işleri kötüleştirmesinin klasik yoludur.
Kendi çıktınızla eğitmeye karşı tedbir alın. Modelin tahminleri bir sonraki etiketlenecek veriyi etkiliyorsa, eğitim seti modelin zaten inandığı şeyin etrafında daralır. Model ne derse desin, rastgele örneklenmiş vakaların bir kısmını incelemeye ayırın.
Yayına Aldıktan Sonra Sahiplik
Sessiz başarısızlığın en yaygın nedeni organizasyoneldir. Pilot bir proje ekibi tarafından kurulur, proje biter ve sistem kimse sorumlu olmadan çalışmaya devam eder.
Dağıtımdan önce bir sahip belirleyin ve kapsamını tanımlayın: izleme ekranlarına kim bakıyor, kalite bozulduğunda kim aranıyor, yeniden eğitimi kim onaylıyor, geri almayı kim yapabiliyor ve yanıt süresi ne. Bu cevaplar yoksa, dürüst tanım şudur: sistemin sahibi yoktur - ve sahipsiz sistemler, birileri dışarıdan fark edene kadar bozulur; o birileri genellikle müşteridir.
Burada çalışma kılavuzları mimari şemalardan daha önemlidir. Vardiyadaki birinin, orijinal ekip olmadan şunları yanıtlayabilmesi gerekir: bunun çalışıp çalışmadığını nasıl anlarım, nasıl geri alırım, belirli bir kararı nasıl açıklarım, kime yükseltirim.
Devir teslim bir toplantı değil, kabul kriterleri olan bir teslimattır. Makul bir test şudur: sistemi kurmamış bir mühendis, yalnızca dokümantasyonu kullanarak bir sürümü geri alabiliyor ve geçmiş bir tahmini yeniden üretebiliyor mu?
Dağıtımdan Önce Kurulması Gerekenler
Hayatta kalmayı belirleyen işin çoğu yayına almadan önce olur ve o aşamada ucuzdur.
Sürecin şu anki halinin referans değerini kaydedin - doğruluk, kapasite, maliyet, sistem neyi iyileştirecekse o. Bu olmadan sonradan değer göstermenin yolu yoktur, yalnızca faaliyet gösterilir.
Çalışma eşiğini ve arkasındaki maliyet asimetrisini karara bağlayın ki karar sınırı, birinin 0,5'te bıraktığı bir varsayılan değil, kayıt altına alınmış bir iş kararı olsun.
Model erişilemez veya emin olmadığında ne olacağını tanımlayın: önceki kural tabanlı sürece dön, insan kuyruğuna yönlendir veya dur. Bunu bilinçli seçin; çünkü varsayılan genellikle açık kalarak başarısız olmaktır ve açık kalma tam da yük altında gerçekleşir.
Kullanımdan kaldırma koşulunu yazın. Hangi ölçülebilir koşullarda bu sistem kapatılırdı? Böyle bir koşulu olmayan proje dürüstçe değerlendirilemez ve maliyetini hak etmeyi bıraktığı noktanın çok ötesinde yaşamaya devam eder.
Bunların hiçbiri makine öğrenmesiyle ilgili değildir. Bir kez çalışmış bir model ile onu kuran insanlar ayrıldıktan sonra da çalışmaya devam eden bir sistem arasındaki farktır.