RAG Framework'leri: LangChain vs LangGraph vs LlamaIndex

5 RAG framework'ünü karşılaştırdık: LangChain, LangGraph, LlamaIndex, Haystack ve DSPy; bunu aynı ajan tabanlı RAG iş akışını standartlaştırılmış bileşenlerle oluşturarak yaptık: aynı modeller (GPT-4.1-mini), gömme vektörleri (BGE-small), alıcı (Qdrant) ve araçlar (Tavily web araması). Bu, her framework'ün gerçek ek yükünü ve token verimliliğini izole eder.

RAG framework'leri karşılaştırma sonuçları

Karşılaştırma 100 sorgudan oluştu ve her framework tam seti 100 kez çalıştırdı, böylece kararlı ortalamalar elde edildi.

• Ortalama Token: Tüm LLM çağrılarında (yönlendirici, belge derecelendirici, cevap derecelendirici ve üretici) tüketilen toplam token; alınan bağlamla birlikte gelen istekleri ve tamamlamaları içerir. Daha düşük = daha az API maliyeti.
• Framework Ek Yükü: Saf düzenleme süresi (ms), framework'ün dahili işlemesi (yönlendirme mantığı, durum yönetimi vb.), LLM API ve araç çağrılarını hariç tutar. Daha düşük = daha hafif framework.

Tüm uygulamalar test setinde %100 doğruluk elde etti. Aynı modelleri, sıcaklıkları, alma sağlayıcısını, web arama aracını ve paylaşılan bir bağlam token sınırını kullandılar.

Temel Bulgular

1. Kontrol edilebilir olanı kontrol etmeye odaklanıyoruz: Aynı model ailesi ve sıcaklıkları, düğüm seviyesinde max_tokens, alıcı (Qdrant + BGE-small, k=5, normalizasyon açık), web sağlayıcısı (sadece Tavily), yönlendirme politikası (sezgisel + model), hesap makinesi erken dönüşü, paylaşılan bağlam token sınırı, aynı derecelendirme kriteri, birleştirilmiş enstrümantasyon. Bu, ölçümlerimizdeki büyük karıştırıcıları önemli ölçüde azaltır.
2. Framework ek yükü ölçülebilir ancak küçüktür: Düzenleme mantığında sorgu başına ~3–14 ms fark gözlemledik. Bu farklılıklar gerçektir ancak >1 saniyelik gecikme farklarının ana kaynağı değildir; çoğu zaman dış modeller/araçlarla I/O’da harcanır.
3. Performans token kullanımını takip eder (bu sınırlamalar altında): DSPy en düşük framework ek yükünü gösterir (~3,53 ms). Haystack (~5,9 ms) ve LlamaIndex (~6 ms) takip ederken, LangChain (~10 ms) ve LangGraph (~14 ms) daha yüksektir. Token kullanımı en düşük olan Haystack’tır (~1,57b), ardından LlamaIndex (~1,60b); DSPy ve LangGraph ~2,03b, LangChain ise ~2,40b civarındadır.
4. Yönlendirme/araç yolu önemlidir: Başlangıç yönlendirmesindeki (alıcıya karşı web'e karşı hesap makinesi) küçük kaymalar ve geri dönüş davranışları, istekler ve bütçeler hizalanmış olsa bile hem token hem de süreyi etkiler.

Farklılıklar neden devam ediyor? "Framework DNA'sı"

Standartlaştırmaya rağmen token sayılarında ve gecikmede küçük farklılıklar kalır. Bunlar her framework'ün içsel, düşük seviyeli davranışlarından, yani "DNA'sından" kaynaklanır.

• İstek ve mesaj serileştirme: Her framework, aynı mantıksal içeriği LLM'ye göndermeden önce hafifçe farklı biçimlendirerek sarmalar ve bu küçük ancak tutarlı token farkları yaratır.
• Bağlam birleştirme: Birleştirilen bağlam içindeki meta verilerin tam sıralaması ve dahil edilmesi framework'e göre hafifçe farklılık gösterebilir ve nihai token sayısını etkiler.
• Yönlendirme eşlik durumları: Sınır durumlarda, bir framework'ün yönlendiricinin JSON çıktısını ayrıştırma şekliyle ilgili ince farklılıklar farklı bir başlangıç aracı seçimiyle sonuçlanabilir.

Bu kurulumda, token ayak izi framework yürütme süresinden daha çok birincil sürücü gibi görünüyor.

Paylaşılan ajan tabanlı RAG mimarisi

Adil bir karşılaştırma sağlamak için tüm beş uygulama aynı kontrol akışına dayandırıldı:

• Yönlendirici: Alıcı, web_search veya hesap makinesini seçen hibrit bir model ve sezgisel düğüm.
• Belgeleri Al: Normalize edilmiş BGE-small gömme vektörlerini kullanarak Qdrant'tan en iyi 5 belgeyi getirir.
• Belgeleri Derecelendir: Bir LLM yargıcı belgelerin ilgili olup olmadığını değerlendirir. İlgisizse, bir web araması geri dönüşü tetikler.
• Cevap Üret: Paylaşılan bir bağlam token sınırıyla sıcaklık=0,0 olan bir LLM kullanarak bir taslak cevap üretir.
• Cevabı Derecelendir: İkinci bir LLM yargıcı taslağı temellilik, çelişkiler (hallüsinasyonlar) ve eksiksizlik açısından değerlendirir.
• Geri Dönüş ve Erken Dönüş: Cevap derecesi yetersizse bir web araması tetiklenir. Ancak hesap makinesi sonuçları doğrudan döndürülür ve üretim ve derecelendirme adımlarını atlar.

İş Akışı Örnekleri

Senaryo A — Veritabanından doğrudan hit:

Senaryo B — Son olay web aracını tetikler:

Senaryo C — Hesap makinesi erken dönüş sağlar:

Senaryo D — Vektör DB yetersizdir, web aramasına geri döner:

RAG framework'leri metodolojisi

Beş uygulamanın tümü, temel gerçek cevaplarla eşleşen 100 sorguluk test setinde %100 doğruluk elde etti. Bu, her framework'ün performans farklarını ölçmeden önce aynı ajan tabanlı RAG iş akışını başarıyla yürütebildiğinden emin olmak için temel gereklilikti.

1. Temel bileşenler ve yapılandırma

Temel araçlar, kaynaktaki performans değişkenlerini ortadan kaldırmak için standartlaştırıldı.

• LLM'ler:
  • Model: Tüm düğümler (yönlendirici, üretici, derecelendirici) OpenRouter API'sini kullanarak openai/gpt-4.1-mini modelini kullandı.
  • Belirlilik: Yönlendirme, üretim ve derecelendirme işlemlerinde maksimum tutarlılık sağlamak için tüm LLM çağrılarında sıcaklık 0,0 olarak ayarlandı.
  • Token sınırları: Sıkı max_tokens sınırları uygulandı: yönlendirici ve derecelendiriciler için 256, üretici için 512. Bu, bir framework'ün aşırı uzun yanıtlar üretmesi nedeniyle gecikme farklarının önüne geçer.
• Gömme modeli ve alma:
  • Model: Tüm framework'ler HuggingFace'ten BAAI/bge-small-en-v1.5 kullandı.
  • Normalizasyon: Performans için kritik bir adım, tüm beş framework'te normalize_embeddings True olarak ayarlandı. (LangChain/LangGraph encode_kwargs ile; LlamaIndex normalize=True ile; Haystack normalize_embeddings ile; DSPy alıcısı normalleştirildi.)
  • Alma: Qdrant vektör deposu tüm uygulamalarda k=5 (en iyi 5 belge) için sorgulandı.
• Araçlar:
  • Web araması: Karşılaştırma sadece Tavily (max_results=3) ile sınırlandırıldı.
  • Hesap makinesi: Beş uygulama da matematiksel ifade ayrıştırma ve değerlendirme için sympy kütüphanesini kullandı ve bu da aynı yetenekleri sağladı.

2. RAG kontrol akışı ve politikası

Ajanın "karar verme" süreci tüm uygulamalarda açıkça yansıtıldı.

• Yönlendirme mantığı: Beş betikte de model zekâsıyla belirleyici kuralları dengelemek için hibrit bir yönlendirme stratejisi uygulandı:
  1. Bir regex tabanlı heuristic_route önce açık hesap makinesi veya web araması desenlerini kontrol eder (örneğin matematik sembolleri, "2024" gibi yıllar).
  2. Bir LLM router_node daha sonra kendi kararını verir.
  3. Son karar hesap makineleri için sezgiseli önceliklendirir, aksi takdirde LLM'nin seçimine iletir.
• Bağlam bütçeleme: Bu, en kritik standartlaştırmalardan biridir. generate_answer düğümü çağrılmasından önce alınan belge bağlamı ve web arama sonuçları birleştirilir ve ardından ortak bir truncate_to_token_budget yardımcı programını kullanarak paylaşılan 2000-token sınırına kısaltılır. Bu, her framework'teki üretici LLM'nin tam olarak aynı boyutta bir girdi almasını sağlar ve böylece tek bir framework'ün alınan bağlamının uzunluğu nedeniyle avantajlı veya dezavantajlı olmasının önüne geçilir.
• Cevap derecelendirme politikası:
  • Hoşgörülü kriter: grade_answer düğümü, LLM yargıcı semantik olarak benzer ve makul ölçüde eksiksiz cevapları kabul etmesini talimatlandıran tüm framework'lerde aynı, hoşgörülü bir istek kullanır.
  • Başarısızlık yönetimi: Derecelendiriciden geçersiz JSON ayrıştırmasının nasıl ele alınacağı standartlaştırıldı. Derecelendiricinin çıktısı geçerli bir JSON değilse sistem varsayılan olarak hoşgörülü bir dereceye geçer (grounded=True, complete=True), bu da kırılgan bir ayrıştırıcının iyi bir cevabı başarısız etmemesi gereken gerçek dünya senaryosunu yansıtır. DSPy yapılandırılmış alanlar döndürür (hiçbir JSON ayrıştırma yok), bu bir dayanıklılık farkı olarak kaydedilir, performans avantajı değil.
• Hesap makinesi erken dönüşü: Kodda görüldüğü gibi, calculator_node'a başarılı bir çağrı doğrudan final_answer'ı ayarlar ve iş akışını erken sonlandırır. Bu, hesap makinesi yolunun generate ve grade_answer LLM'lerini gereksiz yere çağırmamasını önleyen önemli bir iyileştirmedir.
• DSPy uyumu. CoT olmayan tabanlarla adil kalabilmek için DSPy, Yönlendirici ve CevapÜretici için dspy.Predict (CoT yok) kullanır. İmzalar diğer framework'lerin düğüm sözleşmelerini yansıtır; varsa token sayıları modelin bildirdiği kullanımı kullanır, aksi takdirde tiktoken geri dönüşü.

3. Enstrümantasyon ve metrikler

Ölçüm süreci aynıydı ve paylaşılan yardımcı programlar ve ilkeler kullanıldı.

• Gecikme: Tüm zamanlamalar için yüksek hassasiyetli time.perf_counter() kullanıldı. Framework Ek Yükü, Toplam Gecikme – Dış Çağrı Gecikmesi olarak tutarlı bir şekilde hesaplanır.
• Tokenizasyon: Tüm istekler ve tamamlamalar için token sayıları tiktoken, cl100k_base kodlaması kullanılarak hesaplandı ve bu da token metrikleri için tek bir gerçeklik kaynağı sağladı. Sonuçlarda bildirilen "Ortalama Token" metriği, tek bir sorgu iş akışı içindeki her LLM çağrısı (örneğin yönlendirici, derecelendiriciler, üretici) için tüm giriş (istek) ve çıkış (tamamlama) tokenlerinin kümülatif toplamını temsil eder.
• Durum yönetimi: Uygulama sözdizimi değişse de (LangGraph'in TypedDict'i, LlamaIndex'in sınıfı, LangChain'in sözlüğü), durum yapısı işlevsel olarak aynıdır. Her framework, düğümler arasında aynı anahtar kümesini (soru, belgeler, web_sonuçları, vb.) iletir ve böylece kontrol akışı mantığı aynı bilgiler üzerinde çalışır.

Bu katı, kod düzeyinde standartlaştırmaları uygulayarak bu karşılaştırma, yüzeysel karşılaştırmaların ötesine geçmeyi ve sabit bir RAG politikası altında framework performansının çoğaltılabilir bir analizini sunmayı amaçlar.

Sonuçları yorumlamak:

• Şunu sonuca varabilirsiniz: Bu özel, yüksek ölçüde kontrol edilen kurulumda, düzenleme ek yükü genellikle küçüktür; farklılıkları çoğunlukla token sayıları ve araç yolları belirler.
  • Bu özel, yüksek ölçüde kontrol edilen kurulumda, framework ek yükü ihmal edilebilir.
  • Performans farkları token sayısı ve araç yolu varyasyonları nedeniyle ortaya çıktı.
• Genelleme yapamazsınız: Sonuçlar bu mimariye, modellere, isteklere, alıcıya ve web sağlayıcıya özgüdür; bunları değiştirmek sıralamaları değiştirebilir.

Google Arama'da daha fazla kıyaslamamızı ve veri odaklı içgörülerimizi görün.

Tercih edilen kaynak olarak ekle

Geliştirici deneyimi: Nitel bir karşılaştırma

Performans tek faktör değildir; bir framework ile geliştirme yapmanın nasıl hissettirdiği de eşit derecede önemlidir.

• LangGraph: Bildirimsel grafik
  Grafik öncelikli bir paradigm kullanır. Düğümleri tanımlar ve kenarlarla (add_conditional_edges dahil) bağlarsınız, böylece kontrol akışı mimarinin bir parçası olur. Durum, TypedDict ile tür belirtilmiş ve reducer tarzı güncellemelerle (Annotated[…, add]) yapılır.
  • LangGraph'i seçin: Çoklu dallar, yeniden denemeler ve döngüler içeren karmaşık iş akışları için; yapısı ajanlar büyüdükçe dayanıklılık ve bakımı kolaylaştırır.
• LlamaIndex: Zorunlu düzenleme
  Standart Python if/else ile kontrol akışı olan prosedürel bir betiktir; "grafik" kodunuzdadır. Durum özel bir PipelineState sınıfıdır ve framework temiz alma ilkel sağlar (VectorStoreIndex → .as_retriever(k=5)).
  • LlamaIndex'i seçin: Açık prosedürel mantık ve kolay hata ayıklama değer verdiğiniz okunabilir, tek dosyalık iş akışları için.
• LangChain: Bildirimsel bileşenlerle zorunlu
  Düzenleme hâlâ bir Python betiğidir ancak bireysel görevler küçük, birleştirilebilir zincirlerdir | operatörünü kullanarak (örneğin, istek | llm | ayrıştırıcı). Durum esnek, türsüz bir Python sözlüğüdür.
  • LangChain seçin: Hızlı prototipleme veya LangChain ekosisteminde olan ve daha büyük zorunlu bir sürücü içinde küçük bildirimsel birimleri birleştirmeyi tercih eden takımlar için.
• Haystack: Bileşen tabanlı, manuel düzenleme Açık I/O'lu, yazılabilir, yeniden kullanılabilir bileşenler (@component), kontrol akışı hâlâ düz Python (if/else). LLM/alıcı/web arka uçlarını değiştirmek kolaydır ve adım başına birinci sınıf enstrümantasyon sağlar (dışa karşı framework süresi).
  • Haystack'i seçin: Açık sözleşmeleri ve ince ayarlı kontrolü olan, üretim için hazır, test edilebilir iş hatları için.
• DSPy: İmza öncelikli programlar (daha az kod satırı)
  Bir görevi bir imza (girdiler/çıktılar + amaç) olarak tanımlayın, ardından istekleri ve LLM çağrılarını kapsülleyen Modüller ile uygulayın. İstek/kullanım işlemini merkezileştirir ve yapıştırma kodunu kaldırır; içlerini değiştirmek (örneğin, Predict ↔ CoT) sözleşmeyi değiştirmez.
  • DSPy'i seçin: En az gereksiz kod, okunabilir tek dosyalık akışlar, sözleşmeye dayalı geliştirme (isteğe bağlı optimizatörlerle).

Karşılaştırılabilirlik için optimal performansdan vazgeçmek

• LangGraph, paralel yürütme, durum önbelleğe alma ve karmaşık dallanma mantığı için koşullu kenar sistemi kullanmasına izin verildiğinde yerel grafik optimizasyonlarıyla öne çıkabilir.
• DSPy, MIPROv2 gibi imza optimizatörlerini ve zincirde-düşünme (Chain-of-Thought) isteklerini kullandığında, cevap kalitesini önemli ölçüde artırarak çok farklı sonuçlar gösterebilir.
• Haystack, adil olmak için devre dışı bıraktığımız üretim için hazır önbelleğe alma, toplu işlem özellikleri ve bileşen düzeyinde optimizasyonlardan yararlanabilir.
• LlamaIndex, bu karşılaştırmada kullanılmayan gelişmiş dizinleme stratejilerinden, sorgu motorlarından ve çoklu ortam özelliklerinden yararlanabilir.
• LangChain, standartlaştırılmış araç setimizle kısıtlanmadığında geniş araç ekosistemi ve LCEL (LangChain Expression Language) optimizasyonlarıyla parlayabilir.

"En iyi" framework, geliştirme hızı, bakımı kolaylık, performans veya belirli mimari desenler için optimize edilip edilmediğinize bağlıdır.

Daha fazla okuma

Diğer RAG karşılaştırmalarını inceleyin, örneğin:

• Gömme Modelleri: OpenAI vs Gemini vs Cohere
• En İyi Vektör Veritabanı RAG için: Qdrant vs Weaviate vs Pinecone
• Ajan Tabanlı RAG karşılaştırması: çoklu veritabanı yönlendirme ve sorgu üretimi
• Hibrit RAG: RAG Doğruluğunu Artırma

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{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{RAG Framework'leri: LangChain vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Erişim tarihi: 3 Haziran 2026}
}

Cem Dilmegani

Baş Analist

Takip Et

Cem, 2017'den beri AIMultiple'da baş analist olarak görev yapmaktadır. AIMultiple, her ay Fortune 500 şirketlerinin %55'i de dahil olmak üzere yüz binlerce işletmeye (benzer Web'e göre) bilgi sağlamaktadır. Cem'in çalışmaları, Business Insider, Forbes, Washington Post gibi önde gelen küresel yayınlar, Deloitte, HPE gibi küresel firmalar, Dünya Ekonomik Forumu gibi STK'lar ve Avrupa Komisyonu gibi uluslararası kuruluşlar tarafından alıntılanmıştır. AIMultiple'ı referans gösteren daha fazla saygın şirket ve kaynağı görebilirsiniz. Kariyeri boyunca Cem, teknoloji danışmanı, teknoloji alıcısı ve teknoloji girişimcisi olarak görev yapmıştır. On yıldan fazla bir süre McKinsey & Company ve Altman Solon'da işletmelere teknoloji kararları konusunda danışmanlık yapmıştır. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayınlamıştır. Bir telekom şirketinin CEO'suna bağlı olarak teknoloji stratejisi ve tedarikini yönetmiştir. Ayrıca, 2 yıl içinde sıfırdan 7 haneli yıllık yinelenen gelire ve 9 haneli değerlemeye ulaşan derin teknoloji şirketi Hypatos'un ticari büyümesini yönetmiştir. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınlarında yer aldı. Cem düzenli olarak uluslararası teknoloji konferanslarında konuşmacı olarak yer almaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisliği diplomasına ve Columbia Business School'dan MBA derecesine sahiptir.

Tam Profili Görüntüle

Araştıran

Ekrem Sarı

Yapay Zeka Araştırmacısı

Takip Et

Ekrem, AIMultiple'da yapay zeka araştırmacısı olarak çalışmakta olup, akıllı otomasyon, GPU'lar, yapay zeka ajanları ve RAG çerçeveleri üzerine yoğunlaşmaktadır.

Tam Profili Görüntüle

Yorum yapan ilk kişi olun

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder