RAG Çerçeveleri: LangChain, LangGraph ve LlamaIndex

Aynı ajan tabanlı RAG iş akışını standartlaştırılmış bileşenlerle oluşturarak 5 RAG çerçevesini (LangChain, LangGraph, LlamaIndex, Haystack ve DSPy) karşılaştırmalı olarak değerlendirdik: özdeş modeller (GPT-4.1-mini), gömülü vektörler (BGE-small), alıcı (Qdrant) ve araçlar (Tavily web araması). Bu, her çerçevenin gerçek ek yükünü ve belirteç verimliliğini ortaya koymaktadır.

RAG çerçevelerinin kıyaslama sonuçları

Karşılaştırma testi 100 sorgudan oluşuyordu ve her çerçeve, istikrarlı ortalamalar elde etmek için tüm test setini 100 kez çalıştırdı.

• Ortalama Token Sayısı : Tüm LLM çağrıları (yönlendirici, belge değerlendirici, cevap değerlendirici ve oluşturucu) genelinde tüketilen toplam token sayısı; hem istemleri (alınan bağlamla birlikte) hem de tamamlamaları içerir. Daha düşük değer = daha az API maliyeti.
• Çerçeve Ek Yükü : Saf düzenleme süresi (ms), çerçevenin dahili işlemesi (yönlendirme mantığı, durum yönetimi vb.), LLM API ve araç çağrıları hariç. Daha düşük değer = daha yalın çerçeve.

Tüm uygulamalar test setinde %100 doğruluk oranına ulaştı. Aynı modeller, sıcaklıklar, veri alma sağlayıcısı, web arama aracı ve ortak bir bağlam belirteci sınırı kullanıldı.

Başlıca Bulgular

1. Kontrol edilebilir olan şeylere odaklanıyoruz : Aynı model ailesi ve sıcaklıklar, düğüm düzeyinde max_token sayısı, alıcı (Qdrant + BGE-small, k=5, normalizasyon açık), web sağlayıcı (sadece Tavily), yönlendirici politikası (sezgisel + model), hesaplayıcının erken dönüşü, paylaşılan bağlam token sınırı, aynı derecelendirme ölçütü, birleşik ölçüm araçları. Bu, ölçümlerimizdeki önemli karıştırıcı faktörleri önemli ölçüde azaltır.
2. Çerçeve yükü ölçülebilir ancak küçüktür : Orkestrasyon mantığından sorgu başına ~3–14 ms gözlemledik. Bu farklılıklar gerçektir, ancak 1 saniyeden fazla gecikme farkının ana kaynağı değildir; zamanın çoğu harici modeller/araçlarla G/Ç işlemlerine harcanmaktadır.
3. Performans, (bu kısıtlamalar altında) token'ları takip eder : DSPy en düşük çerçeve yükünü (~3,53 ms) gösterir. Haystack (~5,9 ms) ve LlamaIndex (~6 ms) onu 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'te (~1,60k); DSPy ve LangGraph'ta ~2,03k ve LangChain'de ~2,40k'dır.
4. Yönlendirme/araç yolu önemlidir : İlk yönlendirmedeki (alıcıya, web'e veya hesap makinesine) ve yedek davranıştaki küçük değişiklikler, istemler ve bütçeler uyumlu olsa bile, hem belirteçleri hem de süreyi etkiler.

Farklılıklar neden devam ediyor? "Çerçeve DNA'sı"

Standardizasyona rağmen, belirteç sayılarında ve gecikme sürelerinde küçük farklılıklar devam etmektedir. Bunlar, her bir çerçevenin doğasında bulunan, düşük seviyeli davranışlarından, yani "DNA'sından" kaynaklanmaktadır.

• İstem ve mesaj serileştirme: Her çerçeve, LLM'ye göndermeden önce aynı mantıksal içeriği biraz farklı biçimlendirmeyle sarar ve böylece küçük ama tutarlı belirteç farkları oluşturur.
• Bağlam oluşturma: Birleştirilmiş bağlam içindeki meta verilerin kesin sıralaması ve dahil edilmesi, çerçeveye göre biraz farklılık gösterebilir ve bu da nihai belirteç sayısını etkiler.
• Yönlendirme karar verme noktaları: Sınırda kalan durumlarda, bir çerçevenin yönlendiricinin JSON çıktısını nasıl ayrıştırdığına ilişkin ince farklılıklar, başlangıçtaki araç seçiminin farklı olmasına yol açabilir.

Bu kurulumda, çerçeve yürütme süresinden ziyade, belirtecin kapladığı alanın birincil belirleyici faktör olduğu görülüyor.

Paylaşımlı ajan tabanlı RAG mimarisi

Adil bir karşılaştırma sağlamak için, beş uygulamanın tamamı aynı kontrol akışı üzerine kurulmuştur:

• Yönlendirici: Alıcı, web araması veya hesap makinesi arasından seçim yapan, model ve sezgisel yöntemleri birleştiren hibrit bir düğüm.
• Belgeleri Getir: Normalleştirilmiş BGE-small gömme vektörlerini kullanarak Qdrant'tan en iyi 5 belgeyi getirir.
• Değerlendirme Belgeleri: Bir LLM jürisi belgenin uygunluğunu değerlendirir. Uygunsuz bulunursa, web aramasına geri dönülür.
• Yanıt Oluştur: Taslak yanıt oluşturmak için paylaşılan bağlam belirteci sınırına sahip, sıcaklık=0.0 LLM kullanır.
• Değerlendirme Cevabı: İkinci bir LLM jürisi taslağı, sağlamlığı, çelişkileri (yanılsamalar) ve eksiksizliği açısından değerlendirir.
• Yedekleme ve Erken Dönüş: Cevap notu yetersizse bir web araması tetiklenir. Ancak hesap makinesi sonuçları, oluşturma ve notlandırma adımları atlanarak doğrudan döndürülür.

İş Akışı Örnekleri

Senaryo A — Veritabanından doğrudan isabet:

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

Senaryo C — Hesap makinesi erken geri dönüş sağlıyor:

Senaryo D — Vektör veritabanı yetersiz, web aramasına geri dönülüyor:

RAG çerçeveleri metodolojisi

Beş uygulamanın tamamı, 100 sorgudan oluşan test setimizde %100 doğruluk oranına ulaşarak gerçek sonuçlarla eşleşti. Bu, performans farklılıklarını ölçmeden önce her bir çerçevenin aynı ajan tabanlı RAG iş akışını başarıyla yürütebildiğinden emin olmak için temel bir gereklilikti.

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

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

• LLM'ler:
  • Model: Tüm düğümler (yönlendirici, jeneratör, sınıflandırıcı) OpenRouter API'si aracılığıyla openai/gpt-4.1-mini modelini kullandı.
  • Belirlenimcilik: Yönlendirme, oluşturma ve derecelendirmede maksimum tutarlılığı sağlamak için tüm LLM çağrıları için sıcaklık 0,0 olarak ayarlandı.
  • Token sınırları: Sıkı max_token sınırları uygulandı: yönlendirici ve değerlendiriciler için 256 , jeneratör için ise 512. Bu, bir çerçevenin aşırı uzun yanıtlar üretmesinden kaynaklanan gecikme farklılıklarını önler.
• Gömme modeli ve alma:
  • Model: Kullanılan tüm çerçeveler HuggingFace'den BAAI/bge-small-en-v1.5'tir.
  • Normalizasyon: Performans için kritik bir adım olan normalize_embeddings, beş çerçevenin tamamında True olarak ayarlandı. (LangChain/LangGraph encode_kwargs aracılığıyla; LlamaIndex normalize=True aracılığıyla; Haystack normalize_embeddings aracılığıyla; DSPy retriever normalize edildi.)
  • Veri Alma: Tüm uygulamalarda Qdrant vektör deposundan ak=5 (en iyi 5 belge) sorgulandı.
• Takım:
  • Web araması: Karşılaştırma testi yalnızca Tavily ile sınırlandırıldı (max_results=3).
  • Hesap Makinesi: Beş uygulamanın tamamı, matematiksel ifadelerin ayrıştırılması ve değerlendirilmesi için sympy kütüphanesini kullandı ve böylece aynı yeteneklere sahip olmaları sağlandı.

2. RAG kontrol akışı ve politikası

Temsilcinin “karar alma” süreci, genel olarak her yerde açıkça aynı şekilde yansıtıldı.

• Yönlendirme mantığı: Model zekasını deterministik kurallarla dengelemek için beş komut dosyasının tamamında hibrit bir yönlendirme stratejisi uygulandı:
  1. Düzenli ifadelere dayalı bir sezgisel rota, öncelikle bariz hesap makinesi veya web arama kalıplarını (örneğin, matematik sembolleri, "2024" gibi yıllar) kontrol eder.
  2. Ardından bir LLM router_node kendi kararını verir.
  3. Son karar, hesap makineleri için sezgisel yönteme öncelik verir, aksi takdirde LLM'nin tercihine saygı gösterir.
• Bağlam bütçelemesi: Bu, en kritik standardizasyonlardan biridir. generate_answer düğümü çağrılmadan önce, alınan tüm 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 belirteçlik bir sınıra kısaltılır . Bu, her çerçevedeki oluşturucu LLM'nin tam olarak aynı boyutta bir girdi almasını sağlar ve herhangi bir çerçevenin, alınan bağlamın ayrıntılılığı nedeniyle avantajlı veya dezavantajlı duruma düşmesini önler.
• Cevap değerlendirme politikası:
  • Esnek değerlendirme ölçütü: grade_answer düğümü, tüm çerçevelerde aynı, esnek bir yönerge kullanır ve LLM hakimine anlamsal olarak benzer ve makul ölçüde eksiksiz yanıtları kabul etmesini söyler.
  • Hata işleme: Değerlendiriciden gelen başarısız bir JSON ayrıştırmasının işlenmesine yönelik mantık standartlaştırıldı. Değerlendiricinin çıktısı geçerli bir JSON değilse, sistem varsayılan olarak izin verici bir not verir (grounded=True, complete=True), bu da kırılgan bir ayrıştırıcının aksi takdirde iyi bir cevabı başarısız kılmasını istemeyeceğiniz gerçek dünya senaryosunu taklit eder. DSPy yapılandırılmış alan dönüşleri (JSON ayrıştırması yok), performans avantajı olarak değil, sağlamlık farkı olarak kaydedilir.
• Hesaplayıcının erken dönüşü: Kodda görüldüğü gibi, calculator_node'a yapılan başarılı bir çağrı, final_answer'ı doğrudan ayarlar ve iş akışını erken sonlandırır. Bu, tutarlı bir şekilde uygulanan önemli bir optimizasyondur ve hesaplayıcı yolunun generate ve grade_answer LLM'lerini gereksiz yere çağırmasını önler.
• DSPy uyumu. CoT dışı temel ölçütlerle adil bir uyum sağlamak için DSPy, Yönlendirici ve Cevap Üretici için dspy.Predict (CoT yok) kullanır. İmzalar, diğer çerçevelerin düğüm sözleşmelerini yansıtır; mevcut olduğunda, token sayıları model tarafından bildirilen kullanıma göre hesaplanır, aksi takdirde tiktoken yedeklemesi kullanılır.

3. Enstrümantasyon ve ölçümler

Ölçüm süreci, ortak araçlar ve prensipler kullanılarak tamamen aynıydı.

• Gecikme: Tüm zamanlama işlemleri için yüksek hassasiyetli time.perf_counter() kullanılmıştır. Çerçeve yükü, toplam gecikme - harici çağrı gecikmesi olarak tutarlı bir ş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 amacıyla cl100k_base kodlaması olan tiktoken kullanılarak hesaplanmıştır. Sonuçlarda bildirilen "Ortalama Token" metriği, tek bir sorgu iş akışı içindeki her LLM çağrısı (örneğin, yönlendirici, değerlendiriciler, oluşturucu) için tüm giriş (istem) ve çıkış (tamamlama) tokenlerinin kümülatif toplamını temsil eder.
• Durum yönetimi: Uygulama sözdizimi farklılık gösterse de (LangGraph'ın TypedDict'i, LlamaIndex'in sınıfı, LangChain'in sözlüğü), durum yapısı işlevsel olarak aynıdır. Her çerçeve, düğümler arasında aynı anahtar kümesini (soru, belgeler, web_sonuçları vb.) aktararak 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 testi yüzeysel karşılaştırmaların ötesine geçmeyi ve sabit bir RAG politikası altında çerçeve performansının tekrarlanabilir bir analizini sunmayı amaçlamaktadır.

Sonuçların yorumlanması:

• Şu sonuca varabilirsiniz: Bu özel, yüksek düzeyde kontrollü kurulumda, orkestrasyon yükü genellikle küçüktür; farklılıklar esas olarak belirteç sayıları ve araç yolları tarafından belirlenir.
  • Bu özel, son derece kontrollü kurulumda, çerçeve yükü ihmal edilebilir düzeydedir.
  • Performans farklılıkları, belirteç sayısı ve takım yolu varyasyonlarından kaynaklanıyordu.
• Genelleme yapamazsınız: Sonuçlar bu mimariye, modellere, komut istemlerine, veri alıcısına ve web sağlayıcısına özgüdür; bunların değiştirilmesi sıralamaları değiştirebilir.

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

Performans tek faktör değil; bir çerçeveyle geliştirme yapmanın nasıl bir his verdiği de aynı derecede önemli.

• LangGraph: Bildirimsel grafik
  Grafik ö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, indirgeyici tarzı güncellemelerle (Annotated[…, add]) bir TypedDict aracılığıyla tiplendirilir.
  • LangGraph'ı şu nedenlerle tercih edin: birden fazla dallanma, 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çeklenebilir.
• LlamaIndex: Zorunlu orkestrasyon
  Kontrol akışının standart Python if/else yapısıyla sağlandığı, prosedürel bir betik; "grafik" kodunuzda yer alıyor. Durum, özel bir PipelineState sınıfıdır ve çerçeve temiz alma temel öğeleri sağlar (VectorStoreIndex → .as_retriever(k=5)).
  • LlamaIndex'i şu amaçlarla tercih edin: anlaşılır prosedürel mantığa ve kolay hata ayıklamaya önem verdiğiniz, okunabilir, tek dosya halindeki iş akışları.
• LangChain: Bildirimsel bileşenlere sahip emir kipi
  Orkestrasyon bir Python betiği olarak kalır, ancak bireysel görevler | operatörünü kullanan küçük, birleştirilebilir zincirlerdir (örneğin, prompt | llm | parser). Durum, esnek, türsüz bir Python sözlüğüdür.
  • LangChain'i şu amaçlarla tercih edin: Hızlı prototipleme veya LangChain ekosisteminde zaten yer alan ve daha büyük bir zorunlu sürücü içinde küçük bildirimsel birimler oluşturmayı tercih eden ekipler.
• Haystack: Bileşen tabanlı, manuel orkestrasyon. Açık G/Ç'ye sahip, tipli, yeniden kullanılabilir bileşenler (@bileşen), kontrol akışı ise 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 adım enstrümantasyon (harici vs. çerçeve zamanı).
  • Haystack'i tercih edin çünkü: üretime hazır, test edilebilir, net sözleşmelere ve ayrıntılı kontrole sahip işlem hatları sunar.
• 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 istemleri ve LLM çağrılarını kapsayan Modüllerle uygulayın. İstem/kullanım yönetimini merkezileştirir ve gereksiz kodları ortadan kaldırır; iç yapıların değiştirilmesi (örneğin, Tahmin ↔ CoT ) sözleşmeyi değiştirmez.
  • DSPy'yi tercih etmenizin nedenleri: minimum şablon kod, okunabilir tek dosya akışları, sözleşme odaklı geliştirme (isteğe bağlı optimizasyon araçlarıyla).

En iyi performansı karşılaştırılabilirlik uğruna feda etmek

• LangGraph , paralel yürütme, durum önbellekleme ve karmaşık dallanma mantığı için koşullu kenar sistemini kullanmasına izin verildiğinde, yerleşik grafik optimizasyonlarıyla öne çıkabilir.
• DSPy, kendine özgü optimizasyon algoritmalarını (MIPROv2 gibi) ve düşünce zinciri tabanlı yönlendirmeyi kullandığında, cevap kalitesini önemli ölçüde artırabilen, oldukça farklı sonuçlar gösterebilir.
• Haystack, adil olmak adına devre dışı bıraktığımız, üretime hazır önbellekleme, toplu işleme özellikleri ve bileşen düzeyindeki optimizasyonlarından yararlanabilir.
• LlamaIndex, bu kıyaslamada kullanılmayan gelişmiş indeksleme stratejilerinden, sorgu motorlarından ve çok modlu yeteneklerinden faydalanabilirdi.
• LangChain, standartlaştırılmış araç setimizle sınırlı kalmadığında, kapsamlı araç ekosistemi ve LCEL (LangChain İfade Dili) optimizasyonlarıyla öne çıkabilir.

"En iyi" çerçeve, geliştirme hızı, sürdürülebilirlik, performans veya belirli mimari kalıplar için optimizasyon yapıp yapmadığınıza bağlıdır.

Daha fazla okuma

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

• Gömme Modelleri: OpenAI vs Gemini vs Cohere
• RAG için En İyi Vektör Veritabanı: Qdrant vs Weaviate vs Pinecone
• Agentic RAG kıyaslama testi: çoklu veritabanı yönlendirme ve sorgu oluşturma
• Hibrit RAG: RAG Doğruluğunu Artırma

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.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder