En İyi RAG Araçları, Çerçeveleri ve Kütüphaneleri
RAG, LLM yanıtlarını yalnızca modelin eğitim sırasında ezberledikleri yerine harici verilerle temellendirerek iyileştirir. Bir RAG sistemini oluşturan bileşenleri kıyasladık ve sonuçları, yığının her parçasını seçmeye yönelik pratik bir rehberle birlikte tek bir yerde topladık.
Her RAG bileşeni için kıyaslama sonuçlarımıza, RAG yığını seçme rehberimize veya RAG temellerine bakın: nedir, nasıl çalışır ve nerede yer alır.
RAG kıyaslama sonuçları
Gömme modelleri
Gömme modeli hem belgelerinizi hem de kullanıcının sorgusunu vektörlere dönüştürür, bu nedenle getirme kalitesinin tavanını belirler.
15 yoğun gömme modelini artı bir BM25 sözcüksel taban çizgisini üç alanda (yasal sözleşmeler/CUAD, müşteri desteği/TechQA ve sağlık/MedRAG) kıyasladık ve her birini nDCG@3 ile puanladık.
voyage-3.5, 0.9429 ile ilk sırada yer alıyor ve Voyage'ın kendi amiral gemisi voyage-4-large'ı geride bırakırken yarı fiyatına mal oluyor (1M token başına $0.060 karşısında $0.120). En yeni, en büyük model otomatik olarak en iyi satın alma değildir. Maliyet öncelikli yığınlar için, perplexity'nin pplx-embed-v1-0.6b modeli voyage-3.5'in kalitesinin yaklaşık %92'sini (0.8604) yaklaşık on beşte biri fiyata (1M token başına $0.004) sunar. Doğruluk-fiyat görünümü için, alan bazında döküm ve metodolojiyi de içeren tam gömme modelleri kıyaslamasındaki maliyet grafiğine bakın.
Tek vektörlü yoğun gömmelerin ötesinde, geç etkileşimli (çok vektörlü) getiriciler, ColBERT (ve görsel belge ve PDF getirme için ColPali/ColQwen) gibi, daha ince eşleştirme ve daha güçlü alan dışı genelleme için token başına bir vektör tutar, ancak çok daha büyük bir dizin ile (ColPali öğe başına kabaca 1.000 kat daha fazla vektör depolar; çok modlu gömme kıyaslamamıza bakın).
Külliyatınız çok dilli veya görsel ise, gömme seçimi değişir: çok dilli gömme kıyaslamamız, 110M parametreli bir modelin (e5_base) altı dilin tümünde lider olduğunu ve 70 kat daha büyük modelleri yendiğini ortaya koydu ve çok modlu kıyaslamamız Apple'ın DFN5B-H modelini metinden görüntüye Recall@1'de %50.1 ile zirveye yerleştirdi. Verileri bir API'ye gönderemeyen ekipler için, açık kaynak gömme kıyaslamamız NVIDIA'nın Nemotron-8B modelini (0.9249 nDCG@3) birinci sıraya koyarken, Microsoft'un MIT lisanslı 0.6B Harrier-oss modeli kısıtlamasız ticari kullanım için en güçlü seçenek oldu.
Yeniden sıralama
İki kodlayıcılı bir getirici hızlıdır ancak yaklaşıktır. Yeniden sıralayıcı, getiricinin döndürdüğü en iyi adayları yeniden puanlayan ve gerçekten ilgili parçaları LLM'ye ulaşmadan önce en üste itmek için her sorgu-belge çiftini birlikte okuyan bir çapraz kodlayıcıdır. 2026'daki standart işlem hattı, geniş bir küme getirmek, onu yeniden sıralamak ve ardından modele 3-5 parça göndermektir. 1
İngilizce getirme üzerinde 8 yeniden sıralayıcıyı kıyasladık (en iyi 100 aday, 300 sorgu):
Bir yeniden sıralayıcı eklemek, ilk-1 isabet doğruluğunu (Hit@1) %62.67'den %83.00'e yükseltti, yani tek bir ekstra aşamadan 20.33 puanlık bir sıçrama. Satın alma kararını değiştirmesi gereken sonuç: 149M parametreli bir model (gte-reranker-modernbert-base), en üstte 1.2B'lik bir modelle eşleşti, bu nedenle en büyük yeniden sıralayıcı hedeflenmesi gereken değil. Tam yeniden sıralayıcı kıyaslaması, gecikme süresini ve Hit@10 tavanını kapsar.
Vektör veritabanları
Vektör veritabanı, gömmelerinizi depolar ve sorgu zamanında en yakın komşu aramasını sunar, böylece gecikme tabanını ve işletme maliyetinin büyük bir kısmını belirler. Aynı bge-m3 gömmeleri üzerinde yedi açık kaynak, kendi kendine barındırılan motoru kıyasladık; her biri, dizinin tek değişken olması için eşleşen bir Recall@10 değeri olan 0.95'te okundu.
Yedisi getirme doğruluğunda eşit. nDCG@10, 0.803 ile 0.817 arasında, 0.014'lük bir dağılımla yer alırken, tek iş parçacıklı verimde 10 kat (Redis 764 QPS, LanceDB 70) ve 2.25M vektörde tepe bellek kullanımında 3.7 kat (Milvus 17.0 GB, Chroma 62.4 GB) bir dağılım söz konusu. Motor, bu çalışma noktasında kalite tavanını belirleyen gömme modeli olduğu için doğruluktan ziyade bir hız, bellek ve iş yükü kararıdır.
Hangi motorun uyduğu iş yükünden anlaşılır. Redis, kalıcılık kapalıyken RAM'de 559 MB ile 1.7 ms p95 kaydetti. Weaviate, 32 işçi sürecinde 8.330 QPS'ye ulaşırken Redis 1.642'de doyuma ulaştı. Milvus, 2.25M vektörde 17.0 GB tutarken Chroma 62.4 GB ve meta veri filtreleri altında en yüksek en kötü durum geri çağırmasını korudu (0.984). Qdrant, yerel füzyon ile +0.067 nDCG hibrit kaldıraç kaydetti. İki motorun katı sınırları var: Chroma, kendi kendine barındırılan yapısında anahtar kelime araması sunmaz ve 512 eşzamanlı istemcide 13 saniyelik bir p99 döndürür; LanceDB ise saniyede 2.6 tek satırlık yazma işlemi emer, bu da onu sürekli güncellenen bir bilgi tabanı için devre dışı bırakır. Tam açık kaynak vektör veritabanı kıyaslaması filtrelenmiş aramayı, yapım maliyetini ve canlı değişimi kapsar ve vektör veritabanı boyutlandırma hesaplayıcı bu sınırları belirli bir sunucu için motor başına bir karara dönüştürür.
RAG yığınınızı nasıl seçersiniz
Yukarıdaki kıyaslamalar “Hangi bileşen tek başına en iyisidir?” sorusunu yanıtlar. Bu bölüm “Onları nasıl bir araya getiririm?” sorusunu yanıtlar. İşlem hattını sırayla yürütün ve her aşamayı kullanım durumuna, ölçeğe ve bütçeye göre seçin:
- Parçalama: belgeleri yaklaşık 300–500 tokenlik pasajlara, %10–20 çakışma ile bölün; heterojen belgeler için sabit boyutlar yerine anlamsal/yapı farkında bölmeyi tercih edin.
- Gömme modeli: bir API üzerinde en iyi kalite-başına-dolar için voyage-3.5; kendi kendine barındırmanız gerekiyorsa qwen3-embedding-8b veya NVIDIA Nemotron-8B; külliyatınız gerektiriyorsa çok dilli veya çok modlu bir model seçin.
- Vektör veritabanı: tek sorgu gecikmesi baskın olduğunda Redis, sürekli eşzamanlılık için Weaviate veya Milvus, ölçekte bellek kısıt olduğunda Milvus, yığın zaten Postgres üzerindeyse pgvector; yediden dördü (Qdrant, Milvus, Weaviate, LanceDB) hibrit sonuçları yerel olarak birleştirir. Önce dizini sunucuya göre boyutlandırın, çünkü 16 GB'lık bir kutu, 1024 boyutta Redis'te yaklaşık 1.5M vektör ve Qdrant'ta 3.7M vektör tutar.
- Hibrit getirme: yoğun + BM25'i, vektör veritabanı kıyaslamamızda bir anahtar kelime kolu taşıyan motorlar arasında nDCG@10'u 0.030 ila 0.067 yükselten RRF ile birleştirin; bu kaldıraç Qdrant, LanceDB, Redis ve Milvus için %95 güvenle sıfırı aşarken pgvector veya Weaviate için aşmaz.
- Yeniden sıralama: iki kodlayıcının masada bıraktığı yaklaşık 20 puanlık ilk-1 doğruluğunu geri kazanmak için bir çapraz kodlayıcı ekleyin (149M'lik bir model yeterlidir).
- Üretim: kaynak atfedilebilir yanıtlar için temellendirilmiş alıntı desteğine sahip bir model kullanın.
- Değerlendirme: canlıya almadan önce getirme, üretim ve uçtan uca metrikleri bağlayın.
Kurumsal yönetişim
Kurumsal dağıtımlar için, getirme kalitesi gereklidir ancak yeterli değildir; getirme katmanının da yönetilmesi gerekir. Üretim RAG'in şunları zorunlu kılması beklenir: izin farkında getirme (sonuçlar kaynak sistemin erişim kontrollerine saygı duyar, böylece bir kullanıcı doğrudan açamayacağı bir belgeyi asla getirmez), kimlik sağlayıcıları (Okta, Azure AD, Auth0) ile senkronizasyon, böylece izin değişiklikleri neredeyse gerçek zamanlı olarak yansıtılır, denetim için her getirmeyi günlüğe kaydetme, girdi/çıktı koruma korkulukları çalıştırma ve veri ikameti kısıtlamalarına uyma. Bunları, dahili verilere dokunan herhangi bir RAG sistemi için eklenti değil, olmazsa olmazlar olarak kabul edin. 2 Bu kontroller yalnızca üstteki uygulamada değil, getirme katmanında da sağlanmalıdır ve açık kaynak motorların neleri zorunlu kılabileceği farklılık gösterir: kıyasladığımız yediliden yalnızca pgvector belirli bir noktaya kurtarma ve satır düzeyinde güvenlik sunar; Qdrant, Milvus ve Weaviate açık kaynak yapılarında çoğaltma ve RBAC sağlar; Chroma 1.x hiçbir kimlik doğrulama sunmaz ve yedisinden hiçbiri veriyi bekleme durumunda yerel olarak şifrelemez, bu da bunu disk veya birim şifrelemesine bırakır.
RAG ve uzun bağlam karşılaştırması
Bağlam pencereleri milyonlarca token'e ulaşırken, RAG'in hâlâ gerekli olup olmadığı haklı bir sorudur. 2026'da yanıt ya biri ya diğeri değil: RAG ilgili kanıtı getirir, uzun bir bağlam penceresi bunun üzerinde iyileştirme yapabilir ve bir yönlendirme katmanı her sorgunun hangi yolu izleyeceğine karar verir.
Karar genellikle maliyete dayanır. Bir LLM, her istekteki her girdi tokeni için fatura kestiğinden, tüm külliyatı bağlama doldurmak ölçekte pahalıdır. Sürekli sorgu yükü altındaki büyük bilgi tabanları için, RAG, her seferinde tüm arşiv yerine birkaç bin getirilen token için ödeme yaptığından, uzun bağlam doldurmaya kıyasla sorgu başına yaklaşık 1.250 kat daha ucuz çalışabilir. 3
Bu avantaj koşulludur ve dürüstçe belirtmek gerekir: RAG, kabaca 500K tokenin üzerindeki külliyat ve günde birkaç bin sorgu üzerinde maliyette kazanırken, ~200K tokenin altında ve günde birkaç yüz sorguda, prompt'lar önbellekleme ile uzun bağlam genellikle açık ara kazanır, çünkü yalnızca vektör veritabanının sabit barındırma maliyeti tüm uzun bağlam faturasını aşabilir. 4 Boyutlandırma modelimiz bu tabanı somut terimlere döker. 512 tokenlik parçalarla 2 GB'lık bir külliyat yaklaşık 1.15M vektör olur, bu da Qdrant'ta 5.1 GB veya Milvus'ta 6.9 GB RAM gerektirir; bu sunucu ister sorgu gelsin ister gelmesin aynı maliyete sahiptir. Doğruluk, iğne-samanlık aramalarında hâlâ getirmeden yana ağır basar, burada ilgisiz metni filtrelemek, uzun bağlam geri çağırmasını azaltan “ortada kaybolma” dikkat kaymasını azaltır.
Mevcut RAG modelleri ve araçları nelerdir?
RAG araçları üç gruba ayrılır: yerleşik temellendirme özellikli LLM'ler ve API'ler, orkestrasyon çerçeveleri ve altta yatan getirme bileşenleri (gömme modelleri, vektör veritabanları, yeniden sıralayıcılar).
Yerleşik temellendirme özellikli LLM'ler ve API'ler
Birçok model sağlayıcı artık harici bilgiyi kaynak atfıyla ekleyebilmeniz için temellendirilmiş üretim özellikleri sunuyor:
- Anthropic Claude: yanıtları sağladığınız belgelere dayandıran ve kullanılan tam pasajlara referanslar döndüren bir Citations API'si. 5
- Google Gemini: sizin için RAG işini yapan yerleşik bir Dosya Arama aracı (belgeler yükleyin ve Gemini sorgu zamanında onları parçalar, gömer ve getirir), ayrıca yönetilen kurumsal getirme için Vertex AI RAG Motoru. Ayrı “Google Arama ile temellendirme” özelliği ise kendi verilerinizden değil, canlı web'den çeker. 6
- Cohere Command: kullanıma hazır satır içi alıntılar döndüren RAG ayarlı modeller (Command R/R+ ve daha yeni Command A), özel bir Rerank uç noktası ile eşleştirilmiş. 7
- OpenAI: Assistants ve Responses API'lerinde bir dosya arama getirme aracı. 8
RAG kütüphaneleri ve çerçeveleri
Bunlar getirme ve üretimi bir işlem hattına bağlar:
- LangChain / LangGraph: genel amaçlı orkestrasyon; LangGraph durum bilgisi olan, etmen tabanlı getir-yansıt-doğrula döngüleri ekler.
- LlamaIndex: veri alımı, dizinleme ve sorgu motorları.
- Haystack: arama ve soru yanıtlama için uçtan uca işlem hatları.
- DSPy: bildirimsel, eniyileyici güdümlü prompt'lar/getirme programları.
Daha derin bir karşılaştırma için RAG çerçeveleri analizimize bakın.
Retrieval-augmented generation nedir?
Retrieval-augmented generation, bir büyük dil modeline sorgu zamanında harici bir bilgi kaynağına erişim veren bir tekniktir. Model, yalnızca eğitim sırasında sabitlenen parametrelerden yanıt vermek yerine, bir belge deposundan ilgili pasajları getirir ve yanıtını bunlara dayandırır. Bu, yanıtları güncel tutar, alıntı yapılabilir kaynaklara dayandırır ve modeli yeniden eğitmeden bilgi yoğun görevlerde halüsinasyonu azaltır.
RAG modelleri nasıl çalışır?
Özünde, RAG iki aşamada çalışır: getirme (sorguyla ilgili pasajları bul) ve üretim (bu pasajlara dayalı bir yanıt yaz). Üretim sistemlerinde, bu temel döngü daha kapsamlı bir işlem hattıyla sarılır:
- Sorgu yeniden yazma/ayrıştırma: özellikle çok turlu veya çok adımlı sorgular için daha iyi getirme sağlamak amacıyla soruyu yeniden ifade edin veya bölün.
- Hibrit getirme: yoğun (vektör) ve seyrek (BM25) aramaları çalıştırın ve sonuçları RRF ile birleştirin.
- Yeniden sıralama: bir çapraz kodlayıcı adayları yeniden puanlar ve en üsttekileri tutar.
- Bağlam oluşturma: alıntılarla seçilen parçalardan prompt'lar oluşturun.
- Üretim: LLM, oluşturulan bağlamdan yanıt verir.
- Değerlendirme: ideal olarak CI'da getirme ve yanıt kalitesini puanlayın.
İki aşamalı döngü hâlâ zihinsel modeldir; ekstra aşamalar bir demoyu bir üretim sisteminden ayıran şeydir.
Farklı RAG türleri nelerdir?
Doğrusal işlem hattının ötesinde, birkaç RAG çeşidi belirli başarısızlık modlarını hedefler: Spekülatif RAG (hız için taslak-ve-doğrula), Retrieval-Augmented Fine-Tuning (RAFT) (modeli getirilen bağlamı kullanmak üzere eğit), Self-RAG ve Corrective RAG (CRAG) (kanıt zayıf olduğunda model eleştirir ve yeniden getirir). Bunlar aşağıdaki gelişmiş mimarilerle örtüşür.
Gelişmiş RAG mimarileri
Graf tabanlı RAG (GraphRAG)
GraphRAG, külliyat üzerinde, genellikle Neo4j veya FalkorDB gibi özel bir graf veritabanı üzerinde bir bilgi grafı oluşturur, böylece sistem düz vektör aramasının kaçırdığı çok adımlı ve küresel toplama sorularını yanıtlayabilir. Bu sorulardaki avantajı büyük ölçüde, daha iyi pasaj getirmeden ziyade tüm külliyat genelinde ilişkileri önceden hesaplamaktan gelir, bu nedenle vektör araması belirli belge aramalarında hâlâ kazanma eğilimindedir. Pratik çıkarım: sorgular birçok belge genelinde küresel akıl yürütme gerektirdiğinde grafa başvurun, vektör getirmenin yerine geçen bir alternatif olarak değil.
Etmen tabanlı RAG
Etmen tabanlı RAG, getirme işleminin başına bir LLM etmeni koyar: neyin getirileceğine, hangi kaynağın veya aracın çağrılacağına ve ne zaman yansıtılıp yeniden deneneceğine karar verir, yanıt temellendirilene kadar döngüye devam eder. Her soruyu doğru veritabanına yönlendirmesi ve ardından ona karşı SQL yazması gereken bir etmeni test eden etmen tabanlı RAG kıyaslamamızda, en güçlü modeller artık neredeyse mükemmel yönlendirme yapıyor (Claude Opus 4.8 %100, Fable 5 %98), seçilen şemaya karşı doğru SQL yazmak ise daha zor tavan olmaya devam ediyor ve yaklaşık %90'da zirve yapıyor. Yönlendirme neredeyse çözüldü; temellendirilmiş yürütme, etmen tabanlı RAG'in hâlâ farklılaştığı yerdir.
Hibrit, yinelemeli ve aktif RAG
Hibrit getirme (yoğun + seyrek, yukarıda ele alındı) artık gelişmiş bir seçenek yerine varsayılandır. Yinelemeli ve aktif çeşitler (ör. FLARE), modelin üretirken güveni düştüğünde yeni kanıt getirerek tekrar getirme yapmasına izin verir.
Tercih edilen kaynak olarak ekleRAG sistemleri nasıl değerlendirilir
RAG değerlendirmesi artık üç katmanda yaşam döngüsü yapılandırmalıdır: getirme (kesinlik, geri çağırma, MRR, nDCG, hit@k: doğru parçaları getirdik mi?), üretim (temellendirilmişlik, sadakat: yanıt getirilen bağlam tarafından destekleniyor mu?) ve uçtan uca (nihai yanıt doğru mu?).
Araçlar aynı çizgide bölünür: geliştirme sırasında hızlı, referans içermeyen yineleme için RAGAS; CI'da bir regresyonun derlemeyi engellemesi için pytest tarzı geçti/kaldı kapısı olarak DeepEval; ve üretimde izleme ve gözlem için TruLens veya Phoenix. TREC-RAG ve ARES, yargıç kalibrasyonu için faydalı harici referanslardır. 9
Bir vektör veritabanı devreye girdiğinde getirme metrikleri ikiye ayrılır ve yarımlar zıt yönlerde hareket edebilir. ANN geri çağırma, dizinin gerçek en yakın vektörleri döndürüp döndürmediğini sorar, bu veritabanını izole eder; insan etiketlerine karşı nDCG ve MRR, bu belgelerin ilgili olup olmadığını sorar, ki bu çoğunlukla gömme modelinin bir özelliğidir. Vektör veritabanı kıyaslamamızda bir külliyatı 50k'den 2.25M vektöre ölçeklendirmek, nDCG@10'u yaklaşık 0.81'den 0.56'ya düşürürken her motor hâlâ 0.973'ün üzerinde Recall@10 bildirdi ve tam-kNN oracle aynı 0.572'ye düştü. Yalnızca geometrik bir kıyaslama, yanıt kalitesinin üçte birini kaybetmiş bir külliyat üzerinde sağlıklı bir dizin rapor ederdi.
Parça boyutu
Parça boyutu, belgelerin gömmeden önce nasıl bölüneceğini kontrol eder.
2026 rehberliği tek bir sabit boyutun ötesine geçti: anlamsal / yapı farkında parçalamayı tercih edin (bitişik cümleler anlamda ayrıştığında yeni bir parça başlatın), parçaları yaklaşık 300–500 token, %10–20 çakışma ile tutun ve bağlamsal getirmeyi düşünün: Anthropic'in, gömme ve BM25 dizinlemeden önce her parçaya LLM tarafından oluşturulmuş bir bağlam cümlesi ekleme tekniği. Anthropic'in testlerinde, bağlamsal gömmeler en iyi 20 getirme başarısızlık oranını %35, bağlamsal gömmeler artı bağlamsal BM25 %49 ve üstüne bir yeniden sıralayıcı eklemek %67 azalttı. 10 Parça boyutu ayrıca dizinin ne kadar büyük olacağını belirler, çünkü külliyatın kaç vektöre dönüşeceğine karar verir. Vektör veritabanı boyutlandırma hesaplayıcımız bağlantıyı açık hale getirir: varsayılan 512 tokenlik parça ve %15 çakışmada külliyat parça başına 435 token ilerler, bu nedenle parçayı yarıya indirmek hem vektör sayısını hem de veritabanının tutması gereken belleği kabaca iki katına çıkarır.
İnce Ayar ve Retrieval-Augmented Generation Karşılaştırması
RAG ve ince ayar farklı sorunları çözer ve 2026'da alternatifler olmaktan çok giderek birlikte kullanılmaktadır.
Çoğu ekip için yanıt “önce RAG, gerekirse davranışa ince ayar yap” şeklindedir ve RAFT her ikisini birden yapmayı resmileştirir.
Retrieval-augmented generation'ın faydaları
RAG'in avantajları, aslında benimsenmeyi sağlayan birkaç tanede kümelenir: doğruluk ve güncellik (yanıtlar dondurulmuş bir eğitim kesme noktasını değil, güncel, kaynağa dayalı verileri yansıtır), şeffaflık (yanıtlar kullandıkları pasajları alıntılar, böylece denetlenebilirler), ölçekte uzun bağlamdan daha düşük maliyet ve uyarlanabilirlik (modeli yeniden eğitmek yerine bilgi tabanını güncelleyin). Çok modlu RAG bunları görüntülere, PDF'lere ve tablolara genişletir.
Daha fazla bilgi
- Gömme modelleri kıyaslaması
- Yeniden sıralayıcı kıyaslaması
- Açık kaynak vektör veritabanı kıyaslaması
- Vektör veritabanı boyutlandırma hesaplayıcı
- Açık kaynak gömme modelleri
- Çok dilli gömme modelleri
- Çok modlu gömmeler
- Etmen tabanlı RAG çerçeveleri
Bu benchmarkı kaynak gösterin
Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{En İyi RAG Araçları, Çerçeveleri ve Kütüphaneleri}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/retrieval-augmented-generation}},
note = {AIMultiple. Erişim tarihi: 18 Temmuz 2026}
}Referans Linkleri
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.