Foundation model literatürü tuhaf bir şekilde asimetrik. Eğitim tarafında boğulacak kadar çok kaynak var: tokenizasyon stratejileri, scaling law’lar, dikkat mekanizması optimizasyonları, dağıtık eğitim reçeteleri. Çıkarım tarafı da benzer şekilde iyi belgelenmiş — quantization, KV cache, batching. Ama arada, modelin eğitildiği yerle değer ürettiği yer arasında bir boşluk var: model üretimdeki mevcut sistemlere nasıl bağlanacak?
Netflix Teknoloji Blogu’nun kasım ayında yayımladığı yazı — Divya Gadde, Ko-Jen Hsiao, Dhaval Patel ve Moumita Bhattacharya imzalı — tam olarak bu boşluğu adres alıyor ve yazarlar boşluğun varlığını açıkça teslim ediyor: büyük transformer modellerinin eğitimi ve çıkarımı üzerine geniş bir literatür varken, bu modelleri mevcut üretim sistemlerine etkili ve verimli biçimde entegre etme konusunda pratik rehberlik ciddi biçimde eksik.
Bu, akademik bir gözlem değil. Kendi ekibinizde foundation model benzeri bir merkezi model kurduysanız, asıl zorluğun modeli eğitmek değil, on beş farklı ekibin on beş farklı gecikme bütçesi ve teknoloji yığınıyla o modele bağlanmasını sağlamak olduğunu zaten biliyorsunuz. Netflix bu problemi üç ayrı desenle çözmüş ve üçünü de üretimde, farklı kullanım senaryolarında çalıştırıyor.
Neden Merkezi Bir Model?
Kısa arka plan: Netflix ana sayfası uzun süredir çok sayıda özelleşmiş modelle besleniyordu — her satır, her içerik tipi, her yüzey için ayrı bir model. Bu yapının bakımı ve üzerinde inovasyon yapmak ciddi zaman ve kaynak yiyor. Karar, üye tercih öğrenmesini merkezileştirmek oldu: kapsamlı kullanıcı etkileşim geçmişleri ve içerik verisinden büyük ölçekte öğrenen tek bir güçlü model, öğrendiklerini diğer modellere dağıtsın.
Bu, tanıdık bir hikâye. Ama asıl mesele “tek bir güçlü model eğittik” cümlesinden sonra başlıyor. Öğrenilenleri nasıl dağıtıyorsunuz?
Üç Entegrasyon Deseni
Üç yaklaşımın varlığı bir kararsızlığın değil, bilinçli bir tasarım tercihinin sonucu: farklı ekiplerin farklı gecikme gereksinimleri, farklı teknoloji yığını kısıtları ve büyük bir modelin tüm gücünden yararlanma konusunda farklı iştahları var. Bunu tek bir “doğru” desenle çözmeye çalışmak, en katı kısıtı olan ekibi dışarıda bırakmak demek.
1. Embedding’ler: Düşük maliyet, yüksek kaldıraç
En basit ve genellikle ilk tercih edilen yol. Profil embedding’i olarak son kullanıcı olayının gizli durumu (hidden state), item embedding’i olarak item tower’ın ağırlıkları alınıyor.
Tazeleme döngüsü dikkat çekici: foundation model her ay sıfırdan ön-eğitiliyor, aylık ön-eğitilmiş model her gün en güncel veriyle fine-tune ediliyor. Günlük fine-tuning aynı zamanda entity id uzayını genişletiyor ki yeni çıkan başlıklar sisteme girebilsin — soğuk başlangıç problemine sessiz ama zarif bir cevap. Sonra batch inference ile embedding’ler yenileniyor ve Embedding Store’a yayımlanıyor. Embedding Store, versiyonlama ve zaman damgalama işini üstlenen, hem çevrimdışı hem çevrimiçi erişim arayüzleri sunan özelleşmiş bir feature store.
Bu desenin cazibesi açık: embedding’ler mevcut hatlara özellik olarak girebiliyor, aday üretimi (candidate generation) için kullanılabiliyor, başlık-başlığa öneriyi besleyebiliyor. Eğitim ve çıkarım maliyetine etkisi diğer iki yaklaşıma göre daha küçük.
Bedeli ise bayatlık (staleness): embedding’in hesaplandığı an ile aşağı akış modelinin çıkarım yaptığı an arasındaki boşluk, önerilerin tazeliğini düşürüyor. Gerçek zamanlı uyum gerektiren senaryolarda bu doğrudan bir tavan.
Netflix’in bu deseni yeterince değerli bulup üzerine yatırım yapması ilginç bir sinyal: neredeyse-gerçek-zamanlı bir embedding üretim çerçevesi kurmuşlar. Bu çerçeve, oturum sırasındaki kullanıcı hareketlerine göre embedding’leri güncelleyebiliyor. Sınırı da dürüstçe belirtiyorlar — çok büyük modeller için kullanılamıyor.
2. Subgraph: Dikişi ortadan kaldırmak
İkinci desende foundation model’in decoder yığını, uygulama modelinin graph’ının bir alt-grafiği haline geliyor. Ham kullanıcı etkileşim dizilerini işleyip ürettiği temsilleri doğrudan aşağı akış grafiğine veriyor.
Kazanç: statik embedding kullanmaya kıyasla daha iyi performans potansiyeli, çünkü uygulama subgraph’ı kendi eğitim sürecinin parçası olarak fine-tune edebiliyor. Bayatlık tamamen ortadan kalkıyor. Üstelik Embedding Store üzerinden dışarı açılmayan ara katmanlara erişim imkânı doğuyor.
Bedeli ağır ve yazı bu konuda net. Uygulama modellerinin subgraph’ın ihtiyaç duyduğu tüm özellikleri kendi feature generation süreçlerinde üretmesi gerekiyor — bu, o hatlara zaman, hesap ve karmaşıklık ekliyor. Model boyutu ve çıkarım süresi büyüyor. Netflix’in getirdiği azaltıcı çözümlerden biri özellikle öğretici: subgraph’ı bölüp, istek başına profil başına yalnızca bir kez çalışacak ve o istekteki tüm item’lar tarafından paylaşılacak şekilde ayırmışlar. Kullanıcı temsili item sayısından bağımsız olduğu için bu, doğrusal bir maliyeti sabite indiriyor.
Sonuç olarak bu deseni yüksek etkili kullanım senaryolarına saklıyorlar — metrik kazancının maliyeti ve karmaşıklığı telafi ettiği yerlere.
3. Fine-tuning: Modeli doğrudan ürüne koşmak
Üçüncü desen LLM’lerin alan-özel veriyle fine-tune edilmesine en çok benzeyen yaklaşım. Foundation model bir sonraki token tahmini hedefiyle eğitiliyor ve buradaki token’lar kullanıcı etkileşimleri. Ama her etkileşim her yüzey için aynı derecede anlamlı değil.
Yazıdaki örnek meseleyi tam yerinden yakalıyor: “Trending now” satırı için, trend olan başlıklara yapılan yakın zamanlı etkileşimler eski etkileşimlerden daha önemli. Genel amaçlı bir modelin bu ağırlıklandırmayı kendiliğinden yapması beklenemez. Dolayısıyla model ürün-özel veriyle fine-tune edilip doğrudan o yüzeyi besleyebiliyor. Ekipler tam parametre fine-tuning ile bazı katmanları dondurmak arasında seçim yapabiliyor, hatta farklı bir hedefle farklı bir çıktı başlığı (output head) ekleyebiliyor.
Buradaki en sinsi faydayı Netflix bir yan not gibi geçiyor ama bence yazının en önemli cümlelerinden biri: fine-tune edilmiş foundation model, yeni uygulamalar için fiili bir başlangıç seviyesi (baseline) sağlıyor. Yeni bir model yığını kurup aylarca feature engineering yapmak yerine, ekipler doğrudan fine-tune edilmiş modeli kullanabiliyor. Merkezi model, ekiplerin sıfırdan başlama maliyetini ortadan kaldırıyor.
Bedeli organizasyonel: bakılacak model ve hat sayısı artıyor. Ayrıca fine-tune edilmiş modelin gecikmesi ve SLA’ları her kullanım için ayrı ayrı optimize edilmek zorunda.
Asıl Ders: Embedding Uzayı Bir Sözleşmedir
Yazının en çok atlanacak, ama üretimde en çok canınızı yakacak kısmı embedding stabilizasyonu.
Problem şu: ön-eğitim işi modeli sıfırdan yeniden eğittiğinde, rastgele başlatma yüzünden farklı koşuların embedding uzayları birbirinden tamamen farklı oluyor. Dahası, günlük fine-tuning işi bir önceki günün modelinden sıcak başlasa bile embedding’ler zamanla kayıyor (drift). Yani dün 47. boyutun ifade ettiği şey ile bugün 47. boyutun ifade ettiği şey aynı değil.
Bu, aşağı akış tüketicileri için felaket. Embedding’i önceden hesaplanmış bir özellik olarak tüketen her model, her yeniden eğitimde varsayımlarını kaybediyor.
Netflix’in çözümü — Kevin Zielnicki ve Ko-Jen Hsiao’nun RecSys 2025’te yayımlanan çalışması — ortogonal düşük-ranklı bir dönüşüm. Verimli düşük-ranklı SVD ile ortogonal Procrustes dönüşümünü birleştirerek embedding’leri standart bir uzaya eşliyorlar. Yöntemin özelliklerine dikkat: hesaplama açısından verimli, kayıpsız ve hafif; nokta çarpımı ve çıkarım kalitesini koruyor.
Yaklaşımın asıl ayırt edici yanı ise şu. Mevcut yöntemlerin çoğu embedding’lerdeki değişimi minimize etmeyi veya iç çarpım sonuçlarını ve sıralamaları tutarlı tutmayı hedefliyor — ama bunlar her boyutun anlamını dondurmuyor. Netflix’in yöntemi bir embedding’i referans seçip diğerlerini ona dönüştürüyor. Ve kritik olarak, eğitim hedefini veya embedding yapısını değiştiren yöntemlerin aksine bu bir son-işleme (post-processing) adımı; birincil model uygulamasının bütünlüğünü bozmuyor ve başka stabilizasyon teknikleriyle birleştirilebiliyor.
Buradaki mühendislik felsefesi, tekniğin kendisinden daha değerli: eğitim hattını değiştirmek yerine çıktıyı hizala. Modeli sahiplenen ekip ile tüketen ekipler arasındaki bağımlılığı, herkesi yeniden eğitmeye zorlamadan çözüyor.
Sektörel Çıkarımlar
Embedding’i bir sözleşme olarak görün. RAG hatlarında hepimizin yaşadığı senaryo: embedding modelini güncelliyorsunuz ve tüm korpusu yeniden indekslemek zorunda kalıyorsunuz — çünkü indeksteki vektörlerle yeni sorgu vektörleri aynı uzayda değil. Netflix aynı problemi günlük ölçekte yaşıyor ve cevabı “herkes yeniden indekslesin” değil, “çıktıyı referans uzaya hizala” oluyor. Dürüst kalmak gerekirse Procrustes hizalaması her duruma uymaz; yöntem, skorları kullanıcı-item nokta çarpımı olarak tanımlayan faktörizasyon tipi modeller ve softmax tabanlı sinir ağları için tasarlanmış. Tamamen farklı iki metin encoder’ını hizalamak ayrı bir problem. Ama zihinsel model transfer edilebilir: embedding uzayınızın kararlılığını bir arayüz sözleşmesi olarak ele almak, ekipler arası bağımlılığı yönetmenin en ucuz yolu.
Entegrasyon desenini gecikme bütçesine göre seçin, hevese göre değil. Netflix’in üç deseni aslında bir maliyet-fayda merdiveni: embedding (ucuz, bayat), subgraph (pahalı, taze), fine-tuning (esnek, bakım yükü ağır). Her ekibi en güçlü desene zorlamak, çoğu ekibin hiç entegre olmaması demek. Girişe engeli düşük bir yol sunmak, adaptasyon açısından mükemmel çözümden daha değerli.
“Bir kez hesapla, çok kez paylaş” prensibini erken uygulayın. Subgraph’ı istek başına profil başına tek sefer çalıştırıp tüm item’lar arasında paylaştırma hamlesi, herhangi bir sıralama sisteminde geçerli. Aday sayısı arttıkça kullanıcı tarafındaki hesabı tekrarlamıyorsanız, maliyet eğriniz düzleşiyor.
Merkezi model, feature engineering borcunu siliyor. Yeni bir öneri yüzeyi için aylarca özellik mühendisliği yapmak yerine fine-tune edilmiş bir modeli baseline olarak kullanabilmek, organizasyonel hız açısından metrik kazancından daha değerli olabilir. Bu, model kalitesi tartışmasında genelde ölçülmeyen bir kazanım.
Sonuç ve Gelecek Görünümü
Netflix’in yol haritası, üç desenin de zayıf noktalarını hedefliyor: embedding bayatlığı için neredeyse-gerçek-zamanlı çıkarım, subgraph gecikmesi için modelin damıtılmış (distilled) küçük bir versiyonu, ve tüm bunları kullanmayı kolaylaştıracak standartlaştırılmış API’ler.
Bu son madde belki de en önemlisi. Foundation model tartışmalarında parametre sayısı ve benchmark skorları konuşulurken, bir modelin organizasyon içindeki gerçek etkisini belirleyen şey çoğu zaman API’sinin ne kadar kolay tüketilebildiği oluyor.
Kendi yığınınıza bakarken sorulacak soru şu: merkezi modeliniz varsa, ona bağlanmak isteyen bir ekibin önündeki engel ne kadar yüksek? Cevap “birkaç ay” ise, modelin ne kadar iyi olduğunun pek bir önemi yok.
Kaynak: Divya Gadde, Ko-Jen Hsiao, Dhaval Patel, Moumita Bhattacharya, “Integrating Netflix’s Foundation Model into Personalization Applications”, Netflix Technology Blog, 17 Kasım 2025. Embedding stabilizasyonu için: Kevin Zielnicki, Ko-Jen Hsiao, “Orthogonal Low Rank Embedding Stabilization”, arXiv:2508.07574 / RecSys 2025.