Yapay Zekâ Kodlama Ajanları Nasıl Karşılaştırılır: Hız, Maliyet ve Çalışan Kod
Hızlı token üreten bir kodlama ajanı, görevi mutlaka hızlı bitiren ajan değildir. İlk yamayı üretirken daha az, hataları düzeltirken, araç çağrılarını tekrarlarken veya bir insanın sonucu onarmasını beklerken daha çok zaman harcayabilir.
Pratik bir karşılaştırma için tamamlanan işi ölçün: istenen davranış çalıştı mı, ne kadar sürdü ve tüm denemeler ne kadara mal oldu?
Bu, token hızını önemsiz kılmaz. Onu sonucun yerine geçen bir ölçü olmaktan çıkarıp daha büyük bir iş akışının bileşeni yapar.
Aynı görevle ve açık bir başarı tanımıyla başlayın
Ajanları çalıştırmadan önce kabul ölçütlerini yazın. “Çalışan bir sayfa geliştir” ifadesi, başarısızlığı başarılı bir gösterim olarak yeniden yorumlamak için fazla alan bırakır.
Daha yararlı bir görev; formun klavyeyle gönderilmesini, doğrulama hatalarını göstermesini, dar ekranda kullanılabilir kalmasını ve mevcut URL’yi korumasını isteyebilir. Değerlendirici yalnızca ajanın dosya ürettiğini doğrulamakla kalmamalı, bu davranışları denemelidir.
Bir depo hatasında kusuru yeniden üretin ve düzeltilmiş davranışın nasıl olması gerektiğini tanımlayın. Uygun yerlerde etkilenmemesi gereken davranışlar için regresyon kontrolleri ekleyin. Ajanın son açıklamasını geçme koşulu olarak kullanmayın.
Sonuca dayalı bu yaklaşım yerleşik kıyaslamalarda da görülür. SWE-bench değerlendirme rehberi , üretilen yamaların depolara uygulanmasını ve testlerin Docker tabanlı bir ortamda çalıştırılmasını anlatır. Bu, o görevlerde başarıya somut bir anlam verir. Aynı puanın her tarayıcı iş akışını veya her özel kod tabanını öngördüğünü göstermez.
Yalnızca model adlarını değil, yapılandırmaları karşılaştırın
Bir kodlama ajanı dil modelinden ibaret değildir. Araçları, talimatları, bağlam yönetimi, izin politikası ve yeniden deneme stratejisi sonucu değiştirebilir.
En azından şunları kaydedin:
| Öğe | Neden önemli? |
|---|---|
| Model kimliği ve mevcut sürüm | Ortak bir ürün etiketi değişmiş bir modeli gizleyebilir |
| Ajan ve araç sürümleri | Çevresindeki yürütme sistemi modelin yapabileceklerini etkiler |
| Başlangıçtaki depo anlık görüntüsü | Farklı girdiler farklı görevler yaratır |
| Talimatlar ve bağlam | Aksi hâlde bir ajan ek yönlendirme almış olabilir |
| Deneme ve süre sınırları | Sınırsız tekrar, tek denemeyle karşılaştırılamaz |
| Önbellek ve yürütme koşulları | Yeniden kullanılan bağlam, bağımlılıklar veya sonuçlar süreyi ve maliyeti değiştirebilir |
| İnsan müdahaleleri | Onarılmış bir sonuç, bağımsız tamamlanmış görevden farklıdır |
Ürünler arasında özdeş bir düzen her zaman mümkün değildir. Eşitsiz bir karşılaştırmayı kontrollü diye tanımlamak yerine farkları bildirin.
Yalnızca üretim hızını değil, uçtan uca süreyi ölçün
Şu ölçümleri ayrı tutun:
- İlk yanıta kadar geçen süre: kullanıcının herhangi bir çıktı gelmeden önce beklediği süre.
- Üretim hızı: belirtilmiş bir ölçüm yöntemiyle saniyede üretilen token sayısı.
- Uçtan uca görev süresi: denemenin başlangıcından sonuç doğrulanana veya süre sınırı dolana kadar geçen süre.
- İnsan incelemesi ve onarım süresi: ajanın kendi çalışmasından sonra gereken emek.
Araç yürütme, derlemeler, testler, tekrarlar ve açıklama istekleri toplam süreye hâkim olabilir. Etkileşimli işlerde kısa bir ilk yanıt, doğru sonuca ulaşma süresini azaltmadan deneyimi iyileştirebilir.
Zamanlayıcınızın neleri kapsadığını belirtin. İnsan incelemesi ayrı izleniyorsa sonucu kullanmak için gereken toplam emeği anlatırken onu sessizce dışarıda bırakmayın.
Başarısız denemeleri maliyete katın
Sabit bir değerlendirme grubu için yararlı bir betimleyici ölçü şudur:
Başarılı görev başına maliyet = ölçülen toplam grup maliyeti ÷ başarılı görev sayısı.
Başarısız denemeleri de paya dahil edin. Hangi maliyetleri kapsadığınızı açıklayın: model ücretleri, araç ücretleri, yürütme altyapısı ve insan emeği farklı kategorilerdir; sessizce karıştırılmamalıdır.
Bu, bir model sonucu değil, kurgusal bir örnektir:
| Yapılandırma | Denenen görev | Geçen görev | Toplam model ücreti | Geçen görev başına model ücreti |
|---|---|---|---|---|
| Ajan A | 5 | 3 | $1.20 | $0.40 |
| Ajan B | 5 | 5 | $1.50 | $0.30 |
Bu hesaplamada Ajan A’nın toplam grup maliyeti daha düşük, başarılı görev başına maliyeti daha yüksektir. Bu Ajan B’yi her durumda daha iyi yapmaz: örneklem küçüktür; başka görevler veya ölçülmeyen maliyetler hakkında bir şey söylemez. Hiçbir görev geçmezse başarı başına sonlu bir maliyet sunmak yerine sıfır başarıyı ve harcamayı bildirin.
Başarısızlıkları koruyun ve nedenlerini ayırın
Bağımsız denemeler arasında görev durumunu sıfırlayın ve açıklanan sınırlar içindeki her denemeyi kaydedin. Yalnızca en iyi görünen koşuyu tutmayın veya bir yapılandırmaya sessizce ek ipuçları vermeyin.
Yamaları, araç izlerini, test çıktılarını ve ilgili çalışma zamanı kanıtlarını saklayın. Başarısız altyapı kurulumu ile istenen davranışı bozan bir yama farklı gözlemlerdir. İkisini de bildirin; sırf elverişsiz olduğu için hiçbiri sonuçlardan kaybolmamalıdır.
SWE-bench rehberi, çözülemeyen görevlerle değerlendirme hatalı örnekleri ayırarak ve inceleme için gereken günlükleri belgeleyerek bu farkı raporlamasında açıkça ortaya koyar.
Etkileşimli özelliklere doğrudan etkileşim kontrolleri ekleyin. Geçen bir birim testi, gerçek kullanıcının tarayıcıda iş akışını tamamlayabildiğini kanıtlamaz.
Herkese açık puanlarla kısa liste oluşturun
Bir sıralama, değerlendirdiği görevler ve koşullar hakkında yararlı kanıttır. Sonucunu işinize uygulamadan önce veri kümesini, ajan yapılandırmasını, puanlama yöntemini, deneme politikasını ve mevcut yeniden üretim malzemesini kontrol edin.
Sonra kendi iş akışınızdan küçük bir temsili görev kümesini test edin. Sitenin araç kullanımı değerlendirme protokolü bu görevleri tanımlamaya bir örnek verir. Ölçülmüş model sonuçları değil, hazırlanmış bir protokoldür.
Pratik soru, hangi ajanın adının yanında en büyük sayı olduğu değildir. Hangi yapılandırmanın işinizi kabul edilebilir bir bütçeyle güvenilir biçimde tamamladığı ve başkasının sonucu kontrol edebileceği yeterli kanıtı sağladığıdır.
