SWE-bench Verified neden artık frontier kodlama yeteneğini ölçemiyor

 (openai.com)
4 puan yazan GN⁺ 2 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Otonom yazılım mühendisliği görevlerinin başlıca göstergelerinden biri olan SWE-bench Verified, frontier model yeteneğini ölçmek için artık büyük ölçüde yetersiz kalıyor
  • Son dönemde en iyi performanstaki artışın %74,9'dan %80,9'a sınırlı kalmasıyla, kalan başarısızlıkların model sınırlarından mı yoksa veri kümesi kusurlarından mı kaynaklandığını ayırt etmek zorlaştı
  • İncelenen 138 problemden %59,4'ünde test tasarımında veya problem açıklamasında ciddi kusurlar tespit edildi; kısıtlayıcı testler ve aşırı geniş testler, işlevsel olarak doğru çözümleri bile eleyebiliyor
  • Açık veri ve kod tabanlarına dayanan bir değerlendirme olduğu için eğitim verisi kirlenmesini önlemek zordu; bazı modeller yalnızca görev açıklaması ya da kimliğiyle gold patch'i neredeyse aynen yeniden üretebildi
  • Bu nedenle SWE-bench Verified skorlarının raporlanması durduruldu ve değerlendirme odağı, kirlenmeden daha az etkilenen SWE-bench Pro ile özel benchmark'lara kaydı

Benchmark artık neden ölçemiyor

  • SWE-bench Verified, otonom yazılım mühendisliği görevlerinde model performansını ölçmek için yaygın biçimde kullanılan standart bir göstergeydi; ancak mevcut düzeydeki frontier model yeteneklerini ölçmek için artık ciddi ölçüde yetersiz
  • Son 6 ayda en iyi performanstaki artışın 74.9%'dan 80.9%'a sınırlı kalması, geriye kalan başarısızlıkların model sınırlarından mı yoksa veri kümesi kusurlarından mı kaynaklandığını ayırt etmeyi zorlaştırdı
  • Yeni analiz, kusurlu testler ile eğitim verisi kirlenmesini temel sorunlar olarak ortaya koyuyor; böylece skorlar, gerçek kodlama becerisinden çok benchmark'a maruz kalma düzeyini yansıtır hale geliyor
  • Bu yüzden OpenAI, SWE-bench Verified skorlarını raporlamayı durdurdu ve diğer model geliştiricilerine de aynı adımı tavsiye ediyor
  • Alternatif olarak kirlenmeden daha az etkilenen SWE-bench Pro öneriliyor; ayrıca yeni, kirlenmemiş değerlendirme ölçütleri de geliştiriliyor

Arka plan

  • Orijinal SWE-bench, 2023'te yayımlandı ve 12 açık kaynaklı Python deposundaki çözülmüş GitHub issue'ları ile bunlara karşılık gelen PR'lerin eşleştirilmesiyle oluşturuldu
  • Her problemde, yalnızca düzeltme öncesi kod tabanı ve issue metni verilir; modelden kod değişikliği üretmesi beklenir ve değişiklik uygulandıktan sonra tüm testlerin geçmesi başarı ölçütüdür
    • Buna, düzeltme öncesinde başarısız olup doğru düzeltmeden sonra geçen testler dahildir
    • Mevcut işlevlerin bozulup bozulmadığını doğrulayan regresyon testleri de birlikte yer alır
  • Orijinal değerlendirmede, doğru düzeltmeleri bile reddeden aşırı derecede spesifik testler, birden fazla yoruma açık yetersiz spesifikasyonlar ve ortam farklarına bağlı olarak başarısız olan testler gibi sorunlar vardı
  • Bunu azaltmak için 2024'te SWE-bench Verified oluşturuldu ve 1.699 problem uzman incelemesinden geçirilerek 500 problemlik bir set hazırlandı
    • Her problem, 3 uzman tarafından bağımsız olarak incelendi

Test tasarım kusurları

  • OpenAI o3'ün 64 bağımsız çalıştırmada da tutarlı biçimde çözemediği 138 problem denetim kapsamına alındı ve her vaka en az 6 deneyimli yazılım mühendisi tarafından bağımsız olarak incelendi
  • Sonuçta 138 problemin %59,4'ünde, test tasarımında veya problem açıklamasında ciddi kusurlar bulundu; bu da görevleri güçlü model ya da insanlar için bile çok zor veya imkânsız hale getiriyordu
  • Denetlenen görevlerin %35,5'i, belirli uygulama ayrıntılarını zorunlu kılan kısıtlayıcı testler içeriyordu
    • Bu durum, işlevsel olarak doğru olan birden fazla çözümün de geçersiz sayılmasına yol açabiliyor
  • Denetlenen görevlerin %18,8'i, problem açıklamasında yer almayan ek işlevleri de talep eden geniş kapsamlı testler içeriyordu
  • Kalan %5,1'de ise bu iki kategoriye açıkça girmeyen başka sorunlar vardı

  • Kısıtlayıcı test vakaları

    • pylint-dev__pylint-4551 örneğinde, PR testi get_annotation fonksiyonunu doğrudan import ediyor; ancak bu fonksiyon adı problem spesifikasyonunda yer almıyor
    • Bu nedenle problem işlevsel olarak doğru çözüldüğünde bile, o belirli fonksiyon adı uygulanmadıysa test import hatasıyla başarısız olabiliyor

  • Geniş kapsamlı test vakaları

    • sympy__sympy-18199, gerçekte #17373, #17377 ve #18212 olmak üzere üç issue'yu birlikte düzelten bir PR'den alınmıştı
    • Ancak SWE-bench Verified görev açıklaması yalnızca #18212'yi kapsadığı için, açıklamaya uygun bir uygulama yapılsa bile diğer iki issue'yu kontrol eden testlerde başarısız olunabiliyor

Kirlenme sorunu

  • SWE-bench Verified, ilgili depo kod tabanları ve sürüm notlarının tümü açık ve yaygın biçimde kullanılıp tartışıldığı için veri kirlenmesini önlemek zor
  • OpenAI, kendi modellerinde de kirlenme işaretleri tespit etti; buna, neredeyse çözülmesi imkânsız görülen 31 görevin GPT‑5.2 tarafından çözülmesi de dahil
  • django__django-14725 örneğinde testler, problem spesifikasyonunda olmayan edit_only parametresini gerektiriyor; GPT‑5.2 ise akıl yürütme sürecinde bu parametrenin Django 4.1'de tanıtıldığını bile doğru şekilde belirtiyor
  • OpenAI, kirlenmenin ciddiyetini değerlendirmek için otomatik bir red-team test ortamı kurdu
    • Her SWE-bench Verified problemi için GPT‑5, GPT‑5.2‑Chat, Claude Opus 4.5 ve Gemini 3 Flash Preview modellerindeki kirlenme olup olmadığını araştırdı
    • GPT‑5'e görev kimliği, açıklama, gold patch ve PR testleri verildi; toplam 15 tur boyunca prompt'ları ve yönlendirme stratejilerini değiştirmesine izin verildi
    • Her turun ardından bir değerlendirme modeli, yeni ortaya çıkan göreve özgü bilgi miktarına göre kirlenmenin ciddiyetini yok~güçlü olarak sınıflandırdı
    • Güçlü kirlenme vakaları, ek bir değerlendirme modeliyle aşırı bilgi sızıntısı açısından doğrulandı ve nihai olarak doğrudan incelendi

Modeller bazında ciddi kirlenme örnekleri

  • GPT‑5.2

    • django__django-11451 örneğinde, kısa bir görev açıklaması parçacığıyla bile tam doğru gold patch çıktı olarak üretildi
    • ModelBackend.authenticate() içinde username is None or password is None olduğunda erken dönüş yapan koşulun yanı sıra dosya yolu ve yöntem adı da yeniden üretildi

  • Claude Opus 4.5

    • astropy__astropy-13236 örneğinde, düzeltilecek dosya yolu astropy/table/table.py, _convert_data_to_col metodu ve diff içindeki satır içi yorumlar bile harfi harfine alıntılandı
    • Yapılandırılmış ndarray'i NdarrayMixin'e otomatik dönüştüren 4 satırlık kod da eksiksiz biçimde yeniden kuruldu

  • Gemini 3 Flash

    • django__django-11099 örneğinde, görev kimliği dışında neredeyse hiç ek bilgi olmamasına rağmen görev açıklaması ve gold patch'in tamamı harfi harfine üretildi
    • Kullanıcı adı doğrulama regex'inin r'^[\\w.@+-]+$' biçiminden r'^[\\w.@+-]+\\Z' biçimine değişmesi ve satır bazlı diff bile yeniden üretildi

Temel dersler

  • Kamuya açık kaynaklardan türetilen benchmark'lar kirlenme riski taşır ve eğitim verisine maruz kalma, skorları fark edilmeden şişirebilir
  • Benchmark'lar herkese açık crawl verilerinden oluşturuluyorsa, model geliştiricileri kirlenme olup olmadığını kontrol eden ek testler yapmalıdır
  • Açık benchmark'lar ve çözümleri de sonuçta eğitim verisine dahil olabilir; bu nedenle hem veri kümesi dağıtım biçiminde hem de eğitim verisi filtrelemesinde özel dikkat gerekir
    • Parola koruması gibi dağıtım kontrol yöntemlerinden söz ediliyor
    • Canary string'lere sıkı uyum gibi filtreleme yöntemleri de anılıyor
  • Otomatik puanlama, önemsiz uygulama farklarından etkilenmeyecek ama aynı zamanda hileli kısayolları da engelleyecek kadar sağlam olmalı; bunu aynı anda başarmak ise son derece zor
  • Bu tür kusurları ortaya çıkarmak için birden fazla turda büyük ölçekli manuel etiketleme gerekti

Bundan sonraki değerlendirme yönü

  • Son birkaç ayda OpenAI, SWE-bench Pro açık değerlendirme verisi sonuçlarını raporlamaya karar verdi ve diğer model geliştiricilerinin de aynı adımı atmasını tavsiye ediyor
  • SWE-bench Pro da kusursuz değil, ancak deneysel olarak SWE-bench Verified'a göre kirlenmeden daha az etkileniyor
    • İç kirlenme doğrulama pipeline'ında bazı kirlenme vakaları bulundu
    • Ancak bunlar SWE-bench Verified'a kıyasla çok daha seyrek ve daha az ciddiydi
    • Hiçbir model, harfi harfine tamamen aynı gold patch'i üretemedi
  • Gelecekte özgün ve özel olarak yazılmış benchmark'lara yatırım yapılmaya devam edilecek
  • GDPVal içinde alan uzmanları görevleri özel olarak yazıyor ve eğitimli değerlendiriciler çözümleri bütüncül biçimde puanlıyor
  • Bu yaklaşım kaynak yoğun olsa da, gerçek yetenek gelişimini ölçmek için giderek daha vazgeçilmez hale geliyor

İlgili okumalar

1 yorum

 
GN⁺ 2 일 전
Hacker News yorumları

  • SWE-bench ortak yapımcılarından biri olarak özetleyeyim: SWE-bench Verified artık %93,9 ile neredeyse doygunluğa ulaştı ve Anthropic tebriki hak ediyor
    Yine de bu seviyeye henüz ulaşamayan ekiplerin hâlâ ilerleme alanı var
    SWE-bench Multilingual ve SWE-bench Multimodal ise henüz doygun değil; Multimodal’ı gelecek ay içinde açık kaynak olarak yayımlamayı planlıyoruz
    Sonuçta tüm benchmark’lar eninde sonunda doygunluğa ulaşıyor; bu yüzden bir sonraki nesil benchmark’ları da üretmeye devam ediyoruz ve https://codeclash.ai/ ile https://algotune.io/ gibi örnekler şimdiden ortaya çıktı

    • Doygunluğa ulaştı diye SWE-bench Verified artık kullanılmasın demiyorum
      Asıl mesele, testlerin önemli bir kısmının hatalı olması ve bu yüzden gerçekte doğru olan çözümlerin bile yanlış diye puanlanabilmesi
      Ayrıca frontier modellerin, sorunların temelini oluşturan PR’ları zaten okuyup ezberlemiş olma ihtimali yüksek
      Hatta bazı sorular, çözümü ezberlememişseniz fiilen çözülemez durumda; örneğin testten geçmek için soruda hiç geçmeyen belirli bir helper fonksiyon adını aynen üretmeniz gereken durumlar var
      Frontier modellerin bunları geçebilmesinin sebebi de büyük ihtimalle o ada ihtiyaç olduğunu hatırlamaları
      Bir sonraki nesil benchmark’lar bunu çözmezse, doygunluk olup olmamasından bağımsız olarak aynı sorun sürecek
    • Makaledeki anlatıma göre %27,6’lık alt küme denetlenmiş ve bunun %59,4’ünde işlevsel olarak doğru gönderimleri reddeden hatalı testler olduğu söylenmiş
      Hesaplayınca 0.191 * 0.594 > 1 - 0.936 çıkıyor; dolayısıyla ya denetlenen alt küme temsili değildi ya da Anthropic yüksek puanı biraz şüpheli bir şekilde aldı diye düşündürüyor
    • SPECint ve SPECfp de tam olarak aynı döngüden geçti
      Benchmark oluşturuldu, doygunlaştı, terk edildi, yenisiyle değiştirildi ve bu tekrarlandı
      Sonunda bu treadmill’in kendisi bir ürün gibi işlemeye başlıyor; çözümünü bilmiyorum ama tarihin tekerrürü gibi geliyor
    • Bu arada alternatif olarak https://SWE-rebench.com da var gibi görünüyor
      Benim anladığım kadarıyla SWE-bench üzerine ilginç bir varyasyon
    • SWE-bench’in kendisinin harika olduğunu düşünüyorum
      Şu anda bu kadar sert incelenmesi de yaygın biçimde benimsenmiş ve başarılı olmuş olmasının doğal bir sonucu gibi duruyor

  • Yeni çıkan herhangi bir benchmark’ın çok hızlı biçimde eğitim verisine gireceği ve neredeyse anında eskiyeceği fazlasıyla açık görünüyor
    Sırf pazarlama için bile belirli bir benchmark’a göre optimizasyon yapma teşviki hep olacak; eğitim cutoff’u olsa bile genelde yayımlanma zamanı ile arasında yalnızca 3-6 ay fark kalıyor
    Bu yüzden coding benchmark’larındaki asıl zorluk, mevcut benchmark’ları yeniden kullanmadan, eğitim verisinde kesinlikle bulunmadığı garanti edilen tamamen yeni problemler üretmek
    Bu açıdan bakınca modelin çıkışından önce hazırlanmış benchmark’ların o modelin performansını temsil ettiğini söylemek zor; küçük iyileştirmeleri pazarlamak için veriyi içeri sızdırmaya yönelik finansal teşvik de çok büyük
    Dürüst olmak gerekirse pazarlama materyallerinden benchmark’ları tamamen çıkarmak ve modelin kendisinin konuşmasına, topluluğun da karar vermesine izin vermek gerekir; ama işin içinde para olan şirketlerin bunu asla yapacağını sanmıyorum

    • Bu yüzden Zork bench’i yaptım
      Metin tabanlı macera oyunu Zork, LLM eğitim verisinin içinde yer alıyor ve deterministik olduğu için normalde kolayca oynanıp bitirilmesi gerekir
      Ama pratikte öyle olmuyor; Zork bench de bunun nedenini anlamayı hedefliyor
      https://github.com/mnky9800n/zork-bench
    • “Topluluk karar versin” denince, önce hangi topluluktan söz ettiğimiz bile belirsiz
      İçinde 10 yılı aşkın süredir LLM kullanan uzmanlar da var, hayatında kod yazmamış vibe coder’lar da; internette GPT 5.5’i kurtarıcı gibi görenler de var, 5.4’ten daha aptal bulanlar da
      Ben de her yeni model için kendi gizli benchmark’larımı hazırlayacak vakte sahip değilim; o yüzden genelde private veya semi-private benchmark’lara dayanarak ne kadar iyileşme olduğunu tahmin edip sonra abone oluyor ve bizzat deniyorum
      En azından Reddit’teki rastgele kullanıcıların ya da botların yarattığı havadan biraz daha güvenilir
    • Coding benchmark’larını yeniden anlamlı kılmanın kolay bir yolu, model bağlamına önce 200 bin token gürültü veya alakasız içerik doldurmak olabilir
      Ya da aynı bağlam içinde testleri ardışık biçimde çalıştırıp modelin ne kadar dayanabildiğini, ne zaman bağlamı çözmeye başladığını görmek
      Şimdiki benchmark’lar hep greenfield tarzı problemler; oysa gerçekte istediğimiz şey bozulmuş bir bağlamla başa çıkabilen modeller
    • Hâlâ özün bir alt katmanına baktığımızı düşünüyorum
      Mevcut darboğaz yeteneklerin kendisi değil, modelin prodüksiyonda neyi görebildiği
      Bağlam yapısı, retrieval kalitesi, tool use ve çok turlu durumda state’i birleştirme becerisi önemli; SWE-bench’te ise bunların neredeyse hiçbiri yok
      SWE-bench bir one-shot problem seti gibi görünüyor ama frontier coding çalışması artık böyle bir biçimde değil
      Veri kirlenmesi hiç olmasa ve kusursuz bir benchmark yapılsa bile, çoğu muhtemelen yine yanlış ekseni ölçüyor olacak
      İzole problemler açısından zaten insan yüksek lisans öğrencisi seviyesine ulaştık; asıl kaldıraç, bunun daha büyük sistemlerin içinde nasıl çalıştığında
      Ama bu da neredeyse zevk veya tercih meselesine dönüştüğü için nesnel olarak ölçmek son derece zor
    • Çevrimiçi toplulukların kendisi fazlasıyla astroturfing’e maruz kalmış durumda
      Anthropic, influencer’lara para verip Claude Code’u öne çıkarıyor ve çok sayıda bot da kullanıyor gibi; bu yüzden çevrimiçi uzlaşıya güvenmek zor
      Herkes iyi niyetle davransa bile alan farkları yüzünden algı çok değişebilir
      Örneğin yapay zeka frontend’de veya yaygın kullanılan kütüphanelerde çok daha iyi olabilir
      Sonunda model değerlendirmesi için bizzat kullanmaktan başka yol kalmıyor; ama bunu her yeni modelde tekrarlamak hem çok yorucu hem de tek başına yeterince kapsamlı değil

  • Benchmark/eval zaten doğası gereği zor; işin içine sektör ölçeğinde sistemi oynama teşviki girince daha da zorlaşıyor
    ELT-Bench de yakın tarihli bir örnek; veri mühendisliği iş yükleri için yaklaşık bir yıl önce çıkan ilk ciddi benchmark’tı
    Ama birkaç gün önce, orijinal yazarlarından birinin de yer aldığı devam makalesinde benchmark’ın kendisi denetlendi ve yapısal sorunlar nedeniyle sonuçların yanlı olduğu ortaya kondu
    Makale burada: https://arxiv.org/abs/2603.29399
    Aslında bu yeni bir şey değil; daha önceki sektörler bunu daha küçük ölçekte zaten yaşadı
    Bugünkü durumun veritabanı benchmarketing savaşlarına ne kadar benzediğine dair bir yazı da var
    https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

    • Sonuçta en zor mesele, benchmark’ı eğitim verisinden ayırmak
      BrowseComp plus ve diğer deep research veri kümelerinde de benzer bir sorun görülüyor; bu ille de frontier lab’lerin hile yapmasından değil, tüm web’i eğittikleri için doğal olarak ortaya çıkıyor
      Yeni veri kümeleri sürekli ve kalıcı biçimde üretilmek zorunda
    • Veritabanı benchmark’ları da benzer bir aileden
      Bunu bir classifier yaparken bizzat gördüm: bazı görevlerde model, insanlardan tutarlı biçimde daha iyi hale geliyor ve bu durumda precision’ı ölçmek artık mümkün olmuyor
      Sonra o classifier kendi başına state-of-the-art benchmark’a dönüşüyor ve kendisi dışında kıyaslayacak bir şey kalmıyor
      Kodlamaya göre daha az mantık, daha az sürekli muhakeme gerektiren karmaşık görevlerde bile bu oluyorsa, bir noktada ölçülmek istenen şeyden bağımsız olarak kalibre edilmiş benchmark’lar tamamen ortadan kalkabilir
    • Acaba her ay yeni benchmark üretmek bu sorunu çözebilir mi diye merak ediyorum

  • Sonuçta çoğunlukla hak ettiğimiz benchmark’ları alıyor gibiyiz
    SWE-bench’i geçen PR’ların önemli bir kısmı gerçekte merge edilmeyecek gibi duruyor: https://news.ycombinator.com/item?id=47341645
    Ayrıca üst düzey modellerin SWE-bench puanları git history sızıntısı yüzünden çarpıtılmış olabilir: https://news.ycombinator.com/item?id=45214670

  • Belki de en üst düzey modellere benchmark’ı bizzat kendilerine hazırlatmak gerekir diye düşünüyorum
    Şaka bir yana, benim umut bağladığım şey ARC-AGI-3; insan simülasyonunu denediğimde gerçekten ağır biçimde muhakemeye dayalı hissettirdi
    Leaderboard burada: https://arcprize.org/leaderboard
    Şu anda en iyi modellerin çoğu bile %5’i geçemiyor

    • Burada hamle sayısını en aza indirmek önemli ve hiçbir harness’e izin verilmiyor; bu yüzden çıta çok yüksek
      Şu anda doğrulanmış en iyi model olan Claude Opus 4.6 bile ancak %0,45 civarında
      Yine de çok yeni olduğu için bir sonraki nesil modellerde epey gelişme bekliyorum
    • En üst düzey modellere benchmark yaptırma fikri de tamamen saçma değil
      Eski bir modelin yeni modeli mülakata almasını, sonra ikisinin de veya üçüncü bir hakem modelin hangisinin daha zeki olduğuna karar vermesini sağlayıp seed’i değiştirerek bunu 100 kez tekrarlayabilirsiniz
      Her iki tarafın da yeni modelin kazandığını kabul ettiği oranı puan olarak almak mümkün olabilir
    • Muhakeme ağırlığı yüksek benchmark’lar daha iyi bir yön gibi görünüyor
      Çünkü en zor suistimal edilenler onlar
    • Yapay zekanın, yapay zekanın bile çözemeyeceği sorular yazıp yazamayacağını da merak ediyorum
      Düşününce biraz komik gerçekten

  • Daha iyi benchmark’ların nesnel puanlama, çok disiplinli kapsam ve ölçeklenebilirlik taşıması, ayrıca tek doğru cevaba dayanan yapılardan kaçınması gerekir
    https://gertlabs.com üzerinde tasarladığımız şey de bu yönde ve genel olarak kod yazarak problem çözmeyle ilişkili olacak şekilde oluşturuldu

    • Bu benchmark şimdiye kadar gördüğüm diğer sıralamalardan daha doğru hissettiriyor
      Benim deneyimime göre gpt 5.4/5.5 teknik olarak neredeyse kusursuz; sorun çıktığında genelde sebep girdinin belirsiz olması
      Hata düzeltme veya implementasyon sırasında çıkan sorunlarda da çoğu zaman kendi kendine toparlıyor ve işleri boşluk bırakmadan tamamlama eğiliminde
      Buna karşılık Opus’un teknik yetkinlik bakımından biraz fazla değerlendirildiğini düşünüyorum
      Güzel UX üretme konusunda tasarımcı/geliştirici sezgisi daha iyi ama işin doğrulanmasını yine hep gpt 5.5’e bırakıyorum
      En şaşırtıcı sonuç Xiao-Mi oldu; henüz kullanmadım ama bunu görünce denemeyi düşünüyorum
      Yapay zekadaki bu kaotik hız yarışında anlamlı bir referans ürettiğiniz için ekibi tebrik ederim
    • Claude Code ailesinin C++ ve Java’da hâlâ diğer modellerin çok önünde olması, buna karşılık GPT 5.5’in Python ve JS gibi alanlarda daha yüksek görünmesi ilginç
      Bu, eğitim veri kümesindeki önyargıları ya da go-to-market odak farkını yansıtıyor olabilir; hatta Anthropic’in OpenAI’a kıyasla enterprise müşterilere daha fazla odaklanmasının sonucu da olabilir diye düşünüyorum
      Opus’u C++’ta kullanırken edindiğim izlenimle de örtüşüyor
      Yalnız C# sonuçları boş görünüyor; @gertlabs bunun için bir ETA var mı?
    • Bu benchmark’a bakınca Deepseek V4 pro’nun Deepseek V4 flash’tan daha kötü olduğu görülüyor; bu epey ilginç bir sonuç
      Bunun neden böyle çıktığına dair yorum duymak isterim

  • Bu tür bir şeyin, organik ya da inorganik şekilde, eninde sonunda olması kaçınılmazdı
    Kolayca, “benchmark’ta iyi görünsün yeter, dışarıda genellenmese de olur” yaklaşımına kayıyor
    Benzer bir örnek olarak Graduate student descent de akla geliyor
    https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

  • Geriye dönüp bakınca SWE-bench aslında baştan beri o kadar da olağanüstü olmayabilir
    2025 boyunca modellerin iyi kod üretme oranı neredeyse hiç artmadı; daha çok otomatik testleri geçme becerileri gelişti demek daha doğru olabilir
    https://entropicthoughts.com/no-swe-bench-improvement

    • Kod kalitesinde hiç iyileşme olmadığını söylemeye katılmıyorum
      2025 Ocak’ta Claude 3.5 Sonnet, Gemini 1.5 Pro ve OpenAI tarafında GPT-4o öndeydi; o modelleri de bugünün frontier modellerini de kullanmış biri olarak, mevcut modellerin belirgin biçimde bir üst seviyeye çıktığını söyleyebilirim
    • Bu yorum gayet doğru olabilir
      Model kalitesi durakladı gibi görünüyor ve yeni iyileştirme vektörleri bulmak hiç de kolay değil
      Şimdiye kadarki ilerlemeyi taşıyan model genişliği ölçekleme de sınırına yaklaşmış gibi; bunun ileride ne anlama geleceğini merak ediyorum
      Uzun vadede, yalnızca tooling ile çözülebilecek şeylerin de bir sınırı var
    • Yine de otomatik test geçme oranındaki artış, kodlama verimliliği için devasa bir kaynak
      Anthropic’in on milyarlarca dolar değerlemeye ulaşmasının nedenlerinden biri de bu
      SWE-bench’in coding tarafında işe yaramasının sebebi, yazılım mühendisliğinde otomatik test üretme ve kullanma geleneği ile altyapısının çok güçlü olması
    • Belki de bu yüzden son dönemde şirketlerin fiyatlandırması daha kısıtlayıcı ve daha pahalı hale geliyor

  • Makaledeki ifade bana şu anlama geliyor: modelin sıklıkla çözemediği %27,6’lık alt küme denetlendi ve bunun en az %59,4’ünde işlevsel olarak doğru gönderimleri bile reddeden hatalı testler bulundu
    Eğer gerçekten buysa, şimdiye kadar problem ve doğru cevapların büyük bir bölümünün hatalı olduğu sonucuna varıyoruz; bu durumda bunun nasıl geçerli bir ölçüm sayıldığı ciddi bir soru işareti
    Benchmark’ın nasıl oluşturulduğuna dair açıklamaları okuyunca standartların epey yüksek olduğu izlenimi oluşuyor; buna rağmen bu kadar kötü veri kalitesinin nasıl ortaya çıktığını anlamakta zorlanıyorum
    Sorunu kendilerinin açığa çıkarması takdire değer ama yine de geriye çok fazla soru bırakıyor

    • Bu, toplamın dörtte birinin hatalı olduğu anlamına gelmiyor; daha ziyade %27,6’lık alt kümenin %59,4’ünde hatalı testler olduğu anlamına geliyor gibi
      Ayrıca pratik nedenlerle hiçbir benchmark özünde sizin kullanım senaryonuzu ya da tüm kullanım senaryolarını temsil etmez
      Sadece içinde yer alan şeyleri ölçmekte geçerlidir; ne fazlası ne eksiği
      Açık benchmark’lara yönelik ekosistem takıntısını anlamakta zorlanmamın sebebi de bu
      Örneğin Qwen 3.5’in Benchmark X’te Qwen 2.5’ten %50 daha iyi olması, benim kullandığım görevlerde de %50 daha iyi olacağı anlamına neredeyse hiç gelmez
      Ben gerçek kullanımda modelin başarısız olduğu örneklerden yola çıkarak prompt’ları ayarlıyor ve sürekli özel benchmark’lar oluşturuyorum
      Yeni model güncellemelerinde benim benchmark’larımda genelde sadece %2-3 hareket olurken, açık benchmark’larda %30-40 artış diye pazarlanıyor; bu yüzden eğitim verisi kirlenmesi olmadığına inanmak zor
    • ImageNet de dünyanın en ünlü veri kümelerinden biri ama içinde epey fazla yanlış etiketlenmiş görsel var
      Hatta uç durumda, daha yüksek puan almak için yanlış cevaba uyum sağlamanız gereken bölümler bile oluşabiliyor
      Sonuçta cevap, ML’nin bir şekilde çalışmaya meyilli bir alan olması; kusurlar olsa da şaşırtıcı derecede ileri gidebiliyor
      Aynı zamanda, başkalarının fark etmediği kusurları yakaladığınızda neden büyük sıçramalar elde edilebildiğini de açıklıyor
    • Amaç hangi modelin daha iyi olduğunu ayırt etmekse, benchmark puanının gerçek performansla korelasyonlu olması yeterli olabilir
      Görevlerin büyük çoğunluğu doğru puanlanıyorsa yön hissi korunabilir
      Örneğin etiketlerin %49’u yanlış olan korkunç bir benchmark düşünün; eğer bir model sürekli doğruyu yapıp %51 alıyor, diğeri sürekli yanlışı yapıp %49 alıyorsa, sıralama yine de doğru kalır
      Çoğu makine öğrenimi benchmark’ında azımsanmayacak ölçüde yanlış etiket bulunur; ama amaç modelleri birbirinden ayırmaksa, kusursuz puanlama için harcanacak zamandan ziyade daha büyük bir veri kümesi toplamak genellikle daha faydalıdır
    • Özetle, kabaca soruların %16’sında bir sorun olduğu sonucu çıkıyor