RAG mı, Long-Context mı, CAG mı?

Ne öğreneceksin

1. Bölüm bu seriyi tek bir can sıkıcı gerçekle açtı: bilmediği bir şey sorulduğunda bir dil modeli özgüvenle bir şeyler uydurur, ve retrieval bunu düzeltme yöntemimizdir. On beş bölüm sonra tüm makineyi kurmuş bulunuyoruz. Bu bölüm, 1. Bölüm’ün sessizce varsaydığı soruyu sorarak döngüyü kapatıyor: retrieval’a gerçekten ihtiyacın var mı? 2026’da bu artık otomatik bir cevap değil. Bağlam pencereleri yaklaşık bir milyon token’a büyüdü, yani yeterince küçük bir corpus için indeksi tamamen atlayıp her şeyi doğrudan prompt’a koyabilirsin. Ve bu fikrin daha keskin bir versiyonu var: Cache-Augmented Generation (CAG), yani “önbellekle zenginleştirilmiş üretim”. CAG, küçük ve sabit bir corpus’u bağlama bir kez önceden yükler, modelin o corpus için hesapladığı iç durumu önbelleğe alır ve bu durumu her sorguda yeniden kullanır; retrieval gecikmesini, yalnızca bir kez tam fiyatına ödediğin daha büyük bir prompt’la takas eder. Bu üç seçeneğin (RAG, long-context tıkıştırma ve CAG) gerçekte nasıl farklılaştığını, prompt-caching ekonomisinin CAG’i neden uygun fiyatlı kıldığını ve corpus’unun hangisini istediğini söyleyen net bir karar matrisini nasıl okuyacağını öğreneceksin. Burada yeni bir retrieval tekniği yok. Bu bölüm, zaten sahip olduklarına ne zaman uzanacağını, ne zaman uzanmayacağını öğrendiğin bölüm.

Ön koşullar

Bu bir kapanış bölümü, bu yüzden serinin iki ucuna da yaslanıyor. RAG Neden Var? (1. Bölüm) sana lazım, çünkü bu bölüm o bölümün sorduğu sorunun doğrudan cevabı ve “retrieval, modeli sahip olmadığı olgulara dayandırmanın bir yolu” çerçevesinin tamamı, artık ne zaman atlayacağımıza karar verdiğimiz şey. Ve Üretimde RAG (12. Bölüm) sana lazım, özellikle maliyet bölümü, çünkü prompt caching ilk orada birçok kaldıraçtan biri olarak ortaya çıkmıştı ve burada belirleyici faktör haline geliyor. RAG’i Değerlendirmek (11. Bölüm) da aklında olursa iyi olur, çünkü long-context ile RAG karşılaştırmasını maliyet temelinde zaten yapmıştı; bu bölüm tam onun bıraktığı yerden devam ediyor ve onun kapsamadığı caching boyutunu ekliyor. Tek küçük maliyet modeli için temel Python yeterli.

1. Bölüm’ün açık bıraktığı soru

İşte şimdiye kadarki her bölüme gömülü olan varsayım. Modeli kendi belgelerine dayandırmak için retrieve etmen gerektiğini varsaydık: query’yi göm, bir indekste ara, en ilgili birkaç chunk’ı geri çek ve onları prompt’a yapıştır. Bu varsayım, bağlam pencerelerinin birkaç bin token tuttuğu ve gerçek bir corpus’u fiziksel olarak bir prompt’a sığdıramadığın 2023’te doğruydu. Artık her zaman doğru değil. 2026’nın frontier modelleri yaklaşık bir milyon token’lık bağlam pencereleri taşıyor, ki bu bir kerede birkaç bin sayfa metin tutmaya yeter. Yani üç yıl önce sorulamayacak bir soru artık gündemde: tüm corpus pencereye sığıyorsa, ondan retrieve etmeye zahmet etmenin ne anlamı var?

Dürüst cevap, bazen böyle yapmaman gerektiği. Bilgi tabanın küçükse ve nadiren değişiyorsa, retrieval ihtiyacın olmayabilecek bir makine; 15. Bölüm’ün kolay query’ler için vardığı aynı kanı, şimdi corpus’un bütününe uygulanmış hali. Ama “her şeyi olduğu gibi tıkıştır” bedava değil, ve bedava olmamasının sebebi bu bölümdeki tek en önemli gerçek: prompt’taki her token, her istekte faturalandırılır. Bunu 12. Bölüm’de context inflation olarak, RAG’in faturanı düşürmek yerine nasıl sezgiye aykırı biçimde yükseltebileceği olarak görmüştük. Tüm corpus’u prompt’a tıkıştırmak, bu etkinin sınırına kadar götürülmüş hali. Bir milyon token’lık bir prompt bin kez cevaplanırsa bu, corpus hiç değişmemiş olsa bile defalarca ödenen bir milyar input token demektir. Long-context “sığıyor mu” sorununu çözer ve yerine “buna gücün yeter mi” sorununu yaratır.

Bu gerilim, pencereye sığma karşısında her istekte ödeme, bu bölümün geri kalanının çözdüğü şey. Üç cevap var, ve hangisinin doğru olduğu tamamen corpus’unun şekline bağlı.

Üç seçenek

Herhangi bir şeyin fiyatını çıkarmadan önce, üç stratejiyi net biçimde adlandıralım, çünkü kararın tamamı bunlar arasından seçim yapmaktan ibaret.

Birincisi, bu serinin inşa ettiği şey: RAG. Corpus’u bir indekste tutarsın ve her query’de yalnızca ihtiyacın olan bir avuç chunk’ı retrieve edip yalnızca onları gönderirsin. Tanımlayıcı özellik, query başına input’unun küçük ve kabaca sabit olması: corpus’un boyutunu değil, retrieve ettiğin chunk sayısı olan k’yı takip eder. On bin chunk’lık bir corpus’a karşı bir query, on milyon chunk’lık bir corpus’a karşı bir query ile aynı maliyete sahiptir, çünkü her iki durumda da aynı k chunk’ı gönderirsin. Bu RAG’in süper gücü ve hiç ortadan kalkmamasının sebebi: üçü arasında maliyeti corpus’la birlikte büyümeyen tek seçenek odur.

İkincisi, büyük pencerenin naif kullanımı: long-context tıkıştırma (long-context stuffing). Tüm corpus’u her istekte prompt’a koyarsın ve modelin cevap vermek için hepsini okumasına izin verirsin. İndeks yok, retrieval yok, chunking kararı yok, bakımını yapman gereken bir embedding modeli yok. İşe yarayabilecek en basit şey, ve küçük bir corpus için genelde gerçekten işe yarar; tek bir yakalanacak nokta hariç: her tek query’de, tüm corpus için tam fresh-input oranından ödersin. Şimdi basitlik, sonsuza dek corpus boyutuyla doğrusal büyüyen bir maliyet.

Üçüncüsü, akıllı orta yol: CAG, Cache-Augmented Generation. Buradaki içgörü şu: corpus her istekte aynıysa, onu her seferinde sıfırdan işlemek için ödeme yapmak zorunda kalmamalısın. Bu yüzden corpus’u bağlama bir kez önceden yüklersin, modelin bu token’lar üzerinde hesapladığı iç anahtar-değer durumunu (KV cache’ini) hesaplamasına izin verirsin ve bu durumu saklarsın. Sonraki her query’de bu durumu yeniden hesaplamak yerine önbelleklenmiş haliyle yeniden kullanırsın ve yalnızca yeni query fresh olarak işlenir. CAG makalesi (Chan ve ark., arXiv 2412.15605), bunu tam olarak sınırlı bir corpus’a sahip bilgi görevleri için RAG’e bir alternatif olarak çerçeveliyor: ilgili tüm belgeleri önceden yükle, runtime durumunu cache’le ve retrieval adımı olmadan ondan cevap ver; bu da retrieval gecikmesini ve onunla gelen belge-seçim hatalarını ortadan kaldırır. CAG, caching sayesinde uygun fiyatlı hale getirilmiş long-context tıkıştırmadır. Basitliği korur (indeks yok) ve tekrar eden tam-fiyat vergisini kaldırır (corpus cache’lenir, yeniden okunmaz).

Yani: RAG her seferinde küçük bir dilim gönderir, long-context her seferinde her şeyi fresh gönderir, ve CAG her şeyi bir kez gönderir ve yeniden kullanır. Farklar tamamen query başına ne ödediğinle ilgili; bu yüzden karar, özünde, bir ekonomi problemi.

Cache-Augmented Generation, biraz daha detaylı

CAG daha yakından bakmayı hak ediyor, çünkü buradaki en yeni fikir ve en muhtemel tanıdık olmayan o. Mekanizma, her transformer’ın zaten yaptığı bir şeye dayanıyor. Bir model bir prompt’u işlerken, her token için, o token’ı bağlam içinde özetleyen bir dizi anahtar ve değer vektörü hesaplar. Buna KV cache denir, ve modelin tüm prompt’u sıfırdan yeniden okumadan bir sonraki token’ı üretmesini sağlayan şey budur. Normalde bu cache yalnızca tek bir isteğin süresince yaşar ve sonrasında atılır. CAG’in hamlesi onu saklamak. Modele sabit corpus’unu bir kez besler, bu token’lar üzerinde hesapladığı KV durumunu yakalar ve kalıcı hale getirirsin. Sonra bir query geldiğinde, o saklanmış durumu yüklersin ve model, corpus’u aslında okumamış olsa bile, sanki onu az önce okumuş gibi oradan devam eder. Query fresh olarak işlenir; corpus hiç işlenmez, yalnızca yeniden yüklenir.

Kazanç iki yönlü. Birincisi, latency: retrieval adımı yok, query’yi embed etme yok, vektör araması yok, reranking yok; yani query başına yol yalnızca “cache’i yükle, query’yi işle, üret.” İkincisi, sınırlı bir corpus üzerinde doğruluk: model top-k bir dilim yerine gerçekten tüm corpus’u gördüğünden, 11. Bölüm’ün kataloğladığı retrieval hatalarını yapamaz; doğru chunk’ın hiç getirilmemesi, ya da bir karşılaştırmanın iki chunk gerektirip yalnızca bir tanesini alması gibi. Corpus’un tamamı her zaman mevcut. CAG makalesinin çerçevelemesi tam olarak bu: corpus’un önceden yüklenecek kadar küçük ve sabit olduğu bilgi görevleri için, onu cache’lemek hem retrieval gecikmesini hem de retrieval hatasını atlatır.

Dürüst sınırlar, kazanç kadar önemli, ve bunlar long-context’i de sınırlayan aynı iki sınır. Corpus, bağlam penceresine sığmak zorunda, ki bu ne kadarını önceden yükleyebileceğini sınırlar (bir milyon token çok, ama gerçek bir kurumsal bilgi tabanı değil). Ve corpus sabit olmak zorunda, çünkü bir belge değiştiği anda, cache’lenmiş durumu tüm corpus için yeniden hesaplayıp yeniden saklaman gerekir. Bu yüzden CAG genel olarak bir RAG yerine geçen şey değil. Belirli, yaygın bir şekil için bir RAG yerine geçen şey: tekrar tekrar cevaplanan, küçük ve sabit bir bilgi yığını. Bir ürünün dokümantasyonunu, bir politika el kitabını, tek bir sözleşmeyi, bir oyunun kurallarını düşün. Bunlar için CAG genelde doğru araç. Büyük olan, saatlik değişen, ya da içeriği kullanıcı başına erişim-filtrelenmesi gereken (12. Bölüm’ün multi-tenancy kaygısı) bir corpus için, işe yarayan tek şey hâlâ retrieval.

Prompt caching ekonomisi: maliyet köprüsü

İşte CAG’i bir merak konusu olmaktan çıkarıp öteye taşıyan şey, ve bu 12. Bölüm’ün maliyet optimizasyonu altında tanıttığı aynı kaldıraç: prompt caching. 2026 frontier modellerinin fiyatlandırma gerçeği şu: bir cache’ten servis edilen bir token, fresh bir token’dan kabaca bir büyüklük mertebesi daha ucuza mal olur. Somut olarak, sağlayıcılar cache’lenmiş input token’lar için normal input oranının kabaca 0.1 katını faturalandırır, buna karşılık önbelleklenebilir bir bloğu ilk kez yerleştirdiğinde tek seferlik yaklaşık 1.25 katlık bir yazma primi ödersin (daha uzun ömürlü bir cache yazması daha pahalıya mal olur, bir saatlik bir girdi için kabaca 2 kat, ama şekil aynı). Yani model corpus’unu ilk gördüğünde onu cache’lemek için küçük bir prim ödersin, ve ondan sonraki her seferinde onu okumak için normal oranın onda birini ödersin. Yeniden kullanımdaki bu on kat indirim, CAG’in arkasındaki ekonomik motorun tamamı. O olmadan, “corpus’u bir kez önceden yükle” her query’de yine tam fiyata mal olurdu ve CAG yalnızca pahalı bir long-context olurdu. Onunla, corpus ilk istekten sonra neredeyse bedava.

Bu indirimi elde etmek için prompt’u doğru yapılandırman gerekir, ve kural yanlış anlaşılması kolay olduğu için net söylemeye değer. Prompt caching bir prefix eşleşmesidir. Sağlayıcı, prompt’unun sabit bir prefix’ini cache’ler ve onu yalnızca cache noktasına kadar olan byte’lar önceki bir istekle byte’ı byte’ına aynıysa yeniden kullanabilir. Yerleşim için çıkarım katı: sabit içeriği önce koy (sabit talimatların, sonra corpus) ve değişken içeriği (kullanıcının query’si) en sona koy. Corpus ve talimatlar önbelleklenebilir bir prefix oluşturur; her seferinde değişen query onun ardında oturur ve fresh olarak işlenir. Sırayı ters çevirip query’yi öne koyarsan, hiçbir şey cache’lenmez, çünkü prefix her istekte farklıdır.

Bunu bozmanın en yaygın tek yolu, değişken bir şeyin prefix’e sızmasına izin vermek. Sistem prompt’una enterpolasyonla eklenmiş bir zaman damgası (“Şu anki saat: 14:32:07”), istek başına bir id, bir session token, hatta çağrılar arasında değişen bir tool sonucu; bunlardan herhangi biri prefix’te olursa byte’larını değiştirir ve o noktadan sonra cache’i geçersiz kılar. Bu özellikle agentic kurulumlarda dikkat edilmesi gereken tuzak: prompt’un sabit corpus’u değişken tool sonuçlarıyla karıştırıyorsa, tool sonuçları kendilerinden sonraki her şey için cache’i bozar, ve cache’lediğini sandığın corpus için sessizce tam fiyat ödersin. Değişken kısımları en sona, son cache’lenmiş bloktan sonra tut, ya da cache’lenmiş prefix’in tamamen dışında bırak.

Takası gerçek sayılarla görmek yardımcı olur, bu yüzden çalıştırabileceğin küçük bir maliyet modeli yazdım: rag_vs_long_context.py (saf standart kütüphane, bağımlılık yok, ağ yok). Üç stratejiyi göreli maliyet birimleri cinsinden fiyatlandırır, 2026 prompt caching’inin genel şeklini kullanarak (birim olarak fresh input, cache yazması 1.25 kat, cache okuması 0.1 kat), ve aynı küçük, sabit corpus’u defalarca cevaplar. Çıktı, amortizasyonu somutlaştırır. Tek bir query’de, CAG en kötü seçenek: yazma primini ödedin ve bundan tam olarak tek bir okuma elde ettin, ki bu yanlış test. O sabit corpus’a karşı yüz query’de yazma, yüz ucuz okuma üzerinden amortize olmuş olur, ve CAG hem naif long-context’in (ki hiç cache’lemez ve faturada kabaca 2.9 kat kalır) hem de küçük-corpus iş yükünde RAG’in bile altına düşer. Script ayrıca corpus boyutunu tarar ve crossover dönüşünü gösterir: küçük bir corpus için CAG kazanır, ama corpus büyüdükçe cache’lenmiş okumalar (her query’de, gittikçe büyüyen bir corpus’un hâlâ 0.1 katı) sonunda RAG’in neredeyse sabit top-k maliyetine yenilir. O dönüş, iddia edilmiş değil, fiyatlandırmadan türetilmiş karar matrisinin ta kendisi.

11. Bölüm’ün ruhuna uygun bir uyarı: bunlar göreli maliyet birimleri, bir sağlayıcı teklifi değil, ve model bilerek bir oyuncak. Sabit bir ücretin ötesindeki output-token farklarını yok sayar, kusursuz derecede sabit bir prefix varsayar, ve yuvarlak fiyatlandırma oranları kullanır. Sağlayıcının gerçek token-başı oranlarını yerleştir, tam crossover noktası kayacaktır. Kaymayan şey şekil: long-context maliyeti her query’de corpus boyutuyla doğrusal büyür, CAG aynı şekilde ama kabaca on kat daha yavaş büyür (cache’lenmiş okumalar), ve RAG corpus boyutunda düz kalır çünkü her zaman yalnızca k chunk gönderir. Şekle güven, rakamları kendi faturana karşı doğrula.

Karar matrisi

Şimdi bu bölümün açtığı soruyu cevaplayabiliriz, ve bu, corpus’unun iki özelliğine artı beraberlik bozucu olarak maliyete iniyor. İki eksen, corpus’un ne kadar büyük olduğu ve ne sıklıkla değiştiği; yukarıdaki maliyet modeli beraberlikleri hangi yönde bozacağını söylüyor.

Elemeyle başla, çünkü bunlar mutlak. Corpus devasasa (bağlam penceresinden büyük, ya da her query’de cache’lenmiş okumaları bile pahalı olacak kadar büyük), ya da hızlı değişiyorsa (bir cache’i sürekli yeniden hesaplayacağın kadar sık değişiyorsa), ya da kullanıcı başına erişim filtrelemesi gerektirecek şekilde özelse, o zaman RAG’a ihtiyacın var. Retrieval, üçü arasında maliyeti corpus’la büyümeyen tek seçenek, herhangi bir pencereye sığmayacak kadar büyük bir corpus’la başa çıkabilen tek seçenek, ve her kullanıcının neyi görmesine izin verildiğini o prompt’a ulaşmadan önce filtreleyebilen tek seçenek. Gerçekten büyük, yaşayan, multi-tenant bir bilgi tabanı, bu serinin tamamının inşa edildiği şey, ve 2026’da bunların hiçbiri değişmiyor.

Corpus bu elemeleri geçiyorsa, yani küçük ve sabitse, retrieval’ı atlama lüksüne sahipsin, ve seçim CAG ile düz long-context tıkıştırma arasında. Corpus küçük-ama-çok-küçük-değil ve ona karşı birçok query cevaplıyorsan CAG’a meyilli ol, çünkü tam da bu, cache-yazma priminin amortize olduğu ve 0.1 katlık okumaların karşılığını verdiği durum (maliyet modelinin yüz-query örneği). Corpus, caching makinesinin zahmete değmeyeceği kadar çok küçükse, ya da query’ler yazmayı hiç amortize edemeyeceğin kadar seyrekse düz long-context tıkıştırmaya meyilli ol. Ve adını anmaya değer bir orta şerit var: pencereye sığan ama her çağrıda cache’leyip okumak istemeyeceğin kadar büyük, orta boy bir corpus. Bunun için, sıradan long-context (ya da maliyet tırmanırsa RAG) pragmatik seçim. Figürdeki matris tüm bunu çiziyor: sabit olan sol boyunca (küçük için altta CAG, orta boy için üstte long-context), ve sağ tarafın tamamı, hızlı değişen ya da devasa olan her şey, RAG’e ait.

Meta nokta, ve bu bölümü serinin tüm omurgasına bağlayan şey, sorunun artık bir kez ve global olarak cevaplanan “RAG mı değil mi” olmadığı. Soru artık “bu corpus ne istiyor,” corpus’un boyutundan, değişkenliğinden ve trafiğinden cevaplanıyor. Bu, 11. Bölüm’ün long-context’e karşı RAG’de ve 15. Bölüm’ün query-başı yönlendirmede vardığı aynı disiplin: global seçmeyi bırak, ölç, ve karmaşıklığı yalnızca corpus’un talep ettiği yere harca. Bazen corpus tam bir retrieval pipeline’ı talep eder. Bazen yalnızca cache’lenmek ister. Aradaki farkı bilmek, bu serinin öğretmesi gereken son beceri.

Kendin dene

Ekonomi tüm argüman, bu yüzden onu hissetmenin en iyi yolu maliyet modelinin sana yalan söylemesini sağlamak ve sonra bunun durmasını izlemek. rag_vs_long_context.py’ı al (yalnızca standart kütüphane) ve çalıştır. Üç stratejinin tek bir query’de ve yüz query’de fiyatlandırıldığını, CAG’in önce naif long-context’i sonra RAG’i geçtiği crossover noktalarını, ve corpus büyüdükçe kazananın CAG’den RAG’e döndüğü bir corpus-boyutu taramasını göreceksin. Sonra şu üç deneyi sırayla dene.

İlk olarak, cache indirimini öldür ve CAG’in long-context’e çökmesini izle. CAG için tüm argüman, cache-okuma oranının fresh oranın bir kesri olmasına dayanıyor. Pricing dataclass’ında, cache_read’i 0.10’dan 1.0’a değiştir (caching artık hiçbir şey kazandırmıyor) ve yeniden çalıştır. Yüz-query’lik CAG toplamı kabaca naif long-context toplamına sıçrar, CAG’in RAG’i yendiği crossover kaybolur, ve CAG taramada asla kazanan olmaz. Bu, prompt caching olmadan karşı-olgusal bir dünya, ve ucuz cache’lenmiş okumalar var olmadan önce CAG’in neden uygulanabilir bir fikir olmadığının tam sebebi bu. 0.1 katlık indirim bir detay değil; taşıyıcı duvar.

İkincisi, crossover’ı fiyatlandırmanı değil, trafiğini değiştirerek taşı. CAG’in tek query’de kaybedip yüzde kazanmasının sebebi, yazma priminin amortizasyonu. first_crossover("cag", "rag", ...) çağrısını bul ve raporladığı query sayısını not al. Şimdi corpus’u büyüt (Workload’daki corpus_tokens’ı 4000’den 40000’e yükselt) ve yeniden çalıştır: crossover daha geç gelir ya da ortadan kalkar, çünkü daha büyük bir cache’lenmiş corpus’u her query’de okumak daha pahalıya mal olurken RAG’in top-k maliyeti neredeyse hiç kıpırdamaz. Sonra corpus’u küçült (1000’e düşür) ve CAG’in neredeyse hemen kazanmasını izle. Karar matrisinin sınırını elle izliyorsun: küçük ve sabit bir corpus’u ne kadar çok yeniden kullanırsan, CAG o kadar karşılığını verir, ve corpus ne kadar büyürse, RAG liderliği o kadar erken geri alır.

Üçüncüsü, cache-bozan tuzağı simüle et. Model, corpus’un mükemmel cache’lenen temiz, sabit bir prefix’te oturduğunu varsayıyor. Gerçek prompt’lar genelde bunu, prefix’e değişken içerik karıştırarak bozar. Workload’a bir volatile_tokens alanı ekle (diyelim istek-başına 300 token’lık tool sonuçları) ve cost_cag içinde, bu token’ları her çağrıda cache’lenmiş oran yerine fresh oranından faturalandır, sonra onları zihinsel yerleşiminde corpus’un önüne taşı, böylece kendilerinden sonrasının cache’ini geçersiz kılsınlar. Yeniden çalıştır ve CAG’in avantajının küçülmesini ya da buharlaşmasını izle. Bu, “değişken tool sonuçları cache’i bozar” başarısızlığının sayısal hale gelmiş biçimi: cache’lenmiş prefix’inin içinde bir şey değiştiği an, neredeyse bedava olduğunu sandığın corpus için fresh-input oranları ödemeye geri dönersin.

⚠️ Sık düşülen tuzaklar

• Sığmayan ya da yerinde durmayan bir corpus’u tıkıştırmak. Long-context ve CAG’in ikisi de tüm corpus’un bağlam penceresine sığmasını ve sabit kalmasını gerektirir. Pencereden büyük bir corpus basitçe tıkıştırılamaz, ve sık değişen biri cache’i sürekli yeniden hesaplamaya zorlar, CAG’in avantajını siler. İkisinden biri doğruysa cevap RAG’dir, daha büyük bir prompt değil.
• Değişken içeriği cache’lenmiş prefix’e koymak. Caching bir prefix eşleşmesidir: prefix’in herhangi bir yerindeki bir zaman damgası, istek-başına bir id, bir session token, ya da değişen bir tool sonucu, cache’i o noktadan itibaren geçersiz kılar. Sabit kısımları önce tut (talimatlar, sonra corpus) ve değişken query’yi ve tool sonuçlarını en sona, son cache noktasından sonra koy; yoksa cache’lemeyi düşündüğün corpus için fresh-input oranları ödersin.
• CAG’i tek bir query üzerinden yargılamak. Tek bir query’de CAG en pahalı seçenektir, çünkü yazma primini ödedin ve bir okuma elde ettin. Tüm değeri, aynı sabit corpus’un birçok kez yeniden kullanılması üzerinden amortizasyonda. Onu tek bir çağrı üzerinde, ya da yalnızca ara sıra cevapladığın bir corpus üzerinde ölçmek, sana kararlı-durum maliyeti hakkında hiçbir şey söylemez.
• “Bağlam pencereleri artık devasa” düşüncesini “RAG öldü” olarak ele almak. Bir milyon token’lık bir pencere gerçek bir kurumsal corpus’u tutmaz, kullanıcı-başına erişimi filtrelemez, ve maliyeti yok etmez (tıkıştırılan her token her istekte faturalandırılır). Long-context ve CAG dar bir şekilde kazanır (küçük, sabit, tekrar kullanılan); büyük, yaşayan, multi-tenant durum hâlâ RAG’e ait.
• Sabit bir maliyet tasarrufundan bahsetmek. Büyüklük-mertebesi cache-okuma indirimi gerçek, ama gerçek tasarrufun corpus boyutuna, yeniden kullanım oranına ve sağlayıcının tam oranlarına bağlı. Buradaki maliyet modeli crossover şeklini göstermek için göreli birimlerde; taahhüt etmeden önce rakamları kendi faturana karşı doğrula.

Özet çıkarımlar

• 2026 gerçeği, bağlam pencerelerinin yaklaşık bir milyon token’a ulaşması; yeterince küçük bir corpus için retrieval’ı atlayıp her şeyi prompt’a koyabilirsin. Yakalanacak nokta, her prompt token’ının her istekte faturalandırılması; yani “olduğu gibi tıkıştır,” pencereye-sığma kazancını her-query’de-ödenen bir maliyetle takas eder.
• Üç seçenek var: RAG (yalnızca ihtiyacın olan k chunk’ı retrieve et; maliyet corpus boyutunu değil k’yı takip eder), long-context tıkıştırma (her query’de tüm corpus’u fresh gönder; en basiti, ama sonsuza dek corpus boyutunda doğrusal), ve CAG (corpus’u bir kez önceden yükle, KV durumunu cache’le, ve yeniden kullan; caching sayesinde uygun fiyatlı hale gelmiş long-context).
• Cache-Augmented Generation (Chan ve ark., arXiv 2412.15605), küçük ve sabit bir corpus’u bağlama önceden yükler, modelin KV durumunu onun üzerinde kalıcı hale getirir, ve o durumu her query’de yeniden kullanır. Retrieval gecikmesini ve retrieval hatasını kaldırır, ama yalnızca pencereye sığan ve sabit kalan bir corpus için.
• Prompt-caching ekonomisi köprü. Cache’lenmiş bir input token, fresh orana kıyasla kabaca 0.1 kata mal olur, buna karşılık kabaca 1.25 katlık tek seferlik bir yazma primi. Prompt’u sabit, cache’lenebilir bir prefix (talimatlar, sonra corpus) artı en sonda dinamik query olarak yapılandır; prefix’teki değişken tool sonuçları cache’i bozar ve sessizce tam fiyatlandırmaya geri döner.
• Karar matrisi iki eksen artı maliyet üzerinde çalışır: devasa, hızlı değişen ya da özel corpus RAG’e; küçük ve sabit corpus CAG’e (yazmayı amortize edecek kadar yeniden kullanıyorsan) ya da düz long-context tıkıştırmaya (çok küçükse ya da nadiren sorgulanıyorsa); orta boy corpus long-context’e.
• Serinin kapanış dersi, query yerine corpus’a uygulanmış: global olarak “RAG mı değil mi” sormayı bırak. Bu corpus’un ne istediğini, boyutundan, değişkenliğinden ve trafiğinden sor, ve retrieval karmaşıklığını yalnızca hak ettiği yerde harca.

Referanslar

• Brian J. Chan, Chao-Ting Chen, Jui-Hung Cheng ve Hen-Hsen Huang. “Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks.” 2024. arXiv:2412.15605. CAG’i adlandıran ve motive eden makale. İlgili tüm kaynakları genişletilmiş bağlamlı bir modele önceden yüklemeyi ve runtime KV durumunu cache’lemeyi öneriyor; böylece çıkarım anında model, retrieval adımı olmadan önceden yüklenmiş durumdan cevap veriyor. Raporlanan avantaj tam olarak bu bölümün tarif ettiği iki yönlü avantaj: retrieval gecikmesini ortadan kaldırmak ve sınırlı, sabit bir corpus’a sahip bilgi görevleri için RAG’in belge-seçim hatalarını en aza indirmek. Genel bir yerine geçen olarak değil, açıkça bu şekildeki problem için bir RAG alternatifi olarak çerçeveleniyor; bu yüzden bu bölüm onu en tepeye değil, karar matrisinin bir hücresine yerleştiriyor.
• Zhuowan Li, Cheng Li, Mingyang Zhang, Qiaozhu Mei ve Michael Bendersky. “Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.” EMNLP 2024 (industry track). arXiv:2407.16833. Self-Route çalışması, 11. Bölüm’de de anılmıştı. Bulgusu buradaki matrisi destekliyor: long-context ve RAG her biri farklı input’larda kazanıyor, ve pragmatik hamle birini global olarak seçmek yerine query başına yönlendirmek; bu bölümün uyguladığı aynı corpus-başına yargı.
• Kuan Li, Liwen Zhang, Yong Jiang, Pengjun Xie, Fei Huang, Shuai Wang ve Minhao Cheng. “LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs - No Silver Bullet for LC or RAG Routing.” ICML 2025. arXiv:2502.09977. Alt başlığı bu bölümün benimsediği sonucu ifade eden benchmark: long-context ile RAG arasında evrensel bir kazanan yok, dolayısıyla cevap corpus boyutuna, query türüne ve bütçeye bağlı olarak “duruma göre değişir.”

Sözlük

• Long-context tıkıştırma (long-context stuffing): her istekte tüm corpus’u prompt’a koymak ve modelin cevap vermek için hepsini okumasına izin vermek, retrieval olmadan. Basit, ama her query’de tüm corpus için fresh-input oranından ödersin.
• Cache-Augmented Generation (CAG): küçük ve sabit bir corpus’u bağlama bir kez önceden yüklemek, modelin bu token’lar üzerindeki anahtar-değer (KV) durumunu kalıcı hale getirmek, ve corpus hiç yeniden işlenmesin diye o cache’lenmiş durumu her query’de yeniden kullanmak. Retrieval gecikmesini, büyük ama cache’lenebilir bir prompt’la takas eder.
• KV cache: bir transformer’ın bir prompt’u işlerken her token için hesapladığı, prompt’u yeniden okumadan sonraki token’ları üretmesini sağlayan anahtar ve değer vektörleri. CAG, bu cache’i atmak yerine istekler arasında kalıcı hale getirir.
• Prompt caching: prompt’unun sabit bir prefix’ini saklayan ve tek seferlik bir yazma primi (kabaca 1.25 kat) sonrasında sonraki isteklerde onu normal input oranının bir kesrinde (kabaca 0.1 kat) servis eden bir sağlayıcı özelliği. Bir prefix eşleşmesidir: prefix’teki herhangi bir byte değişikliği, o noktadan itibaren cache’i geçersiz kılar.
• Önbelleklenebilir prefix (cacheable prefix): bir prompt’un cache’lenebilen ve yeniden kullanılabilen sabit, öndeki kısmı (tipik olarak sabit talimatlar ve ardından corpus). Dinamik query ve herhangi bir değişken tool sonucu, ondan sonra gelmeli, yoksa cache bozulur.
• Bağlam şişmesi (context inflation): prompt’a konan her chunk’ın ya da belgenin her istekte input token olarak faturalandırılması etkisi (12. Bölüm’den); yani daha fazla bağlam tıkıştırmak query-başına maliyeti yükseltir. Long-context tıkıştırma, bu etkinin sınırına götürülmüş hali; prompt caching onu evcilleştiren şey.
• Karar matrisi (decision matrix): RAG, CAG ve long-context arasında seçim yapma kuralı, iki eksende (corpus boyutu ve değişkenlik) ve beraberlik bozucu olarak maliyetle: devasa, hızlı değişen ya da özel olan RAG’e; küçük ve sabit olan CAG’e ya da tıkıştırmaya; orta boy olan long-context’e.

---

Sırada, 17. Bölüm’de, Üretimde RAG en çok atlanan ve en çok canını yakan konuyu işaret etmişti: güvenlik. Ona tam bir işlem yapacağız: tehdit modeli, saldırı kataloğu (retrieve edilen belgeler üzerinden prompt injection, tenant’lar arası veri sızıntısı), ve derinlemesine işlenmiş savunmalar, doğrudan 12. Bölüm’ün production temeli üzerine inşa ederek. Burada karara bağladığımız retrieve edip etmeme kararı, ancak nasıl güvenli retrieve edeceğini bildiğinde güvenlidir.