Dashboard gerçekten kusursuz görünüyordu—her şey yerli yerindeydi.

Model production’a alınmadan önce tüm son kontroller yapılmıştı: accuracy %94’tü, test sonuçları stabildi, pipeline sorunsuz çalışıyordu. Kısacası, ekip “hazırız” diyordu ve model deploy edildi.

İlk birkaç saat her şey beklendiği gibi ilerledi.

Ama sonra metrikler yavaş yavaş düşmeye başladı—öyle ani bir çöküş değil, sessiz ve sinsi bir gerileme. Fark etmesi zor, ama etkisi büyük.

Bir günün sonunda sistem neredeyse kullanılamaz hale gelmişti.

Tahminler tutarsızdı, alınan kararlar hatalıydı ve kullanıcı davranışı değişmişti. Ekip tekrar bir araya geldi ve herkesin aklına aynı klasik sorular geldi: “Model drift mi var?”, “Data mı değişti?”, “Production’da bug mı çıktı?”

Ama bu kez sorun modelde değildi.

Sorun verideydi—ve daha da önemlisi, veriye nasıl yaklaşıldığındaydı.

Kod açıldı ve o kritik satır bulundu:
train_test_split(data, test_size=0.2, shuffle=False)

Veri zaman bağımlıydı ama split yöntemi bunu dikkate almıyordu. Model aslında geleceği tahmin etmeyi değil, geçmişi tekrar etmeyi öğrenmişti. Yani gerçek dünyaya hazır değildi.

Test sonuçları neden bu kadar iyiydi?

Çünkü model gerçekten test edilmemişti—sadece daha önce gördüğü bir düzenin farklı parçalarıyla yeniden karşılaştırılmıştı.

İlginç olan şu: Kimse bu satırı gözden kaçırmamıştı.

Herkes görmüştü ama kimse durup şu basit soruyu sormamıştı: “Bu split gerçekten doğru mu?”

Sorun kodda değildi.

Sorun, sorgulanmayan bir varsayımdı.

Peki, üretim hataları neden bu kadar tehlikeli?

Çünkü production gerçek dünyadır: gerçek veriyle çalışır, gerçek kullanıcıları etkiler ve gerçek maliyetler üretir. En kritik nokta ise şu—bu hatalar genellikle hemen fark edilmez. Sistem çökmez, sadece yanlış çalışır.

Çoğu ekip şu döngüye güvenir: train, test, metric, deploy.

Ama burada gözden kaçan kritik bir soru var: Test gerçekten gerçeği temsil ediyor mu? Eğer etmiyorsa, %94 accuracy hiçbir anlam taşımaz. Model güvenilir değildir; sistem yanıltıcıdır.

Bu tür hatalar özellikle zaman bağımlı verilerde sık görülür.

Eğer geçmiş ve gelecek karışırsa, veri sırası korunmazsa ya da aynı olayın parçaları farklı setlere dağılırsa, model aslında “zaten olacak olanı” öğrenir. Ama production’da bu bilgi yoktur.

Bu noktada mesele teknik değil, dikkat meselesidir.

Ve çözüm karmaşık değildir—sadece doğru soruları sormak gerekir: “Veri nasıl bölündü?”, “Zaman sırası korunuyor mu?”, “Test seti gerçekten bağımsız mı?” Bu sorular sorulmazsa unutulur, ama sesli dile getirilirse ekip fark eder.

İşte bu yüzden checklistler hayat kurtarır.

Deploy öncesi veri split yöntemi açık mı, zaman bağımlılığı kontrol edilmiş mi, aynı varlığa ait kayıtlar ayrılmış mı ve validation senaryosu production’a benziyor mu—bunların hepsi net olmalı. Ama unutmayın: işaretlemek kolaydır, düşünmek zordur.

En tehlikeli senaryo nedir, biliyor musunuz?

Model çalışır, sonuç üretir… ama yanlış üretir. Ve kimse bunu hemen fark etmez. Bu da iş kararlarını bozar, kullanıcı güvenini zedeler ve sistemin değerini zamanla eritir.

Oysa bu hatayı önlemek için gereken şey çok basitti.

Birinin durup şu soruyu sorması yeterdi: “Bu veri gerçekten doğru şekilde test edildi mi?”

Sonuç olarak şunu unutmayın:

Production’daki en büyük risk sistemin çalışmaması değil, yanlış çalışmasıdır. Çünkü sistem çalışıyorsa kimse durdurmaz—ve hata sessizce büyümeye devam eder.

Her şey doğru görünüyordu. Ama gerçek yanlıştı.