RAG pipeline'ımı bir kara kutu gibi görürdüm. Embedding'ler girer, cevaplar çıkardı ve bir yerlerde bulut faturam kabarırdı. Konuştuğum çoğu geliştirici gibi, yoğun vektör modellerinin suçlu olduğunu varsayıyordum. Kulağa pahalı geliyorlardı. Binlerce sayfayı yüksek boyutlu float değerlerine dönüştürmek ağır bir üretim süreci gibi hissettiriyordu, bu yüzden buna uygun bir dikkatle yaklaşıyordum. Hatta daha önce işlediğim verileri yeniden embedding işlemine sokmamak için özel bir önbelleğe alma (caching) katmanı bile inşa etmiştim. Bu optimizasyonla gurur duyuyordum. Sonra faturayı açtım ve hesabı yaptım.
Tamamen yanlış şeyi optimize ediyordum.
Embedding Tuzağı
Varsayımlarımı yıkan rakam şuydu: 1.000 sayfalık bir belgeyi embedding işlemiyle vektörleştirmek yaklaşık on sekiz sent tutuyor. Bu bir yazım hatası değil. Çoğu şehirde bir fincan kahve fiyatından daha ucuza, bütün bir kitabı vektörleştirebilirsiniz. Daha da önemlisi, bu maliyet sadece bir kez, ingestion (veri alımı) aşamasında gerçekleşir. İlk geçişten sonra, bu vektörler depolamada durur ve bekler. Her kullanıcı uygulamanızı açtığında metrelenen ücretler biriktirmezler. Bunlar sürekli bir gider değil, sermaye gideridir.
Yine de bu efsane devam ediyor. Karışıklığın bir kısmı yapısal. Mühendislerin enerjilerini ilk olarak harcadıkları yer ingestion pipeline'ıdır. Chunker'ı yazarsınız, tokenizer ile mücadele edersiniz, terminalinizde ilerleme çubuklarının yavaşça ilerlemesini izlersiniz. Bu görünür çaba, bir oran illüzyonu yaratır. Emek yoğun bir kısım olduğu için pahalı kısım öyleymiş gibi hissettirir. Ancak emek ve maliyet aynı şey değildir ve RAG sistemlerinde bunlar genellikle ters orantılıdır.
Üç Çok Farklı Fatura
Maliyetleri bir araya toplamak yerine aşamalara ayırdığımda tablo netleşti. Bir RAG sistemi üç farklı ekonomik model üzerinde çalışır ve bütçenizi kontrol altında tutmak istiyorsanız aradaki farkı anlamak esastır.
Embedding'ler tek seferlik bir üretim maliyetidir. Belgeleri vektörlere dönüştürmek için ödeme yaparsınız ve işlem biter. Belgeleriniz statikse, bu kalem aylık faturanızda neredeyse hiç görünmez.
Vektör veritabanları altyapı kirasıdır. Sistemin günün her saati ayakta kalması için ödeme yaparsınız. Milyonlarca chunk'ı tutan SSD'ler, indeksleri koruyan CPU çekirdekleri ve 100 milisaniyenin altındaki aramaları sağlayan ağ için ödeme yaparsınız. Bu maliyet gerçektir ve veri hacmiyle birlikte ölçeklenir, ancak genellikle öngörülebilirdir. Bir spor salonu üyeliği gibi davranır. İster bir kez ister on bin kez sorgu yapın, temel altyapı maliyeti kabaca aynı kalır.
Büyük dil modelleri (LLM) tüketim vergileridir. Her bir kullanıcı sorusu bir fatura tetikler. Retrieval (getirme) katmanınızdan çıkan ve prompt'a giren her bir token para maliyetidir. Her bir akıl yürütme adımı, her bir biçimlendirme talimatı, modelden oluşturmasını istediğiniz her bir atıf mikroskobik bir ağırlık ekler. Ancak bu mikro ücretler oturum sayısıyla çarpılır ve oturum sayıları yukarı yönlü bir eğilim gösterir. Gecikmenin (latency) harcamalarla katlanarak arttığı yer burasıdır. Yavaş bir sorgu kullanıcı için sadece sinir bozucu değildir; kullanıcı beklerken aktif olarak nakit yakar.
Bunlar aynı problemin farklı varyasyonları değildir. Bunlar üç ayrı problemdir. Ingestion işlemini ucuzlatarak sorgu anındaki harcama problemini çözemezsiniz. Bu, otopark ücretinden tasarruf etmek için arabanızın motorunu ayarlamaya benzer.
Para Aslında Nereye Gidiyor
Eğer üretim aşamasında (production) bir RAG uygulaması çalıştırıyorsanız, maliyet gezgininizi (cost explorer) açın ve kullanım türüne göre filtreleyin. Bahse girerim ki embedding işiniz günde bir kez düz bir çizgi halindeyken, LLM uç noktanız (endpoint) trafikle birlikte yükselen bir kalp atışı gibi görünecektir. Bu desen tüm hikayeyi anlatıyor. Vektörleriniz uyur; modeliniz ise her kullanıcı bir soru sorduğunda uyanır.
Bu farkındalık, mühendislik çalışmalarına öncelik verme şeklimi değiştirdi. Ingestion işlemini nasıl daha ucuz hale getireceğimi sormayı bıraktım ve her bir soruyu nasıl daha ucuz hale getirebileceğimi sormaya başladım. Bu değişim kulağa bariz geliyor ancak çoğu ekip hala tahminlerle hareket ediyor. Embedding aşaması için karmaşık tekilleştirme (deduplication) mantıkları kuruyorlar ve sonra LLM'e hiç düşünmeden şişkin, odaklanmamış bağlam pencereleri (context windows) besliyorlar. Çatı akıtırken yerleri parlatıyorlar.
Pipeline'ınızı Bozmadan Maliyetleri Nasıl Düşürürsünüz
Bir RAG sisteminde tasarruf etmek, taktiği maliyet modeliyle eşleştirmeyi gerektirir. İşte gerçekten işe yarayan yöntemler:
İşlemden Önce Tekilleştirme Yapın
Çoğu kurumsal bilgi tabanı yavaş ilerler. Politikalar, el kitapları, araştırma PDF'leri ve arşivlenmiş raporlar aylarca dokunulmadan bekler. Birçok veri hattında (pipeline), kaynak dokümanların yaklaşık yüzde sekseni veri alım süreçleri arasında aynı kalır. Buna rağmen, pek çok sistem tüm külliyatı atıp indeksi belirli aralıklarla sıfırdan oluşturur. Bunu yapmayın. Veri hattınızın girişine bir kapı kurun. Gelen dosyaları hash'leyin. Son değiştirilme zaman damgalarını karşılaştırın. Eğer bir doküman değişmediyse, onu tamamen atlayın. Statik dosyaları yeniden işlemek tamamen israftır. İşlem gücü tüketir, SSD'leri gereksiz yere yıpratır ve veri alım günlüklerinizi (ingestion logs) sahte aktivitelerle şişirir.
Pratikte, dosya yollarını checksum'lara eşleyen hafif bir manifest dosyası saklayın. Zamanlayıcı çalıştığında, önce manifest'i kontrol etmesini sağlayın. Sadece değişen azınlık sayıdaki dosyalar bir chunker'dan geçmelidir.
Dokümanları Değiştirmek Yerine Yamalayın
Bir doküman değiştiğinde, onu tamamen yeni bir dosya gibi ele alma içgüdüsüne karşı koyun. Elli sayfalık bir teknik şartname, dördüncü bölümünde iki paragraflık bir revizyon alabilir. Eğer veri hattınız tüm dosyayı değiştirirse, kırk dokuz mükemmel sayfayı hiçbir sebep yokken yeniden parçalar (re-chunk) ve yeniden gömer (re-embed).
Bunun yerine, yeni versiyonu eskisiyle karşılaştırın. Farkı (delta) belirleyin. Ardından sadece değişen bölümleri yeniden parçalayın ve yeniden gömün. Sınırları takip etmek için sayfa numaraları, bölüm kimlikleri (section IDs), başlık çapa noktaları (header anchors) veya paragraf aralıkları gibi meta verileri kullanın. Eğer parçalama (chunking) stratejiniz doküman yapısına saygı duyuyorsa, bu oldukça basittir. Duymuyorsa, chunker'ınızı düzeltmek, daha büyük bir çıkarım kümesi (inference cluster) satın almaktan daha iyi bir yatırımdır. Doküman sayınız ölçeklendikçe, fark farkındalığı olan (diff-aware) bir veri hattı sürdürmenin mühendislik maliyeti kendini haftalar içinde amorti edecektir.
Tekrarlayan Maliyetlere Doğrudan Saldırın
LLM çağrıları her sorguda çalıştığı için, birkaç token tasarrufu sağlamak veya bir avuç yanıtı önbelleğe almak bile büyük getiriler sağlar. Prompt caching (istem önbelleğe alma) ile başlayın. Eğer bir kullanıcı iade politikanızı sorarsa ve bir diğeri on dakika sonra aynı şeyi sorarsa, modele iki kez başvurmak için hiçbir neden yoktur. Yakın anlamsal benzerlik eşleştirmesi ile son sorgu-yanıt çiftlerini saklayın. Yeni bir soru, önbelleğe alınmış bir soruyla benzerlik eşiği içindeyse, saklanan yanıtı doğrudan döndürün. Token üretilmez, dolar harcanmaz.
Ardından, getirme (retrieval) kalitenize yakından bakın. Özensiz bir retriever, LLM'i iğneyi bulmak için samanlık okumaya zorlar. Eğer top-k sınırınız çok gevşek olduğu için istemi (prompt) yirmi alakasız parça ile doldurursanız, modele gürültüyü taraması için ödeme yapıyorsunuz demektir. Getirmeyi sıkılaştırın. Top-k değerinizi düşürün. Parçaları göndermeden önce sıkıştırın. Veri alımı sırasında basmakalıp altbilgi ve üstbilgileri (boilerplate footers and headers) kaldırın ki isteme hiç ulaşmasınlar. Bağlam penceresinden (context window) çıkardığınız her token, tasarruf edilen bir sentin küçük bir parçasıdır ve bu küçük parçalar binlerce günlük sorgu boyunca birikir.
Daha iyi bir getirme işlemi, maliyetin bir başka biçimi olan gecikmeyi (latency) de iyileştirir. Kullanıcılar yavaş arayüzleri terk eder. Daha hızlı bir yanıt, hem üretilmesi daha ucuzdur hem de kullanıcıyı elde tutma (retention) açısından daha iyidir.
Asıl Çıkarılması Gereken Ders
Pahalıymış gibi hissettiren şeyleri optimize etmeyi bırakın ve faturanızın pahalı olduğunu söylediği şeyleri optimize etmeye başlayın. Her aşamayı bağımsız olarak ölçün. Muhtemelen embedding'lerin ucuz kısım, vektör depolamanın istikrarlı kısım ve LLM çıkarımının (inference) ise bütçeyi tüketen kısım olduğunu göreceksiniz. Enerjinizi sorgu zamanı verimliliğine, artımlı güncellemelere ve cerrahi düzeyde tekilleştirmeye odaklayın. Ellinci doküman yüklemesi için değil, bininci kullanıcı sorusu için inşa edin. Darboğaz nadiren düşündüğünüz yerdedir.
Kaynak: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Tartışmaya GyaanSetu AI öğrenme topluluğunda katılın.