Özellik Deposu (Feature Store) Mimarisi: Çalışan Üç Yapı

MLOps mlops, feature-store

Feature store bir veritabanı değil kütüphanedir. Canlıda çalışan üç mimari şekil ve ekibinizin ölçeğine göre doğru olanı seçtiren mühendislik kriterleri.

  • Yazar: Orzed Team
  • 1 dk okuma
Önemli çıkarımlar
  • Eğitim-sunum sapması (training-serving skew) en yaygın canlı ML hatasıdır ve feature store doğrudan bunu çözer.
  • Küçük ekipler için mevcut veri ambarı üzerindeki 200 satırlık bir kütüphane, ağır bir feature store kurulumundan çok daha iyidir.
  • Feast sınıfı kendi barındırdığınız çözümler, aynı özellikleri paylaşan birden fazla ML ekibi olduğunda doğru orta yoldur.
  • Yönetilen (managed) sistemler, özellik hacmi ve milisaniye altı sunum gecikmesi altyapı maliyetinden daha kritik olduğunda değerini çıkarır.

Üç yıldır ML platformunu ölçekleyen bir müşterimizde, dokuz canlı modelin dokuz farklı ekip tarafından yönetildiğini gördük. Denetimin ilk haftasında user_lifetime_value (kullanıcı yaşam boyu değeri) özelliğinin bu dokuz modelde altı farklı şekilde tanımlandığını keşfettik: üçü 30 günlük pencere, ikisi 90 günlük pencere kullanıyor, sadece ikisi iadeleri düşüyordu. Finansın LTV raporuyla ML ekibinin tahminleri hiçbir zaman tutmuyordu.

Bir özellik deposu (feature store) tam olarak bu iki işi yapar: çevrimdışı eğitim ile çevrimiçi sunumda aynı varlık için birebir aynı değerin üretilmesini (training-serving consistency) ve bir ekibin yazdığı özelliğin diğer ekiplerce yeniden kullanılmasını sağlar.

Canlıda Çalışan Üç Mimari Şekil

  1. Şekil 1: Veri ambarı üzerinde ince kütüphane. 1 ila 3 ML mühendisi ve 1 ila 3 modeli olan küçük ekipler için feature store, veri ambarı üzerinde çalışan 200 satırlık bir Python kütüphanesidir. Eğitim ve sunum aynı fonksiyonu (as_of zaman parametresiyle) çağırır. Tek doğruluk kaynağı koddur, ek altyapı gerektirmez ve 50-500 ms sorgu gecikmesinin kabul edilebilir olduğu her yerde çalışır.
  2. Şekil 2: Kendi barındırdığınız Feast sınıfı sistem. 5 ila 20 mühendisli ve çoklu modelli ekiplerde, özellik tanımları kodda kayıtlıdır; eğitim için çevrimdışı ambar (Snowflake, BigQuery), düşük gecikmeli canlı sunum için çevrimiçi depo (Redis, DynamoDB) kullanılır. Zamanda nokta (point-in-time) doğruluğunu ve tek haneli milisaniye gecikmesini sağlar; kurulumu 4 ila 12 hafta sürer.
  3. Şekil 3: Yönetilen (Managed) özellik deposu. Tecton, Vertex AI veya Databricks Feature Store gibi platformlar operasyonel yükü, izlemeyi ve milisaniye altı sunumu üstlenir. 12’den fazla modeli, yüksek QPS ihtiyacı veya ağır denetim şartları olan kurumsal yapılarda, 3 kişilik bir platform ekibinin zaman maliyetinden daha ucuza gelir.

Yapay Zeka Çağı Özellikleri ve Doğru Geçiş

Gömme vektörleri (embeddings) ve LLM ile türetilmiş nitelikler klasik tablosal özellik depolarına doğrudan uymaz; vektörler ayrı bir vektör veritabanında, LLM nitelikleri ise hız sınırlı ayrı boru hatlarında tutulmalıdır. Yeni başlayan bir ekip Şekil 1 ile başlamalı, model sayısı üçü geçtiğinde Şekil 2’ye geçecek şekilde özellik şemalarını baştan temiz tanımlamalıdır.

Sıkça sorulanlar

Sıkça sorulan sorular

Gerçekten bir özellik deposuna (feature store) ihtiyacımız var mı?

Tek modeliniz ve tek veri bilimciniz varsa hayır. Ancak kullanıcı, ürün veya hesap gibi ortak varlıkları paylaşan üç veya daha fazla modeliniz varsa evet; aksi takdirde özellik tanımları modeller arasında ayrışır.

Çevrimiçi (online) özellik sunumu her zaman zorunlu mudur?

Hayır. Saatlik güncellenen öneri sistemleri veya gecelik skorlanan dolandırıcılık sinyalleri gibi pek çok model toplu (batch) modda gayet iyi çalışır. Çevrimiçi sunum altyapı maliyeti ekler; yalnızca düşük gecikme gerçekten zorunluysa kurun.

Özellik depoları LLM'lerle nasıl çalışır?

LLM'ler tablosal özellikleri klasik ML gibi tüketmez. Ancak bazı ekipler kullanıcı paketi, hesap durumu veya son aktiviteler gibi meta verileri LLM istemlerine hızlıca enjekte etmek için mevcut feature store yapılarını başarıyla kullanmaktadır.