İçerik Kişiselleştirmede Feature Store Kullanımı

Saha notu. Bir gün iki farklı rapor gördük. Aynı gün, aynı kampanya. CTR biri yüksek, diğeri düşük. Model iyi. İçerik iyi. Sorun nerede? Kısa cevap: Özellikler tutarlı değildi. Eğitimi dünün verisi ile yaptık. Yayında ise bugünün akışını aldık. Zaman penceresi farklıydı. Bu küçük fark, öneriyi bozdu. O gün bir karar aldık: özellikleri tek yerde, izli, sürümlü ve hızlı yöneteceğiz. Yani, feature store.

Kişiselleştirme net bir üçgen ister: hız, doğruluk, gizlilik. Hız yoksa anı kaçırırız. Doğruluk yoksa güveni yitiririz. Gizlilik yoksa uyum ve etik riski doğar. Bu yazı bu üçgeni pratik adımlarla kapatır. Kısa, açık, sahadan.

Kullanıcı beklentisi de nettir. Hızlı, alakalı ve saygılı içerik ister. Bunu görmek için “kullanıcı beklentileri ve kişiselleştirme” araştırmalarına bakmak yeter. Peki, bunu nasıl kurarız? Cevap: feature store ile.

90 saniyelik tanım: Feature store nedir, ne değildir?

Feature store, modelin kullandığı “özellik” verisini tek yerde toplar, sürümler, paylaşır ve çok hızlı sunar. Eğitimde (offline) ve yayında (online) aynı tanımı kullanırız. Böylece sonuçlar tutarlı olur. Ekipler aynı özelliği tekrar tekrar yazmaz. Hata azalır, hız artar.

Ama bu bir genel veri ambarı değil. Sadece bir önbellek de değil. Amaç; özellik üretimi, kalite kontrolü, erişim izni, düşük gecikme ile getirme ve izleme işini bir araya toplamaktır. Temel hedef: yeniden kullanım, tutarlılık ve milisaniye düzeyinde yanıt.

Kısa başvuru: Açık kaynak bir örnek için “feature store nedir” sayfasına göz atabilirsiniz.

Mimari: bir çizgi roman gibi

Akış şöyle: veri kaynakları (olay akışları, OLTP, CMS) → özellik boru hattı (temizleme, zenginleştirme, pencereler) → offline depo (eğitim için) ve online depo (yayın için) → istek anında özellik alımı → model skoru → günlükleme ve izleme.

Kenar notu: Tutarlılık en kritik noktadır. Eğitim ve yayın verisi aynı mantık ile üretilmezse “gizli teknik borç” doğar. Bu durumu anlatan klasik bir makale var: ML’de gizli teknik borç. Biz bu borcu, tek kaynak ve sürümlü özellik mantığı ile düşürürüz.

Olay zamanı önemlidir. Kullanıcı tıklar, olay akar, bazıları geç gelir. Pencere (ör. son 30 dk) olay zamanına göre hesaplanmalıdır. Aksi, güncel sanılan veri ile eski veriyi karıştırır. Teknik başvuru için Flink event time kavramına bakın.

Gecikme bütçesi düşünün. Diyelim hedef P95 = 100 ms. Ağ 20 ms, özellik alımı 40 ms, model skoru 30 ms, iş kuralı 10 ms. Biri taşarsa, tüm deneyim donar. Bu yüzden “özellik getirme” yolunu kısa tutmak ve sıcak önbellek şarttır.

Bilgilendirici tablo: hedef, sinyal, hız, risk

Aşağıdaki tabloyu, canlı bir plan olarak düşünün. İlk sütun hedef. Sonra hangi özellikler, hangi kaynaktan, ne sıklıkla güncellenir, gecikme hedefi nedir, gizlilik riski nedir, ve denetim notu.

Soğuk başlangıç içeriği	İçerik embedding, trend skoru, kategori popülerliği	CMS + olay akışı	15 dk	150 ms	Düşük	Embedding v2, onaylı liste
Oturum içi öneri	Son N tıklama, dwell time, cihaz türü	Olay akışı (Kafka)	Gerçek zamanlı	50 ms	Orta	Pencere = 30 dk, idempotent yazım
Spam / risk sinyali	Hızlı tekrar, anormal kalıp, yaş/doğrulama bayrağı	OLTP + akış	1 dk	20 ms	Yüksek	Erişim kayıtlı, rol bazlı yetki
Kampanya kişiselleştirme	RFM skoru, son satın alma, ilgi kategorileri	Ambar + akış	24 saat	100 ms	Orta	Segment sürüm = 1.3, onay tarihi

Özellik grupları ve tazeleme stratejisi

Kısa vadeli sinyaller: oturum olayları, son tıklama, geri dönüş süresi. Bu sinyaller hızlı yaşar, hızlı solar. Akış temelli ürünler ile gerçek zamanlı üretin. Tamlık için “exactly-once” semantiği ya da en azından idempotent yazım gerekir. Bu konuda Kafka işlem semantiği iyi bir referans.

Orta vadeli sinyaller: RFM, kategori ilgisi, cihaz ve konum. Bunlar saatlik/günlük tazelenir. Offline depoda saklanır, online depoya sıcak özet atılır. Ani dalgalanma varsa, eşik ile kontrol edin.

Embedding’ler: Hem içerik hem kullanıcı için embedding üretin. Metin için Sentence-Transformers gibi araçlar iş görür. Embedding sürümünü mutlaka etiketleyin (ör. emb_v3). Aynı anda iki sürüm ile A/B yapabilirsiniz.

Veri sözleşmesi (data contract) şart. Şema değişirse, kırılma olmasın. Hangi alan, hangi tip, hangi aralık, kim sorumlu? Standart için data contracts rehberine bakın. Kısa kural: “sözleşme bozulursa, boru tıkanır; tıkanırsa, öneri düşer”.

Gizlilik ve güvenlik: KVKK’ya pratik uyum

Asgari veri ilkesi ile başlayın: iş için gerekenden fazlasını almayın. Takma ad (pseudonym) kullanın. Yaş ve yer gibi hassas alanları ayrı tutun. Erişim, rol bazlı olsun. Türkiye için resmi kaynak: KVKK rehberleri. AB’ye hizmet veriyorsanız, EDPB GDPR yönergeleri ile uyumu da kontrol edin.

Onay yönetimi net olsun. Kullanıcı “kişiselleştirme” iznini verirse, hangi özellik grupları açılır? Geri alırsa, ne olur? Bu akış feature store’da “etiket” bazlı yönetilebilir. Log’ları saklayın. Denetimde hayat kurtarır.

Kenar notu: Bazı dikeyler regüle. Kumar, sağlık, finans gibi. Bu alanlarda yaş doğrulama ve sorumlu içerik kuralları net yazılmalı. Kural kodda olmalı. İnsan hatası beklemeyin.

Model stratejileri: hızlı uyum ve derin bağlam

Başlangıçta keşif gerekir. Çok kollu haydut (bandit) yöntemleri hızlı öğrenir. Anlatımı net bir kaynak: multi-armed bandit kılavuzu. Bandit ile ilk seçimi yapın, sonra sıralama modeline verin.

Sıralama tarafında karma model iyi işler. Lineer ve derin katmanı birleştiren Wide & Deep gibi yapılar pratik ve güçlüdür. Büyük ölçek örneği için “YouTube Recommendations makalesi” yol gösterir.

Metrikler net olsun: CTR, dwell time, session success. Etkiyi görmek için A/B test şart. Ama hatası bol bir alan. İyi bir uyarı listesi için “A/B testte yapılan hatalar” yazısı iyidir.

Kısa risk notu: Çevrim içi öğrenme yapıyorsanız, geçici önyargı birikir. İçerik tarafı da etkilenir. Bu yüzden önyargı göstergeleri (örn. aynı kaynağı çok vurma) için sınır koyun.

Mikro-vaka: regüle bir içerik portalı

Somut bir örnek düşünelim. Bir kumar inceleme portalı. Burada lisans, yaş sınırı ve “sorumlu oyun” ilkesi kritik. Biz bu sahada şöyle çalıştık: yeni kullanıcıya temel rehber ve uyarı gösterdik; deneyimli kullanıcıya ise detaylı sağlayıcı analizi sunduk. Bu seçimi, feature store’daki segment ve risk sinyali ile yaptık. Bir sayfa örneği için online casino rehberi içeriği gibi bölünmüş sunum fikrini düşünebilirsiniz. Burada amaç, kişiselleştirme ile hızlı değer verirken, etik çizgiyi korumaktır.

Risk yönetimi çerçevesi de net olmalı. Devlet ya da iç kontrol bakınca, kural ve kanıt görmek ister. Bu yaklaşım için geniş bir çerçeve: NIST AI Risk Management Framework. Kendi bağlamınıza uyarlayın: yaş doğrulama, bildirim, limit uyarısı, açıklanabilirlik kaydı.

Operasyon ve izleme: yangın çıkmadan dumanı gör

Üretimde model ve özellik izleme bir disiplindir. Veri kayması, özellik eksikliği, pencere hatası, gecikme artışı… Hepsini toplayın. TFX gibi üretim hatları bu işte yardımcıdır: TFX ile üretimde ML. Özellik seviyesi metrikleri de ekleyin: null oranı, dağılım değişimi, p95 gecikme.

Açıklanabilirlik notları tutun. “Bu içerik neden önerildi?” sorusuna kısa bir cevap verin. Örneğin “son 10 tık içinde benzer konu arttı + içerik skoru yüksek” gibi. Bu sadece güven için değil, hatayı bulmak için de gereklidir.

Post-mortem (kısa). Bir gün öneri sayfasında tekrarlar arttı. Sebep: pencereyi olay zamanı yerine işlem zamanına göre almışız. Geç gelen olaylar pencereden düşmüş. Çözüm: olay zamanı penceresi + su işareti (watermark) ve özellik sürümünü v3’e çektik. Denetim notu eklendi. Bu kayıt, yeni gelen mühendise bir saat kazandırdı.

Mini sözlük

Feature: Modelin girdi sinyali. Örn. son tıklama sayısı.
Feature store: Özelliklerin ortak ve hızlı deposu.
Event time: Olayın gerçekten olduğu an.
Exactly-once: Bir olayı tek kez işler gibi güvence.
Embedding: İçeriği ya da kullanıcıyı sayısal vektör ile gösterme.
Bandit: Keşif-yaklaşım dengelemesi yapan yöntem.

SSS

Feature store olmadan da kişiselleştirme yapabilir miyim?

Evet, küçük ölçekte mümkündür. Ama ekip ve veri büyüyünce, tutarlılık ve hız sorun olur. Feature store bu noktada kaldıraç sağlar.

Hangi özellik ile başlamalıyım?

Oturum içi sinyaller (son tıklama, dwell time) en hızlı faydayı verir. Sonra embedding ekleyin. Ardından segment ve RFM ile zenginleştirin.

KVKK uyumu nasıl garanti edilir?

Asgari veri, açık onay, rol bazlı erişim, silme talebi akışı ve denetim logu. Riskli alanları etiketleyin, kullanımı kısıtlayın.

A/B test ne kadar sürmeli?

Trafik ve etki büyüklüğüne bağlıdır. İstatistiksel güç olmadan karar vermeyin. Yanılgılardan kaçınmak için yukarıda verdiğimiz “A/B testte yapılan hatalar” yazısını okuyun.

Online ve offline tutarlılığı nasıl ölçerim?

Aynı kullanıcı-id için, aynı zaman penceresinde, eğitim ve yayın özelliğini karşılaştırın. Fark belirli eşiği aşarsa alarm üretin.

Uygulama kontrol listesi

Hedef ve metrikler yazıldı (CTR, dwell, lift).
Özellik kataloğu açıldı; tanım, sahip, sürüm eklendi.
Event time pencereleri ve geç veri politikası net.
Online depo için P95 gecikme bütçesi belirlendi.
KVKK ve GDPR etiketleri tanımlandı; erişim rolleri atandı.
Embedding sürümleme ve soğuk/ılık start planı hazır.
Bandit + sıralama hattı kuruldu; güvenli keşif sınırı kondu.
İzleme panelleri açıldı: veri kayması, null, gecikme, throughput.
A/B test planı yazıldı; durdurma kuralı belirlendi.
Post-mortem şablonu hazır; olay günlüğü saklanıyor.

Kısa özet

İçerik kişiselleştirme; hız, tutarlılık ve gizlilik dengesi ister. Feature store bu dengeyi sağlar. Özellikleri tek yerde toplar, sürümler, paylaşır ve hızlı sunar. Olay zamanı ve pencere doğru kurulursa, yayın ve eğitim eşleşir. Gizlilik için asgari veri ve açık onay şarttır. Model katmanında bandit ile keşif, Wide & Deep ile derin bağlam iyi bir ikilidir. İzleme ve post-mortem ise sürekli kalite sağlar.

Hızlı referanslar (metin içinde geçenler)

Google: kullanıcı beklentileri ve kişiselleştirme
Açık kaynak: feature store nedir
Teknik borç: ML’de gizli teknik borç
Olay zamanı: Flink event time
İşlem semantiği: Kafka işlem semantiği
Gizlilik: KVKK rehberleri, EDPB GDPR yönergeleri
Model: multi-armed bandit kılavuzu, Wide & Deep, YouTube Recommendations makalesi
A/B test: A/B testte yapılan hatalar
Üretim ML: TFX ile üretimde ML
Veri sözleşmeleri: data contracts
Embedding: Sentence-Transformers
Risk: NIST AI Risk Management Framework

Kapanış. Küçük başlayın: bir hedef, üç özellik, tek metrik. Feature store’u bu dar alana koyun. Sonuç gelince genişletin. Her geniş adımda sözleşme, gizlilik ve izleme ekleyin. Böylece hızla ilerler, güveni korur, etkili ve sorumlu kişiselleştirme sunarsınız.

İsim:
Yorum:	En fazla 1000 karakter