Eğitimde gördüğünü üretimde görmemek: Uber’in özellik loglama çerçevesi
Taming the ML Firehose: Scaling Feature Consistency
Uber'in hedefi net: çıkarım anında kullanılan özellikler, bir sonraki model yinelemesini eğitirken kullanılan özelliklerle aynı olsun. Tek doğruluk kaynağı, daha güçlü model performansı ve sorunların daha hızlı tespiti demek.
Problem sinsi: çevrimiçi ve çevrimdışı hatlar özellikleri farklı hesaplayıp tüketebiliyor. Model eğitimde sabit bir sözlükten öğreniyor (örneğin dil kodları en-US, fr-FR), ama servis anında aynı özellik en olarak gelebiliyor. Çevrimdışı hat da biçim farkı üretebiliyor (jp_JA ile jp-JA). Sonuç: model, servis sırasında hiç görünmeyen kategorilerden öğrenmiş oluyor ve güçlü sinyaller sessizce bozuluyor. Dağılımlar kayıyor, tahmin kararlılığı düşüyor ve görünür hiçbir hata yok. Ek sorunlar: birbirine bağımlı ETL işlerinden oluşan kırılgan veri hatları (eksik bölümler, sessizce bozulan eğitim verisi), çok günlük tazelik gecikmeleri ve geliştiricilerin sorunları anlamak için haftalar harcaması.
Çözüm özellik loglama: çıkarım anında modele giden gerçek özellikleri kaydedip eğitimde onları kullanmak. Ölçek ise başlı başına sorun. Transformer tabanlı öneri sistemleri saniyede 8 milyon sorguya ulaşıyor; her tahminin özelliklerini loglamak günde yüz milyarlarca kayıt, ayda 5 trilyon satır ve günde yaklaşık 1,7 PB demek. Restoran öneri modeli için tüm özellikleri yollamak saniyede yaklaşık 9,3 GiB ve mevcut Kafka kümelerinin çok üstünde.
Çevrimiçi mimarideki çözümler: özellik izin listesi (modelin kullanmadığı özellikleri loglamamak) yük boyutunu 4-5 kat düşürüyor; özellik adı takma adları: uzun adlar (store_unique_identifier_operational_meal_period_context_key) serileştirmede kompakt tamsayı kimliklere çevriliyor; gösterim filtreleme: sıralamaya giren adayların yalnızca yaklaşık %40'ı filtre sonrası kalıyor ve onların da yalnızca %5'i gerçekten gösterime dönüşüyor, o yüzden Flink'te tahminler istemci olaylarıyla zaman pencereli olarak birleştirilip yalnızca gerçekten gösterilenler tutuluyor.
Flink işini ölçeklemek de öğreticiydi. Paralelliği körü körüne artırmak işe yaramadı: her operatör ayrı profillendi ve birleştirme öncesi operatörlere 512, birleştirmeye 768 paralellik (Uber'in en büyük Flink dağıtımı) verildi. Varsayılan RocksDB kontrol noktası saatte 12 TB'ı aşarak bulut yazmalarını başarısız kıldı; çözüm özel durum yönetimi: yalnızca gerekli metadata'yı tutmak, birleştirmeden hemen sonra kayıtları atmak ve tekrarları silmek. Nesne yeniden kullanımı, tipli yükler, yapılandırma önbelleği ve daha az serileştirme gibi küçük iyileştirmeler tepe tüketici gecikmesini yaklaşık %70 düşürdü.
Öne çıkanlar
- Training-serving skew hata vermez, sessizce kaliteyi düşürür; bu yüzden en tehlikeli ML hatalarından.
- Tek doğruluk kaynağı: eğitimde, servisin gördüğü özellikleri kullan.
- Her veriyi loglama: modelin kullandığı özellikler ve gerçekten gösterilen adaylar yeterli.
- Uzun metin adları yerine tamsayı kimlik: milyarlarca kez gönderilen şeyde bayt başına maliyet çarpılır.
- Paralellik artırmak yetmez; her operatörü ayrı profillendir. Varsayılan kontrol noktası stratejisi ölçekte patlayabilir.
Neden önemli?
ML sistemlerinin üretimde en sık kırıldığı yer model değil, modelin besleme hattıdır. Hata genelde ‘kod çalışıyor ama değerler farklı’ biçiminde gelir ve aylarca fark edilmez. Çözüm, eğitim verisini servisten elde etmek: iki ayrı hesaplamayı birbirine denk tutmaya çalışmak yerine tek hesaplamayı iki yerde kullanmak.
Sende karşılığı
Bu, Tradebot’un en kritik sorusu: backtest’te kullandığın özellikler canlıda hesapladıklarınla birebir aynı mı? Backtest için toplu (Pandas) bir kod, canlı için ayrı bir akış kodu yazdıysan, iki kodun farklı yuvarlama, farklı zaman penceresi ya da farklı eksik veri davranışı vardır. Paper/shadow execution’ın değeri de burada: canlıda karar anında hesaplanan özellikleri logla ve sonraki backtest’i o loglarla yap. Aynısı DBH’daki gibi kategori kodlayan her LLM hattında geçerli: eğitimde gördüğün 'Fuel' ile üretimde gelen 'fuel ' farklı kategoridir; girdileri normalize edip şemayla doğrula.
Sözlük
- training-serving skew eğitim-servis uyumsuzluğu
- Modelin eğitimde gördüğü özelliklerle üretimde gördüklerinin farklı hesaplanması; sessiz kalite kaybına yol açar.
- feature store özellik deposu
- Model özelliklerinin tutarlı biçimde saklandığı ve hem eğitime hem servise sunulduğu merkezî katman.
- allow list izin listesi
- Yalnızca açıkça listelenen öğelerin kabul edildiği filtreleme yaklaşımı.
- windowed join pencereli birleştirme
- Akış verilerini, belirli bir zaman penceresi içinde gelen karşılıklarıyla eşleştirme.