Senior SWE-Bench: benchmark open-source untuk mengevaluasi agen setingkat engineer senior

 (senior-swe-bench.snorkel.ai)
4 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Senior SWE-Bench adalah benchmark yang bertujuan mengevaluasi agen coding bukan dengan tugas junior yang terlalu dirapikan, melainkan dengan pengembangan fitur, perbaikan bug, dan masalah performa yang mendekati pekerjaan engineer senior di dunia nyata
  • Tugas fitur menggunakan instruksi realistis yang terbaca seperti pesan bahasa alami, dan meningkatkan reliabilitas evaluasi dengan validation agent yang membuat pengujian perilaku sesuai solusi yang diajukan
  • Tugas bug diambil dari PR yang berawal dari laporan pengguna dan membutuhkan investigasi runtime seperti menjalankan layanan, log, data profiling, dan langkah reproduksi
  • Skor mengevaluasi tasteful solve dengan menggabungkan bukan hanya kesesuaian runtime, tetapi juga metrik kualitas berbasis praktik codebase; praktik penting yang tidak disebutkan dalam instruksi pun dapat menjadi target verifikasi
  • Claude Opus 4.8, model teratas di leaderboard, pun hanya mencapai pass@1 24,0% pada konfigurasi Mini-SWE-Agent max, sehingga model papan atas juga gagal lebih dari 75% dalam menyelesaikan tugas dengan kesesuaian dan taste setingkat senior

Desain tugas yang mendekati PR nyata

  • Senior SWE-Bench adalah benchmark yang bertujuan mengurangi kesenjangan antara penggunaan agen coding yang pada praktiknya seperti engineer senior dan evaluasi yang masih seperti tugas untuk junior
  • Tugas diambil dari PR di berbagai repositori, mulai dari library hingga aplikasi multi-layanan, dan menargetkan PR yang dibuat oleh engineer yang telah menulis ratusan commit di masing-masing repositori
  • Jenis tugas utama dibagi menjadi dua jalur
    • PR fitur yang melintasi beberapa tahap dan beberapa stack
    • PR bug/performa yang membutuhkan investigasi runtime yang signifikan
  • Tugas publik berjumlah 50, dan ada 50 tugas privat
  • Contoh repositori yang disertakan adalah sebagai berikut

Tugas fitur: instruksi yang mendekati bahasa alami

  • Tugas fitur menggunakan instruksi realistis yang terbaca seperti pesan bahasa alami, bukan requirement yang dipecah terlalu rinci
  • Untuk mengevaluasi tugas seperti ini secara stabil, diperkenalkan validation agent
    • Menggunakan resep yang dirancang oleh pakar
    • Menulis pengujian perilaku sesuai solusi yang diajukan
  • Instruksi mencerminkan komunikasi agen yang alami, dan median panjangnya sekitar 31% dari SWE-Bench Pro

Tugas bug: dari laporan pengguna hingga investigasi runtime

  • Tugas bug mencerminkan laporan pengguna yang sulit, sehingga lebih menuntut investigasi penyebab dan proses reproduksi daripada sekadar perubahan kode
  • Tugas dapat mencakup pekerjaan seperti berikut
    • Memulai layanan
    • Men-debug masalah runtime yang subtil
    • Memeriksa log
    • Memanfaatkan data profiling
    • Menelusuri langkah reproduksi
  • Sumbernya adalah PR yang dalam proses penyelesaiannya membutuhkan investigasi runtime yang signifikan

Kriteria evaluasi: mengukur kesesuaian dan taste sekaligus

  • Senior SWE-Bench menilai tasteful solve dengan menggabungkan pengujian kesesuaian runtime dan beberapa metrik kualitas
  • Metrik kualitas didasarkan pada praktik codebase yang diamati
  • Verifier dan validation agent dapat menguji praktik yang penting dalam codebase meski tidak tertulis dalam instruksi
  • Syarat solve di leaderboard mencakup item berikut
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Leaderboard: model terbaik pun pass@1 rendah

  • Leaderboard menampilkan hasil berdasarkan Tasteful solve rate(pass@1)
  • Hasil teratas adalah sebagai berikut
    • 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%
  • Model frontier terkuat pun tidak mampu menyelesaikan lebih dari 75% tugas yang menuntut kesesuaian dan taste setingkat senior

Cakupan tugas dan karakteristik benchmark

  • Jenis tugas ditandai sebagai feature, bug, perf, migrat
  • Stack mencakup Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE, dan lainnya
  • Tugas fitur dapat melintasi beberapa layanan, dan rata-rata menyentuh 11 file per tugas
  • Dirancang untuk menuntut alur kerja panjang, sehingga agen terkuat pun membutuhkan ratusan langkah
  • SLOC dan jumlah file pada solusi referensi diukur dengan cara yang sama di ketiga benchmark
  • Panjang instruksi mengecualikan boilerplate harness
  • Jumlah token dan jumlah langkah pada benchmark lain didasarkan pada metrik yang dilaporkan sendiri oleh masing-masing benchmark

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Dari yang saya lihat di Twitter, katanya ada ujian di kelas machine learning Universitas Tsinghua yang meminta mahasiswa membuat kuis yang sebisa mungkin gagal dijawab oleh banyak LLM
    Saya jadi berpikir, bagaimana kalau benchmark seperti ini dibuat lalu diberi skor ELO. Model saling berhadapan dengan mengajukan pertanyaan, bug, atau implementasi yang belum selesai, lalu lawannya harus menjawab, memperbaiki, atau melengkapinya

    • Ini bisa disebut generative adversarial network (GAN) :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • Masalahnya adalah bagaimana mencegah strategi degeneratif. Misalnya, seseorang bisa dengan mudah membuat soal yang mustahil dengan memberikan hash SHA256 lalu meminta menebak input aslinya
      Di kelas, mungkin bisa dibuat aturan bahwa setidaknya ada satu LLM yang harus bisa menjawabnya, tetapi untuk duel satu lawan satu saya tidak tahu bagaimana menyelesaikannya
    • Sepertinya itu bukan Tsinghua, melainkan Fudan

  • Saya penasaran bagaimana benchmark ini akan tetap relevan seiring waktu
    Jika benchmark-nya berupa implementasi fitur dari proyek open source, LLM bisa saja sudah memasukkan perubahan itu ke dalam data latihnya, sehingga dapat menjawab persis atau dengan sedikit modifikasi
    Sebaliknya, jika benchmark hanya memasukkan perubahan kode setelah cutoff pengetahuan model, maka masalah pada waktu T dan T+1 menjadi berbeda, sehingga perbandingan lintas waktu jadi kurang valid

  • Kalau ini Staff SWE Bench, sepertinya LLM pertama-tama akan mempertanyakan apakah ini memang seharusnya dikerjakan, mengkritik keseluruhan proyeknya, menolak merge kode, tetapi dengan senang hati menghapusnya

    • Kedengarannya seperti bercanda, tetapi menurut saya penolakan memang inti dari pekerjaan ini. Bukan sekadar “tidak, pergi sana”, melainkan mundur selangkah untuk meminta gambaran besar dan melihat apakah organisasi benar-benar membutuhkan proyek itu dalam jangka panjang serta mampu menanggungnya; itu nyaris merupakan prosedur minimum sebelum mulai
      LLM sepertinya juga bisa melakukan ini dengan cukup baik, mungkin bahkan lebih baik daripada kita, tetapi perlu dilatih secara khusus untuk itu. Hanya saja saya tidak langsung terpikir dari mana data latih seperti itu bisa didapat
    • Versi principal mirip, tetapi juga akan berkata bahwa satu-satunya pendekatan yang boleh dipakai adalah cara yang dilakukan di perusahaan sebelumnya

  • Jadi ini menjelaskan kenapa saya selalu merasa Opus 4.8 jauh lebih unggul daripada GPT 5.5. Kemampuannya menerima requirement yang tidak lengkap lalu mengisi kekosongan dengan cara yang masuk akal sesuai proyek itu benar-benar bagus

    • Saya malah tidak paham kenapa sejak awal diberi requirement yang tidak lengkap. Kedua model sama-sama mampu mempertanyakan asumsi dan edge case serta mengajukan pertanyaan klarifikasi, tetapi tampaknya hanya ketika diminta secara eksplisit. Misalnya ketika diminta dengan teknik seperti “brainstorming”
      Menurut saya kedua metode evaluasi itu tidak cukup mendorong model untuk meragukan semua asumsi dan bertanya. Mungkin karena pengguna bisa merasa terganggu, tetapi tahap itu menurut saya hampir wajib
      Seri GPT-5 semuanya sangat teliti sehingga berguna untuk code review dan matematika. Itu penting untuk pekerjaan saya, tetapi tampaknya mengganggu untuk kode yang “estetis”. Misalnya, model berusaha mengantisipasi semua edge case meskipun kemungkinannya kecil
      Sepertinya memang ada trade-off antara fleksibilitas dan kepatuhan terhadap instruksi. Dalam pengalaman saya, Opus kadang mengabaikan instruksi tetapi lebih pandai mengisi kekosongan, sedangkan GPT-5.5 lebih patuh namun jadi lebih kaku
    • Benchmark terbaik adalah benchmark buatan sendiri
      Dalam pengalaman saya, Opus tidak unggul telak atau secara jelas lebih baik. Lagi pula GPT 5.5 punya Instant, Medium, High, Extra High, dan Pro, dan tabelnya terlihat seperti membandingkan dengan Extra High, jadi bukankah seharusnya dibandingkan dengan Pro?
    • Mungkin saya hidup di gelembung yang aneh, tetapi bagi saya GPT 5.5 jauh lebih baik daripada Opus 4.8. Sampai-sampai saya penasaran bagaimana orang mengevaluasinya dan pekerjaan seperti apa yang mereka lakukan
      Ada tugas tertentu seperti pengembangan frontend dan desain di mana Opus lebih baik, tetapi selain itu 5.5 benar-benar mendominasi
    • Mungkin lebih baik untuk vibe coder yang selalu kurang eksplisit. Tetapi masalahnya adalah pada titik mana model memutuskan bahwa “requirement-nya kurang eksplisit”, lalu akhirnya mengimplementasikan hal-hal yang sebenarnya melampaui spesifikasi yang sudah cukup jelas
    • Saya juga mengamati hal yang sama. Opus 4.8 terasa jauh lebih matang, dan akan bertanya balik atau menentang permintaan yang terasa mengganjal. Sebaliknya GPT 5.5 akan dengan senang hati setuju dan melakukan apa yang diminta, tetapi sering kali harus disuruh ulang beberapa kali
      4.8 juga memang butuh lebih dari satu prompt, tetapi kualitas output-nya jauh lebih tinggi dan memberi lebih banyak wawasan
      Namun Fable 5 adalah cerita lain lagi

  • Saat ini tingkat penyelesaian terbaik berdasarkan Opus 4.8 adalah 24%, tetapi manusia yang kompeten seharusnya bisa mendapat skor berapa?

    • Mungkin tidak lebih tinggi, karena manusia juga bisa memakai alat yang digunakan model terbaik
      Sebaliknya, saya juga penasaran apakah model akan mendapat skor lebih tinggi jika bisa mengarahkan manusia sesuka hati
    • Kalau diasumsikan semua masalah ini memang sudah pernah diselesaikan, sepertinya harusnya 100%. Tentu bukan orang yang sama yang menyelesaikan semuanya, tetapi model harus bagus di berbagai codebase, sedangkan manusia bisa belajar dan terspesialisasi pada satu produk
      Menurut saya adil jika dibandingkan dengan individu yang memang terbiasa bekerja pada produk tersebut
      Saya justru lebih penasaran bagaimana hasil Fable nanti

  • Nilai dari peran senior adalah menerapkan solusi dan strategi yang sudah diketahui pada masalah baru. Saya tidak yakin benchmark yang tidak pernah berubah bisa tetap menjadi tantangan baru dalam jangka panjang
    Benchmark yang bagus seharusnya terlebih dahulu membuat sekumpulan masalah besar dengan memanfaatkan seluruh TRIZ, lalu melihat apakah AI dapat menyimpulkan solusi optimalnya

  • Senang melihat benchmark publik baru dari Snorkel. Mereka melakukan pekerjaan yang cukup canggih di sana

  • Menarik bahwa Sonnet 5 cukup dekat dengan Opus 4.8

  • Kalau pendekatan seperti ini berhasil, bukankah itu berarti wawancara teknis juga bisa diotomatisasi?

  • Pendekatan menyuruh LLM membuat penilaian subjektif dengan kalimat seperti “You are a senior SWE-Bench reviewer, make no mistakes.” tampak cacat secara mendasar
    Saya tidak tahu cara yang lebih baik sambil tetap menjaga kelayakan implementasinya

    • Yang lebih penting, ini justru bisa mengganggu pekerjaan nyata. Jika LLM membuat kesalahan, ia bisa terdorong untuk mengecilkan masalah lalu lanjut saja alih-alih mengakuinya dan memperbaikinya
    • Pendekatan ini pada dasarnya menanamkan konteks tentang bagaimana LLM seharusnya bertindak. “senior reviewer” adalah gaya respons yang diinginkan, dan “SWE-Bench” adalah konteks serta domain tempat LLM akan beroperasi
      Ini pendekatan yang umum dalam system prompt dan membantu membingkai jawaban
      Misalnya, jika diberi peran “bajak laut yang menulis sea shanty tentang pemrograman”, “jurnalis berita yang menulis artikel fisika”, atau “insinyur perangkat lunak senior yang sangat paham PostgreSQL”, hasil responsnya akan berbeda
      Untuk yang pertama, mungkin akan keluar jawaban bergaya Wellerman seperti “There once was a program that was set to C ...”
      Namun bagian “make no mistakes” memang mencurigakan. Menarik jika dibandingkan hasil dengan dan tanpa frasa itu, lalu juga diuji cara lain untuk mendapatkan perilaku yang sama
    • Ceramah “make no mistakes” itu terlihat cukup lucu. Di YouTube pun sudah sering diejek, tetapi saya bisa membayangkan cara yang mungkin membuatnya bekerja. Misalnya, itu bisa saja ditafsirkan hanya sebagai “tinjau pekerjaan ini”
      Tentu saja, tampaknya tidak ada pihak yang secara terbuka melakukan pengukuran perbandingan seperti ini agar kita bisa sampai pada kesimpulan yang masuk akal