Çoklu Ajan Çerçeveleri Kıyaslaması: Zorluklar ve Güçlü Yönler
Çoklu ajan sistemleri, karmaşık görevleri çözmek için birlikte çalışan uzmanlaşmış ajanlar kullanır. Temel zorluk şudur: Daha fazla ajan ve araç eklendikçe performans düşer mi, yoksa orkestrasyon mekanizmaları artan karmaşıklığı verimli bir şekilde yönetebilir mi?
Üç farklı görevle 750 çalıştırma üzerinden 5 farklı ajan tabanlı çerçeveyi karşılaştırmalı olarak değerlendirdik. Ölçeklenebilirlik altında hangi mimari modellerin verimliliği koruduğunu ve hangilerinin düştüğünü belirlemek için gecikme süresini, belirteç tüketimini ve düzenleme yükünü ölçtük.
Çoklu ajan çerçevesi kıyaslaması
Ajan ve araç sayısı arttıkça token kullanımının ve gecikmenin nasıl ölçeklendiğini test ettik. Aynı probleme sahip üç görevde, ajan sayısını ve araç kullanılabilirliğini kademeli olarak artırdık. LangChain ve LangGraph için, sıralı mimarilerinin çoklu ajan sistemlerinin karşılaştığı aynı karmaşıklığı nasıl ele aldığını gözlemlemek amacıyla tek ajanlı kurulumlar kullandık.
Grafiğe %95'in altında doğruluk oranına sahip çerçeveyi (Swarm) dahil etmedik. Karşılaştırma metodolojimizi okuyabilirsiniz.
Özellikle Swarm için, doğruluk oranının bu karmaşıklıkla birlikte değiştiğini ve bunun model yeteneklerinden ziyade mimari farklılıklardan kaynaklandığını gözlemledik.
Ajan tabanlı çerçevelerdeki doğruluk, genellikle LLM seçimi veya yapılandırma ayarlaması yoluyla iyileştirilebilir. Bununla birlikte, kıyaslamamızdaki doğruluk varyasyonlarının mimari nedenlerini incelemek değerli bilgiler ortaya çıkardı. Bu, çerçeveler arasındaki temel tasarım farklılıklarını anlamamıza yardımcı oldu.
Çoklu ajan çerçevesi kıyaslama sonuçları
CrewAI, tüm ajanların sırayla çalışmasını zorunlu kılarak, her ajanın çıktısının bir sonraki ajanın bağlamına eklenmesiyle token sayısında üstel bir artışa neden olur. Bu katılık, eksiksizliği sağlar ancak büyük bir ek yük oluşturur.
Swarm, durumsuz yönlendirme yoluyla hızı önceliklendirir ancak görev karmaşıklığı arttıkça doğruluk oranında kademeli bir düşüş yaşar (%84 → %0). Küresel durum takibi olmadan, ajanlar erken sonlanır ve çok adımlı zincirler kırılır.
LangChain , birleşik bağlamlı tek bir ajanlı "süper ajan" kullanarak koordinasyon yükünü tamamen ortadan kaldırır. Performans, araç kütüphanesi boyutu (100 araç) ve akıl yürütme karmaşıklığı gecikmeyi önemli ölçüde artırana kadar verimli kalır.
LangGraph, LangChain'in güvenilirliğine eşdeğerdir ancak grafik üzerinde gezinme yükünü artırır. Yüksek karmaşıklık altında durum yönetimi maliyeti belirginleşir, ancak yüksek doğruluğu korur.
AutoGen, sohbet tabanlı koordinasyon yoluyla yüksek devir teslim sayıları üretir ancak gereksiz temsilcileri dinamik olarak elemek için GroupChatManager'ı kullanır. Bu, CrewAI'nin üstel büyümesini önlerken yüksek doğruluğu korur; ancak konuşma geçmişinin yeniden işlenmesi nedeniyle belirteç tüketimi tek temsilcili temel seviyelerden daha yüksek kalır.
CrewAI
CrewAI'nin rol tabanlı sıralı işlem hattı, süreç boyunca gereksiz gürültü ajanlarını filtrelemeden atanan her ajanı çalıştırır. Bu mimari özellik, her ajanın kritik bir işlevi yerine getirdiği ajan tabanlı sistemler için önemli sonuçlar doğurur. Çerçevenin beklenen adımların hiçbirini atlamamasını ve otonom yönlendirme kararları almak yerine her ajanı kullanmaya devam etmesini sağlar. Bununla birlikte, bu katılık, görev karmaşıklığı arttıkça kaynak tüketimi ve gecikme açısından yüksek bir maliyete yol açar.
Görevler genelinde üstel kaynak artışı
1. görevden 3. göreve kadar, sürekli olarak artan token tüketimi ve gecikme gözlemledik. Her görev artışıyla gecikme yaklaşık olarak iki katına çıkarken, token tüketimi daha da çarpıcı bir oranda arttı. Ajan devir sayısı da bu ölçeklendirmeye paralel olarak doğal olarak arttı.
CrewAI neden daha fazla token ve zaman tüketiyor?
CrewAI'nin sıralı işlem hattı, her iki iş akışıyla da doğal bir şekilde uyum sağladı. 1. Görevde, Veri Analisti, Hakem karar vermeden önce bilgi topladı. 2. Görevde, bu model genişletilmiş ajan rolleriyle devam etti. CrewAI tüm araçları doğru bir şekilde seçti ve sıralı yürütmenin koordinasyon karışıklığını ortadan kaldırdığını, her ajanın yönlendirme belirsizliği olmadan kendisine atanmış araçları yürüttüğünü gösterdi.
Ancak bu doğal uyum, önemli ve giderek artan ek maliyetleri de beraberinde getirdi:
Devlet bileşikleşme mekanizması:
- Her bir ajan, görevini tamamladıktan sonra ayrıntılı bir rapor oluşturur.
- Bu rapor sıradaki bir sonraki temsilciye iletilir.
- Son hakem görevi devraldığında, önceki tüm aracıların geçmişini ve çıktılarını, ayrıca kendi sistem talimatlarını ve araç meta verilerini içeren bir belgeyi okur.
- LLM, görevler arasında büyük Markdown durum nesnelerini okumak ve yeniden oluşturmak için önemli miktarda zaman harcar.
Bu ayrıntılı durum yönetimi, küçük veri noktalarını bile önemli düzenleme meta verileriyle sarmaladı. CrewAI, verimlilikten ziyade tam bağlam farkındalığına öncelik veriyor.
Görev 2-3'ün katılığı:
- Çerçeve, yalnızca bir alt kümesinin kesinlikle gerekli olduğu durumlarda bile, önceden tanımlanmış sırayla 5 ajanın tamamını çalıştırdı.
- Bu katılık, yüksek doğruluğu korurken hem token maliyetlerini hem de gecikmeyi artırdı.
- Çerçeve yapısının gereksiz aracıları atlama yeteneğinin olmaması, temel bir mimari kısıtlama olarak giderek daha belirgin hale geldi.
- Eklenen her bir etken, sonraki etkenlerin işlemesi gereken bağlamı daha da karmaşık hale getirdi.
Sürü
Swarm'ın hafif yönlendirme mekanizması, minimum orkestrasyon yüküyle gerçek çoklu ajan delegasyonunu gösterdi. İlk ajan gerekli bağlamı topladı, işinin bittiğini aktif olarak fark etti ve oturumu açıkça farklı bir karar verici ajana devretti. Bu durumsuz mimari, hızı ve sadeliği önceliklendirdi ve basit senaryolarda tek ajanlı temellerle karşılaştırılabilir bir performans elde etti. Bununla birlikte, görev karmaşıklığı arttıkça, bu hafif yaklaşım, küresel durum takibinin ve merkezi orkestrasyonun yokluğunun kademeli doğruluk düşüşüne neden olduğu temel ölçeklenebilirlik sınırlamalarını ortaya çıkardı.
Görevler genelinde kademeli doğruluk azalması
1. görevden 3. göreve kadar, hızlı yürütme hızlarını korumamıza rağmen doğrulukta dramatik bir düşüş gözlemledik. Doğruluk, 1. görevde %84'ten 2. görevde %22'ye düştü ve nihayetinde 3. görevde %0'a ulaştı. Bu kademeli bozulma, kısa süreli etkileşimlerde hız için optimize edilmiş Swarm'ın durumsuz mimarisinin, çok adımlı akıl yürütme zincirleri için temelde ölçeklenebilir olmadığını ortaya koydu.
Karmaşıklığı artırdıkça doğruluk neden azaldı?
Swarm'ın hafif yönlendirme yapısı, tüm görevler boyunca tamamlama belirteçlerini son derece düşük ve gecikmeyi hızlı tuttu. Çerçeve, küresel bir durum olmaksızın bağımsız ajanların bayrak yarışı gibi çalıştı; her ajan, merkezi gözetim olmadan özerk devir teslim kararları aldı. Bu yaklaşım, belirteç tüketimini en aza indirmede ve hızlı yürütme sağlamada mükemmeldir, ancak operasyonel kalıcılık gereksinimleri arttıkça güvenilirlik ve hassasiyet açısından yüksek bir maliyete sahiptir.
Mimari kör nokta:
Kayıtların incelenmesi sonucunda, yalnızca komut satırı mühendisliğiyle çözülemeyen mimari bir kör nokta ortaya çıktı. Başlangıçta, bir komut satırı hatası (eksik aktarım talimatları) tespit edildi ve düzeltildi. Ancak, açık aktarım komutlarına rağmen Swarm, zinciri tamamlayamadı.
Çerçeve durumsuz olduğundan ve küresel niyet takibinden yoksun olduğundan, ilk alıcı ajan (örneğin, Finans) basitçe bir konuşma onayı (örneğin, "Veriler alındı, finansal denetim başlatılıyor") gönderir ve ileti dizisini sonlandırır. Swarm, herhangi bir konuşma sonunu görev tamamlanması olarak yorumlar ve bu da en hızlı ancak en anlamsız sonuçlara yol açar. Görev durumunu koruyacak ve tüm adımların yürütülmesini sağlayacak merkezi bir düzenleyici olmadan, çerçeve "ajan bir onay verdi" ile "görev tamamen tamamlandı" arasında ayrım yapamaz. Bu temel sınırlama, zincir basit etkileşimlerin ötesine uzandığında, açık devir teslimlerle gerçek çoklu ajan delegasyonunun bile görev tamamlanmasını garanti edemeyeceği anlamına gelir.
Görev 1-2: Artan hassasiyet sorunları
Swarm'ın kısa ajan zincirleriyle güçlü performans sergilediği 1. Görevde, çerçeve eksik aktarım çözümü nedeniyle çalıştırmaların %16'sında başarısız oldu. Konuşma kayıtlarını analiz ederek, Hakemin başarılı bir şekilde kararlar verdiğini, ancak Swarm'ın çıktı mekanizmasının bunun yerine Veri Analistinin ara aktarım mesajını ortaya çıkardığını bulduk. Kullanıcılar gerçek karar yerine "Bu bilgiyi şimdi Hakeme aktaracağım" mesajını aldılar; bu da dinamik yönlendirme sistemlerinin ajan geçişleri sırasında nihai sonuçları kaybetme riskini taşıdığını ortaya koymaktadır.
2. Görevde, 5 ajan seçeneği ve 20 araç kapsamıyla, çerçevenin hafif, bağlamdan yoksun yönlendirme stratejisi artan karmaşıklık karşısında çökmeye başlayınca hassasiyet önemli ölçüde azaldı:
- Doğru alet seçme oranı %40'a düştü; bu da 1. göreve göre %20'lik bir düşüşü temsil ediyor.
- Temsilciler zaman zaman alakasız araçları çağırdılar veya gerçek araç çağrılarının beklendiği yerlerde yönlendirme mesajları gönderdiler.
- Temsilciler bazen yanlış alan adından araçlar kullanmaya çalıştılar veya başarısız aramaları tekrar denediler.
- Merkezi bir kontrol mekanizması olmadan, aracılar yürütme durumunu takip edemez hale geldi veya kesin sonuç vermiş gibi görünen ancak gerekli araç çağrılarını henüz gerçekleştirmemiş rollere devredildi.
Görev 3: Devir teslim paradoksu
3. Görev, en hızlı yürütme hızını korumasına rağmen %0 doğrulukla Swarm'ın temel mimari sınırlamasını ortaya koydu. Bu tam başarısızlık, "Devir Teslim Paradoksu" olarak adlandırdığımız şeyi ortaya çıkardı: 10 ajanlı bir zincirde, Swarm her bağlantıda %100 araç tabanlı aktarımlar gerektirir, ancak merkezi bir düzenleyici veya durum grafiği (LangGraph gibi) olmadan, zincir ilk bağlantıda kırılır. Swarm bire bir devir teslimlerde mükemmel olsa da, uzun zincirler boyunca operasyonel süreklilik gerektiren çok adımlı iş akışlarında çöker.
Aktarma zincirinin tükenmesi:
1. Görevde, tek bir el değiştirme ile zincir yeterince kısa olduğundan hedef bağlam içinde kaldı. Ancak, zincir 3. Görevde 9 el değiştirmeye uzadıkça, kümülatif başarı olasılığı sıfıra düştü. Her ek uzman, son Hakem'e ulaşılmadan önce konuşma şeklinde bir yanıtın süreci sonlandırabileceği bir "sızıntı noktası" görevi gördü. Bu geometrik başarısızlık oranı, durumsuz yönlendirmenin hız için optimize edilmiş olsa da, çok adımlı akıl yürütme maratonlarına ölçeklenemediğini göstermektedir.
DilZinciri
LangChain, görevleri basit bir durum makinesi olarak yürüttü: komut istemini al, araçları değerlendir, yürüt, sonlandır. LangChain'i, tüm görevler boyunca sıfır el değiştirme ve tek bir benzersiz ajanla tek ajanlı bir yürütücü olarak yapılandırdık. Bu birleşik bağlam yaklaşımı, yürütme boyunca tek bir mantıksal varlığı koruyarak, sıfır diyalogsal sıçrama yaptı ve her görevin gerektirdiği şeyi, orkestrasyon yükü olmadan tam olarak yürüttü. Çerçevenin doğrusal yürütme modeli, ajan işbirliği gerektirmeyen görevlerin, çoklu ajan sistemlerinde bulunan koordinasyon maliyetlerinden kaçınmaktan önemli ölçüde fayda sağladığını gösterdi.
Araç entropi eşiğine kadar verimli ölçeklendirme
LangChain, üç görevin tamamında doğru çıktılar sağladı. Bununla birlikte, Görev 3, çerçevenin araç kütüphanesi boyutuna ve mantıksal çıkarım karmaşıklığına duyarlılığını ortaya koydu; her iki boyut da genişledikçe gecikme belirgin şekilde arttı.
LangChain neden verimli kalmaya devam etti?
Görev 1-2: Doğrusal yürütme avantajı
1. Görevde, LangChain minimum gecikme süresi elde etti ve doğru araç seçimi hassasiyetiyle token kullanımını optimize etti. Çerçeve, koordinasyon mekaniğiyle uğraşmaktan kaçınarak, görevi tamamlamak için gerekli olan işlemleri gerçekleştirdi. Tek ajanlı mimari, ajanlar arası iletişim yükünün olmaması, adımlar arasında rapor oluşturulmaması ve gereksiz konuşmaların olmaması anlamına geliyordu.
2. Görevde, tek bir denetleyicinin 20 aracın tamamına doğrudan erişebildiği bir "süper ajan" mimarisi kullanarak LangChain'i uyguladık. Rolleri tek bir mantıksal varlığa birleştirerek, çerçeve ajanlar arası veri aktarımı, rapor oluşturma ve konuşma doldurma ihtiyacını ortadan kaldırdı. Bu doğrusal yürütme modeli, LLM'nin yalnızca ilgili araç sonuçlarını işlemesini sağlayarak, çoklu ajan çerçevelerinde görülen istem geçmişinin üstel büyümesini önledi.
Birleşik bağlam mimarisi, kütüphanede 20 aracın bulunmasının seçim karışıklığına yol açmadığı anlamına geliyordu. Tek bir aracı, diğer aracılarla koordinasyon veya müzakereye gerek duymadan araç çağrılarını sırayla işledi ve genişletilmiş araç kütüphanesine rağmen doğru araç seçimini korudu. Sıfır aktarım, karmaşıklık arttıkça herhangi bir orkestrasyon ek yükünün ortaya çıkmadığını doğruladı.
Araç entropisi ve akıl yürütme karmaşıklığı
3. Görev, LangChain'in performansını etkileyen iki önemli zorluğu ortaya çıkardı:
Araç entropisi:
Görev 1'de 5 araç, Görev 2'de 20 araç bulunurken, Görev 3'te 100 kullanılabilir araç sunulmuştur. LangChain tek ajanlı bir sistem olarak çalıştığı için, her mesajda bu 100 aracın tümünün tanımlarının yer alması gerekir. Bu durum iki darboğaz yaratır:
- LLM'nin doğru aracı seçmek için 100 seçeneği değerlendirmesi gerekiyor, bu da işlem süresini uzatıyor.
- Büyük komut istemi boyutu (tüm araç tanımlarını içerir), modelin ilk belirtece ulaşma süresini geciktirerek genel gecikmeyi artırır.
Akıl yürütme karmaşıklığı (10 uzman rolü):
1. ve 2. görevlerde, ajan sadece bir hakem gibi davranarak karar verdi. 3. görevde ise ajana, 10 farklı uzmanın bakış açısını sırayla değerlendirmesi talimatı verildi.
Bu talimat, modelin önemli ölçüde daha uzun çıktılar üretmesine ve 2. Göreve kıyasla tamamlama belirteçlerinin önemli ölçüde artmasına neden oldu. Daha fazla üretilen metin, modelin her belirteci sırayla üretmesi gerektiğinden, doğrudan daha uzun yürütme süresine dönüşür.
Bu zorluklara rağmen, LangChain doğru çıktıları korudu ve asla yanlış araçları seçmedi. Çerçevenin basit döngü yapısı (AgentExecutor), ek mimari yük getirmeden araç çağrılarını ve yanıtlarını işledi ve gecikme artışlarını, düzenleme mekanizmalarıyla artırmak yerine, görevin doğal karmaşıklığıyla orantılı tuttu.
LangChain'in mimari yaklaşımı, birleşik bağlam yürütmesinin karmaşıklık arttıkça güvenilirliği koruyabileceğini kanıtladı; ancak performans, araç kütüphanesi boyutuna ve akıl yürütme derinliğine duyarlı hale geliyor. Çerçevenin, çoklu ajan sistemlerinin belirteç patlaması ve koordinasyon yükünden kaçınırken tüm görevlerde doğru çıktılar üretebilme yeteneği, ajan işbirliği gerektirmeyen görevler için doğrusal yürütme modellerinin değerini gösterdi.
DilGrafiği
Ajan tabanlı çerçeveler kıyaslamamızda gözlemlendiği gibi, LangGraph, açık durum geçişleri ve grafik tabanlı kontrol akışına sahip bir durum makinesi mimarisi kullandı. LangGraph'ı, tüm görevler boyunca sıfır el değiştirme ve tek bir ajanla çalışan tek ajanlı bir yürütücü olarak yapılandırdık. Bu yaklaşım, tanımlanmış düğümler ve kenarlar aracılığıyla yürütme ilerlemesini izleyen yapılandırılmış durum yönetimi sağlarken, ajanlar arası iletişimi tamamen ortadan kaldırdı. Çerçeve, biçimsel durum izlemenin birleşik bağlam yürütmesiyle birlikte var olabileceğini gösterdi.
Grafik yönetimi yüküyle tutarlı güvenilirlik
LangGraph, üç görevin tamamında hatasız ve doğru çıktılar üretti. Görev 1 ve Görev 2'de performans, LangChain'in doğrusal yürütme modeline neredeyse aynı kaldı. Bununla birlikte, Görev 3, LangChain'e kıyasla daha belirgin gecikme artışları ortaya koyarak, yüksek araç entropisi ve akıl yürütme karmaşıklığı altında grafik tabanlı durum yönetiminin hesaplama maliyetini gösterdi.
LangGraph neden LangChain ile eşleşti?
LangGraph'ın durum grafiği, birden fazla aracı gerektirmeden resmi bir kontrol akışı sağladı. Her iki görevde de çerçeve, tüm araçları doğru seçerken sıfır el değiştirme (transport) sağladı. Tek denetleyici, gerekli tüm araçlara doğrudan erişti ve her adımı aracı el değiştirmeleri yerine durum geçişleri yoluyla işledi.
“Süper ajan” uygulaması, çerçevenin bilişsel yükü birden fazla kişiliğe bölmemesini sağladı. Görev 2'de 20 kullanılabilir araç olmasına rağmen, araç seçimi hassas kaldı ve ajan asla yanlış veya alakasız araçları çağırmadı. Birleşik bağlam, ajanlar arası koordinasyona dayanan çerçevelerde görülen seçim karışıklığını önledi.
Token tüketiminin LangChain ile neden eşleştiği
Her iki çerçeve de aynı LLM yapılandırmasını, araç tanımlarını ve sistem istemlerini kullandı. Ajanlar arası konuşmalar ve ara koordinasyon mesajları yoluyla koordinasyon yükü oluşturan çoklu ajan çerçevelerinin (AutoGen, CrewAI) aksine, her iki tek ajan çerçevesi de tüm uzmanlığı tek bir model çağrısında birleştirir. Harcanan her token, ara "Ajan A, Ajan B ile konuştu" yükü olmadan, ya giriş talimatlarını ya da doğrudan çıktıyı temsil eder. Ek olarak, her iki çerçeve de görevi çözmek için aynı araçları aynı sırayla çağırır ve altta yatan sistemden aynı verileri alır; bu da son derece benzer tamamlama token sayılarıyla sonuçlanır. Çerçeveler arasındaki token farklılıkları ihmal edilebilir düzeydedir çünkü LLM her iki durumda da aynı akıl yürütme işini gerçekleştirmiştir.
Görev 3: Grafik üzerinde gezinmenin getirdiği ek yük artırıldı
3. Görev, LangChain'in karşılaştığı aynı zorlukları (100 araç ve 10 rollü akıl yürütme karmaşıklığı) ortaya koydu, ancak LangGraph'ın grafik tabanlı mimarisi performans etkisini artırdı:
Araç entropi yükü:
LangChain gibi, LangGraph da tek ajanlı mimarisi nedeniyle her komut isteminde 100 araç tanımının tamamını içermelidir. LLM, her seçim için tüm araç kütüphanesini değerlendirmelidir ve büyük komut istemi boyutu yanıt üretimini geciktirir.
Akıl yürütme karmaşıklığı:
10 uzmanın bakış açısını sırayla değerlendirme talimatı, LangGraph'ın tıpkı LangChain'de olduğu gibi önemli ölçüde daha uzun çıktılar üretmesine neden oldu. Ancak, LangGraph'ın ek yükü burada görünür hale geldi.
Grafik yönetiminin getirdiği ek yük:
LangChain, araçları çağıran ve yanıtları işleyen basit bir döngü yapısı (AgentExecutor) kullanırken, LangGraph her adımda tüm bir grafik yapısını dolaşır. Her araç çağrısı için:
- Çerçeve, grafiğin tamamını başlangıçtan bitişe kadar dolaşmalıdır.
- Mesaj geçmişi (Durum), her düğüm geçişinde güncellenir.
- Sistem, düğümler arasındaki geçişleri doğrular ve durum tutarlılığını korur.
Görev 1 ve Görev 2'de bu ek yük önemsizdi. 100 araç ve karmaşık akıl yürütme gereksinimleriyle Görev 3'te bu grafik yönetim yükü önemli hale geldi. LangChain'e kıyasla ek gecikme, yüksek karmaşıklık altında durum grafiği yapısının korunması ve gezilmesinin maliyetini doğrudan yansıtmaktadır.
Bu ek yüke rağmen, LangGraph hiçbir zaman yanlış araçlar seçmedi ve her adımı tamamlamak için yalnızca gerekli fonksiyonları tutarlı bir şekilde çağırdı. Çerçevenin resmi durum takibi, artan işlem süresi pahasına yapılandırılmış bir kontrol akışı sağladı.
LangGraph'ın mimari yaklaşımı, açık durum yönetiminin karmaşıklık arttıkça güvenilirliğini koruyabileceğini göstermiştir; ancak grafik geçişinin getirdiği ek yük, yüksek araç entropisi ve mantık yürütme karmaşıklığı altında daha belirgin hale gelir. Denetlenebilirlik, geri alma yetenekleri veya karmaşık dallanma mantığı gerektiren uygulamalar için bu ödünleşme değerli olabilir. Basit sıralı yürütme için, LangGraph'ın ek yapısı, LangChain gibi daha basit doğrusal modellere kıyasla sınırlı bir değer sağlar.
Autogen
AutoGen, tek ajanlı temel modellere kıyasla önemli ölçüde daha fazla kaynak tüketti, ancak CrewAI'nin sıralı işlem hattının aşırı seviyelerine ulaşmadı. Çerçeve, bir UserProxy ve uzmanlaşmış ajanlar arasında birden fazla görüşmeyi içeriyordu. Bu sohbetin her aşaması, o güne kadarki tüm konuşma geçmişini yeniden işleyen tam bir LLM geçişi gerektiriyordu.
Ancak AutoGen, tüm görevlerde tutarlı bir şekilde doğru araçları seçti ve alakasız araçları çağırmadan doğru çıktılar üretti. Çerçeve, yürütmeden çok koordinasyona zaman harcadığı için konuşma tabanlı bir yük getirdi. Bu basit görev için, AutoGen'in sohbet tabanlı koordinasyonu, iş birliğine dayalı bir fayda olmaktan ziyade gereksiz bir karmaşıklık haline geldi.
AutoGen, iş akışı koordinasyonunu yöneten bir UserProxy aracılığıyla uzmanlaşmış temsilcilerin işbirliği yaptığı, sohbet tabanlı bir mimari kullanmıştır.
AutoGen'i her üç görevde de GroupChatManager kullanarak yapılandırdık ve sıralı yürütmeyi zorlamak yerine dinamik ajan seçimine olanak sağladık. Bu mimari, akıllı orkestrasyonun, katı işlem hatlarının katlanarak artan kaynak maliyetleri olmadan çoklu ajan işbirliğini sağlayabileceğini gösterdi.
Yüksek devir teslim sayıları ve rekabetçi performans
AutoGen, tüm çerçeveler arasında en yüksek devir sayısını kaydetti. Görev 1'de, çerçeve CrewAI'nin yalnızca Görev 3'te (9 devir) ulaştığı devir seviyelerine zaten ulaşmıştı. Bu, AutoGen'in konuşmaya dayalı yapısını yansıtıyordu: KullanıcıProxy'si ile uzman temsilciler arasındaki her etkileşim, hangi aracın çağrılacağı tartışılırken bile, bir devir olarak kaydediliyordu.
Ancak, bu yüksek aktarım sayılarına rağmen, AutoGen'in gecikme süresi, Görev 1 ve Görev 2'de sıralı çerçevelerle rekabet edebilir düzeyde kaldı. Görev 3'te, CrewAI'nin çerçeve yükü 1,35 milyon token'a ulaşırken, AutoGen yalnızca 56.700 token tüketti (LangChain ve LangGraph'ın 13.500 ve 13.600'üne kıyasla).
AutoGen'in gecikmesine rağmen neden daha fazla token tükettiği
AutoGen, tek ajanlı temel modellere kıyasla önemli ölçüde daha fazla token tüketti, ancak CrewAI'nin sıralı işlem hattının aşırı seviyelerine ulaşmadı. Çerçeve, bir UserProxy ve uzmanlaşmış ajanlar arasında birden fazla görüşmeyi içeriyordu. Bu sohbetin her aşaması, o güne kadarki tüm konuşma geçmişini yeniden işleyen tam bir LLM geçişi gerektiriyordu.
Bu tekrarlayan token birikimi, gecikme süreleri rekabetçi kaldığında bile AutoGen'in token tüketiminin LangChain ve LangGraph'tan daha yüksek kalmasının nedenini açıklıyor. Sohbet geçmişi her turda büyüyor ve komut istemi boyutunu artırıyor, ancak çerçevenin GroupChatManager'ı gereksiz aracıları budayarak sıralı işlem hatlarında görülen üstel patlamayı önlüyor.
Ancak AutoGen, alakasız araçları çağırmadan tüm görevlerde tutarlı bir şekilde doğru araçları seçti ve doğru çıktılar üretti. Konuşma yükü, çerçevenin yürütmeden çok koordinasyona daha fazla zaman harcaması anlamına geliyordu, ancak bu koordinasyon, hiçbir ajanın odak noktasını kaybetmemesini veya yanlış araçları çağırmamasını sağladı.
AutoGen'in Grup Sohbet Yöneticisi
AutoGen'in mimari gücü: GroupChatManager aracılığıyla dinamik temsilci seçimi. Görev 2'nin sıralı düzenlemesinin aksine, GroupChat modu, çerçevenin mevcut havuzdan yalnızca gerekli temsilcileri etkinleştirmesine olanak tanıdı.
Yönetici gereksiz uzmanları eleyerek 10 ajanlık havuzdan yalnızca 5-6 ajanı etkinleştirdi. Hakem bir karar için yeterli gerekçe bulur bulmaz, Yönetici döngüyü sonlandırdı. Bu, bağlamın kalan her ajana sırayla zorla uygulanması durumunda meydana gelecek olan üstel token büyümesini önledi.
Bu dinamik budama, CrewAI'nin katı sıralı işlem hattına kıyasla önemli ölçüde daha düşük gecikme süresi ve token tüketimiyle sonuçlandı. CrewAI, gerekli olup olmamasına bakılmaksızın 10 ajanın tamamının çalışmasını zorlarken, AutoGen'in GroupChat'i yalnızca karar vermek için gereken ajanları adaptif olarak seçti.
Koordinasyon yüküne rağmen, yüksek devir sayısı, ajanların sonlandırmadan önce bulguları çapraz referansladığı kapsamlı bir değerlendirmeyi yansıtmaktadır. AutoGen'in sıralı ve Grup Sohbeti modları arasında geçiş yapabilme özelliği, katı mimarilerin sahip olmadığı esnekliği sağlayarak, akıllı ajan seçimiyle sohbet tabanlı orkestrasyonun, karmaşık çoklu ajan iş akışları için sabit işlem hatlarına göre daha verimli bir şekilde ölçeklenebileceğini göstermektedir.
AutoGen GroupChatManager nasıl çalışır:
- Her aşamada, yönetici konuşma bağlamına dayanarak "sıradaki hangi temsilcinin konuşması gerektiğine" karar verir.
- Çerçeve, tüm ajanların sırayla çalıştırılmasını gerektirmez.
- Yeterli bilgi erken aşamada toplanırsa, yönetici gereksiz uzmanlardan vazgeçebilir.
- Yönetici, temsilcinin karar verebilmesi için yeterli bilgiye sahip olduğu anda döngüyü sonlandırabilir.
“Lütfen Devam Edin” sorunu: AutoGen'in varsayılan davranışı, konuşmaları canlı tutmaktır. Performans testleri için, “token sızıntısını” önlemek amacıyla kesin sonlandırma sinyalleri kritik öneme sahiptir. Bunu, tüm uzman ajanların görev tamamlandığında açık SONLANDIRMA sinyalleri içermesini sağlayarak çözdük.
Yönetici yükü: GroupChatManager ile bile, AutoGen'in dahili mesaj durumu, çoklu ajan düzenlemesi nedeniyle LangChain'inkinden daha büyüktür. Bununla birlikte, bu, daha basit çerçevelere kıyasla önemli ölçüde daha yapılandırılmış günlükler ve müzakere izleri sağlar.
Sıralı işlem ve Grup Sohbeti karşılaştırması hakkında not: Tüm görevleri Grup Sohbeti Yöneticisi kullanarak gerçekleştirdik. Sıralı düzenleme ile yapılan deneysel çalışmalarda, Grup Sohbeti moduna kıyasla belirteç tüketiminin ve gecikmenin en az iki katına çıktığını gözlemledik; bu da dinamik aracı seçiminin sabit işlem hatlarına göre önemli verimlilik kazanımları sağladığını doğrulamaktadır.
Çoklu ajan çerçevesi kıyaslama metodolojisi
Her bir çerçeve, her görev için 50 yineleme (N=50) boyunca test edildi.
Modelin akıl yürütme sürecindeki değişkenliği ortadan kaldırmak için, tüm çerçeveler aynı LLM yapılandırmasını kullandı. Kullanılan model, OpenRouter API'si aracılığıyla openai/gpt-5.2 idi. Sıcaklık 0.0 olarak ayarlandı.
LLM'nin yanıtlarına maksimum belirteç sınırı getirilmedi; bu da çerçevelerin, görevi çözmek için kendi iç mimarilerinin gerektirdiği kadar bağlam kullanmasına olanak sağladı.
Kaydedilen ölçümler şunlardır: LLM API çağrılarının sayısı, aracılar arasındaki aktarımlar, çağrılan benzersiz aracılar, gerçekleştirilen araç çağrıları ve araç çağrı doğruluğu. Tüm ölçümler her yineleme için kaydedildi ve 50 çalıştırmalık örneklem genelinde toplandı.
Orkestrasyon verimliliğini ölçmek için, ham LLM çıktılarını orkestrasyonun getirdiği ek yükten ayırdık. LLM çıktı belirteçleri, model tarafından üretilen gerçek, kullanışlı yanıtları temsil ederken, Çerçeve Yükü, çerçevenin bu yanıtları elde etmek için arka planda LLM'ye beslemesi gereken sistem komutlarını, araç tanımlarını ve konuşma geçmişlerini kapsar.
Çıktı token'larını toplam token'lardan çıkararak hesaplanan bu metrik (Toplam – Çıktı token'ları), çerçevenin kullanıcıdan gizlediği "yönetim maliyetini" doğrudan ortaya koymaktadır. Bu ayrım sayesinde, hangi çerçevelerin verimli ve yalın kaldığını, hangilerinin ise her orkestrasyon adımında LLM'ye tekrar tekrar büyük veri yükleri yüklediğini görebiliriz. Analizimizi, birincil verimlilik metriği olarak çerçeve ek yük token'larına dayandırdık.
Çerçevelerin yalnızca koordinasyon mantığına göre ölçülmesini sağlamak için diğer tüm değişkenleri senkronize ettik. Bu, karıştırıcı faktörleri ortadan kaldırdı ve mimari farklılıkları izole etti.
Ajanlar merkezi bir dosyada tanımlandı. Her çerçevenin sarmalayıcısı, AutoGen için system_message, CrewAI için backstory, LangChain/LangGraph için system prompts ve Swarm için agent descriptions gibi yerel parametrelerine tam olarak aynı persona dizesini enjekte etti. Çerçeveye özgü herhangi bir prompt mühendisliği uygulanmadı.
Kullanılan her çerçeve aynı temel Python fonksiyonlarını kullandı. Araç tanımları, doküman metinleri ve parametre şemaları standartlaştırıldı. Çerçeveye özgü önceden oluşturulmuş araçlar kullanılmadı. Bu, araç yürütme mantığının tutarlı olmasını ve yalnızca düzenleme mekanizmalarının farklılık göstermesini sağlar.
Her yinelemede, "DataCo Akıllı Tedarik Zinciri" veri seti aracılara beslendi. Gerçek veriler (sevkiyat durumu, ödeme durumu, kar marjları) tüm çerçevelerde sabit kaldı.
Girişleri aynı tutarken, her çerçeve kendi doğal yapısal modunda çalıştı. Çerçeveleri doğal olmayan mimarilere zorlamadık. Bunun yerine, gerçek dünya performansını ölçmek için her çerçeveyi amaçlanan tasarım modeline göre uyguladık.
AutoGen, konuşma tabanlı bir grup sohbet sistemi olarak çalışır. Çıkış koşullarını yönetmek için TERMINATE sinyalleriyle initial_chats kullanır. Temsilciler mesaj alışverişi yoluyla iletişim kurar ve bir UserProxy iş akışını koordine eder.
CrewAI, görev tabanlı sıralı bir işlem hattı uygular. Ajanların sabit bir sırayla çalıştığı Process.sequential'ı kullanır. Her ajan görevini tamamlar ve bir sonraki ajan başlamadan önce bir rapor oluşturur.
LangChain doğrusal zincir mimarisine sahiptir. Araç çağırma döngüsünü saran standart bir AgentExecutor kullanır. Ajan, araçları tek bir bağlam içinde sırayla yürütür.
LangGraph, yürütmeyi döngüsel bir durum grafiği olarak yapılandırır. İşlem adımlarını temsil eden düğümlere ve akışı belirlemek için koşullu yönlendirme kenarlarına sahip bir StateGraph kullanır.
Swarm, aktarım tabanlı rutinler kullanır. Çalışma zamanı kararlarına bağlı olarak ajanlar arasında kontrolü dinamik olarak aktarmak için transfer_to_agent fonksiyonlarını kullanır.
Görevler, farklı orkestrasyon yeteneklerini ve arıza modlarını test etmek amacıyla karmaşıklık açısından kademeli olarak gelişti.
Görev 1 (2 Aracı / 5 Araç): Sipariş bilgisi toplama ve iade kararı verme gerektiren basit bir iş akışı için temel orkestrasyon yükünü test eder.
Görev 2 (5 Ajan / 20 Araç): Gürültü altında yönlendirme zekasını test eder. Sadece 2-3 ajan ve 3-5 araç gereklidir, ancak 5 ajan ve 20 araç mevcuttur.
Görev 3 (10 Ajan / 100 Araç): Yüksek entropili filtreleme ve ölçeklenebilirlik sınırlarını test eder. Sadece 2-3 ajan ve 3-5 araca ihtiyaç duyulmaktadır, ancak yönlendirmeyi karıştırmak için tasarlanmış 98 alakasız gürültü aracı da dahil olmak üzere 10 ajan ve 100 araç mevcuttur.
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.