Embedding Drift: Üretimde Vector DB'leri Nasıl Sürdürürüz

Production'da RAG sistemi çalıştırırken embedding modeli değiştirdiğinizde vector DB'niz anlamsızlaşır. Eski embeddingler yeni query vektörleriyle karşılaştırılamaz — arama sonuçları çöker, semantic accuracy düşer. Şirketler genellikle bu sorunu model freeze ile erteliyor: "yeni model çıktı ama migration maliyeti çok yüksek, kalırız burada." Oysa embedding drift kaçınılmaz — model provider'lar her 6-9 ayda yeni versiyon yayınlıyor, doğruluk farkı %8-12 seviyelerine çıkıyor. Kalmanın bedeli teknik borç, güncelliğin bedeli re-index. Bu yazı o bedeli nasıl minimize edeceğinizi gösterir.

Embedding Drift Gerçekten Ne Kadar Hızlı Oluşuyor

OpenAI Aralık 2024'te text-embedding-3-small'ın MTEB skor ortalamasını %3.7 artıran güncellemesini duyurdu. Cohere Nisan 2025'te embed-v4'ü yayınladı, çokdilli retrieval'da %11 kazanç. Voyage AI Haziran 2025'te domain-specific model'larını genişletti. Ortalama drift hızı: production deployment'tan 180 gün sonra mevcut modeliniz benchmark'ın %6-10 gerisinde kalıyor.

Bu fark kullanıcı deneyiminde doğrudan hissedilir. E-ticaret arama: retrieval accuracy %5 düşerse conversion %2-3 düşer. Support chatbot: yanlış makale retrieval oranı %10 artarsa ticket escalation %8 artar. Drift'i ignore etmek kısa vadede stable görünür, uzun vadede sistemin competitive edge'ini yok eder.

Daha büyük sorun: embedding dimension değişimi. Bazı model güncellemeleri dimension'ı koruyor (1536 → 1536), bazıları değiştiriyor (768 → 1024). İkinci durumda DB schema migration zorunlu — sadece re-embed değil, index reconstruction gerekiyor. Bu senaryoda downtime planlanmazsa production çöker.

Re-Indexing Stratejileri: Blue-Green vs Rolling vs Lazy

Üç temel strateji var, her birinin cost/downtime/complexity tradeoff'u farklı.

Blue-Green Migration: Yeni model için tamamen ayrı vector index oluştur, test et, DNS/routing ile switch yap.장점: sıfır downtime, rollback hızlı. Maliyet: database storage ve compute %100 duplicate. Örnek: 50M embedding × 1536 dim × 4 byte = ~300GB storage. Blue-green 2× = 600GB. Cloud provider fiyatlarında ayda $180-240 ek maliyet. Büyük corpus'larda (500M+ embedding) bu ekonomik olarak sürdürülemez.

Rolling Re-Index: Corpus'u batch'lere böl (örn. 10M/batch), her batch'i yeni modelle re-embed et, aynı DB'ye upsert yap. Bu sırada query hem eski hem yeni vektörleri dönebilir — hybrid search uygulaması gerekir. Avantaj: storage duplicate yok. Dezavantaj: migration süresi uzun (50M embedding, batch 1M, her batch 2 saat → 100 saat süreç), bu sürede query consistency düşük.

Lazy Migration: Sadece query edilen chunk'ları re-embed et, zamanla coverage artır. Kullanıcı bir dokümanı sorguladığında, o doküman yeni modelle re-compute edilir ve cache'lenir. Avantaj: hot data hızlı migrate olur, cold data maliyeti yok. Dezavantaj: migration asla %100 bitmez, coverage %70-80'de platolar. Ayrıca query latency spike riski: ilk erişimde embed + insert overhead.

Roibase production'da hybrid yaklaşım kullanıyor: blue-green ile kritik corpus (son 90 gün, sık erişilen %20) hızlıca taşınıyor, geri kalan %80 rolling batch ile 2 haftalık pencerede tamamlanıyor. Bu yöntem maliyeti %40 düşürdü, migration süresini 10 günden 4 güne indirdi.

Migration Sırasında Query Consistency Nasıl Korunur

Rolling migration'da DB hem eski hem yeni embedding barındırırken query accuracy problemi yaşarsınız. Çözüm: multi-vector querying. Query embedding'ini HEM eski HEM yeni modelle oluştur, her iki vektörle search yap, sonuçları birleştir. Psödokod:

def hybrid_search(query_text, k=10):
    old_vec = old_model.encode(query_text)
    new_vec = new_model.encode(query_text)
    
    old_results = vector_db.search(old_vec, collection="docs_old", top_k=k)
    new_results = vector_db.search(new_vec, collection="docs_new", top_k=k)
    
    # Reciprocal rank fusion
    combined = reciprocal_rank_fusion([old_results, new_results], k=k)
    return combined

Bu pattern migration bitene kadar query edge case'lerini yakalıyor. Performans overhead: query latency 1.4×. Migration tamamlandığında dual-query kapatılır, latency normale döner.

Cost Tradeoff: Compute vs Storage vs Downtime

Migration maliyeti üç bileşenden oluşur:

Örnek corpus: 100M embedding, text-embedding-3-small ($0.02/1M token), ortalama chunk 512 token.

• Compute: 100M × 512 token = 51.2B token → $1,024
• Storage: 100M × 1536 dim × 4 byte = 614GB → Pinecone p2 pod'da ~$500/ay

Blue-green 1 ay duplicate tutarsa: $1,024 + $500 = $1,524. Rolling: $1,024 + $0 = $1,024. Lazy: ~$400 + engineering overhead.

Seçim şirkete göre değişir. E-ticaret downtime tolere etmez → blue-green. Research/analytics consistency kaybını tolere eder → rolling. Startup cash-constrained → lazy.

Roibase için karar matrisi: production customer-facing RAG → blue-green. Internal tooling (dokümantasyon search) → rolling. Cold archive (eski case study'ler) → lazy.

Model Versiyonlama ve Metadata Tracking

Migration'ı sürdürülebilir yapmak için embedding metadata tutmalısınız. Her vektör yanında:

• model_name: "text-embedding-3-small"
• model_version: "2024-12-01"
• embedding_dim: 1536
• created_at: timestamp

Bu data sayesinde:

1. Hangi chunk'ların eski modelde olduğunu query ile bulabilirsiniz
2. A/B test yapabilirsiniz (aynı chunk, 2 model, hangisi daha iyi retrieval veriyor)
3. Rollback planlayabilirsiniz (yeni model kötü çıkarsa)

Metadata olmadan migration blind — hangi chunk'ın ne zaman embed edildiğini bilemezsiniz. Bazı vector DB'ler (Weaviate, Qdrant) metadata filtrelemeyi native destekler. Pinecone'da custom payload field eklenir.

Embedding Versiyonunu Otomatik Detect Etmek

Model provider'lar genellikle versiyon değişiminde deprecation notice veriyor (30-60 gün). Otomasyon için:

import hashlib

def get_model_fingerprint(model):
    """Test embedding ile model signature oluştur"""
    test_text = "The quick brown fox jumps over the lazy dog"
    vec = model.encode(test_text)
    return hashlib.md5(vec.tobytes()).hexdigest()[:8]

# Production'da fingerprint değişince alert
current_fp = get_model_fingerprint(embed_model)
if current_fp != expected_fp:
    alert("Embedding model changed, migration required")

Bu pattern model silent update'lerde hayat kurtarır. OpenAI bazen patch yapar, versiyon numarası aynı kalır ama output hafifçe değişir. Fingerprint bunu yakalar.

Attribution ve Veri Kalitesi: Migration'ın Gizli Kazancı

Re-indexing sadece model değişimi için değil, veri temizliği için de fırsat. Production vector DB'lerde zamanla çöp birikir: duplicate chunk'lar, outdated içerik, kötü parse edilmiş PDF'ler. Migration sırasında bu data quality sorunlarını düzeltebilirsiniz.

Roibase bir müşteri projesinde migration sırasında chunk deduplication yaptı: 80M embedding → 68M. %15 reduction. Aynı zamanda chunk overlap stratejisini değiştirdi (128 token → 256 token), retrieval accuracy %4 arttı. Bu iyileştirmeler model değişiminden bağımsız.

Migration ayrıca First-Party Veri & Ölçüm Mimarisi prensiplerini embedding pipeline'ına entegre etme fırsatı. Hangi chunk'ların sık retrieve edildiği, hangi query'lerin miss verdiği — bu metrikler olmadan embedding stratejisi körlemedir. Migration sırasında logging/monitoring katmanını kurarsanız, bir sonraki migration'ı data-driven yaparsınız.

Downtime'sız Geçiş Mimarisi

Blue-green migration'ı eksiksiz uygulamak için altyapı gereksinimleri:

1. Dual write: Yeni data hem eski hem yeni index'e yazılır (migration başladığında aktif)
2. Shadow traffic: Production query'lerinin %5-10'u yeni index'e gönderilir, sonuç loglenir (A/B karşılaştırma için)
3. Cutover checkpoint: Eski index'in son snapshot'ı alınır (rollback guarantee)
4. DNS/routing switch: Trafik yeni index'e yönlendirilir
5. Dual write kapatılır: Eski index read-only olur, 7-14 gün sonra silinir

Bu pattern'in en kritik adımı shadow traffic. Yeni index'i production yükü altında test etmeden switch yapamazsınız. Shadow traffic sayesinde latency, accuracy, edge case failure'ları önceden görürsünüz.

Örnek: Bir projenin shadow traffic testinde latency p99 hedefinin %18 üzerinde çıktı. Sebep: yeni model batch inference optimize edilmemişti. Production switch öncesinde batch boyutu 32 → 128 değiştirildi, p99 hedefe indi. Shadow traffic olmasaydı bu sorun production'da patlar, downtime olurdu.

Sonuç: Migration Kaçınılmaz, Strateji Seçime Bağlı

Embedding model freeze kısa vadeli çözüm, uzun vadeli risk. Competitive ortamlarda model evolution hızı artıyor — 2026'da ortalama drift window 180 günden 120 güne düşecek. Migration stratejinizi şimdi kurmak, 6 ay sonra panik yapmaktan daha ucuz.

Üç stratejiyi hibrit kullanın: kritik data blue-green, bulk corpus rolling, cold archive lazy. Metadata tracking kurun, fingerprint monitoring ekleyin, shadow traffic ile test edin. Migration sadece teknik zorunluluk değil, data quality ve pipeline optimization fırsatıdır — bu pencereyi iyi kullanın.