RAG Framework'leri: LangChain vs LangGraph vs LlamaIndex

5 RAG framework'ünü kıyasladık: LangChain, LangGraph, LlamaIndex, Haystack ve DSPy'yi, aynı etmen tabanlı RAG iş akışını standart bileşenlerle oluşturarak: aynı modeller (GPT-4.1-mini), gömme modeli (BGE-small), getirici (Qdrant) ve araçlar (Tavily web araması). Bu, her framework'ün gerçek yükünü ve token verimliliğini izole eder.

RAG framework'leri kıyaslama sonuçları

Kıyaslama, 100 sorgudan oluştu ve her framework, kararlı ortalamalar sağlamak için tüm seti 100 kez çalıştırdı.

• Ort. Token: Tüm LLM çağrılarında (yönlendirici, belge değerlendirici, cevap değerlendirici ve oluşturucu) tüketilen toplam token sayısı; hem istemleri (getirilen bağlamla birlikte) hem de tamamlamaları içerir. Düşük = daha az API maliyeti.
• Framework Ek Yükü: Saf düzenleme süresi (ms), framework'ün iç işlemleri (yönlendirme mantığı, durum yönetimi vb.), LLM API ve araç çağrıları hariç. Düşük = daha yalın framework.

Tüm gerçeklemeler, test setinde %100 doğruluk elde etti. Aynı modeller, sıcaklıklar, getiri sağlayıcı, web arama aracı ve paylaşılan bağlam token sınırı kullanıldı.

Önemli Bulgular

1. Kontrol edilebilir olanı kontrol etmeye odaklanıyoruz: Aynı model ailesi ve sıcaklıklar, düğüm düzeyinde max_tokens, getirici (Qdrant + BGE-small, k=5, normalizasyon açık), web sağlayıcı (yalnızca Tavily), yönlendirici politikası (sezgisel + model), hesap makinesi erken dönüşü, paylaşılan bağlam token sınırı, aynı değerlendirme ölçeği, birleşik enstrümantasyon. Bu, ölçümlerimizdeki büyük karıştırıcı faktörleri önemli ölçüde azaltır.
2. Framework ek yükü ölçülebilir ancak küçüktür: Düzenleme mantığından sorgu başına ~3–14 ms gözlemledik. Bu farklar gerçek olmakla birlikte, >1 s gecikme farklarının ana kaynağı değildir; zamanın çoğu harici modeller/araçlarla G/Ç'ye harcanır.
3. Performans token sayısına bağlıdır (bu kısıtlamalar 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 Haystack'te (~1.57k), ardından LlamaIndex (~1.60k); DSPy ve LangGraph ~2.03k, LangChain ise ~2.40k.
4. Yönlendirme/araç yolu önemlidir: Başlangıç yönlendirmesindeki (getirici, web veya hesap makinesi) ve yedekleme davranışındaki küçük değişiklikler, prompt'lar ve bütçeler aynı hizada olsa bile token sayısını ve süreyi etkiler.

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

Standartlaştırmaya rağmen, token sayıları ve gecikmelerde küçük farklılıklar kalır. Bunlar, her framework'ün doğal, düşük seviyeli davranışlarına, yani “DNA’sına” bağlanabilir.

• İstem ve mesaj serileştirme: Her framework, aynı mantıksal içeriği LLM'ye göndermeden önce biraz farklı biçimlendirme ile sarar, bu da 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 bu da nihai token sayısını etkiler.
• Yönlendirme eşitlik durumu: Sınır durumlarda, bir framework'ün yönlendiricinin JSON çıktısını nasıl ayrıştırdığındaki ince farklar, farklı bir başlangıç araç seçimine yol açabilir.

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

Paylaşılan etmen tabanlı RAG mimarisi

Adil bir karşılaştırma elde etmek için, beş gerçeklemenin tümü aynı kontrol akışı üzerine inşa edildi:

• Yönlendirici: Getirici, web_search veya hesap makinesini seçen karma bir model ve sezgisel düğüm.
• Belgeleri Getir: Normalize edilmiş BGE-small gömme vektörlerini kullanarak Qdrant'tan en iyi 5 belgeyi getirir.
• Belgeleri Değerlendir: Bir LLM değerlendirici belge ilgililiğini değerlendirir. İlgisizse, bir web araması yedekleme tetikler.
• Cevap Oluştur: Taslak bir cevap oluşturmak için sıcaklık=0.0 LLM ve paylaşılan bağlam token sınırı kullanır.
• Cevabı Değerlendir: İkinci bir LLM değerlendirici, taslağı temellilik, çelişkiler (halüsinasyonlar) ve eksiksizlik açısından değerlendirir.
• Yedekleme ve Erken Dönüş: Cevap notu yetersizse bir web araması tetiklenir. Hesap makinesi sonuçları ise doğrudan döndürülür, oluşturma ve değerlendirme adımları atlanır.

İş Akışı Örnekleri

Senaryo A — Veritabanından doğrudan isabet:

Senaryo B — Güncel olay web aracını tetikler:

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

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

RAG framework'leri metodolojisi

Beş gerçeklemenin tümü, 100 sorguluk test setimizde %100 doğruluk elde ederek referans cevaplarla eşleşti. Bu, performans farklılıklarını ölçmeden önce her framework'ün aynı etmen tabanlı RAG iş akışını başarıyla yürütebilmesini sağlayan temel gereklilikti.

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

Performans değişkenlerini kaynağında ele almak için temel araçlar standartlaştırıldı.

• LLM'ler:
  • Model: Tüm düğümler (yönlendirici, oluşturucu, değerlendiriciler) OpenRouter API'si üzerinden openai/gpt-4.1-mini modelini kullandı.
  • Determinizm: Yönlendirme, oluşturma ve değerlendirmede maksimum tutarlılık sağlamak için tüm LLM çağrılarında sıcaklık (temperature) 0.0 olarak ayarlandı.
  • Token sınırları: Katı max_tokens sınırları uygulandı: yönlendirici ve değerlendiriciler için 256, oluşturucu için 512. Bu, bir framework'ün aşırı uzun cevaplar üretmesinden kaynaklanan gecikme farklılıklarını önler.
• Gömme modeli ve getiri:
  • Model: Tüm framework'ler HuggingFace'ten BAAI/bge-small-en-v1.5 kullandı.
  • Normalizasyon: Performans için kritik bir adım olan normalize_embeddings, beş framework'ün hepsinde True olarak ayarlandı. (LangChain/LangGraph encode_kwargs üzerinden; LlamaIndex normalize=True ile; Haystack normalize_embeddings ile; DSPy getirici normalleştirildi.)
  • Getiri: Qdrant vektör deposu, tüm gerçeklemelerde k=5 (en üst 5 belge) için sorgulandı.
• Araçlar:
  • Web araması: Kıyaslama, yalnızca Tavily (max_results=3) ile sınırlandırıldı.
  • Hesap makinesi: Beş gerçekleme de matematiksel ifade ayrıştırma ve değerlendirme için sympy kütüphanesini kullandı ve aynı yetenekleri sağladı.

2. RAG kontrol akışı ve politika

Etmenin “karar verme” süreci tümüyle aynen yansıtıldı.

• Yönlendirme mantığı: Beş betikte de, model zekasını belirlenimci kurallarla dengelemek için karma bir yönlendirme stratejisi uygulandı:
  1. Regex tabanlı bir heuristic_route, önce belirgin hesap makinesi veya web arama kalıplarını (ör. matematik sembolleri, “2024” gibi yıllar) kontrol eder.
  2. Ardından bir LLM yönlendirici_düğümü kendi kararını verir.
  3. Nihai karar, hesap makineleri için sezgisel olana ö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, tüm getirilen belge bağlamı ve web arama sonuçları birleştirilir ve ardından ortak bir 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 oluşturucu LLM'nin tam olarak aynı boyutta girdi almasını sağlar ve herhangi bir framework'ün getirilen bağlamının laf kalabalığı nedeniyle avantajlı veya dezavantajlı olmasını önler.
• Cevap değerlendirme politikası:
  • Hoşgörülü değerlendirme ölçeği: grade_answer düğümü, tüm framework'lerde aynı, hoşgörülü bir prompt'lar kullanarak LLM değerlendiricisine anlamsal olarak benzer ve makul ölçüde eksiksiz cevapları kabul etmesini söyler.
  • Hata yönetimi: Değerlendiriciden başarısız bir JSON ayrıştırmayı ele alma mantığı standartlaştırıldı. Değerlendiricinin çıktısı geçerli JSON değilse, sistem, gevşek bir değerlendirmeye (grounded=True, complete=True) varsayılan olarak döner; bu, kırılgan bir ayrıştırıcının aksi takdirde iyi bir cevabı başarısız saymasını istemeyeceğiniz gerçek dünya senaryosunu taklit eder. DSPy yapılandırılmış alan döndürür (JSON ayrıştırması yok), bu bir performans avantajı olarak değil, bir dayanıklılık farkı olarak kaydedilir.
• 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 gereksiz yere generate ve grade_answer LLM'lerini çağırmasını önleyen, tutarlı şekilde uygulanan önemli bir optimizasyondur.
• DSPy uyumu. CoT olmayan temel hatlarla adaleti korumak için, DSPy yönlendirici ve AnswerGenerator için dspy.Predict (CoT yok) kullanır. İmzalar diğer framework'lerin düğüm sözleşmelerini yansıtır; mümkün olduğunda token sayıları model tarafından bildirilen kullanımı kullanır, aksi takdirde tiktoken yedek olarak devreye girer.

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ü, Toplam Gecikme – Harici Çağrı Gecikmesi olarak tutarlı şekilde hesaplanır.
• Tokenizasyon: İstemler ve tamamlamalar için tüm token sayıları, token metrikleri için tek bir doğruluk kaynağı sağlamak üzere tiktoken, cl100k_base kodlaması kullanılarak hesaplandı. Sonuçlarda bildirilen “Ort. Token” metriği, tek bir sorgu iş akışındaki her LLM çağrısı (ör. yönlendirici, değerlendiriciler, oluşturucu) için tüm girdi (prompt'lar) ve çıktı (tamamlama) tokenlarının kümülatif toplamını temsil eder.
• Durum yönetimi: Uygulama sözdizimi değişiklik gösterse 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.) geçirir ve kontrol akışı mantığının aynı bilgi üzerinde çalışmasını sağlar.

Bu katı, 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çlamaktadır.

Sonuçların yorumlanması:

• Şu sonuca varabilirsiniz: Bu spesifik, yüksek ölçüde kontrollü kurulumda, düzenleme ek yükü önemsiz olma eğilimindedir; farklılıklar esas olarak token sayıları ve araç yollarından kaynaklanır.
  • Bu spesifik, yüksek ölçüde kontrollü kurulumda, framework ek yükü ihmal edilebilir düzeydedir.
  • Performans farklılıkları token sayısı ve araç yolu farklılıklarından kaynaklanmıştır.
• Genelleme yapamazsınız: Sonuçlar bu mimariye, modellere, istemlere, getiriciye ve web sağlayıcıya özgüdür; bunları değiştirmek 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 eşit derecede önemlidir.

• LangGraph: Bildirimsel graf
  Önce graf paradigmasını 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, azaltıcı tarzı güncellemelerle (Annotated[…, add]) bir TypedDict aracılığıyla yazılır.
  • LangGraph'i şunlar için seçin: çoklu dallanma, yeniden denemeler ve döngüler içeren karmaşık iş akışları; yapısı, etmenler büyüdükçe dayanıklılık ve bakım yapılabilirlik açısından ölçeklenir.
• LlamaIndex: Buyurgan düzenleme
  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 erişim temelleri (VectorStoreIndex → .as_retriever(k=5)) sağlar.
  • LlamaIndex'i şunlar için seçin: açık prosedürel mantığı ve kolay hata ayıklamayı değerli bulduğunuz okunabilir, tek dosyalı iş akışları.
• LangChain: Bildirimsel bileşenlerle buyurgan
  Düzenleme bir Python betiği olarak kalır, ancak bireysel görevler, | operatörünü kullanan küçük, birleştirilebilir zincirlerdir (örn. prompt'lar | llm | ayrıştırıcı). Durum, esnek, türsüz bir Python sözlüğüdür.
  • LangChain'i şunlar için seçin: Hızlı prototipleme veya daha büyük bir buyurgan sürücü içinde küçük bildirimsel birimleri birleştirmeyi tercih eden, zaten LangChain ekosistemindeki ekipler.
• Haystack: Bileşen tabanlı, manuel düzenleme Açık I/O ile türlendirilmiş, yeniden kullanılabilir bileşenler (@component); kontrol akışı düz Python (if/else) olarak kalır. LLM/getirici/web arka uçlarını değiştirmek kolaydır, ayrıca birinci sınıf adım bazında enstrümantasyon (hariciye karşı framework zamanı).
  • Haystack'i şunlar için seçin: net sözleşmeler ve ince ayarlı kontrol ile üretime hazır, test edilebilir işlem hatları.
• DSPy: İmza-öncelikli programlar (daha az kod satırı)
  Bir görevi bir imza (girdiler/çıktılar + amaç) aracılığıyla tanımlayın, ardından prompt'lar oluşturma ve LLM çağrılarını kapsayan Modüller ile uygulayın. İstem/kullanım yönetimini merkezileştirir ve yapıştırıcı kodu ortadan kaldırır; iç bileşenleri (örn. Predict ↔ CoT) değiştirmek sözleşmeyi değiştirmez.
  • DSPy'yi şunlar için seçin: minimal taslak kod, okunabilir tek dosya 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 önbellekleme ve karmaşık dallanma mantığı için koşullu kenar sistemini kullanmasına izin verildiğinde, doğal graf optimizasyonlarıyla öne çıkabilir.
• DSPy, imza optimize edicilerini (MIPROv2 gibi) ve cevap kalitesini önemli ölçüde artırabilen Zincirleme Düşünce (Chain-of-Thought) istemini kullandığında çarpıcı biçimde farklı sonuçlar gösterebilir.
• Haystack, adalet için devre dışı bıraktığımız üretime hazır önbellekleme, toplu işleme özelliklerinden ve bileşen düzeyindeki optimizasyonlardan yararlanabilir.
• LlamaIndex, bu kıyaslamada test edilmeyen gelişmiş indeksleme stratejilerinden, sorgu motorlarından ve çok modlu yeteneklerinden yararlanabilir.
• LangChain, standartlaştırılmış araç setimizle sınırlı olmadığında geniş araç ekosistemi ve LangChain İfade Dili (LCEL) optimizasyonlarıyla parlayabilir.

“En iyi” framework, geliştirme hızı, bakım yapılabilirlik, performans veya belirli mimari desenler için optimize edip etmediğ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

Ek okuma

Diğer RAG kıyaslamalarını keşfedin, örneğin:

• Gömme Modelleri: OpenAI vs Gemini vs Cohere
• En İyi Vektör Veritabanı RAG için: Qdrant vs Weaviate vs Pinecone
• Etmen tabanlı RAG kıyaslaması: çoklu veritabanı yönlendirme ve sorgu oluşturma
• 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  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Erişim tarihi: 4 Ağustos 2026}
}

Cem Dilmegani

Baş Analist

Takip Et

Cem, 2017'den beri AIMultiple'da baş analisttir. AIMultiple, her ay Fortune 500'ün %60'ı dahil olmak üzere (similarWeb'e göre) yüz binlerce işletmeyi bilgilendirmektedir.

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 uluslarüstü kuruluşlar tarafından alıntılanmıştır.

Cem, kariyeri boyunca 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ında danışmanlık yapmıştır. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayımlamıştır.

CEO'ya rapor verirken bir telekomünikasyon şirketinin teknoloji stratejisini ve satın alımını yönetmiştir. 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önetmiştir. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınları tarafından ele alınmıştır.

Cem, uluslararası teknoloji konferanslarında düzenli olarak konuşma yapmaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisi olarak mezun olmuş 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 bir Yapay Zeka Araştırmacısı ve Veri Analistidir. 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