Terminal-Bench'te yapılan denetim, hataların %30'unda kusur buldu; agent doğruluğunu 10 puandan fazla kaydırdı

Terminal-Bench hakkındaki dev.to'daki bir yazı, kodlama agent benchmark'larının kendi kendine yozlaştığı savını ortaya koyuyor: görevler değiştiği için değil, modeller gerçekten doğru olan çözümler keşfettikçe otomatik doğrulayıcıların bunları reddetmesi nedeniyle. Önerilen çare, benchmark değerlendirmesini sabit bir veri kümesi gibi değil, sürekli bakım yapılan bir kod tabanı gibi yürütmek.

Bu sayılar Terminal-Bench 2.0'dan geliyor; 2.0, kapsamlı insan ve LM destekli incelemelerin ardından yayınlandı. Sonraki bir denetim, benchmark'ın yaklaşık %30'unda yine de sorunlar buldu ve yazıya göre bunların düzeltilmesi ölçülen doğruluğu 10'dan fazla puan kaydırdı ve sıralama tablosundaki konumları en fazla üç basamak oynattı. Yazarın argümanı, bunun orijinal sürümdeki bir özensizliği yansıtmadığı — bir benchmark'ın basitçe yazılım gibi davrandığı ve bunun gerektirdiği tüm bakım yükünü taşıdığı yönünde.

Benchmark'lar nasıl bayatlar

Yazı, bu yozlaşmayı birbirini güçlendiren üç katmana ayırıyor. Birincisi, doğrulayıcılar bayatlar: bir agent, beklenenden farklı düzenlenmiş doğru bir çözüm üretebilir — tek bir dosya düzeni varsayan bir denetleyici, başka bir şekilde yazılmış eşdeğer kodu başarısız sayar. İkincisi, altyapı kayar: harness'ler değişir, bağımlılıklar güncellenir ve timeout varsayımları gerçeğe uymaz hale gelir; örneğin 60 saniyelik yürütme üzerine tasarlanmış bir görev, agent daha fazla yol keşfettiği için artık 120 saniye gerektirebilir. Üçüncüsü, spesifikasyonlar belirsizdir: örtük varsayımlar yalnızca modeller uç durumları zorladığında ortaya çıkar; örneğin, yinelenen kullanıcı adlarının hata mı vereceğini yoksa üzerine mi yazılacağını hiç belirtmeyen bir profil oluşturma görevinde her iki davranış da savunulabilirdir, ama doğrulayıcı yalnızca birini kabul eder.

Bu katmanlar birikir. Bayat bir doğrulayıcı yanlış negatifler ürettiğinde, ekipler agent'leri görevi çözmek yerine denetleyiciyi memnun edecek şekilde ayarlamaya başlar ve skor, yeteneği değil doğrulayıcıya uyumu ölçer hale gelir.

CI'yı model alan bir onarım hattı

Terminal-Bench'in cevabı, yazılım CI/CD'sini yansıtan bir iş akışı. Görevler, doğrulayıcılar, agent izleri ve oracle kontrolleri, etiketlenmiş sürümlerle bir Git deposunda tutulur; böylece geçmiş karşılaştırmalar, kayan bir "en son" işaretçisi yerine commit hash'lerine başvurur. Kullanıcılar, bir agent doğrulamada başarısız olan geçerli bir çözüm ürettiğinde rapor açar; izi, başarısız testi ve çözümün neden doğru olduğuna dair insan açıklamasını ekler. Herhangi bir onarım birleşmeden önce, otomatik bir oracle kontrolü güncellenmiş doğrulayıcıyı saklanan agent çıktıları üzerinde yeniden oynatır ve kararı değişen her durumu işaretleyip insan incelemesine gönderir. Ardından bir bakımcı onaylar, birleştirir ve yeni bir sürüm çıkarır; eski sürüm erişilebilir kalır.

Somut olarak, hattın beş aşaması vardır: agent'i çalıştır ve stdout, stderr, dosya sistemi değişiklikleri ile API çağrılarını yakala; doğrulayıcıyı çalıştır; izi içerik adresli bir anahtarla object storage'da sakla; bildirilen sorunları görev spesifikasyonuna göre triyaj et; ve onarımları geriye dönüş için geçmiş izlere karşı doğrula. Bir iz ve benchmark sürümü verildiğinde değerlendirme deterministik olduğu için, doğrulayıcılar agent kotası harcamadan eski izlere karşı yeniden çalıştırılabilir — bir doğrulayıcı değişikliğinin geçmiş sonuçlardan hangilerini etkileyeceğini bilmeyi mümkün kılan da budur.

Kaynak bütçeleri soruyu değiştirir

Yazı ayrıca zaman ve kaynak limitlerini spesifikasyonun bir parçası olarak yeniden çerçeveliyor. Yazıya göre, duvar saati limitini 60 saniyeden 120 saniyeye çıkarmak, GPT-4o'daki 20 puanlık doğruluk açığını kapattı ve GPT-4o mini'deki 30 puanlık açığı 5 puana indirdi. Bu bir hata değil: benchmark, bir agent'in bir bütçe içinde neler yapabildiğini ölçer, sınırsız zamanla değil; dolayısıyla timeout'u değiştirmek soruyu değiştirir. Token bütçeleri, API rate limitleri ve bellek üst sınırları benzer davranır ve yazı, bunların görevlerle birlikte sürümlendirilmesi gerektiğini savunuyor — aksi halde altı ay önceki bir sıralama tablosu girişi farklı limitler altında çalışmış ve karşılaştırılamaz olmuş olabilir.

Sürekli yaklaşımın başarısızlık modları

Sürekli bakım kendi risklerini de getirir: sürüm çoğalması (her agent'i her yeni sürümde yeniden çalıştır ya da ayrı sıralama tabloları bak), geçmiş iz derlemi temsilci olmadığında geçerli onarımları reddedebilen kırılgan oracle kontrolleri, incelemelerden daha hızlı büyüyen bakımcı kuyrukları ve ekipleri yetenek yerine sıralama kovalamaya teşvik eden sıralama tablosu dalgalanması. Önerilen hafifletme, onarımları üç aylık sürümler halinde toplamak ve sürekli hat arka planda çalışırken resmi karşılaştırmalar için kararlı bir donmuş sürüm tutmaktır.

İzleme ve izolasyon

Bayatlamada hata ayıklamak üç katmanda metrik gerektirir: görev başına geçme oranı, yürütme süresi ve token tüketimi — ani bir geçme oranı düşüşü doğrulayıcıya, çalışma zamanı sıçramaları altyapı kaymasına işaret eder; doğrulayıcı düzeyinde yanlış pozitif ve yanlış negatif sayıları; ve geçerli çıktıların reddedildiğine işaret edebilen tekrarlanan yeniden denemeler gibi agent düzeyi davranışlar. Yazı, bir görevin geçme oranı sürümler arasında 10 puandan fazla düştüğünde otomatik olarak inceleme sorunu açan bir dashboard tanımlıyor. Harness güvenilmeyen agent kodu yürüttüğü için, ağ erişişi olmayan geçici container'larda çalışır; dosya sistemi yazmaları sandbox'lı bir dizinle sınırlanır ve CPU ile bellek üstten sınırlanır.

Neden önemli

Terminal-Bench rakamları, kimse görevlere dokunmasa bile benchmark geçerliliğinin aşındığını gösteriyor. Modelleri değerlendiren herkes için pratik çıkarımlar şunlar: benchmark sürümlerini sabitlemek, kaynak bütçelerini sonuçların yanında kaydetmek ve doğrulayıcılar onarıldığında geçmiş çalıştırıların yeniden doğrulanabilmesi için izleri arşivlemek. Agent geliştiren ekipler için başarısız bir benchmark görevi, agent'ten çok doğrulayıcıyı suçluyor olabilir. Daha geniş açıdan, bir sıralama tablosu skoru, arkasındaki bakım süreci kadar güvenilirdir.