Bakım tahmininde model geleceğin bilgisini kullanıyor olabilir mi?

Geçmiş tabloda görünen her alan geçmişte biliniyor değildi

Bakım kayıtlarını birleştirdiniz ve deneme modeli arızalı haftaları kolayca buldu. Özellikler arasında onarım süresi ve son kök neden kodu da var. Bu alanlar bugünkü veri tabanında aynı satırda duruyor olabilir; ancak tahmin yapılması gereken anda henüz oluşmamışlardı. Model, geleceği öngörmek yerine sonuçlandıktan sonra doldurulan kayıtları okuyorsa ölçülen başarı gerçek kullanım görevini temsil etmez.

Aşağıdaki uygulama sentetik bir veri hazırlığı incelemesidir. Model eğitmiyor, arıza olasılığı veya bakım kararı üretmiyoruz. Çıktı, hangi alanın hangi tahmin anında kullanılabileceğini açıklayan bir matristir. Bu kontrolü erken yapmak, bir veri setini yalnızca doluluk oranı ve satır sayısıyla uygun kabul etmenizi önler. Zaman bakımından yanlış bir sütun, eksiksiz olduğu için daha da yanıltıcı olabilir.

scikit-learn belgeleri, tahmin sırasında erişilemeyecek bilginin model geliştirmeye girmesini veri sızıntısı olarak ele alır; ön işleme ve özellik seçiminin test verisiyle öğrenilmemesini de vurgular. Bu yazı o ilkeyi bakım kayıtlarının zaman alanlarına uygular. Verilen tarihler ve alan kararları eğitim örneğidir; bütün bakım sistemleri için hazır bir veri sözleşmesi değildir.Kaynak: scikit-learn — Veri sızıntısı ve yaygın hatalar

Karar anını ve hedef penceresini açık yazın

Tahmin anı: 10 Şubat 2026, 08.00; bütün saatler aynı yerel saat diliminde.
Hedef: Bu andan başlayıp 17 Şubat 08.00'den önce gerçekleşecek arıza kaydı var mı?
Girdi sınırı: Tahmin anından önce sisteme ulaşmış ve yalnızca geçmişi anlatan bilgi.
Çıktı: Bu yazıda tahmin üretilmez; alanların kullanım uygunluğu incelenir.

İki zaman bilgisine ihtiyaç vardır: olayın ne zaman olduğu ve kaydın sisteme ne zaman ulaştığı. Operatör 07.30’da bir gözlem yapıp 09.15’te sisteme girdiyse 08.00’de çalışan model o kaydı kullanamaz. Bugünkü arşivden geriye dönük veri hazırlarken yalnızca gözlem saatine bakmak bu gecikmeyi saklar. Kaynak sistem bu ikinci zamanı tutmuyorsa kullanılabilirliği kesin doğrulayamadığınızı kaydedin.

Pencere sınırını da netleştirin. Burada başlangıç dahil, bitiş hariç yedi günlük aralık kullanıyoruz. Tam 17 Şubat 08.00’deki olay bu tahminin hedefi değildir. Bir sonraki pencereye geçebilir. Sınırlar belirsiz bırakılırsa aynı olay farklı ekiplerce farklı etiketlenir ve veri incelemesindeki uyuşmazlık model hatası gibi görünebilir.

Sütunları zaman kanıtıyla elekten geçirin

Alan adı tek başına yeterli değildir. ‘Son yedi gün ortalaması’ geçmişten hesaplanmış görünebilir; fakat sonradan düzeltilen ölçümler kullanılarak yeniden hesaplandıysa 08.00’deki gerçek değeri temsil etmeyebilir. Tabloya bu nedenle koşul ekledik. Tarihsel kopya veya o andaki kaynak sürümü yoksa veri mühendisiyle hangi değerin gerçekten erişilebilir olduğunu doğrulayın.

Onarım süresi hedefi oluşturmaya yardımcı bir kayıt olabilir; bu onu tahmin girdisi yapmaz. Etiket hazırlama için kullanılan sonradan oluşmuş alanlarla modele verilecek özellikleri ayrı tutun. Aynı geniş tabloda saklanmaları mümkün olsa da özellik listesi açık olmalıdır. ‘Kimlik hariç bütün sütunları kullan’ gibi bir istem, bu ayrımı ortadan kaldırabilir.

Yapay zekâdan tahmin değil alan gerekçesi isteyin

Verilen sentetik tahmin anı ve alan tablosunu incele. Her alan için olay zamanı, sisteme ulaşma zamanı, kapsanan dönem ve tahmin anında bilinebilirlik gerekçesi yaz. Gelecekte oluşan veya sonradan gelen alanı girdi listesine alma. Kanıtı eksik alanı belirsiz bırak. Etiket üretiminde kullanılabilecek bilgiyle model girdisini karıştırma. Model başarısı, arıza olasılığı veya bakım talimatı üretme. Sonuç olarak kabul, red ve ek doğrulama listesi ver.

Kabul adayı: Son sayaç değeri.
Koşullu aday: Geçmiş yedi gün ortalaması; kaynakların zamanında geldiği doğrulanmalı.
Bu tahminde red: Geç girilen operatör notu, onarım süresi, kök neden kodu, geleceği içeren haftalık ortalama.
Açık kontrol: Sonradan düzeltmelerin tarihsel değerleri değiştirip değiştirmediği.
Bu liste veri kalitesinin bütün boyutlarını veya model yeterliliğini onaylamaz.

Tablodaki kararları modelden bağımsız olarak zaman çizelgesine yerleştirin. 07.52, 08.00’den öncedir; 09.15 sonradır. 12 ve 13 Şubat kayıtları da karar anından sonra oluşur. Bu basit sıralama, etkileyici bir açıklamanın gizlediği mantık hatasını yakalar. Gerçek kayıt saatleri farklı dilimlerdeyse önce ortak zaman standardına dönüştürüp dönüşümü kaydedin.

Alan kontrolünü veri bölme kontrolüyle tamamlayın

Doğru alanları seçmek test kümesinin bağımsızlığını tek başına sağlamaz. Örneğin geliştirme verinizin etiketlerinin 31 Ocak 08.00’e kadar tamamlanmış olmasını istiyorsanız yedi günlük hedef için en geç 24 Ocak 08.00 tahmin anını kullanabilirsiniz. 30 Ocak tahmini, şubat olaylarını hedef olarak içerir. Yalnızca tahmin tarihine göre ayırıp hedef penceresini unutmayın.

Örnek bir düzen, bu sınıra uyan geçmiş kayıtlarla geliştirme, şubatta ayrı doğrulama ve daha sonra martta ayrılmış son test dönemi kullanmaktır. Aynı arıza olayının veya çok benzer komşu pencerelerin iki gruba taşınıp taşınmadığını inceleyin. Ölçekleme, eksik değer doldurma veya özellik seçimi öğrenilecekse yalnızca geliştirme verisiyle öğrenin; son test sonucuna bakarak tekrar tekrar seçim yapmak testi de geliştirme aracına dönüştürür.

Küçük alıştırma: Operatör notunun sisteme girişini 07.45 yapın, içeriğini ve olay saatini koruyun. Bu alan zaman bakımından kullanılabilir aday olur. Ancak gelecekteki onarım süresi hâlâ reddedilir; bir kaydın düzelmesi bütün tabloyu geçerli yapmaz. Son çıktınızı alan listesi, zaman gerekçeleri, belirsiz kayıtlar ve değerlendirme dönemleriyle tamamlayın. Model kurma kararı ancak bu veri sözleşmesi netleştikten sonra daha anlamlı hale gelir.