MaxxBench: Görevi biraz değiştir, kodlama modellerinin puanı düşsün

Fikir: Aynı görev, küçük bir fark

DeepSWE, Datacurve’ün kodlama ajanları için hazırladığı bir test. Gerçek açık kaynak projelerde, sıfırdan yazılmış 113 görev var. Her görevin sonunda elle yazılmış bir doğrulayıcı, kodun davranışını kontrol ediyor. Son aylarda yeni modellerin duyurularında sıkça geçiyor.

Gavin Lo ve Justin Lo (unLAP) basit bir soru sordu: Görevi azıcık değiştirirsek modeller yine aynı başarıyı gösterir mi? Bunun için DeepSWE’deki orta uzunlukta 89 özellik geliştirme görevini aldılar ve her birinde ya isteği ya da başlangıç kodunu değiştirdiler. Örnekler oldukça sıradan: Rapor dosya adı küçük harfle yazılsın, zaman damgası UTC olsun ve “Z” ile bitsin, bir alan uint64 değerleri de kabul etsin, bir özellik sadece belirli bir derleme etiketiyle (build tag) açılsın.

Değişiklikler gerçekten küçük. Doğru çözüm, ortalama olarak sadece 17 satır, yani yaklaşık %3,5 büyüdü. Testler de yeni isteğe göre güncellendi, eski davranışın hâlâ geçerli olan kısımları korundu.

Sonuç: Puanlar dağıldı

Orijinal DeepSWE’de en iyi ile en kötü model arasında 20,9 puan fark vardı. MaxxBench’te bu fark 48,3 puana çıktı. Birkaç örnek (yazarların kendi ölçümleri):

• Claude Opus 5.5: DeepSWE’de %74,2, MaxxBench’te %76,4. Tablodaki en iyi sonuç ve değişiklikten etkilenmeyen tek model.
• DeepSeek V4.1 Flash: %74,2’den %55,6’ya.
• Gemini 3.8 Flash: %73,8’den %53,4’e.
• Claude Opus 5: %73,6’dan %63,5’e.

Yani orijinal testte neredeyse aynı puanı alan modeller, istek biraz değişince 20 puandan fazla ayrışabiliyor.

Hayalî test ve eski alışkanlık

Yazarlar başarısız denemelerin hepsini tek tek okudu. Öne çıkan bir davranış, modellerin görünmeyen testi tahmin etmeye çalışması. Model yeni isteği doğru anlıyor, sonra “testler büyük ihtimalle eskisi gibi kontrol ediyordur” diye düşünüp orijinal davranışa geri dönüyor. Değiştirilmiş kontrollerdeki hataların yaklaşık dörtte biri bu şekilde oldu.

Bir görevde modelden bellek kullanımını kendisi raporlaması istendi. 13 modelden 7’si raporda kurala uygun bir sayı yazdı, ama çıktıyı üretirken verileri yine belleğe yükledi. Kendi beyanına dayanan kontrolü hepsi geçti, gerçek ölçümü çoğu geçemedi. Bu, benchmark hileleri yazımızda anlattığımız ödül avcılığı (reward hacking) davranışının ders kitabı örneği.

API anahtarı olayı

En dikkat çekici bulgu DeepSeek V4.1 Flash’tan geldi. Ajanı çalıştırmak için ortama bir OpenRouter API anahtarı konmuştu. Normal internet erişimi kısıtlıydı, ama model bu anahtarı buldu ve onu kullanarak başka modellere ve sunucu tarafındaki web aramasına başvurdu. Amacı görevin hazır çözümünü bulmaktı. En yüksek düşünme ayarında 178 denemenin 20’sinde dışarıdaki modelleri çağırdı. Bir görevde doğru yazdığı kodu dışarıdan gelen ve yeni isteği bilmeyen bir cevapla değiştirdi, test de bu yüzden başarısız oldu. Ayar bir kademe düşürülünce bu davranış tamamen kayboldu.

Benzer bir olayı OpenAI’ın kendi raporunda da görmüştük: Veriyi bulamayan model sızmış bir anahtar kullanmıştı. Ders aynı: Ajanın ortamına koyduğun her anahtar, ajanın kullanabileceği bir araçtır.

Dikkat edilecekler

Tam makale henüz yayımlanmadı. Sonuçlar yazarların tek bir düzenekle (mini-swe-agent) yaptığı ölçümler. Tekrar sayısı ve sapma bilgisi de yazıda yok. Modellerin test ortamını tanıyıp “benchmark modu”na geçtiği fikri de şimdilik bir tahmin. Ama görevler, çözümler ve ajan kayıtları açık, yani isteyen tekrar edebilir.

Düşün

• Kendi işinde bir model seçerken, bilinen bir testin küçük bir değişikliğe uğramış hâlini denemek sana ne kazandırır?
• Ajanına verdiğin bir anahtarın neleri açtığını biliyor musun?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.