LangChain mi LlamaIndex mi? PDF hacmi kararı değiştirebilir

Araç kullanan bir ajan geliştiriyorsanız LangChain, PDF ağırlıklı bir RAG veri hattı kuruyorsanız LlamaIndex güçlü bir başlangıç noktasıdır. LangChain’in ajan belgeleri modelin araçları görev tamamlanana kadar çağırdığı, istem ve ara katmanlarla yapılandırılan bir döngüyü anlatır. LlamaIndex Framework belgeleri ise özel veriler üzerinde RAG ve ajan geliştirmeye yönelik Python araç setini tanımlar.

Bu başlangıç tercihi bir ürün sınırı değildir; iki çerçeve de belge sorgulama ve ajan geliştirmeyi destekler. Kararı değiştiren, ekibin hangi işi daha sık ve daha büyük ölçekte yapacağıdır. Az sayıda belgeye erişen, çoğunlukla harici araçlar arasında karar veren bir ajan ile sürekli yeni PDF alan bir arama sistemi aynı darboğaza sahip değildir. Belge koleksiyonu büyüdüğünde dosyaları işleme ve dizini güncelleme maliyeti, ajan kurulumundaki kolaylıktan daha belirleyici olabilir.

Ajan orkestrasyonu hangi projede öne çıkar?

Ajan projesinde temel iş, bir isteği uygun araca yönlendirmek, araç sonucuyla sonraki adımı belirlemek ve konuşma durumunu korumaktır. Örneğin uygulama bir bilgi arama aracından sonuç alıp ardından harici bir sistemde işlem başlatacaksa araç çağrılarının sırası ve hata sonrasındaki davranış önem kazanır. LangChain’in model, araç, istem ve ara katmanları yapılandırmaya açan ajan yapısı bu tür işlerde doğal bir başlangıç sunar. Burada PDF sayısını ana ölçüt yapmak, uygulamanın asıl karmaşıklığını gözden kaçırır.

LlamaIndex’i yalnızca pasif bir belge dizini gibi düşünmek de seçimi daraltır. Çerçeve, veri üzerinde çalışan ajanları ve çok adımlı iş akışlarını da kapsar. Fark, hangi ürünün bir özelliğe sahip olduğundan çok, ekibin hangi katmanı daha fazla özelleştireceğinde ortaya çıkar. Harici araçların davranışı, durum aktarımı ve müdahale noktaları ön plandaysa ajan katmanını; dosya okuma, dönüştürme ve güncelleme ön plandaysa veri katmanını önce değerlendirmek daha anlamlıdır.

Yayımlanmış PDF süreleri neyi gösteriyor?

Markaicode’un karşılaştırmasında yazar, Hetzner CCX23 ortamında 500 bin PDF’nin LlamaIndex 0.11.2 hattında 4,2 saatte, LangChain 0.3.10 ve UnstructuredLoader kullanılan hatta 7,1 saatte işlendiğini bildiriyor. Bu, yazarın belirttiği kurulumlara ait bir sonuçtur. Yazıdaki örnek kod sorgu gecikmesini gösterir; PDF koleksiyonunun uçtan uca işlenmesini yeniden üretmeye yetecek dosya kümesini ve çalışma adımlarını sunmaz. Bu nedenle süreleri bütün kurulumlara taşınabilen bir hız sıralaması olarak kullanmak mümkün değildir.

İşleme süresi çerçeve adından daha fazla değişkene bağlıdır. Metin içeren PDF ile taranmış sayfa aynı ayrıştırma yükünü doğurmaz; taranmış sayfada OCR, tablo ağırlıklı dosyada ise yapının korunması gerekir. Parça boyutu, gömme modeli, eşzamanlı çalışan işçi sayısı ve vektör deposuna yazma biçimi de toplam süreyi etkiler. İki hatta farklı ayrıştırıcılar veya farklı çıktı kalitesi kullanıldığında ölçülen farkı yalnızca LangChain ya da LlamaIndex’e bağlamak yanıltıcı olur.

Hacim arttıkça ilk tam dizin oluşturma süresinin yanında değişen dosyaları yeniden işleme süresi de önem kazanır. Sık güncellenen bir koleksiyonda her değişiklikten sonra bütün belgeleri yeniden hazırlayan hat, ilk kurulumda hızlı olsa bile işletmede pahalıya gelebilir. Buna karşılık seyrek değişen küçük bir koleksiyonda mevcut ajan uygulamasına arama eklemek, ayrı bir veri hattı kurmaktan daha az geliştirme işi çıkarabilir. Ölçümün kararı değiştirmesi, ekibin kendi dosya türlerinde ve aynı arama kalitesinde benzer farkı görmesine bağlıdır.

RAG’de veri alma ve arama birlikte düşünülmeli

LlamaIndex’in veri alma kılavuzu, yüklenen belgelerin dönüşümlerle düğümlere ayrıldığını ve tekrarlanabilir, önbellekten yararlanabilen bir alma hattı kurulabildiğini gösterir. Bu yapı, belge kaynağı ile aranabilir dizin arasındaki adımları ayrı ayrı ele almaya yardım eder. PDF’de sayfa bağlamı, başlıklar veya tablolar sorunun yanıtını taşıyorsa dosyanın okunmuş olması tek başına yeterli değildir. Yanlış ayrılmış içeriği hızlı dizine yazmak, daha sonra getirilen parçaların isabetini düşürebilir.

LangChain de RAG için geçerli bir seçenektir. LangChain’in eğitim örnekleri PDF üzerinde anlamsal arama ile RAG ajanını ayrı kullanım biçimleri olarak sunar. Mevcut bir LangChain ajanına belge arama aracı eklemek isteyen ekip, sırf belgeler kullanılıyor diye çerçeve değiştirmek zorunda değildir. Asıl karşılaştırma, aynı dosyalardan üretilen parçaların doğru bilgiyi bulup bulmadığı ve dosya değiştiğinde arama dizininin nasıl yenilendiğidir.

Hibrit arama ihtiyacında da çerçeve adı tek başına sonucu açıklamaz. Tam terim eşleşmesi gerektiren bir kurum kısaltması ile anlamca yakın cümleleri bulmayı gerektiren bir soru farklı arama davranışlarını sınar. Karşılaştırmada belge kümesi, parçalama, gömme modeli ve arama altyapısı mümkün olduğunca aynı tutulmalıdır. Türkiye’de kullanılan belgeler için ekli Türkçe sözcükler, kısaltmalar ve tablo başlıkları sorulara dâhil edilirse arama farkı daha görünür olur. Yanıtın akıcılığı kadar, getirilen parçanın doğru sayfaya dayanması da değerlendirilmelidir.

Entegrasyon sayısı ve bellek kararı nasıl etkiler?

Toplam entegrasyon sayısı yerine uygulamanın gerçekten kullanacağı bağlantılara bakmak gerekir. Model sağlayıcısı, PDF kaynağı, vektör deposu ve harici araçların her biri için gereken paketi ve veri aktarım biçimini belirlemek, geniş bir katalogdan daha kullanışlıdır. Tek bir kritik bağlayıcının eksikliği özel kod yazdırabilir; kullanılmayacak çok sayıda entegrasyon ise bu maliyeti azaltmaz. Hazır bağlantının bulunması da bakım, sürüm uyumu ve hata davranışının uygun olduğu anlamına gelmez.

Bellek karşılaştırmasında iki ayrı yük vardır. Ajanın konuşma durumu ve araç sonuçları çalışma sırasında taşınırken belge dizini parçaları, üstveriyi ve arama yapılarını saklar. Birincisi uzun araç zincirlerinde, ikincisi büyük PDF koleksiyonlarında öne çıkabilir. Dolayısıyla tek bir bellek rakamı yerine dosya yükleme, dizin oluşturma ve sorgulama aşamalarının tepe kullanımlarını ayrı kaydetmek gerekir. Kullanılan vektör deposu veya gömme modeli değiştiğinde farkın hangi bileşenden kaynaklandığı ancak böyle anlaşılır.

Seçim için hangi koşullar sabitlenmeli?

Karşılaştırmanın anlamlı olması için Python ve paket sürümleri, PDF’lerin türü, ayrıştırıcı, parça boyutu, gömme modeli, vektör deposu, donanım ve eşzamanlılık ayarı yazılı olmalıdır. İlk dizin oluşturma süresiyle değişen dosyaların yeniden işlenme süresi ayrı ölçülmelidir. Aynı soruların getirdiği belge parçaları da karşılaştırılmalıdır; yalnızca daha kısa sürede tamamlanan hat, aranan tabloyu veya doğru sayfayı kaybediyorsa projeye daha iyi hizmet etmeyebilir. Sürüm sabitleme, yayımlanmış bir ölçümle ekip içindeki denemenin aynı bileşenleri kullandığını anlamayı sağlar.

Seçim, baskın iş yüküne göre yapılabilir: araç çağrıları ve ajan durumu geliştirme işinin merkezindeyse LangChain; PDF alma, güncelleme ve aranabilir hâle getirme merkezindeyse LlamaIndex önce denenebilir. İki ihtiyaç aynı uygulamada belirginse belge alma hattı ile ajan katmanını ayrı seçmek de mümkündür. Büyük koleksiyonlarda belirleyici soru, yayımlanmış süre sıralamasının tekrarlanıp tekrarlanmadığından öte, kendi belgelerinizde işleme maliyeti düşerken getirilen bilgilerin doğruluğunun korunup korunmadığıdır.

Ayrıca okuyun: