Agentic LLM Kıyaslaması: En İyi 13 LLM Karşılaştırması
Ajan tabanlı bir CLI aracı kullanarak 10 yazılım geliştirme görevi genelinde 13 LLM'yi kıyasladık. Hem API hem de UI katmanlarında performansı ölçmek için model başına yaklaşık 300 otomatik doğrulama adımı gerçekleştirdik.
Agentic LLM kıyaslama sonuçları
Başarı oranı karşılaştırması
Claude 4.5 Sonnet ve GPT-5.2, hem API mantığı hem de kullanıcı arayüzü entegrasyonunda en tutarlı sonuçlarla en yüksek genel puanları aldı. Gemini 3.1 Pro Preview ve GPT-5.2 Codex ise işlevsel arka uç mantığına sahip olmalarına rağmen daha zayıf ön uç çıktısıyla onları takip etti.
Claude Sonnet 4.5
Test edilen tüm modeller arasında en yüksek kullanıcı arayüzü oranına ulaşan Claude Sonnet 4.5, işlevsel arka uç mantığına sahip çalışan ön uçlar üretti. CRUD işlemlerini, girdi doğrulamasını, kaynak toplamayı, çok adımlı iş akışlarını ve çok aşamalı durum yaşam döngülerini başarıyla uyguladı. Bununla birlikte, bazı görevlerde kimlik doğrulama doğru şekilde ayarlanmış olsa da, alan özel uç noktalarında kaynak oluşturma, kısıtlama uygulama veya rol tabanlı erişim denetimi eksikti.
Gemini 3.1 Pro Önizlemesi
Teknik olarak kusursuz arka uç kodu ancak kırılgan altyapı kurulumu. Bazı görevlerde temel kimlik doğrulama ve listeleme adımlarını geçti ancak genel olarak şu konularda başarısız oldu:
- Ön uç başlatma
- Sıkı şema doğrulaması
- Zamana dayalı doğrulama kısıtlamaları
- Karmaşık durum geçişleri
- Basamaklı kaynak oluşturma
GPT-5.2
GPT-5.2 tarafından ele alınan görevlerin çoğu, işlevsel arka uçlar ve çalışan ön uçlarla karakterize edildi; CRUD, girdi doğrulama, rol tabanlı erişim kontrolü ve çok adımlı iş akışlarında güçlü performans sergiledi. Eksik kaldığı noktalar:
- Durum makinesi mantığı: Kimlik doğrulama ve kaynak listeleme oluşturuldu ancak yönetici durum geçişleri ve geri döndürülemez durum uygulama işlemleri atlandı.
- Bazı görevlerde rol zorunluluğu veya kısıtlı kaynak oluşturma
GPT-5.2 Kodeks
Kayıt, kaynak listeleme ve koleksiyon yönetimi gibi temel akışlar GPT-5.2 Codex tarafından iyi bir şekilde ele alınıyordu. Başlıca zayıf yönleri şunlardı:
- Eksik detay alma uç noktaları
- Yönetim durumu geçişleri yok
- Ön uçlarının yarısı çalışma zamanı hatalarıyla çöktü (10 üzerinden 5).
GPT-5.2 ile karşılaştırıldığında, Codex daha güvenilir arka uçlar üretti ancak ön uçlar önemli ölçüde daha az istikrarlıydı.
Örnek günlük kaydı:
Gemini 3 Pro
Daha basit, tek rollü görevlerde Gemini 3 Pro, CRUD işlemlerini, aramayı, rol tabanlı erişimi ve veri almayı doğru bir şekilde uyguladı. Çok rollü uygulamalar ise zayıf yönüydü:
- Sağlık kontrolü ve kimlik doğrulama başarılı oldu ancak kaynak oluşturma, ilişkilendirme yönetimi, rol uygulama ve yönetici iş akışlarında başarısız oldu.
- İki çok rollü görevde 16 adımdan 13'ünde başarısız oldum.
- Ön uçlar 4 görevde oluşturulamadı.
Claude Sonnet 4.6
Toplam iki arka uç hatası ve çoğu görevde düşük API puanlarıyla Claude Sonnet 4.6 tutarsız bir performans sergiledi. Bir istisna: neredeyse tamamlanmış CRUD, kimlik doğrulama, rol uygulama ve kaynak yönetimi içeren tek bir görevde 0,92 API puanı aldı (yalnızca silme işleminde başarısız oldu). Diğer görevlerde, proje iskeleti ve çalışan kimlik doğrulama katmanları oluşturdu, ancak alana özgü iş mantığını tamamlamadı. Eksik uygulamalar:
- Kaynak oluşturma, listeleme ve detaylı bilgi alma
- Durum geçişleri, rol uygulaması, girdi doğrulaması
- Alan iş akışları: sepet/ödeme, bilet yönetimi, randevular, anketler, etkinlik katılımı onayı, işlem takibi
Claude Opus 4.6
Claude Opus 4.6'dan neredeyse tamamlanmış ön uçlar ortaya çıktı, ancak arka uç mantığı minimal düzeydeydi. Sağlık kontrolü, kayıt ve giriş adımlarını geçti, ancak genel olarak şu adımlarda başarısız oldu:
- Kaynak oluşturma
- Devlet geçişleri
- Rol tabanlı erişim
- Giriş doğrulama
- Yönetici iş akışları
Örnek günlük kaydı:
Kimi K2.5
Bazı görev türleri için eksiksiz uygulamalar gerçekleştirilirken, diğerleri için arka uçlarda başarısızlıklar yaşandı; bu da Kimi K2.5'in daha basit CRUD görevlerini başarıyla yerine getirdiğini ancak karmaşık çok rollü veya çok adımlı uygulamalarla mücadele ettiğini gösteriyor.
GLM 4.7
GLM 4.7'nin genel performansı sınırlı sonuçlarla karakterize edildi. En yüksek puan alan görevlerinde ön uçlar kısmen yüklenmişti, ancak kimlik doğrulama uç noktaları yanlış durum kodları döndürüyordu. Görevlerin çoğunda arka uç veya ön uç kodunda bozukluk vardı.
Grok 4
Grok 4'ten minimal bir arka uç kodu ortaya çıktı ve genellikle yalnızca sağlık kontrolü ve kimlik doğrulama uç noktalarını uyguladı. Bir görevi tamamen tamamladı, ancak diğerlerinde başarısız oldu:
- Hizmet listeleri
- Kaynak oluşturma
- İdari işlemler
- Devlet geçişleri
Devstral 2 2512
Devstral tarafından kısmi arka uç mantığı oluşturuldu, ancak eksik dosyalar veya bozuk modül referansları nedeniyle hiçbir görevde geçerli ön uç kodu görünmedi.
Qwen3 Coder Sonraki
Qwen3 Coder Next tarafından denenen görevlerin çoğunda çalıştırılamayan arka uç kodları öne çıkıyordu. Arka uçlar çalışmaya başlarken, ön uçlar eksik giriş noktaları veya bozuk bileşenler nedeniyle başarısız oluyordu.
Trinity Büyük Önizlemesi
Genel olarak en düşük puanları alan Trinity Large Preview, uygulamaların çalışmasını engelleyen hatalar içeren proje yapıları üretti. Çoğu arka uçta işlevsel rota uygulamaları eksikti ve ön uçlarda eksik veya bozuk bileşenler vardı.
Maliyet ve başarı karşılaştırması
Claude Opus 4.6, üretim başına en pahalı model olmasına rağmen sıralamada ortalarda yer aldı; Devstral ise Claude 4.5 Sonnet ile benzer bir maliyete sahip olmasına rağmen önemli ölçüde daha düşük puan aldı. GPT-5.2 ve GPT-5.2 Codex, nispeten düşük bir maliyetle yüksek puanlar elde etti.
Tamamlama jetonları ve görev tamamlama süresi
Devstral, tüm modellerde yüksek miktarda token tüketti ancak çalışan bir ön uç üretmedi; bu da çıktısının büyük bir kısmının işlevsiz veya gereksiz kod olduğu anlamına geliyor.
Kimi K2.5 ve GLM 4.7 en yüksek gecikme sürelerine sahipti ve sonuçlarda karşılık gelen bir iyileşme olmaksızın görev başına önemli ölçüde daha fazla zaman harcadılar.
Grok-4, nispeten az sayıda belirteç üretmesine rağmen benzer şekilde yavaştı; bu da büyük çıktılar yerine üretimler arasında uzun duraklamalar olduğunu gösteriyor. Daha hızlı olan Gemini 3 Pro Preview ve GPT-5.2 Codex, orta düzeyde belirteç kullanımıyla görevleri hızlı bir şekilde tamamladı ve her ikisi de genel puanların üst yarısında yer aldı.
LLM'nin tek bir başarılı görevdeki performansı
10 görevle yaptığımız kıyaslama testinde, tüm LLM'lerin doğru şekilde tamamladığı hiçbir görev olmadığını ve birçok adımda başarısız olduklarını gördük. Bu nedenle, tüm LLM'lerin kolayca başarıyla tamamlayabileceği bir görevde token'ların ve gecikme sürelerinin nasıl performans göstereceğini görmek istedik.
Bu amaçla, minimum düzeyde bir temel görev tasarladık: dört CRUD uç noktasına, temel doğrulamaya ve kimlik doğrulama veya veritabanı içermeyen basit bir bellek içi Notes API'si. Her LLM bu görevi %100 başarı oranıyla tamamladı ve karmaşıklık ortadan kaldırıldığında tüm modellerin basit API oluşturmayı yönetebildiğini doğruladı.
Bu sayede, tek bir başarılı görevde token kullanımını, maliyetini ve gecikme süresini karşılaştırabildik.
Maliyet ve kod satırı sayısı karşılaştırması
Tam karşılaştırma testinde, Claude 4.5 Sonnet, görev başına ortalama 0,29 dolarlık maliyetle en yüksek puanı alan model oldu; burada ise sadece 0,012 dolarlık maliyetle temel testi tamamlayarak en ucuz modellerle aynı performansı gösterdi.
Tam görev kıyaslamasında sonuncu ve sondan ikinci sırada yer alan Qwen3 Coder (0,012 $) ve Trinity (ücretsiz), en yüksek puanı alan Sonnet modellerine kıyasla rekabetçi fiyatlandırma sunuyordu. Bu, hepsinin tamamlayabileceği bir görevde, en iyi ve en kötü performans gösterenler arasındaki maliyet farkının büyük ölçüde ortadan kalktığı anlamına gelir; ancak Opus, görev zorluğundan bağımsız olarak pahalı kalmaya devam eder.
Gemini 3.1 Pro Preview, 0,016$ fiyatıyla bu temel görevde verimli fiyatlandırma sergiledi; ancak maliyeti en ucuz modellerden biraz daha yüksekti. Bu durum, onu orta sınıf performans gösterenler arasında rekabetçi bir konuma yerleştirdi ve görev karmaşıklığı azaldığında makul bir maliyet verimliliği gösterdi.
Devstral 2 2512, görev başına 0,31 dolardan 0,021 dolara düşerek en çarpıcı maliyet azalmasını gösterdi. Tam kıyaslamada yalnızca 0,07 puan aldığı için, bu durum LLM fiyatlandırmasının önemli bir yönünü ortaya koyuyor: yüksek maliyetler her zaman pahalı token başına oranları yansıtmaz, modelin temel fiyatlandırma yapısından ziyade tekrarlanan başarısız denemelerden kaynaklanabilir.
Claude Opus 4.6, 0,086 dolar ile en pahalı token olmaya devam etti; bu, tam karşılaştırmadaki 1,17 dolarlık ortalama fiyatıyla tutarlı olup, görev zorluğundan bağımsız olarak token başına fiyatlandırmasının onu maliyetli hale getirdiğini doğrulamaktadır.
Grok-4, tam kıyaslamada düşük token kullanımına uygun olarak en az kod satırı üretti. GPT-5.2 Codex ve GPT-5.2 benzer maliyetlere sahipti, ancak GPT-5.2 daha hızlı ve daha verimliydi. Bu, GPT-5.2'nin aynı maliyetle daha yüksek puan aldığı ve çözümlere daha doğrudan ulaştığını gösteren tam kıyaslamayı yansıtıyor.
Tamamlama belirteçleri ve görev tamamlama karşılaştırması
Kimi K2.5, çoğu modelin 30 saniyenin altında tamamladığı bir görevi 135 saniyede tamamladı; bu da tam kıyaslamada gözlemlenen yüksek gecikmenin, görev karmaşıklığından değil, model düzeyinde bir kısıtlamadan kaynaklandığını doğruluyor.
Tam kıyaslama testindeki en yavaş model olan GLM 4.7, bu görevi 24 saniyede tamamladı; bu da 25 katlık bir azalma anlamına geliyor ve gecikme süresinin zorlukla orantılı olduğunu gösteriyor.
Qwen3 Coder, tam kıyaslamada sonuncu olmasına rağmen 10 saniye ile en hızlısıydı. GPT-5.2, GPT-5.2 Codex'ten daha az belirteç kullandı ve daha hızlı bitirdi; bu da GPT-5.2'nin daha özlü olmasına rağmen daha yüksek puan aldığı tam kıyaslamayla tutarlıydı.
Ajan tabanlı LLM sistemleri nedir?
Yazılım geliştirme yinelemeli bir süreçtir: kod yazın, çalıştırın, hataları okuyun, düzeltin, tekrarlayın. Ajan tabanlı yapay zeka sistemleri, dil öğrenme modellerinin de aynı döngüyü izlemesini sağlar. Model, dosya yazabileceği, komutları çalıştırabileceği, çıktıları okuyabileceği ve gördüklerine göre değişiklikler yapabileceği bir geliştirme ortamında çalışır ve görev tamamlanana kadar bu süreç devam eder.
Bu önemlidir çünkü gerçek uygulamalar tek bir dosyadan oluşmaz. Yönlendirme ve veritabanı modellerine sahip arka uçları, bileşenlere ve API çağrılarına sahip ön uçları, yapılandırma dosyaları, bağımlılıkları ve testleri vardır. Bunların birlikte çalışmasını sağlamak, yinelemeli test ve iyileştirme gerektirir; ajan tabanlı mimari de tam olarak bunu mümkün kılar.
Nasıl çalışır?
Model, bir shell, dosya sistemi ve yürütme çıktısına erişimi olan bir donanımın içinde yer alır. Bir uygulama oluşturması istendiğinde, dosyaları artımlı olarak yazar. Her adımdan sonra, donanım modele neler olduğunu gösterir: sunucu başladı mı, testler geçti mi, linter hataları işaretledi mi? Bu geri bildirime dayanarak, model bir sonraki adımda ne yazacağına veya düzelteceğine karar verir.
Bu, tek seferlik üretimden temel olarak farklıdır. Tek seferlik kurulumlarda, model tüm kod tabanını körü körüne üretir ve çalışıp çalışmadığını doğrulamanın hiçbir yolu yoktur. Ajan tabanlı LLM sistemlerinde, model her eylemin sonuçlarını görür ve düzeltme yapar. Ancak, bu yetenek tek başına yeterli değildir. Modelin iş mantığını doğru bir şekilde uygulamak için güçlü bir akıl yürütmeye ihtiyacı vardır ve performans farklılıkları burada gerçekten ortaya çıkar.
Agentic LLM kıyaslama metodolojisi
Tüm aracılar için Aider'ı kullandık ve modellerle OpenRouter aracılığıyla bağlantı kurduk. Basit rezervasyon sistemlerinden karmaşık etkileşimli gösterge panellerine kadar değişen 10 yazılım geliştirme görevinde (T-1 ila T-10) bağımsız olarak çalışma yeteneklerini değerlendirdik. Bu görevler, aracıların çoklu dosya projelerini yönetmesini ve işlevsel ürünler sunmasını gerektiriyor.
Yürütme ve orkestrasyon
Her ajan ve görev temiz bir ortamda başlar. Talimatlar TASK.md dosyası olarak sağlanır ve başlatma komut dosyaları için 20 dakikalık bir kalp atışı izleme mekanizması kullanırız. Bu aşamada, çıkış kodlarını, yürütme süresini ve arka uç ve ön uç dosyalarının oluşturulup oluşturulmadığını kaydederiz. Ayrıca, giriş, çıkış ve önbelleğe alınmış kategorilerde gerçek zamanlı belirteç kullanımını da izleriz.
Arka uç doğrulama : Oluşturulan projeleri, standart bir YAML sözleşmesine göre test etmek için izole ortamlara dağıtıyoruz. Doğrulama, sorunsuz çalışma senaryolarını, hata yönetimini (400/403/409) ve veri tutarlılığını kapsar.
Sonuçları iki modda test ediyoruz:
Uyarlanabilir mod, farklı rota adlarına sahip olsa bile işlevselliği doğrular; Katı mod ise sözleşmeye tam olarak uyulmasını gerektirir.
Arka uç genel puanı şu şekilde hesaplanır: backend_overall = (hazır_görevler / toplam_görevler) × Ortalama(Uyarlanabilir + Katı başarı oranları)
Kullanıcı arayüzü ve kullanıcı senaryosu testleri
Ön kontrol, görüntüleme ve kimlik doğrulama dahil olmak üzere gerçek kullanıcı akışlarını simüle etmek için tarayıcı otomasyonunu kullanıyoruz. Uygulamanın çökmeden çalışmasını sağlamak için giriş gönderimi ve giriş sonrası davranış gibi işlevsel adımları doğruluyoruz.
Kullanıcı arayüzü performansı, adım geçme oranı ile ölçülür: adım_geçme_oranı = geçti / (geçti + başarısız + engellendi)
Jeton hesaplaması
Token sayıları LLM API yanıtından çıkarılır. Etkin girdiyi elde etmek için önbelleğe alınmış girdi token'larını toplam girdi token'larından çıkarırız; bu, yalnızca yeni işlenmiş token'ları yansıtır. Çıktı token'ları asla önbelleğe alınmaz, bu nedenle değişmeden kalırlar.
Son toplama
Son kıyaslama puanı, önceki aşamalardan elde edilen sonuçların birleştirilmesiyle hesaplanır: Nihai Puan = (0,7 × backend_overall) + (0,3 × ui_overall) Arka uca daha yüksek bir ağırlık atıyoruz çünkü API seviyesindeki mantık hataları genellikle ön uçtaki herhangi bir başarıyı geçersiz kılar.
Görev örneği
Görev 6: Yardım masası bilet sistemi
6. Görev, karmaşık bir müşteri destek ekosisteminin geliştirilmesine odaklanmaktadır. Birincil amaç, iş kurallarını ve güvenlik sınırlarını sıkı bir şekilde uygularken müşteriler ve destek temsilcileri arasındaki iletişimi düzenleyen bir platform oluşturmaktır. Bu görev, bir temsilcinin tam yığınlı bir ortamda çok kullanıcılı durum makinelerini, veri izolasyonunu ve çoklu iş parçacıklı iletişimi yönetme yeteneğini değerlendirir.
Bu görev, aşağıdaki özelliklere sahip bir yardım masası sistemi oluşturmayı gerektiriyordu:
- Müşteriler (soru gönderme/yanıtlama) ve Temsilciler (yönetim/çözüm) için ayrı yetkilendirmeler.
- Yasadışı geçişleri önleyen ve role özgü eylemleri zorunlu kılan katı bir durum iş akışı.
- Sistem bütünlüğünü korumak için yetkisiz kaynak isteklerinin 403 yerine 404 döndürmesini sağlayan gelişmiş veri izolasyonu.
- Müşteri temsilcisi ile müşteri arasında sorunsuz etkileşim sağlayan kronolojik yanıt sistemi.
- FastAPI tabanlı bir arka uç, duyarlı Vite destekli bir ön uç (React/Vue/Svelte) ile birleştirilmiştir.
- Belirli shell komutları aracılığıyla tekrarlanabilir kurulum, anında sistem aktivasyonu sağlar.
Görev 6 dokümantasyonunu GitHub'da inceleyebilirsiniz.
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.