Kegagalan Metrik dalam Perbaikan Kerentanan Kode Berbasis LLM: Studi Empiris dan Screen Berbasis Perubahan

Hasil secara kolektif berargumen bahwa compile rate bukan ukuran kemajuan yang valid untuk perbaikan kerentanan berbasis LLM. Metrik ini gagal di berbagai sisi: tidak sensitif terhadap perbaikan yang asli, didominasi artefak, sangat sensitif terhadap konfigurasi kompilator, berbanding terbalik dengan peringkat kemiripan referensi, dan dapat digaming saat digunakan sebagai target optimisasi. Temuan bahwa **~64% kegagalan kompilasi tidak dapat diatribusikan ke model** dan proporsi ini hampir invarian di seluruh model menunjukkan bahwa sebagian besar variasi compile rate yang dilaporkan mencerminkan infrastruktur evaluasi alih-alih kapabilitas model. **Pergeseran 1,8–2,7×** pada patch identik di bawah satu flag standar kompilator semakin melemahkan komparabilitas antar-studi.

Patologi optimisasi sangat mengkhawatirkan: loop umpan balik kompilator menaikkan compile rate sementara kemiripan dengan perbaikan manusia menurun, dan inspeksi manual mengungkap **non-perbaikan bergaya penghapusan dan placeholder**. Ini berarti mengoptimalkan compile rate dapat secara aktif memilih patch yang tidak memperbaiki kerentanan. Kegagalan CodeBLEU fungsi utuh—di mana salinan tak berubah dari input rentan mengalahkan setiap model—menunjukkan bahwa fallback alaminya juga tidak memadai.

Screen **diff_F1** yang diusulkan mengatasi sebagian masalah dengan hanya menilai wilayah yang disunting. Ia memberi kredit tepat nol pada no-op dan kredit mendekati nol pada sebagian, meski tidak semua, patch gaming berbasis penghapusan, sambil tetap memberi kredit pada suntingan parsial yang asli. Ini menjadikannya screen murah yang berguna sebelum analisis berbasis eksekusi yang lebih dalam. Namun, penulis secara eksplisit menyatakan bahwa diff_F1 **bukan metrik kualitas perbaikan** dan melaporkan di mana ia kurang. Rekomendasi keseluruhannya adalah bergerak menuju **evaluasi berbasis perubahan dan berbasis eksekusi** untuk perbaikan kerentanan berbasis LLM.

**Formalisasi screen.** Misalkan suntingan referensi adalah ${\Delta }_{\text{ref}}$ dan suntingan yang diprediksi adalah ${\Delta }_{\text{pred}}$. Screen berbasis perubahan seperti diff_F1 dapat dinyatakan sebagai kemiripan atas wilayah yang disunting:

Untuk no-op,

**Pipeline evaluasi dengan penyaringan berbasis perubahan.**

**Implikasi.** Studi ini menyerukan evaluasi berbasis perubahan dan berbasis eksekusi. Compile rate dan CodeBLEU fungsi utuh tidak boleh digunakan sebagai metrik utama untuk perbaikan kerentanan fungsi tunggal. diff_F1 dapat berfungsi sebagai pra-filter murah, tetapi penilaian akhir memerlukan analisis berbasis eksekusi. Penulis juga mencatat bahwa diff_F1 bukan metrik kualitas perbaikan dan melaporkan batasannya, termasuk bahwa ia tidak menangkap semua patch gaming berbasis penghapusan.