Özellik deposu (feature store) kurma ve kullanma rehberi

Feature store hangi sorunu çözer?

Makine öğrenmesi projelerinde modeller girdi olarak özellikler kullanır: müşterinin son dönem alışveriş sayısı, bir cihazın ortalama sıcaklığı, bir hesabın hareket yoğunluğu gibi. Bu özellikler ekipler büyüdükçe farklı sorunlara yol açar. Bunlardan biri tekrar üretimdir: Aynı özelliği farklı ekipler kendi betikleriyle yeniden hesaplar, tanımlar zamanla ayrışır. Bir diğeri tutarsızlıktır: Eğitimde defter üzerinde hesaplanan özellik, canlı serviste başka bir kodla hesaplanır ve model üretimde eğitimde gördüğünden farklı girdi alır. Bu duruma eğitim-servis sapması denir ve sessiz kalite düşüşlerinin sık nedenidir.

Feature store, özelliklerin tanımlandığı, hesaplandığı, saklandığı ve hem eğitime hem canlı servise tek kaynaktan sunulduğu ortak bir katmandır. Böylece özellik bir kez tanımlanır, tekrar kullanılır, sürümlenir ve hem geçmiş veriden eğitim kümeleri üretmek hem de milisaniye düzeyinde canlı sorgu yapmak mümkün olur.

Temel kavramlar: tanım, çevrimdışı depo, çevrimiçi depo

Feast gibi açık kaynak özellik deposu araçlarının dokümantasyonunda geçen kavramlar, bu yapının iskeletini gösterir. Bir varlık (entity), özelliklerin ilişkili olduğu nesnedir: müşteri, ürün, cihaz gibi. Özellik görünümü (feature view), bir veri kaynağına bağlı bir ya da birden çok özelliği tanımlar; eğitim kümesi üretilirken ve çevrimiçi depoya değer taşınırken bu veri kaynağı kullanılır. Özelliklerin çevrimiçi depoya aktarılmasına Feast terminolojisinde materialization denir.

Çevrimdışı depo geçmiş özellik değerlerini büyük hacimde tutar; genellikle veri ambarı ya da veri gölü üzerinde çalışır ve eğitim kümesi üretmek için kullanılır. Çevrimiçi depo ise her varlığın güncel özellik değerini hızlı okuma için saklar; canlı serviste tek bir kayıt, düşük gecikmeyle çekilir. Aynı özellik tanımı çevrimdışı ve çevrimiçi depoyu birlikte besler. Dokümantasyondaki ayrıntılar kullandığınız ürüne göre değişir; ürün seçerken bu kavramların karşılığına bakmak yeterlidir.

Zaman doğruluğu: eğitim verisinde sızıntıyı önlemek

Özellik depolarının önemli bir değeri, eğitim kümesini zamana duyarlı üretmesidir. Bir müşterinin geçen ay verdiği siparişle ilgili tahmin modeli eğitiliyorsa, her örnek için yalnızca o tarihte bilinebilecek özellik değerleri kullanılmalıdır. Örneğin tahmin anından sonraki bir alışveriş, özellik hesabına karışırsa model gerçek hayatta elde edemeyeceği bilgiyle eğitilmiş olur. Bu veri sızıntısı, test sonuçlarını olduğundan iyi gösterir ve üretimde hayal kırıklığı yaratır.

Zaman noktası doğru birleştirme (point-in-time join) bu sorunu çözmek için kullanılan yaklaşımdır: Her etiketli örnek için, örnek tarihinden önceki en son özellik değeri birleştirilir. Özellik deposu bu mantığı kendi içinde yönettiğinde, her ekibin kendi tarih filtresini yazması ve hata yapması gerekmez. Aracı değerlendirirken geçmişe dönük birleştirmenin nasıl yapıldığını ayrıca kontrol edin.

Adım adım kurulum

Feature store kurulumu genellikle şu sırayla ilerler.

• İhtiyacı doğrulayın: Birden çok model aynı özellikleri kullanıyor mu? Eğitim-servis sapması yaşıyor musunuz? Canlı serviste düşük gecikmeli özellik okuması gerekiyor mu? Yanıtlar hayır ise tam bir feature store gereksiz yük olabilir.
• Varlıkları ve özellikleri tanımlayın: Anahtar alanları, özellik adlarını, veri türlerini ve sahiplerini netleştirin. Tanımlar kodda ve sürüm kontrolünde tutulur.
• Veri kaynaklarını bağlayın: Toplu özellikler veri ambarı ya da gölünden, akış özellikleri mesaj kuyruğu ya da olay akışından beslenir.
• Hesaplama mantığını tek yerde yazın: Aynı dönüşüm hem eğitimde hem servis tarafında kullanılır.
• Çevrimiçi depoyu doldurun: Zamanlanmış işlerle güncel değerler çevrimiçi depoya taşınır; tazelik beklentisini her özellik için belirleyin.
• Eğitim hattına bağlayın: Eğitim kümeleri depodan, zaman doğruluğuyla üretilsin.
• Servise bağlayın: Model servisi, çevrimiçi depodan varlık anahtarıyla özellik okusun.
• İzleyin: Özellik tazeliği, boş değer oranı ve dağılım değişimi için uyarı kurun.

Örnek: kayıp riski modelinde ortak özellikler

Örneğin bir abonelik şirketi, müşteri kaybı tahmini yapan bir model ve ayrıca kampanya hedefleme için başka bir model kullanıyor olsun. Her model "son dönem destek talebi sayısı", "son giriş tarihinden bu yana geçen süre" ve "ortalama kullanım yoğunluğu" gibi özelliklere ihtiyaç duyuyor.

Özellik deposu olmadığında ekipler bu özellikleri ayrı ayrı hesaplar; "son dönem" tanımı bir yerde takvim ayı, diğerinde kayan pencere olur. Canlı serviste kullanılan kod da eğitimdeki defterden farklı yazıldığı için modelin üretimdeki girdileri eğitimde gördüğünden ayrışır.

Feature store kurulduğunda özellik tanımları tek yerde yazılır, modeller ortak özellikleri okur. Eğitim kümesi geçmiş tarihlere göre doğru birleştirilir, servis anında çevrimiçi depodan müşteri anahtarıyla güncel değerler çekilir. Bir tanım düzeltildiğinde modeller bundan faydalanır ve değişiklik tek sürüm kaydında izlenir.

Sık yapılan hatalar

Özellik deposu projelerinde tekrar eden hatalar şunlardır:

• İhtiyaç olmadan kurmak: Tek modelli, küçük bir projede ek altyapı yük getirir; ortak bir özellik modülü yeterli olabilir.
• Tazelik beklentisini belirlememek: Çevrimiçi depodaki değerin ne kadar eski olabileceği her özellik için tanımlı olmalıdır.
• Özelliklere sahip atamamak: Sahipsiz tanımlar eskir ve güveni azaltır.
• Eğitim ile servis hattını farklı kodla kurmak: Depo, bu ayrımı kaldırmak için vardır.
• Zaman doğruluğunu kontrol etmemek: Gelecek bilgisinin eğitim verisine sızması fark edilmeden kalabilir.
• Aşırı genelleştirmek: Her olası özelliği depoya doldurmak; yalnızca yeniden kullanılacak ve üretimde gerçekten gerekli olanları almak daha sağlıklıdır.

Başlangıç için bir iş problemi ve az sayıda yüksek değerli özellikle küçük bir pilot kurmak, ekibin yaklaşıma alışmasını sağlar.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

MLOps Mühendisliği Sertifika Programı, "Özellik Mühendisliği ve Feature Store" modülünü içerir; program ayrıca deney takibi ve model versiyonlama, veri boru hatları ve veri kalitesi, model izleme ve sapma tespiti, yeniden eğitim otomasyonu gibi çevre konuları kapsar. Uçtan Uca MLOps Referans Mimarisi eğitiminde "Veri Hattı ve Öznitelik Deposu (Feature Store)" modülü yer alır.

Bu içerik, makine öğrenmesi modellerini üretime taşıyan veri mühendisleri, ML mühendisleri ve platform ekipleri için uygundur; kurumsal ekiplerde veri bilimi ile mühendislik arasındaki ortak özellik tanımı sorununu çözmek isteyen yapılara da zemin sağlar.