3 Kasım 2026, Salı

F3 (Facebook Feature Framework), Meta’nın reklam ranking modellerinin altındaki ML feature’larını yazma, derleme ve sunma çerçevesi; tek bir istek 20.000’den fazla feature gerektirebiliyor. ML sistemleri ham veriyi doğrudan tüketmez: bir modelin tahmin yapmadan önce depolanmış sinyalleri okuması, olayları bir zaman penceresine göre filtrelemesi, sayması ya da toplaması, normalleştirmesi ve ara sonuçları birleştirmesi gerekir. En basit tasarım her feature’ı bağımsız bir fonksiyon sayar ama ölçekte bu israftır, çünkü feature’lar hesaplama açısından bağımsız değil: yedi günlük tıklama sayısı ile yedi günlük gösterim sayısı aynı olay kaynağını okuyup aynı zaman filtresini uygulayabilir ve bir tıklama oranı feature’ı ikisini yeniden kullanabilir.

F3’ün çözümü bir DAG. Feature çıkarımı, her düğümün bir işi (girdi okuma, filtre, toplama) yaptığı ve kenarın bir hesaplamanın başka bir hesaplamanın sonucuna bağlı olduğunu gösterdiği bir yönlü döngüsüz graf (directed acyclic graph). Mühendisler her feature’ı bağımsız yazıyor; F3 derleyicisi her tanımı küçük bir grafa çevirip bir servisin kullandığı tüm feature’ların graflarını tek bir merged graph’ta birleştiriyor. İki feature’ın paylaştığı işlem (yedi günlük filtre gibi) tek düğüme indirgeniyor ve istek başına bir kez çalışıyor.

Bedeli: her release hep-ya-da-hiç. Merged graph hesaplamayı verimli paylaştırdı ama aynı zamanda release birimi oldu: bozuk tek bir tanım diğer tüm feature’ların çıkışını engelleyebiliyordu. Yazının örneği: A’dan G’ye yedi feature var, beşi geçerli, D ve G ilgisiz hatalar içeriyor. İlk deneme D’de fail ediyor, yedisi de çıkmıyor; D düzeltilince ikinci deneme G’de fail ediyor; ancak üçüncü denemede tüm graf production’a ulaşıyor. F3 birkaç yüz feature’ı sunarken merge’ler çoğunlukla başarılıydı; bugün 20.000’den fazla feature var ve farklı feature türleri kendi kontrollerini gerektiriyor. Merged graph üzerinde yapılan her iyileştirme release hızını bir süre geri getirdi ama feature’lar eklendikçe kazanç eridi, çünkü hepsi hâlâ birlikte çıkıyordu.

F3 Lightning iki değişiklik getiriyor. *Deployment granularity:* her feature, doğrulanabilen, yayınlanabilen ve geri alınabilen bağımsız bir konfigürasyon. Derleyici her feature’ı kendi başına, komşusundan hiçbir şey ödünç almadan, gerekli tüm düğümleri sırasıyla taşıyan tek bir konfigürasyona çeviriyor. Release yolu ‘ya hepsi ya hiçbiri’ yığını yerine sıralı bir kuyruk; değişiklikler neyi engellediklerine göre önceliklendiriliyor. *Efficiency parity:* F3’ün verimi merged graph’tan geliyordu, her feature’a ayrı release vermek bu kaynağı kaldırıyor. İlk prototipler yalnızca deployment’ı ayırdı ve feature’lar bağımsız çıksa da yürütme paylaşılmadığından CPU kullanımı belirgin biçimde arttı. Çözüm, merge’ü geri getirmeden paylaşımlı yürütmeyi geri getirmek: başlangıçta F3 Lightning yeniden bir merged graph kurmuyor, aktif feature konfigürasyonlarını alıp ortak işi birleştiriyor ve tek bir yürütme sırasına diziyor. Verimi korumak için dört optimizasyon: stable computation identifier’lar (aynı hesaplamanın feature’lar arasında tutarlı kimliği), tek bir paylaşımlı execution plan, tüm feature’lar için tek bir paylaşımlı bellek buffer’ı ve doğrudan dizi erişimi için dense index mapping.

Sonuç: karşılaştırılabilir extraction feature’ları production’a önceki F3’ten yaklaşık 3,6 kat hızlı ulaşıyor ve altyapı hesaplama maliyeti artmıyor. Daha kısa release döngüsü aynı sürede daha fazla model iterasyonu demek.