RAG Framework'leri: LangChain vs LangGraph vs LlamaIndex

5 RAG framework'ünü, aynı ajanik RAG iş akışını standartlaştırılmış bileşenlerle oluşturarak kıyasladık: LangChain, LangGraph, LlamaIndex, Haystack ve DSPy; özdeş modeller (GPT-4.1-mini), embedding'ler (BGE-small), retriever (Qdrant) ve araçlar (Tavily web araması). Bu, her framework'ün gerçek yükünü ve token verimliliğini izole eder.

RAG framework kıyaslama sonuçları

Kıyaslama, istikrarlı ortalamalar sağlamak için her framework'ün tam seti 100 kez çalıştırdığı 100 sorgudan oluşuyordu.

• Ort. Token: Tüm LLM çağrılarında (router, belge değerlendirici, yanıt değerlendirici ve üretici) tüketilen toplam token; hem prompt'ları (getirilen bağlamla birlikte) hem de tamamlamaları içerir. Daha düşük = daha az API maliyeti.
• Framework Ek Yükü: Saf orkestrasyon süresi (ms), framework'ün dahili işlemesi (yönlendirme mantığı, durum yönetimi vb.), LLM API ve araç çağrıları hariç. Daha düşük = daha yalın framework.

Tüm uygulamalar test setinde %100 doğruluk elde etti. Aynı modeller, sıcaklık değerleri, retrieval sağlayıcısı, web arama aracı ve ortak bağlam token sınırı kullanıldı.

Temel Bulgular

1. Kontrol edilebilir olanı kontrol etmeye odaklanıyoruz: Aynı model ailesi ve sıcaklık değerleri, düğüm düzeyinde max_tokens, retriever (Qdrant + BGE-small, k=5, normalizasyon açık), web sağlayıcısı (yalnızca Tavily), router politikası (sezgisel + model), hesap makinesi erken dönüşü, ortak bağlam token sınırı, aynı değerlendirme rubriği, birleşik enstrümantasyon. Bu, ölçümlerimizdeki büyük karıştırıcı değişkenleri önemli ölçüde azaltır.
2. Framework ek yükü ölçülebilir ancak küçük: Orkestrasyon mantığından sorgu başına ~3–14 ms gözlemledik. Bu farklar gerçektir, ancak >1 s gecikme farklarının ana kaynağı değildir; zamanın çoğu harici model/araçlarla yapılan I/O işlemlerinde geçer.
3. Performans token'ları takip ediyor (bu kısıtlar altında): DSPy en düşük framework ek yükünü gösteriyor (~3.53 ms). Haystack (~5.9 ms) ve LlamaIndex (~6 ms) onu izlerken, LangChain (~10 ms) ve LangGraph (~14 ms) daha yüksektir. Token kullanımı en düşük Haystack'te (~1.57k), ardından LlamaIndex'te (~1.60k) gelir; DSPy ve LangGraph ~2.03k ve LangChain ~2.40k düzeyindedir.
4. Yönlendirme/araç yolu önemlidir: İlk yönlendirmedeki (retriever, web, hesap makinesi arasındaki) küçük kaymalar ve fallback davranışı; prompt'lar ve bütçeler hizalı olsa bile hem token'ları hem de süreyi etkiler.

Farklılıklar neden sürüyor? “Framework DNA’sı”

Standardizasyona rağmen token sayılarında ve gecikmede küçük farklılıklar kalmaya devam ediyor. Bunlar her framework'ün kendine özgü düşük seviyeli davranışlarına, yani “DNA’sına” atfedilebilir.

• Prompt & mesaj serileştirme: Her framework, aynı mantıksal içeriği LLM'ye göndermeden önce biraz farklı biçimlendirmeyle sarar ve küçük ama tutarlı token farkları oluşturur.
• Bağlam oluşturma: Birleştirilmiş bağlam içindeki meta verilerin tam sıralaması ve dahil edilmesi framework'e göre biraz farklılık gösterebilir ve nihai token sayısını etkiler.
• Yönlendirme eşitlik bozma: Sınırda kalan durumlarda, bir framework'ün router'ın JSON çıktısını ayrıştırma biçimindeki küçük farklar, farklı bir ilk araç seçimine yol açabilir.

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

Paylaşılan ajanik RAG mimarisi

Adil bir karşılaştırma sağlamak için beş uygulamanın tümü aynı kontrol akışı üzerine inşa edildi:

• Router: Retriever, web_search veya hesap makinesini seçen hibrit model-ve-sezgisel düğüm.
• Belgeleri Getir: Normalleştirilmiş BGE-small embedding'lerini kullanarak Qdrant üzerinden en iyi 5 belgeyi getirir.
• Belgeleri Değerlendir: Bir LLM değerlendiricisi belge ilgililiğini değerlendirir. İlgisizse bir web araması fallback'ini tetikler.
• Yanıt Üret: Taslak yanıt üretmek için ortak bağlam token sınırına sahip temperature=0.0 bir LLM kullanır.
• Yanıtı Değerlendir: İkinci bir LLM değerlendiricisi taslağı temellendirme, çelişkiler (halüsinasyonlar) ve eksiksizlik açısından değerlendirir.
• Fallback & Erken Dönüş: Yanıt notu yetersizse bir web araması tetiklenir. Hesap makinesi sonuçları ise üretim ve değerlendirme adımları atlanarak doğrudan döndürülür.

İş Akışı Örnekleri

Senaryo A — Veritabanından doğrudan isabet:

Senaryo B — Yakın tarihli olay web aracını tetikler:

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

Senaryo D — Vektör VT yetersiz kalır, web aramasına geri döner:

RAG framework metodolojisi

Beş uygulamanın tümü %100 doğruluk elde etti ve 100 sorguluk test setimizde referans yanıtlarla eşleşti. Bu, performans farklarını ölçmeden önce her framework'ün aynı ajanik RAG iş akışını başarıyla yürütebilmesini sağlayan temel gereklilikti.

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

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

• LLM'ler:
  • Model: Tüm düğümler (router, üretici, değerlendirici) OpenRouter API üzerinden openai/gpt-4.1-mini modelini kullandı.
  • Determinizm: Yönlendirme, üretim ve değerlendirmede maksimum tutarlılık sağlamak için tüm LLM çağrılarında temperature 0.0 olarak ayarlandı.
  • Token sınırları: Katı max_tokens sınırları uygulandı: router ve değerlendiriciler için 256, üretici için 512. Bu, bir framework'ün aşırı uzun yanıtlar üretmesinden kaynaklanan gecikme farklarını önler.
• Embedding modeli & retrieval:
  • Model: Tüm framework'ler HuggingFace'ten BAAI/bge-small-en-v1.5 kullandı.
  • Normalizasyon: Performans için kritik bir adım olarak beş framework'te de normalize_embeddings True olarak ayarlandı. (LangChain/LangGraph encode_kwargs ile; LlamaIndex normalize=True ile; Haystack normalize_embeddings ile; DSPy retriever normalleştirildi.)
  • Retrieval: Tüm uygulamalarda Qdrant vektör deposu k=5 (en iyi 5 belge) için sorgulandı.
• Araçlandırma:
  • Web araması: Kıyaslama yalnızca Tavily (max_results=3) ile sınırlandırıldı.
  • Hesap makinesi: Beş uygulamanın tümü, matematiksel ifadeleri ayrıştırma ve değerlendirme için sympy kütüphanesini kullanarak aynı yetenekleri sağladı.

2. RAG kontrol akışı & politika

Ajanın “karar alma” süreci tüm taraflarda açıkça aynı şekilde yansıtıldı.

• Yönlendirme mantığı: Model zekâsını deterministik kurallarla dengelemek için beş script'in tümünde hibrit yönlendirme stratejisi uygulandı:
  1. Regex tabanlı bir heuristic_route önce belirgin hesap makinesi veya web araması desenlerini kontrol eder (ör. matematik sembolleri, “2024” gibi yıllar).
  2. Ardından bir LLM router_node kendi kararını verir.
  3. Nihai karar, hesap makineleri için heuristic'e öncelik verir; aksi takdirde LLM'nin seçimine uyar.
• Bağlam bütçeleme: Bu, en kritik standartlaştırmalardan biridir. generate_answer düğümü çağrılmadan önce, getirilen tüm belge bağlamı ve web araması sonuçları birleştirilir ve ardından ortak truncate_to_token_budget yardımcı programı kullanılarak 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 herhangi bir framework'ün getirilen bağlamın ayrıntı düzeyi nedeniyle avantajlı ya da dezavantajlı olmasını önler.
• Yanıt değerlendirme politikası:
  • Esnek rubric: grade_answer düğümü, tüm framework'lerde aynı esnek prompt'u kullanır ve LLM değerlendiricisine anlamsal olarak benzer ve makul ölçüde eksiksiz yanıtları kabul etmesini söyler.
  • Hata işleme: Değerlendiriciden gelen başarısız JSON ayrıştırmasını işleme mantığı standartlaştırıldı. Değerlendiricinin çıktısı geçerli JSON değilse sistem izin verici bir nota varsayılan olarak döner (grounded=True, complete=True); bu, kırılgan bir ayrıştırıcının aksi hâlde iyi bir yanıtı başarısız saymasını istemeyeceğiniz gerçek dünya senaryosunu taklit eder. DSPy yapılandırılmış alanlar döndürür (JSON ayrıştırması yok); bu, bir performans avantajı değil, sağlamlık farkı olarak kaydedilir.
• Hesap makinesi erken dönüşü: Kodda görüldüğü gibi, calculator_node'a yapılan başarılı bir çağrı doğrudan final_answer'ı belirler ve iş akışını erken sonlandırır. Bu, tutarlı bir şekilde uygulanan önemli bir optimizasyondur ve hesap makinesi yolunun generate ve grade_answer LLM'lerini gereksiz yere çağırmasını önler.
• DSPy uyumu. CoT olmayan taban çizgileriyle adaleti korumak için DSPy, Router ve AnswerGenerator için dspy.Predict (CoT yok) kullanır. İmzalar diğer framework'lerin düğüm sözleşmelerini yansıtır; mevcut olduğunda token sayıları model tarafından bildirilen kullanımı kullanır, aksi takdirde tiktoken fallback'ine başvurur.

3. Enstrümantasyon ve metrikler

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

• Gecikme: Tüm zamanlamalar için yüksek hassasiyetli time.perf_counter() kullanıldı. Framework Ek Yükü, sürekli olarak Toplam Gecikme – Harici Çağrılar Gecikmesi şeklinde hesaplanır.
• Tokenizasyon: Prompt'lar ve tamamlamalar için tüm token sayıları, token metrikleri için tek bir doğruluk kaynağı sağlayan cl100k_base kodlaması kullanılarak tiktoken ile hesaplandı. Sonuçlarda bildirilen “Ort. Token” metriği, tek bir sorgu iş akışındaki her LLM çağrısı (örn. router, değerlendiriciler, üretici) için tüm girdi (prompt) ve çıktı (tamamlama) token'larının kümülatif toplamını temsil eder.
• Durum yönetimi: Uygulama sözdizimi değişse de (LangGraph’ın 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 (question, documents, web_results vb.) ileterek kontrol akışı mantığının aynı bilgiler üzerinde çalışmasını sağlar.

Bu sıkı, kod düzeyindeki standartlaştırmaları uygulayarak bu kıyaslama, yüzeysel karşılaştırmaların ötesine geçmeyi ve sabit bir RAG politikası altında framework performansının tekrarlanabilir bir analizini sunmayı amaçlar.

Sonuçların yorumlanması:

• Şu sonuca varabilirsiniz: Bu spesifik, sıkı şekilde kontrol edilen kurulumda orkestrasyon ek yükü genellikle önemsizdir; farklar esas olarak token sayıları ve araç yollarından kaynaklanır.
  • Bu spesifik, sıkı şekilde kontrol edilen kurulumda framework ek yükü ihmal edilebilir düzeydedir.
  • Performans farkları token sayısı ve araç yolu değişikliklerinden kaynaklandı.
• Genelleme yapamazsınız: Sonuçlar bu mimariye, modellere, prompt'lara, retriever'a ve web sağlayıcısına özeldir; bunların değiştirilmesi sıralamaları değiştirebilir.

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

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

• LangGraph: Bildirimsel graf
  Graf-öncelikli bir paradigma kullanır. Düğümleri tanımlar ve bunları kenarlarla (add_conditional_edges dahil) bağlarsınız, böylece kontrol akışı mimarinin bir parçası olur. Durum, reducer tarzı güncellemelerle (Annotated[…, add]) bir TypedDict aracılığıyla tiplenir.
  • LangGraph'ı şunun için seçin: birden çok dal, yeniden deneme ve döngü içeren karmaşık iş akışları; yapısı, ajanlar büyüdükçe sağlamlık ve sürdürülebilirlik açısından ölçeklenir.
• LlamaIndex: Emirsel orkestrasyon
  Kontrol akışının standart Python if/else olduğu prosedürel bir betik; “graf” kodunuzda yaşar. Durum özel bir PipelineState sınıfıdır ve framework temiz retrieval ilkelleri sağlar (VectorStoreIndex → .as_retriever(k=5)).
  • LlamaIndex'i şunun için seçin: açık prosedürel mantığa ve kolay hata ayıklamaya değer verdiğiniz okunabilir, tek dosyalık iş akışları.
• LangChain: Bildirimsel bileşenlerle emirsel
  Orkestrasyon bir Python betiği olarak kalır, ancak bireysel görevler küçük, birleştirilebilir | operatörünü kullanan zincirlerdir (ör. prompt | llm | parser). Durum esnek, tipsiz bir Python dict'idir.
  • LangChain'i şunun için seçin: hızlı prototipleme veya daha büyük emirsel bir sürücü içinde küçük bildirimsel birimler oluşturmayı tercih eden, hâlihazırda LangChain ekosisteminde olan ekipler.
• Haystack: Bileşen tabanlı, manuel orkestrasyon Açık I/O'ya sahip tipli, yeniden kullanılabilir bileşenler (@component); kontrol akışı düz Python (if/else) olarak kalır. LLM/retriever/web arka uçlarını değiştirmek kolaydır; ayrıca birinci sınıf adım başına enstrümantasyon sunar (harici ve framework süresi).
  • Haystack'i şunun için seçin: net sözleşmelere ve ince ayarlı kontrole sahip üretime hazır, test edilebilir pipeline'lar.
• DSPy: Önce imza programları (daha az kod satırı)
  Bir görevi imza (girdiler/çıktılar + amaç) ile tanımlayın, ardından prompt'lamayı ve LLM çağrılarını kapsayan Modüller ile uygulayın. Prompt/kullanım işlemlerini merkezileştirir ve yapıştırıcı kodu ortadan kaldırır; dahili parçaları değiştirmek (örn. Predict ↔ CoT) sözleşmeyi değiştirmez.
  • DSPy'yi şunun için seçin: minimum kalıp kod, okunabilir tek dosyalık akışlar, sözleşme odaklı geliştirme (isteğe bağlı optimize edicilerle).

Karşılaştırılabilirlik için optimal performanstan ödün verme

• 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 graf optimizasyonlarıyla öne çıkabilir.
• DSPy, imza optimize edicilerini (MIPROv2 gibi) ve yanıt kalitesini önemli ölçüde artırabilen Chain-of-Thought prompt'lamayı kullandığında çarpıcı biçimde farklı sonuçlar gösterebilir.
• Haystack, adalet için devre dışı bıraktığımız üretime hazır önbelleğe alma, yığın işleme özellikleri ve bileşen düzeyi optimizasyonlardan yararlanabilir.
• LlamaIndex, bu kıyaslamada kullanılmayan gelişmiş indeksleme stratejilerinden, sorgu motorlarından ve çok modlu yeteneklerden yararlanabilir.
• LangChain, standartlaştırılmış araç setimizle sınırlandırılmadığında kapsamlı araç ekosistemi ve LCEL (LangChain Expression Language) optimizasyonlarıyla parlayabilir.

“En iyi” framework; geliştirme hızı, sürdürülebilirlik, performans veya belirli mimari desenlerden hangisi için optimize ettiğinize bağlıdır.

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

Daha fazla okuma

Aşağıdakiler gibi diğer RAG kıyaslamalarını keşfedin:

• Embedding Modelleri: OpenAI vs Gemini vs Cohere
• RAG için En İyi Vektör Veritabanı: Qdrant vs Weaviate vs Pinecone
• Ajanik RAG kıyaslaması: çoklu veritabanı yönlendirme ve sorgu üretimi

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  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Erişim tarihi: 31 Ağustos 2026}
}

Değişiklik günlüğü

7 güncelleme

Tümü7Genel5Metodoloji2

1. 202629 Oca

   Kıyaslama metodolojisine sorgu ve çalıştırma sayısı eklendi.

2. 27 Oca

   RAG çerçeveleri karşılaştırma sonuçları ve metodolojisi güncellendi.

3. 202510 Kas

   RAG çerçeveleri karşılaştırma sonuçlarına ortalama jeton ve çerçeve yükü tanımı eklendi.

4. 1 Kas

   Ana Bulgular bölümündeki performans verileri değiştirildi.

5. 1 Kas

   RAG çerçeveleri bölümündeki metodoloji açıklaması değiştirildi.

6. 31 Eki

   RAG çerçeve karşılaştırmasına Haystack ve DSPy eklendi.

7. 31 Eki

   Metodoloji bölümündeki uygulama sayısı güncellendi.

Cem Dilmegani

Baş Analist

Takip Et

Cem, 2017'den beri AIMultiple bünyesinde baş analisttir. Cem'in AIMultiple'daki çalışmaları; Business Insider, Forbes, Morning Brew ve Washington Post gibi önde gelen küresel yayınlar, Deloitte ve HPE gibi küresel firmalar, Dünya Ekonomik Forumu gibi STK'lar ve Avrupa Komisyonu gibi uluslarüstü kuruluşlar tarafından alıntılanmıştır. [1], [2], [3], [4], [5] Kariyeri boyunca Cem; teknoloji danışmanı, teknoloji alıcısı ve teknoloji girişimcisi olarak görev yaptı. On yılı aşkın süre boyunca McKinsey & Company ve Altman Solon'da işletmelere teknoloji kararlarında danışmanlık yaptı. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayımladı. CEO'ya rapor verirken bir telekom şirketinin teknoloji stratejisini ve satın alma süreçlerini yönetti. Ayrıca 2 yıl içinde 0'dan 7 haneli yıllık yinelenen gelire ve 9 haneli değerlemeye ulaşan derin teknoloji şirketi Hypatos'un ticari büyümesini yönetti. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınları tarafından ele alındı. Cem, uluslararası teknoloji konferanslarında düzenli olarak konuşma yapmaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisi olarak mezun oldu 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ı ve Veri Bilimcidir. Yapay zeka ve LLM sistemleri için uygulamalı benchmark'lar tasarlar ve yürütü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