Sorgu başına gerçek maliyet
Maliyet karşılaştırması senaryoya göre kökten değişiyor, ama kaynaklı fiyatlarla hesaplanabilir. RAG'da her sorgu yalnız ilgili chunk'ları gönderir: 5K token'lık bir chunk base input (Fable 5.1: $10/MTok) üzerinden $0.05 eder; üstüne OpenAI'nin resmi fiyatlandırma sayfasına göre File Search tool call'u (1000 çağrı başına $2.50) $0.0025 ekleniyor → sorgu başına ~$0.0525. Uzun bağlamda ise 1M token'ı cache'ten okumak, Anthropic'in Fable 5.1 için verdiği $0.25/MTok cache-read fiyatıyla ~$0.25 tutar — yani 1M token bağlamda RAG sorgu başına yaklaşık 4,8 kat ucuz. Başa-baş noktası da aynı iki fiyattan çıkıyor: 0,25 × bağlam = 10 × chunk denklemi bağlam ≈ 40 × chunk verir, 5K chunk varsayımıyla ~200K token. Pratik okuma: ~200K'nın altındaki statik ve sık tekrar sorgulanan korpuslarda cache'li uzun bağlam hem basit hem ucuz; üstünde sorgu başına maliyet RAG'ın lehine döner, ama vektör DB, embedding üretimi ve yeniden-indeksleme bakımını da sayan toplam sahip olma maliyetinde uzun bağlam yine kazanabilir. Unutma: ilk çağrı cache write olduğu için tam input fiyatından faturalanır, cache'in faydası ancak sorgular tekrarlandığında doğar.
İlk-token gecikmesi
RAG mimarisinde retrieval adımı (vektör arama + varsa yeniden-sıralama) generation'dan önce gerçekleşir ve bu, isteğe ek bir tur ekler — Amazon Bedrock'un resmi dokümantasyonuna göre 'Agentic Retrieval' özelliği karmaşık sorguları alt-sorgulara bölüp birden fazla knowledge base'de iteratif arama yapabiliyor, bu da çok-adımlı senaryolarda gecikmeyi daha da artırabilir. Uzun bağlamda ise ayrı bir retrieval turu yok; üstelik Anthropic'in resmi prompt caching dokümantasyonu, cache'te bulunan içeriğin 'işlem süresini ve maliyeti azalttığını' açıkça belirtiyor. Ancak bu avantaj yalnız cache-hit durumunda geçerli — ilk çağrıda (cache miss) tüm bağlamın işlenmesi gerektiği için gecikme retrieval'e kıyasla daha yüksek olabilir.
Veri güncelliği ve anlık güncelleme
RAG'ın var olma nedenlerinden biri tam olarak bu: Pinecone'un öğrenme sayfasına göre modellerin bilgi kesim tarihi 'bir bilgi boşluğu yaratıyor ve modellerin yakın tarihli gelişmeler sorulduğunda makul ama yanlış yanıtlar üretmesine yol açıyor'. RAG'da kaynak belge güncellenince yalnız o belgenin embedding'ini yeniden indekslemek yeterli — model hiç değişmiyor. Uzun bağlamda ise güncellik, yalnız o oturuma o anda eklenen belgeyle sınırlı; Anthropic'in context window dokümantasyonu bağlamı 'çalışma belleği' (working memory) olarak tanımlıyor — yani prompt'a ne koyarsan güncel olan yalnız odur, modelin kendi parametrik bilgisi hâlâ eğitim kesim tarihinde donmuş durumda.
Doğruluk ve 'ortada kaybolma' riski
Bu, uzun bağlamın en belgeli zayıflığı. Liu ve ekibinin arXiv:2307.03172 numaralı makalesi, modellerin 'ilgili bilginin girdinin başında veya sonunda bulunduğu durumlarda en yüksek performansı gösterdiğini, ilgili bilgiye bağlamın ortasında erişmesi gerektiğinde performansın belirgin şekilde düştüğünü' kanıtlarla ortaya koydu. Anthropic bu olguyu kendi resmi dokümantasyonunda 'context rot' terimiyle tanımlıyor: token sayısı arttıkça doğruluk ve hatırlama düşüyor. RAG tarafında ise orijinal makale (arXiv:2005.11401), yalnız ilgili parçaların modele verilmesinin bilgi-yoğun görevlerde parametrik-only modelleri ve görev-özel retrieve-and-extract mimarilerini geride bıraktığını iddia ediyor — yani odaklanmış, küçük bağlam RAG'ın doğal avantajı.
Kurulum ve bakım maliyeti
RAG'ın 'customer-managed' kurulumu (AWS Bedrock dokümantasyonuna göre) kendi vektör deponu (OpenSearch Serverless, Aurora vb.) kurup yönetmeni gerektirir — chunking stratejisi, embedding modeli seçimi, yeniden-indeksleme pipeline'ı sürekli bakım ister. 'Managed Knowledge Base' seçeneği bu yükü sağlayıcıya devrediyor ama yine de bir kurulum adımı. Uzun bağlamda ise Anthropic'in resmi dokümantasyonu kurulumun ne kadar hafif olduğunu şöyle özetliyor: '1M token'a kadar beta header gerekmiyor, uzun-bağlam istekleri standart fiyattan faturalandırılıyor' — yani teknik olarak tek satırlık bir prompt değişikliği yeterli, ek altyapı yok.
Erişim kontrolü / satır-seviyesi yetkilendirme
Bu kriter RAG'ın uzun bağlama karşı en net yapısal üstünlüğü. AWS Bedrock Knowledge Bases resmi dokümantasyonu, retrieval zamanında 'belge-seviyesi izin filtrelemesini Access Control List'lerle (Web Crawler hariç)' desteklediğini belirtiyor — yani her kullanıcı yalnız yetkili olduğu belgelerden retrieval sonucu alabiliyor. Uzun bağlamda bu native olarak yok: Anthropic'in context window dokümantasyonuna göre 'istekteki her şey' (sistem promptu, her mesaj, araç sonuçları, görseller, belgeler) bağlam penceresine aynı yetki düzeyinde dahil oluyor. Çok-kiracılı bir uygulamada her müşteriye ayrı, izole bağlam hazırlamak teknik olarak mümkün ama bunun native bir erişim-kontrolü katmanı olmadığını, uygulama tarafında elle inşa edilmesi gerektiğini unutma.
Hibrit (cache + retrieval) yaklaşımın maliyeti
Olgun mimarilerde yaygın bir desen ikisini aynı sistemde birlikte kullanmak. Anthropic'in resmi prompt caching dokümantasyonu, cache'in özellikle 'çok sayıda örnek içeren promptlar' ve 'büyük miktarda bağlam veya arka plan bilgisi' için önerildiğini belirtiyor — yani sabit, sık tekrarlanan sistem promptu/arka plan bilgisi cache'lenip uzun bağlamda tutulurken, kullanıcıya veya ana konuya özel, sık değişen veri RAG ile anlık olarak getiriliyor. Google Cloud'un Vertex AI context caching dokümantasyonu da benzer bir ayrım yapıyor: implicit caching'in depolama maliyeti yok, ama bu yalnız aynı içeriğin kısa sürede tekrar kullanılması durumunda devreye giriyor — sık değişen veride avantaj kaybolur. Pratik sonuç: hibrit mimaride toplam maliyet, sabit kısmın cache-read fiyatı ile dinamik kısmın retrieval maliyetinin toplamına iner — her iki kalem için de yalnız gerçekten gereken veri kadar ödenir.