Bağlam Penceresi Ekonomisi: RAG Sistemlerinin Gizli Faturası

LLM Maliyet Mühendisliği baglam-penceresi, rag

Bağlamı doldurmak, modelin görmezden geldiği tokenlar dahil her çağrıda maliyet yazar. RAG bağlamını alakalı, sıralı ve sıkıştırılmış tutan mühendislik.

  • Yazar: Orzed Team
  • 1 dk okuma
Önemli çıkarımlar
  • Tipik bir RAG çağrısı, tokenlarının %60 ila %80'ini nihai yanıtta hiç kullanılmayan metin parçalarına harcar.
  • Çapraz kodlayıcı (cross-encoder) ile yeniden sıralama, kalite kaybı olmadan bağlamı yaklaşık 3 parçaya indirir.
  • Uzun bağlamlı (long-context) modeller bu sorunu çözmez; sadece faturayı daha pahalı hale getirir.
  • İstem başına token bütçeleri bir model özelliği değil, operasyonel bir mühendislik disiplinidir.

Canlıda RAG sistemi çalıştıran bir ekip, her sorguda uzun bağlamlı bir modele 800’er tokenlık 12 metin parçası gönderiyordu. 2.500 tokenlık sistem istemiyle birlikte çağrı başına girdi maliyeti 12.100 tokendı ve aylık 1.4 milyon sorguda LLM faturası 58.800 dolara ulaşmıştı.

Rastgele seçilen 200 çağrıyı incelediğimizde, modelin yanıt üretirken ortalama yalnızca 2.4 parçadaki bilgiyi kullandığını gördük. Geri kalan 9.6 parça tamamen gürültüydü; parası ödeniyor ve model tarafından yok sayılıyordu. İlk 50 sonuç içinden en alakalı 3 parçayı seçen bir çapraz kodlayıcı (cross-encoder) yeniden sıralayıcı ekledik. Çağrı başı girdi 4.800 tokena, aylık fatura ise 23.200 dolara düştü; üstelik bağlam sulanması azaldığı için doğruluk skoru %4 arttı.

Üç Temel Kaldıraç: Yeniden Sırala, Kırp ve Bütçele

Vektör araması yaklaşık benzerliğe göre sıralama yapar ve doğru parça bazen 8. sırada kalabilir. Ekipler güvende olmak için ilk 12 parçayı gönderir. İki aşamalı erişim bu sorunu çözer: vektör veritabanından ilk 50 adayı çekin, ardından sorgu ile metni birlikte puanlayan küçük bir çapraz kodlayıcı modelle en iyi 3 parçayı seçin. 50 ila 200 milisaniyelik bu ek adım, LLM girdi maliyetini yarıdan fazla düşürür.

İkinci kaldıraç metin parçalarını kırpmaktır. İndeksleme sırasında 800 yerine 200-400 tokenlık parçalar (100 token örtüşmeyle) kullanmak veya erişim sonrasında sorguyla alakasız cümleleri filtrelemek gereksiz dolgu metinlerini temizler. Üçüncü kaldıraç ise kod seviyesinde zorlanan istem başı token bütçeleridir (PROMPT_BUDGETS). Bir istem için 4.000 token sınırı koyduğunuzda, yeni bir şey eklemek isteyen her geliştirici önce neyi çıkaracağını düşünmek zorunda kalır.

Uzun Bağlam Yanılgısı ve Canlı Ortam Standardı

200K veya 1M token penceresine sahip modeller bağlam ekonomisini ortadan kaldırmaz. Üstelik araştırmalar bağlam 30K-50K tokenı geçtiğinde modellerin ortadaki bilgileri kaçırma (“lost in the middle”) eğiliminin arttığını göstermektedir. İyi ayarlanmış bir 2026 RAG sistemi çağrı başına önbellekli bir sistem istemi ve yeniden sıralanmış 2 ila 4 parçayla toplam 10K tokenın altında kalır ve naif kurulumlardan 3 ila 5 kat daha ucuza çalışır.

Sıkça sorulanlar

Sıkça sorulan sorular

Uzun bağlamlı bir model kullanmak bu sorunu doğrudan çözmez mi?

Hayır. Uzun bağlamlı modeller daha fazla token kabul eder ancak gönderdiğiniz her token için ücret ödersiniz. 200 bin tokenlık bir çağrı, aynı modele yapılan odaklanmış 8 bin tokenlık çağrıdan çok daha pahalıdır. Bağlam uzunluğu bir maliyet avantajı değil, kapasite özelliğidir.

En iyi yeniden sıralama (reranking) yöntemi hangisidir?

Sorguyu ve metin parçasını birlikte değerlendiren küçük bir BERT sınıfı çapraz kodlayıcı (cross-encoder) en yüksek kesinliği sunar. Çoğu canlı RAG sisteminde vektör aramasından gelen ilk 50 adayı yeniden sıralayıp LLM'e yalnızca en iyi 3 ila 5 parçayı göndermek idealdir.

Getirilen parçaları modele göndermeden önce özetlemeli miyim?

Parçalar uzunsa (her biri 500 token üzeri) ve soru dar kapsamlıysa ucuz bir modelle özetlemek mantıklıdır. Ancak özetleme ek bir LLM çağrısı ve gecikme demektir; parçalar zaten kısaysa cümle düzeyi filtreleme daha ekonomiktir.