Senior SWE-Bench: kıdemli mühendis düzeyi ajanları değerlendirmek için açık kaynak benchmark

 (senior-swe-bench.snorkel.ai)
3 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Senior SWE-Bench, kodlama ajanlarını aşırı derecede düzenlenmiş junior görevlerle değil, gerçek kıdemli mühendislerin üstlendiği özellik geliştirme, hata düzeltme ve performans sorunlarına daha yakın şekilde değerlendirmeyi amaçlayan bir benchmark'tır
  • Özellik görevleri, doğal dil mesajı gibi okunan gerçekçi talimatlar kullanır ve gönderilen çözüme göre davranış testleri üreten bir doğrulama ajanıyla değerlendirme güvenilirliğini artırır
  • Hata görevleri, kullanıcı raporlarından başlayıp servis çalıştırma, loglar, profiling verileri ve yeniden üretim adımları gibi çalışma zamanı incelemesi gerektiren PR'lerden alınır
  • Puanlama, yalnızca çalışma zamanı doğruluğunu değil, kod tabanı pratiklerine dayalı kalite ölçütlerini de birleştirerek tasteful solve'u değerlendirir; talimatlarda yer almayan önemli pratikler de doğrulama kapsamına girebilir
  • Liderlik tablosundaki en iyi model olan Claude Opus 4.8 bile Mini-SWE-Agent max ayarında yalnızca pass@1 %24,0 seviyesine ulaşıyor; yani üst düzey modeller bile kıdemli seviye doğruluk ve taste içeren çözümlerde %75'ten fazla oranda başarısız oluyor

Gerçek PR'lere daha yakın görev tasarımı

  • Senior SWE-Bench, kodlama ajanlarının pratikte kıdemli mühendis gibi kullanılması ama junior düzey görevlerle değerlendirilmesi arasındaki boşluğu azaltmayı hedefleyen bir benchmark'tır
  • Görevler, kütüphanelerden çok servisli uygulamalara kadar çeşitli depolardaki PR'lerden alınır ve her depoda yüzlerce commit yazmış mühendislerin hazırladığı PR'ler hedeflenir
  • Başlıca görev türleri iki kola ayrılır
    • Çok aşamalı ve çoklu stack'e yayılan özellik PR'leri
    • Kayda değer çalışma zamanı incelemesi gerektiren hata ve performans PR'leri
  • Açık görev sayısı 50, kapalı görev sayısı da 50'dir
  • Dahil edilen depo örnekleri şunlardır

Özellik görevleri: doğal dile yakın talimatlar

  • Özellik görevleri, aşırı parçalanmış gereksinimler yerine doğal dil mesajı gibi okunan gerçekçi talimatlar kullanır
  • Bu tür görevleri istikrarlı biçimde değerlendirmek için bir doğrulama ajanı (validation agent) kullanılır
    • uzmanların tasarladığı recipe'ler kullanılır
    • gönderilen çözüme göre davranış testleri yazılır
  • Talimatlar, doğal ajan iletişimini yansıtır ve uzunluk medyanı SWE-Bench Pro'nun %31'i düzeyindedir

Hata görevleri: kullanıcı raporundan çalışma zamanı incelemesine

  • Hata görevleri, zorlu kullanıcı raporlarını yansıtarak basit kod değişikliklerinden çok kök neden araştırması ve yeniden üretim süreci gerektirir
  • Görevler şu tür işleri içerebilir
    • servis başlatma
    • ince çalışma zamanı sorunlarını debug etme
    • logları inceleme
    • profiling verilerini kullanma
    • yeniden üretim adımlarını takip etme
  • Kaynakları, çözüm sürecinde kayda değer çalışma zamanı incelemesi gerektiren PR'lerdir

Değerlendirme ölçütleri: doğruluk ve taste birlikte ölçülüyor

  • Senior SWE-Bench, çalışma zamanı doğruluk testlerini çeşitli kalite ölçütleriyle birleştirerek tasteful solve puanı üretir
  • Kalite ölçütleri, gözlemlenen kod tabanı pratiklerine dayanır
  • Doğrulayıcılar ve doğrulama ajanı, talimatlarda yazmasa bile kod tabanında önemli olan pratikleri test edebilir
  • Liderlik tablosundaki solve koşulları şu maddeleri içerir
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Liderlik tablosu: en iyi modellerde bile düşük pass@1

  • Liderlik tablosu sonuçları Tasteful solve rate(pass@1) ölçütüne göre gösterir
  • Üst sıralardaki sonuçlar şöyledir
    • Claude Opus 4.8, Mini-SWE-Agent max: %24,0
    • Claude Sonnet 5, Mini-SWE-Agent max: %19,4
    • GPT-5.5, Mini-SWE-Agent xhigh: %16,0
    • Claude Opus 4.7, Mini-SWE-Agent max: %14,1
    • GPT-5.4, Mini-SWE-Agent xhigh: %14,0
    • GLM-5.2, Mini-SWE-Agent max: %12,5
    • Kimi K2.6, Mini-SWE-Agent default: %8,2
    • Claude Sonnet 4.6, Mini-SWE-Agent high: %8,2
    • Gemini 3.1 Pro, Mini-SWE-Agent high: %6,1
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: %3,0
  • En güçlü frontier modeller bile kıdemli seviye doğruluk ve taste gerektiren görevlerin %75'inden fazlasını tamamlayamıyor

Görev kapsamı ve benchmark özellikleri

  • Görev türleri feature, bug, perf, migrat olarak işaretlenir
  • Stack'ler arasında Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust ve TS FE yer alır
  • Özellik görevleri birden fazla servise yayılabilir ve görev başına ortalama 11 dosya değiştirilir
  • Uzun iş akışları gerektirecek şekilde tasarlanmıştır; bu nedenle en güçlü ajanlar bile yüzlerce adım gerektirir
  • Referans çözümlerin SLOC'u ve dosya sayısı üç benchmark'ta da aynı yöntemle ölçülür
  • Talimat uzunluğu, harness boilerplate hariç tutulacak şekilde hesaplanır
  • Diğer benchmark'lardaki token ve adım sayıları, ilgili benchmark'ların kendi raporladığı ölçütlere dayanır

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Twitter’da gördüğüm kadarıyla Tsinghua University’deki bir makine öğrenmesi dersinde, öğrencilere mümkün olduğunca çok LLM’in başarısız olacağı bir quiz hazırlatma sınavı yapılmış
    Böyle bir benchmark oluşturup buna ELO puanı vermek nasıl olur diye düşünüyorum. Modellerin birbirleriyle karşı karşıya gelip soru, hata ya da eksik uygulanmış özellikler ortaya koyduğu; karşı tarafın da bunları yanıtladığı, düzelttiği ya da tamamladığı bir yapı

    • Buna üretici çekişmeli ağ (GAN) denebilir :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • Sorun, dejeneratif stratejilerin nasıl engelleneceği. Örneğin bir SHA256 hash’i verip özgün girdiyi bulmasını istersen, imkânsız bir problemi çok kolay üretebilirsin
      Derste en az bir LLM’in cevap verebilmesi gerektiği gibi bir kural konabilir ama bire bir karşılaşmada bunun nasıl çözüleceğini bilmiyorum
    • O Tsinghua değil, sanırım Fudan idi

  • Bu benchmark’ın zaman içinde ilgili kalmayı nasıl sürdüreceğini merak ediyorum
    Benchmark açık kaynak projelerde özellik geliştirmeye dayanıyorsa, LLM o değişiklikleri eğitim verisinde görmüş olabilir ve aynı ya da biraz değiştirilmiş bir cevap üretebilir
    Öte yandan benchmark’a yalnızca modelin bilgi kesim tarihinden sonraki kod değişikliklerini koyarsan, T zamanı ile T+1 zamanındaki problemler farklılaşır ve zaman içindeki karşılaştırılabilirlik azalır

  • Staff SWE Bench olsaydı, LLM’in en başta bunu yapması gerekip gerekmediğinden şüphelenir, projenin tamamını sorgular, kodun birleştirilmesini reddeder ama silmeye memnuniyetle yanaşırdı

    • Şaka gibi geliyor ama gerçekte reddetmenin işin özünde olduğunu düşünüyorum. Basitçe “olmaz, git” demek değil; bir adım geri çekilip büyük resmi istemek, organizasyonun tamamının o projeye uzun vadede ihtiyaç duyup duymadığını ve onu taşıyıp taşıyamayacağını görmek, işe başlamadan önceki asgari süreç gibi
      LLM’ler de bunu yeterince, hatta belki bizden iyi yapabilir gibi geliyor; ama buna özel olarak eğitilmeleri gerekir. Yine de bu eğitim verisinin nereden bulunacağını pek kestiremiyorum
    • Principal sürüm de benzer olurdu ama ayrıca izin verilen tek yaklaşımın önceki şirkette yapılan yöntem olduğunu söylerdi

  • Bu, neden hep Opus 4.8’in GPT 5.5’ten çok daha önde olduğunu hissettiğimi açıklıyor. Eksik gereksinimleri alıp projeye uygun makul bir şekilde boşlukları doldurma becerisi gerçekten iyi

    • En başta neden eksik gereksinimler verildiğini anlamıyorum. İki model de varsayımları ve uç durumları sorgulamada, netleştirme soruları sormada iyi; ama sanki bunu yalnızca açıkça istendiğinde yapıyorlar. Örneğin “beyin fırtınası” gibi tekniklerle istenince
      Bence iki değerlendirme yöntemi de modeli tüm varsayımlardan şüphelenmeye ve soru sormaya yeterince teşvik etmiyor. Belki kullanıcıyı yorabileceği içindir ama bu aşamanın neredeyse zorunlu olduğunu düşünüyorum
      GPT-5 ailesinin tamamı çok titizdi; kod incelemesi ve matematik için faydalı oldu. Benim işim için önemli ama “estetik” kod yazarken engel oluyor gibi. Mesela olasılığı düşük uç durumların bile hepsine karşı savunma yazmaya çalışması gibi
      Esneklik ile talimatlara uyma arasında da bir ödünleşim var gibi. Benim deneyimime göre Opus bazen talimatları görmezden geliyor ama boşlukları daha iyi dolduruyor; GPT-5.5 ise talimatları daha iyi izliyor ama bu yüzden daha katılaşıyor gibi
    • En iyi benchmark, kendi yaptığın benchmark’tır
      Benim deneyimime göre Opus ezici biçimde önde ya da daha iyi değildi. Her hâlükârda GPT 5.5’te Instant, Medium, High, Extra High, Pro var; tabloda Extra High ile karşılaştırılmış gibi görünüyor, Pro ile karşılaştırmak gerekmez mi diye düşünüyorum
    • Garip bir balonun içinde mi yaşıyorum bilmiyorum ama bana göre GPT 5.5, Opus 4.8’den çok daha iyi. Nasıl değerlendirdiğinizi, ne tür işler yaptığınızı merak edecek kadar
      Frontend geliştirme ve tasarım gibi Opus’un daha iyi olduğu belirli işler var, ama onun dışında 5.5 düpedüz üstün
    • Sürekli daha az açık yazan vibe coder için daha iyi olabilir. Ama sorun şu: model hangi noktadan itibaren “gereksinimler yeterince açık değil” diye düşünüp, aslında yeterince belirtilmiş spesifikasyonun ötesine geçen bir uygulama yapmaya başlıyor?
    • Ben de aynı gözlemi yaptım. Opus 4.8 çok daha olgundu; içine sinmeyen isteklerde geri soru soruyor ya da itiraz da ediyordu. Buna karşılık GPT 5.5 memnuniyetle kabul edip söyleneni yapıyor, ama çoğu zaman birkaç kez yeniden yönlendirmek gerekiyordu
      4.8 de birden fazla prompt gerektiriyor ama çıktı kalitesi çok daha yüksek ve daha fazla içgörü veriyor
      Ama Fable 5 bambaşka bir varlık

  • Şu an en iyi çözme oranı Opus 4.8 için %24 ise, yetkin bir insanın yaklaşık kaç puan alması beklenir?

    • Muhtemelen en iyi modelin kullandığı şeyleri insan da kullanabileceği için, ondan daha yüksek olur diye düşünüyorum
      Tersinden, model insanları istediği gibi çalıştırabilseydi daha yüksek puan alır mıydı diye de merak ediyorum
    • Bu problemlerin hepsinin zaten çözülmüş olduğunu varsayarsak %100 gibi. Elbette aynı kişinin hepsini çözdüğü anlamına gelmez; ama modelin çeşitli codebase’lerde iyi olması gerekirken insan tek bir üründe uzmanlaşıp onu öğrenebilir
      Bir ürün üzerinde çalışmaya alışkın bir bireyle karşılaştırmanın adil olduğunu düşünüyorum
      Fable’ın nasıl çıkacağını daha çok merak ediyorum

  • Senior rolünün değeri, bilinen çözümleri ve stratejileri yeni problemlere uygulamaktır. Hiç değişmeyen bir benchmark’ın uzun süre yeni bir meydan okuma olarak kalıp kalamayacağını bilmiyorum
    İyi bir benchmark, önce TRIZ’in tamamını kullanarak dev bir problem yığını oluşturmalı, ardından yapay zekanın en iyi çözümü çıkarıp çıkaramadığına bakmalı

  • Snorkel’den yeni bir açık benchmark gelmesi sevindirici. Orada oldukça incelikli işler yapıyorlar

  • Sonnet 5’in Opus 4.8’e epey yaklaşması ilginç

  • Bu yöntem işe yararsa teknik mülakatların da otomatikleştirilebileceği anlamına gelmez mi?

  • LLM’e “You are a senior SWE-Bench reviewer, make no mistakes.” gibi ifadelerle öznel yargı yaptırma yaklaşımı temelden kusurlu görünüyor
    Uygulanabilirliği korurken daha iyi yöntemin ne olduğunu bilmiyorum

    • Daha önemlisi, bunun gerçekten işi engelleyebilmesi. LLM hata yaptığında bunu kabul edip düzeltmek yerine küçültüp geçmeye yönlendirilebilir
    • Bu yöntem aslında LLM’in nasıl davranması gerektiğine dair bağlam yerleştirmek. “senior reviewer” istenen yanıt tarzı, “SWE-Bench” ise LLM’in çalışacağı bağlam ve alan
      Sistem prompt’larında yaygın bir yöntem ve yanıtın çerçevesini belirliyor
      Örneğin “programlama hakkında bir denizci şarkısı yazan korsan”, “fizik makalesi yazan haber muhabiri”, “PostgreSQL’i kusursuz bilen kıdemli yazılım mühendisi” dersen her biri farklı yanıt üretir
      İlki için Wellerman tarzında “There once was a program that was set to C ...” gibi bir cevap gelebilir
      Yine de “make no mistakes” kısmı şüpheli. Bu ifadeyi ekleyip çıkardığında sonuçları karşılaştırmak ve aynı istenen davranışı elde etmenin başka yollarını da denemek ilginç olurdu
    • “make no mistakes” nasihati oldukça komik görünüyor. YouTube’da da zaten çok alaya alındı ama işe yarayabilecek bir mekanizma hayal etmek kolay. Örneğin basitçe “çalışmanı gözden geçir” şeklinde yorumlanabilir
      Tabii bu tür karşılaştırmalı ölçümleri herkese açık biçimde yapıp makul bir sonuca varmayı sağlayan bir yer var gibi görünmüyor