SWE-bench nedir, kodlama benchmark’ları nasıl okunur?
SWE-bench, Terminal-Bench, LiveCodeBench ve öteki kodlama benchmark’ları neyi ölçer? Bir skoru okurken sorulacak altı soruyu anlattık.
Özet. Kodlama benchmark’ı, bir modelin ya da kodlama ajanının sabit bir görev setinde ne kadar iş çıkardığını ölçer. SWE-bench ailesini, Terminal-Bench’i, LiveCodeBench’i, Aider Polyglot’u, BFCL’i, FrontierCode’u, DeepSWE’yi ve bunları bir araya getiren Artificial Analysis dizinini 20 Ekim 2026 günü her birinin kendi sayfasından okuduk. Bağımsız denetimler için Epoch AI’ın ve METR’in yayınlarına baktık.
- Her skor, adından beklenenden daha dar bir soruya cevap verir. Görevlerin nereden geldiği, kimin puanladığı, görevlerin eğitim verisine sızıp sızmadığı ve modelin hangi ajanın içinde çalıştığı skoru belirler.
- SWE-bench Verified artık modelleri ayırmıyor. Epoch AI Eylül’de Verified’ı “kusurlu” buldu: OpenAI’ın denetlediği görevlerin %59,4’ünde test doğru bir çözümü reddediyordu. Terminal-Bench 4.0 ve BFCL v4 için de aynı hükmü verdi.
- Testi geçen kodu bakımcı her zaman birleştirmez. METR’e göre testi geçen SWE-bench Verified PR’larının yaklaşık yarısı bakımcı incelemesinden geçmezdi. Bu boşluğu test değil, kod incelemesi kapatır.
- Skoru okurken altı soru sorun. Hangi set, hangi ajan, hangi effort seviyesi, kaç koşu, kim ölçtü ve set doymuş ya da sızmış mı?
SWE-bench nedir, nasıl puanlanır?
Bir kodlama benchmark’ı (kıyaslama), sabit bir görev listesiyle bir puanlama kuralından oluşur. Model ya da kodlama ajanı görevleri çözer, kural her çözümü geçti ya da kaldı diye işaretler, skor da geçenlerin yüzdesidir. Bu yazı önce en çok konuşulan benchmark’ı, SWE-bench’i açıyor, sonra ötekileri aynı dört soruyla okuyor. Modelin etrafındaki yapıyı (harness) harness engineering yazısında, bir hakem modelle puanlanan değerlendirmeleri LLM-as-a-judge yazısında anlattık.

SWE-bench, gerçek GitHub issue’larından kurulmuş bir benchmark. Sayfasına göre ilk sürüm Ekim 2023’te yayımlandı ve 12 popüler Python deposundaki issue ve pull request’lerden toplanmış 2.294 görevden oluşuyor. Her görev, bir issue’yu kapatan ve test dosyalarını da değiştiren bir pull request’ten çıkarılıyor.
Puanlama şöyle işliyor: modele issue’nun metni ve deponun pull request’ten önceki hâli verilir, model de kodu değiştirir. Model işini bitirince iki grup test çalışır:
- FAIL_TO_PASS: pull request’ten önce başarısız olan, sonra geçen testler. Issue’nun gerçekten çözüldüğünü gösterir.
- PASS_TO_PASS: önce de sonra da geçmesi gereken testler. Değişikliğin var olan bir şeyi bozmadığını gösterir.
İki grup da geçerse görev çözülmüş sayılır. Skor, çözülen görevlerin yüzdesidir; sıralama tablolarında “% Resolved” diye yazar.
SWE-bench bugün tek bir set değil, bir aile. Tablodaki sayıları 20 Ekim 2026 günü her setin kendi sayfasından okuduk:
| Set | Görev | Ne farklı |
|---|---|---|
| SWE-bench | 2.294 | İlk sürüm: 12 Python deposundan gerçek issue’lar |
| SWE-bench Lite | 300 | Daha ucuz bir değerlendirme için seçilmiş alt küme |
| SWE-bench Verified | 500 | OpenAI’la birlikte insanların elden geçirdiği alt küme: açıklama net, test doğru, görev çözülebilir |
| SWE-bench Multilingual | 300 | 42 depo, 9 dil: C, C++, Go, Java, JavaScript, TypeScript, PHP, Ruby, Rust |
| SWE-bench Multimodal | 480 | Issue’lar görsel öğelerle anlatılmış |
| SWE-bench Pro (Scale AI) | 1.865 | 41 depo; çözümler ortalama 107,4 satır, 4,1 dosya. Herkese açık set 731, şirketlerin kapalı kodundan özel set 276, sonucu yayımlanmayan ayrılmış set 858 görev |
Kaynak: SWE-bench’in sayfası, Multilingual’ın tanıtım yazısı ve Scale AI’ın SWE-bench Pro sayfası, 20 Ekim 2026. Pro’nun özel setinin sonuçları ayrı bir tabloda yayımlanıyor.
Liderlik tablosunu okurken bir ayrıntı daha önemli. Verified’ın sayfası, tablonun basit ajan döngülerinden birden çok deneme yapan sistemlere kadar her türden kodlama sistemini aynı listeye koyduğunu yazıyor. Modelleri kendi aralarında karşılaştırmak için ayrı bir “Bash Only” görünümü var: orada her model aynı küçük ajanla (mini-SWE-agent) ve yalnızca bir bash kabuğuyla çalışır.
SWE-bench Verified neden artık yetmiyor?
Verified Ağustos 2024’te OpenAI’la birlikte çıktı. Epoch AI’a göre orijinal setteki 2.294 görevden 500’ü, sorunlu görevleri ayıklamak için üç uzmanın bağımsız incelemesiyle seçildi.
Epoch 3 Eylül’de Verified’ı yeniden inceledi ve “kusurlu” (Flawed) dedi. Üç gerekçe sayıyor:
- Testler doğru çözümü reddediyor. OpenAI, 23 Şubat 2026’da yayımladığı denetimde modellerin sık çözemediği görevlere baktı. Görevlerin %27,6’sını inceledi ve bunların %59,4’ünde testin doğru çalışan bir çözümü reddettiğini buldu. Epoch’a göre bu, bütün görevlerin en az %16,4’ünün bozuk olduğu anlamına geliyor. Epoch’un çıtası, soruların %20’sinden azında böyle bir kusur olması.
- Görevler eğitim verisine sızmış. Verified sabit bir set; görevlerin de çözümlerin de tamamı herkese açık. OpenAI’ın denetimine göre test ettiği bütün öncü modeller bu problemlerin ve çözümlerin en azından bir kısmını eğitimde görmüştü. OpenAI’ın vardığı sonuç şu: Verified’daki ilerleme artık gerçek yazılım geliştirme becerisini değil, modelin eğitimde bu benchmark’ı ne kadar gördüğünü gösteriyor.
- Puan kandırılabiliyor. Berkeley’deki RDI ekibi, tam puan getiren bir ödül hilesi (reward hack) buldu.
Model üreticileri de buna göre davrandı. Cursor’ın yazısına göre OpenAI, öncü modellerin referans çözümleri ezberden yeniden üretebildiğini görünce Verified sonuçlarını raporlamayı tamamen bıraktı. Anthropic’in 24 Temmuz’daki Opus 5 sistem kartı Verified’ı hâlâ raporluyordu: beş denemenin ortalaması %96,0. 22 Eylül’deki Opus 5.5 kartında ise Verified yok; yalnızca Pro, Multilingual ve Multimodal var. Anthropic aynı modelin duyurusunda şunu da yazıyor: bu yetenek düzeyinde benchmark’taki farklar, gerçek kullanımdaki farkı artık daha az güvenilir biçimde gösteriyor.
Herkesin tavana yaklaştığı bir benchmark, modelleri artık birbirinden ayıramaz. Bunu benchmark’ları kuranlar da görüyor. Aider, eski düzenleme benchmark’ında skorlar %80’i geçince yerine daha zor bir set kurdu. Terminal-Bench 4.0, en yeni modellerin hepsinin 5 denemenin 5’inde çözdüğü görevleri “doymuş” sayıp setten çıkardı. DeepSWE’nin sayfası da öndeki modellerin dar bir skor bandına sıkıştığını, komşu yapılandırmaların güven aralıklarının çoğu zaman üst üste bindiğini yazıyor.
Epoch aynı hafta iki kodlama benchmark’ına daha aynı hükmü verdi. Kusurlar puanın %20’sini ya da fazlasını etkileyebildiğinde bir benchmark’ı “kusurlu” sayıyor:
| Benchmark | İnceleme | Ne buldu |
|---|---|---|
| SWE-bench Verified | 3 Eylül | Denetlenen görevlerin %59,4’ünde test doğru çözümü reddediyor; görevler ve çözümler herkese açık |
| Terminal-Bench 4.0.0 | 4 Eylül | 66 görevin 30’unda (%45,5) kamuya açık puanlama kusuru; bir görevde ajan testleri geçmeden “geçti” sinyalini kendisi yazabiliyor |
| BFCL v4 | 10 Eylül | Rastgele seçilen 50 maddenin 24’ünde (%48) doğru cevabı yanlış ya da yanlış cevabı doğru sayabilen kusur |
Kaynak: Epoch AI’ın incelemeleri. Verified’da Epoch, OpenAI’ın denetimine dayanıyor. Terminal-Bench’in görevleri topluluktan geliyor; Epoch, deposunda herkese açık olarak bildirilmiş sorunları saydı. BFCL’de 5.088 maddeden rastgele bir örnek aldı.
Kusurun nasıl göründüğüne BFCL’den bir örnek: “Sydney’de saat kaç?” görevinde modele get_local_time(location) adlı bir fonksiyon veriliyor. Cevap anahtarı görevi “ilgisiz” diye işaretlemiş. Tam puanı yalnızca hiçbir fonksiyon çağırmayan model alıyor; fonksiyonu doğru çağıran model sıfır alıyor.
Öteki kodlama benchmark’ları neyi ölçer?
SWE-bench tek tür bir işe bakıyor: bir depodaki issue’yu kapatan bir patch. Bir kodlama ajanından beklenen iş daha geniş; bu yüzden her benchmark başka bir dilimi ölçüyor. Tablodaki bilgileri 20 Ekim 2026 günü her benchmark’ın kendi sayfasından okuduk:
| Benchmark | Görev | Kim puanlıyor | Sızıntıya karşı | Okurken dikkat |
|---|---|---|---|---|
| SWE-bench Pro (Scale AI) | 41 depoda uzun, çok dosyalı değişiklikler | FAIL_TO_PASS ve PASS_TO_PASS testleri | Copyleft lisanslı depolar, şirketlerin kapalı kodu ve sonucu yayımlanmayan bir set | Cognition’a göre yalnızca işlevsel doğruluğu ölçer, kod kalitesini değil |
| Terminal-Bench 4.0 | Terminalde uçtan uca görevler: yazılım, bilim, ML, operasyon, güvenlik, donanım, medya | Her görevin kendi doğrulayıcısı | Çözümü herkese açık hâle gelen görevler setten çıkarılıyor | Puan bir model ve ajan çiftine ait; Cursor’a göre görevler bulmaca tarzında |
| LiveCodeBench | LeetCode, AtCoder ve Codeforces yarışma problemleri: kod yazma, kendi kodunu düzeltme, kod çalıştırma, test çıktısı tahmini | Testler; pass@1 | Her problemin yayım tarihi var; model, eğitim tarihinden sonra çıkan problemlerle ölçülebilir | Görev tek bir yarışma problemi, bir depo değil |
| Aider Polyglot | C++, Go, Java, JavaScript, Python ve Rust’ta Exercism’in en zor 225 alıştırması | Birim testleri; ilk denemede kalan model test hatalarını görüp bir kez daha dener | Sayfasında yazmıyor | Tablodaki yüzde ikinci denemeden sonraki sonuç; tablo en son 20 Kasım 2025’te güncellendi |
| BFCL v4 | Fonksiyon (araç) çağırma: tek çağrı, çok turlu konuşma, ajan görevleri | Sabit bir cevap anahtarı | Sayfasında yazmıyor | Kod yazmayı değil, doğru aracın doğru argümanla çağrılmasını ölçer |
| FrontierCode (Cognition) | 36 açık kaynak deponun bakımcılarıyla hazırlanmış 150 görev | Testler, bir kapsam denetimi ve kod kalitesine bir dil modelinin verdiği puan | Görevler yayımlanmıyor | Görevler kapalı olduğu için sonucu dışarıdan tekrarlayamazsınız |
| DeepSWE v1.1 (Datacurve) | 91 depoda, 5 dilde 113 uzun görev | Elle yazılmış doğrulayıcılar: uygulama ayrıntısını değil davranışı sınar | Görevler sıfırdan yazılmış, var olan commit ya da PR’lardan uyarlanmamış | Bütün modeller aynı küçük ajanla (mini-swe-agent) çalışıyor; kendi aracınızdaki sonucu göstermez |
| Artificial Analysis Coding Agent Index | Modeli bir kodlama aracının içinde ölçer: DeepSWE, Terminal-Bench 4.0 ve SWE-Atlas-QnA’dan toplam 303 görev | Her benchmark’ın kendi doğrulayıcısı; görev başına 3 deneme | Bileşen benchmark’lara bağlı | Canlı bir sayfa; güven aralığı sayfada yazmıyor. Model reddederse görevi başka bir model bitirebiliyor ve deneme yine sayılıyor |
| CursorBench (Cursor) | Cursor mühendislerinin gerçek oturumlarından görevler | Ajan tabanlı puanlayıcılar | Görevlerin birçoğu Cursor’ın kendi kodundan; set birkaç ayda bir yenileniyor | Dışarıdan tekrarlanamaz; skorlar yalnızca aynı sürüm içinde karşılaştırılır |
Kaynak: her benchmark’ın kendi sayfası ya da tanıtım yazısı, 20 Ekim 2026. “Sayfasında yazmıyor”: o gün okuduğumuz sayfada bunu söyleyen bir cümle bulamadık. Cognition’ın ve Cursor’ın değerlendirmeleri, kendi benchmark’larını tanıttıkları yazılardan.
Tabloların ne kadar taze olduğu da farklı. Aider’ın tablosu en son 20 Kasım 2025’te, BFCL’in tablosu 12 Nisan 2026’da güncellendi. LiveCodeBench’in deposundaki en yeni sürüm (release_v6), Mayıs 2023 ile Nisan 2025 arasında yayımlanmış 1.055 problemi kapsıyor. Bir model böyle bir tabloda yoksa bu, modelin kötü olduğunu değil, tablonun eski olduğunu gösterebilir.
Listede olmayan en eski ad HumanEval: OpenAI’ın 2021’de yayımladığı, docstring’den kod yazdıran set. Deposu bugün “bakımı yapılmıyor” diye işaretli. LiveCodeBench ekibi de HumanEval’de iyi olan bazı modellerin bu sete aşırı uymuş olabileceğini buldu.
Kod inceleme araçlarının da benchmark’ları var. GitHub 5 Ekim’de ReviewBench’i yayımladı; bir yorumun doğru bir bulgu olup olmadığına orada bir hakem model karar veriyor ve GitHub hakemin prompt’unu da yayımladı. Hakem modelle puanlanan bir benchmark’ın nasıl okunacağını LLM-as-a-judge yazısında anlattık.
Testi geçen kod birleştirilir mi?
SWE-bench’in skoru otomatik bir notlayıcıdan gelir: testler geçerse görev çözülmüş sayılır. METR, 10 Mart 2026’da yayımladığı çalışmada bu sayının gerçek bir bakımcı incelemesine ne kadar denk düştüğünü ölçtü. Verified’daki 3 deponun (scikit-learn, Sphinx, pytest) 4 aktif bakımcısı, toplam 296 yapay zekâ PR’ını gerçek bir inceleme gibi okudu ve birleştirip birleştirmeyeceğine karar verdi. PR’ı kimin yazdığını bilmiyorlardı.
Sonuç: testi geçen PR’ların yaklaşık yarısını bakımcılar birleştirmezdi. Bakımcı kararı da kişiden kişiye değişebildiği için METR, aynı bakımcılara depoda gerçekten birleştirilmiş insan PR’larını da okuttu; bunların yaklaşık %68’ini onayladılar. Skorlar bu tabana göre ölçeklenince otomatik notlayıcı, bakımcı kararından ortalama 24,2 puan yukarıda kalıyor. Ölçeklemeden bakınca fark 34,9 puan.
Bakımcıların reddetme gerekçeleri üç türdü: değişiklik sorunu gerçekten çözmüyor, ilgisiz koda dokunup onu bozuyor ya da kod deponun standardına uymuyor. METR sınırlarını da açıkça yazıyor: ajanlara geri bildirimle düzeltme şansı verilmedi, tek bir benchmark’ın bir kısmına ve tek bir ajana bakıldı. Yani sonuç, modellerin bunu yapamayacağını söylemiyor. Söylediği şu: skor tek başına okunursa ajan olduğundan daha işe yarar görünür.

FrontierCode bu soruları puana katan bir benchmark. Cognition, 36 açık kaynak deponun bakımcılarıyla 150 görev hazırladı; bir değişikliğin birleştirilebilir sayılmasının ölçütlerini her depoda bakımcılar belirledi. Birim testlerinin yanında bir kapsam denetimi var: değişiklik yalnızca izin verilen dosyalara mı dokunuyor, diff belirli bir büyüklüğü aşıyor mu. Ajanın yazdığı testler de eski, bozuk kodda çalıştırılıyor; orada kırılmayan test bir şey sınamıyor demektir.
Kapsam cezasının etkisini Anthropic’in kendi raporu gösteriyor. Opus 5 sistem kartına göre model, high’ın üstündeki effort seviyelerinde görevin istediğinden fazla değişiklik yaptı ve FrontierCode puanı düştü. Prompt’a görevin kapsamında kalmasını söyleyen kısa bir talimat eklenince görevlerin çoğunda puan geri geldi. Bu, satıcının Opus 5 için bildirdiği bir sonuç; kart kaç puan geri geldiğini yazmıyor.
Kod incelemesi tam bu boşlukta çalışır: test, değişikliğin istenen davranışı verdiğini gösterir; inceleme ise değişikliğin oraya ait olup olmadığını sorar. diffox’ta bu soruyu soran uzman ajanlar var. Biri değişen satırları deponun kural dosyasındaki (AGENTS.md, CLAUDE.md) kurallarla tek tek karşılaştırır; dosyada yazmayan bir kuralı saymaz. Bir başkası, adının söylediğini sınamayan testi ya da hiçbir zaman başarısız olamayacak bir doğrulamayı arar; eksik testi ise bulgu saymaz. Bir testin gerçekten bir şey sınayıp sınamadığını nasıl okuyacağınızı yapay zekânın yazdığı kodu inceleme yazısında anlattık.
Bir benchmark skorunu nasıl okumalı?
Bir skorla karşılaştığınızda şu altı soruyu sorun. İki skor bu sorulardan birinde ayrışıyorsa, artık aynı şeyi ölçmüyor demektir:
- Hangi set ya da alt küme? “SWE-bench” tek başına bir şey söylemez: Verified, Pro’nun herkese açık seti ya da bir şirketin seçtiği alt küme ayrı sayılardır. Anthropic’in belgesi, Pro’dan seçtiği 482 problemlik alt kümedeki skorların herkese açık tabloyla karşılaştırılamayacağını yazıyor. Aynı şirketin sistem kartındaki Pro sonuçlarıyla da karşılaştırılamıyorlar, çünkü onlar başka bir problem setinde ve max effort’la ölçüldü.
- Hangi ajanın içinde? Puan modele değil, modelle onu çalıştıran ajanın ikilisine aittir. Epoch’a göre Verified’ın sonuçları büyük ölçüde kullanılan ajana bağlı; Terminal-Bench’in tablosunda her satır bir model ve bir ajan. Aynı benchmark’ta bile ayar farkı çıkabiliyor: Epoch, Terminal-Bench’te Codex girişlerinin güvenlik retlerini yeniden denediğini, varsayılan ayarın ise denemediğini not etti. Artificial Analysis de sonuçlarının ürün adlarına değil belirli yapılandırmalara ait olduğunu, modelin, ayarların ve çalıştırma biçiminin sonucu ciddi ölçüde değiştirebildiğini yazıyor. Epoch, ajanın bağlamı kötü yönetmesini de skoru düşüren bir kurulum sorunu sayıyor; bağlam dolunca kodlama ajanlarının ne yaptığını auto compact yazısında anlattık.
- Hangi effort seviyesinde? Tablolar modeli çoğu zaman en iyi sonucu verdiği seviyede gösterir. Anthropic’in Opus 5.5 duyurusundaki sonuçlar, aksi yazılmadıkça max effort’la ölçüldü; Terminal-Bench satırı her modelin en yüksek skorunu verdiği seviyede. FrontierCode da her modeli her effort seviyesinde 5’er kez çalıştırıp en iyi seviyeyi raporluyor. Aracı varsayılan seviyede kullanıyorsanız tablodaki sonucu görmeyebilirsiniz.
- Kaç koşu, belirsizlik ne kadar? Aynı yapılandırma iki koşuda farklı skor verebilir. Terminal-Bench’in tablosu 5 koşunun ortalamasını %95 güven aralığıyla gösteriyor; Epoch hata payı için model başına en az 5 koşu öneriyor. Fark gürültüden büyük değilse fark değildir; kendi ölçümlerimizde iki koşu arasındaki gürültüyü LLM-as-a-judge yazısında anlattık.
- Kim ölçtü? Model üreticisinin tablosu kendi seçtiği koşullarda ölçülür. Bağımsız ölçümler her modeli aynı kurallarla çalıştırmaya çalışır: DeepSWE bütün modelleri aynı küçük ajanla çalıştırıyor. İkisinde de ayrıntıya bakın: Artificial Analysis bir model görevi reddedince başka bir modelin bitirmesine izin veriyor ve o denemeyi de sayıyor; Anthropic de güvenlik önlemleri devreye girdiğinde Opus 5.5’in görevlerinin bir kısmını başka modellerin tamamladığını yazıyor.
- Set doymuş mu, sızmış mı, güncel mi? Herkesin tavana yakın olduğu bir set modelleri ayırmaz; görevleri ve çözümleri açık bir set ezberi de ölçebilir. Görevlerin yayım tarihine bakın (LiveCodeBench bunu her problem için tutuyor), setin kapalı bir bölümü var mı diye sorun ve tablonun en son ne zaman güncellendiğine bakın.
Effort’un etkisini aynı model ve aynı görevler üzerinde gösteren bir örnek Anthropic’in maliyet ve zekâ belgesinde var. Değişen tek şey effort seviyesi:

Aynı modelde yalnızca effort değişince skor 9,3 puan oynuyor, görev başına maliyet de $0,11’den $0,74’e çıkıyor. İki modeli karşılaştıran bir tabloda önce her birinin hangi seviyede ölçüldüğüne bakın: biri max’ta, öteki varsayılan seviyede ölçüldüyse aradaki fark modelden değil ayardan gelebilir.
Hangi iş için hangi benchmark’a bakılmalı?
Benchmark seçmek, ajandan ne istediğinizi seçmektir. Aşağıdaki tablo sık karşılaşılan işleri ona en yakın benchmark’la eşleştiriyor:
| İşiniz | Bakın | Neden |
|---|---|---|
| Bir depodaki hataları düzelten ajan | SWE-bench Pro | Gerçek depolarda çok dosyalı görevler; kapalı ve yayımlanmayan setler sızıntıyı azaltır |
| Terminalde ortam kuran, komut çalıştıran ajan | Terminal-Bench 4.0 | Uçtan uca terminal görevleri; tablo her model ve ajan çifti için koşu ortalaması ve güven aralığı veriyor |
| Tek bir fonksiyon ya da algoritma yazdırmak | LiveCodeBench | Modeli, eğitim tarihinden sonra çıkan problemlerle ölçebilirsiniz |
| Birden çok dilde kod yazdırmak ve düzenletmek | SWE-bench Multilingual, Aider Polyglot | 9 ve 6 dil; Aider’ın tablosunun tarihine bakın |
| Araç çağırmanın güvenilirliği | BFCL v4 | Doğru aracın doğru argümanla çağrılmasını ölçer; Epoch’un bulduğu kusurları hesaba katın |
| Bir aracı ve modeli birlikte seçmek | Artificial Analysis Coding Agent Index | Modeli bir kodlama aracının içinde, görev başına 3 denemeyle ölçer |
| Birleştirilecek kalitede kod | FrontierCode | Kapsamı, testlerin anlamını ve kod kalitesini puana katar; görevleri kapalı |
Kaynak: bu yazıdaki tablolar ve her benchmark’ın sayfası, 20 Ekim 2026.
Hiçbiri sizin deponuzdaki işin yerini tutmaz. Anthropic’in belgesi de effort ayarını kendi işiniz üzerinde denemenizi öneriyor. En güvenilir ölçüm, kendi deponuzdan birkaç gerçek görevi aynı ajanla, aynı effort seviyesinde ve birden çok kez çalıştırmaktır.
Hiçbiri bir değişikliğin birleştirilip birleştirilmemesi gerektiğini de ölçmez. Buna en çok FrontierCode yaklaşıyor, ama orada da kararı bakımcıların önceden yazdığı ölçütler veriyor. Sizin deponuzda o kararı inceleme verir.
Sıkça sorulan sorular
SWE-bench nedir?
SWE-bench, yapay zekâ modellerinin ve kodlama ajanlarının gerçek GitHub issue’larını çözüp çözemediğini ölçen bir benchmark’tır. Modele issue metni ve deponun o anki hâli verilir, model de kodu değiştirir. Değişiklik, issue’nun çözüldüğünü gösteren FAIL_TO_PASS testlerini ve bir şeyin bozulmadığını gösteren PASS_TO_PASS testlerini geçerse görev çözülmüş sayılır. İlk sürüm 12 Python deposundan 2.294 görev içeriyor; Verified, Pro ve Multilingual gibi alt kümeleri ve kardeş setleri var.
SWE-bench Verified ile SWE-bench Pro farkı nedir?
Verified, orijinal setten insanların elden geçirdiği 500 görevlik bir alt küme; görevleri ve çözümleri herkese açık. Pro, Scale AI’ın 41 depodan 1.865 görevlik daha zor seti: çözümler ortalama 107,4 satır ve 4,1 dosya. Pro’nun görevleri copyleft lisanslı depolardan ve şirketlerin kapalı kodundan geliyor, bir kısmının sonucu hiç yayımlanmıyor. Epoch AI Eylül 2026’da Verified’ı kusurlu buldu; Anthropic’in son model kartı da Verified yerine Pro’yu raporluyor.
SWE-bench skoru yüzde kaç olursa iyi sayılır?
Tek bir eşik yok. Skor hangi sete, hangi ajana ve hangi effort seviyesine ait olduğuna göre değişir: Anthropic’in kendi alt kümesinde aynı model yalnızca effort’la 9,3 puan oynuyor ve Anthropic bu skorların herkese açık tabloyla karşılaştırılamayacağını yazıyor. İki skoru ancak aynı sette, aynı ajanla ve benzer ayarlarla ölçüldüyse karşılaştırın; bir sayıya tek başına değil, aynı koşullarda ölçülmüş öteki modellerle arasındaki farka bakın.
Terminal-Bench neyi ölçer?
Terminal-Bench, bir ajanın terminalde uçtan uca görevleri tamamlayıp tamamlayamadığını ölçer: yazılım, bilim, ML, operasyon, güvenlik, donanım ve medya görevleri. Her görevin kendi doğrulayıcısı var. 4.0 sürümüyle sürekli güncellenen bir benchmark oldu; doymuş, reddedilen ve çözümü açığa çıkan görevleri setten çıkarıyor. Tablo her model ve ajan çifti için 5 koşunun ortalamasını %95 güven aralığıyla gösteriyor. Epoch AI 4 Eylül’de 66 görevin 30’unda kamuya açık puanlama kusuru kaydetti.
LiveCodeBench ile SWE-bench arasındaki fark ne?
LiveCodeBench, LeetCode, AtCoder ve Codeforces yarışmalarından toplanan problemlerle modelin kod yazma, kendi kodunu düzeltme, kod çalıştırma ve test çıktısı tahmin etme becerisine bakar; görev tek bir problemdir. SWE-bench ise bir depodaki gerçek issue’yu kapatan bir değişiklik ister. LiveCodeBench her problemi yayım tarihiyle işaretlediği için bir modeli, eğitim kesim tarihinden sonra çıkan problemlerle ölçebilirsiniz; böylece model çözümü eğitimde görmüş olamaz.
Benchmark skoruna ne kadar güvenilir?
Skor, benchmark’ın sorduğu dar soruya cevap verir. Güvenmeden önce altı şeye bakın: hangi set, hangi ajan, hangi effort seviyesi, kaç koşu ve güven aralığı, kimin ölçtüğü ve setin doymuş ya da sızmış olup olmadığı. Bağımsız denetimler bu yüzden önemli: Epoch AI Eylül 2026’da SWE-bench Verified, Terminal-Bench 4.0 ve BFCL v4’ü kusurlu buldu; METR, testi geçen SWE-bench PR’larının yaklaşık yarısının bakımcı incelemesinden geçmeyeceğini ölçtü.
diffox hangi benchmark’la ölçülüyor?
diffox bir yapay zekâ kod inceleme aracı; bu yüzden kodlama benchmark’larıyla değil, kod inceleme benchmark’larıyla ölçülüyor. Martian’ın açık kaynak kod inceleme benchmark’ını kendimiz çalıştırdık ve sonucu kanıtıyla yayımladık: her inceleme herkese açık bir pull request, puanlamayı benchmark’ın kendi kodu yaptı ve tabloyu kanıt deposundaki komutlarla kendi makinenizde yeniden kurabilirsiniz. O yazı her satırın kaç koşudan geldiğini de söylüyor: herkese açık koşuyu o zamanki Yüksek duyarlılık ayarında yaptık, Orta ve Düşük satırları ise birden çok iç koşunun ortalaması.