isi
Masalah Harness karya Can Bölük menunjukkan bahwa edit bergaya hashline (dengan nomor baris sebagai acuan, seperti 4#WB) mengungguli edit mode replace tradisional (pencocokan old_string/new_string) untuk agen pemrograman.
Saya sedang bereksperimen membangun harness sendiri (tau), dan ingin memverifikasi hasil ini serta melihat apakah saya perlu mempertimbangkan hashline sebagai strategi edit bawaan di sana.
Jadi, saya membuat edit-bench untuk mengujinya sendiri pada berbagai bahasa dan model.
Pengaturan
edit-bench menghasilkan pengujian berbasis mutasi dari basis kode yang sudah ada. Anda mengarahkan skrip ke suatu direktori, lalu skrip itu menghasilkan mutasi seperti menghapus pernyataan, membalik nilai boolean, menukar argumen, dan sebagainya.
- Bahasa: Python (dari hive), TypeScript (dari oh-my-pi), Rust (dari irradiate)
- Model:
gpt-4.1-mini,google/gemini-3-flash-preview,qwen/qwen3.5-397b-a17b - Mode edit: replace (old_string/new_string) vs hashline (dengan nomor baris sebagai acuan)
- 20 tugas per bahasa, eksekusi one-shot dengan satu percobaan
- Saya juga baru-baru ini menambahkan pencocokan fuzzy ke
tau(trim bertingkat:trim_end → trim_both → unicode normalization) dan ingin melihat apakah ini membantu
Hasil
Mode replace:
| Model | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
Mode hashline (dari pengujian sebelumnya):
| Model | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline menurunkan kinerja pada Python secara nyata, dan tampaknya relatif netral pada TypeScript dan Rust. Ketergantungan pada bahasa ini menarik — whitespace yang bermakna secara sintaksis dalam Python mungkin membuat edit berbasis acuan baris lebih rentan terhadap kesalahan.
Apakah Pencocokan Fuzzy Membantu?
Tampaknya tidak.
Saya menambahkan pengumpulan trace untuk melihat apakah mekanisme trim bertingkat untuk pencocokan fuzzy di tau pernah aktif selama eksekusi mode replace. Dari 114 edit yang berhasil dan 20 edit yang gagal (3 model × 3 bahasa), pencocokan fuzzy terpicu nol kali.
Dari 20 edit yang gagal tersebut:
- 1 memiliki whitespace di akhir (secara teori dapat diperbaiki)
- ~8 menyertakan nomor baris dalam
old_string(bug pada model) - ~11 berisi konten yang sepenuhnya merupakan halusinasi
Ketika model menghasilkan old_string dengan benar, whitespace-nya juga benar.
Ketika model salah, hasilnya meleset jauh — trim bertingkat tidak membantu.
Kesimpulan
-
Tidak ada pemenang yang jelas antara hashline dan replace. Pengaruhnya bergantung pada bahasa dan model. Hashline berkinerja lebih buruk pada Python; hasil pada TypeScript netral; pada Rust, hasilnya bisa condong ke salah satu.
-
Hasil Can sulit digeneralisasi. react-edit-benchmark hanya mencakup JavaScript dan menggunakan LSP untuk umpan balik validasi. Pengaturan kami (tanpa LSP, dengan beberapa bahasa) menunjukkan gambaran yang berbeda. Secara khusus, siklus umpan balik LSP kemungkinan menjadi faktor perancu. Memberi model pesan kesalahan tipe sebagai acuan untuk mencoba ulang memberikan peningkatan berarti yang berinteraksi dengan format edit.
-
Pencocokan fuzzy bukan persoalan bagi model saat ini. LLM mereproduksi teks sumber secara persis atau menghalusinasikan sesuatu yang sama sekali berbeda. Kasus yang hanya meleset pada whitespace, yang menjadi sasaran pencocokan fuzzy, pada dasarnya tidak terjadi dalam praktik.
-
Untuk model generasi saat ini dalam harness modern, format edit bukan hambatan utama. Kesenjangan antarmodel (gemini-3-flash pada 90%+ vs gpt-4.1-mini pada 55-65%) jauh lebih besar daripada kesenjangan antarformat edit. Fokuskan upaya pada pemilihan model dan rekayasa prompt sebelum mengkhawatirkan format edit.
Penafian wajib: n kecil, tidak ketat secara statistik, jadi sikapi hasilnya dengan mempertimbangkan hal itu.
Semua data: nwyin/edit-bench, issue #13 dan #14.