Bagaimana cara memprogram dengan LLM

Masalah kedua adalah kita bisa berbuat lebih baik. Saya senang bahwa kita sekarang hidup di masa di mana pemrogram menulis pengujian mereka sendiri, tetapi kita tidak menerapkan standar pengujian yang sama seperti yang kita lakukan dengan kode produksi. Itu adalah trade-off yang masuk akal; Hari ini memiliki jumlah jam yang terbatas. Namun kekurangan LLM dalam keterampilan aritmatika, mereka menutupinya dengan antusiasme.

Mari kita minta bukti yang lebih baik lagi.

Dalam pengujian, terapkan versi kode standar kuartil yang paling sederhana dan paling mudah dibaca pada kumpulan nilai tetap yang diketahui dalam suatu segmen. Kemudian jalankan kasus uji melalui kode standar dan sampler reservoir dan konfirmasikan bahwa keduanya berada dalam satu epsilon satu sama lain. Susun kode perbandingan sehingga dapat juga digunakan dalam pengujian fuzzy.

Ini memberi kami kode pengujian baru:

// referenceQuartiles calculates the exact quartiles for a slice of float64 values  
// using linear interpolation, matching the behavior expected from the sampler.  
func referenceQuartiles(data []float64) (q1, median, q3 float64) { … }

// compareQuartiles checks if two sets of quartiles are within epsilon of each other.  
// Returns true if they match within the tolerance, false otherwise.  
func compareQuartiles(q1a, meda, q3a, q1b, medb, q3b, epsilon float64) bool { … }

// checkQuartiles is a test helper that compares sampler output against the reference  
// implementation and reports any differences.  
func checkQuartiles(t *testing.T, data []float64, epsilon float64) {  
   t.Helper()  
    
   // Get reference values  
   wantQ1, wantMed, wantQ3 := referenceQuartiles(data)  
    
   // Get sampler values using a large reservoir for accuracy  
   qs := NewQuartileSampler(1000)  
   for _, v := range data {  
       qs.Add(v)  
   }  
   gotQ1, gotMed, gotQ3 := qs.Quartiles()  
    
   if !compareQuartiles(gotQ1, gotMed, gotQ3, wantQ1, wantMed, wantQ3, epsilon) {  
       t.Errorf("Quartiles mismatch:ngot  (q1=%v, med=%v, q3=%v)nwant (q1=%v, med=%v, q3=%v)nepsilon=%v",  
           gotQ1, gotMed, gotQ3, wantQ1, wantMed, wantQ3, epsilon)  
   }  
}

Tes asli di atas telah dimodifikasi untuk menggunakan checkQuartiles dan kami memiliki sesuatu yang baru:

func FuzzQuartileSampler(f *testing.F) {  
   // Add some seed corpus  
   f.Add([]float64{1, 2, 3, 4, 5})  
    
   f.Fuzz(func(t *testing.T, data []float64) {  
       // Use a larger epsilon for fuzzing since we might get more extreme values  
       checkQuartiles(t, data, 0.2)  
   })  
}

Ini lucu karena itu salah. karir saya gopls Alat tersebut segera mengatakan:

fuzzing arguments can only have the following types:
    string, bool, float32, float64,
    int, int8, int16, int32, int64,
    uint, uint8, uint16, uint32, uint64,
    []byte

Menempelkan kesalahan itu kembali ke LLM akan membuat ulang pengujian fuzzy sehingga dibuat berdasarkan a func(t *testing.T, data []byte) fungsi yang menggunakan math.Float64frombits untuk mengekstrak float dari segmen data. Interaksi seperti ini mengarahkan kita pada otomatisasi umpan balik alat; yang saya butuhkan hanyalah pesan kesalahan yang jelas untuk membuat kemajuan yang solid menuju sesuatu yang bermanfaat. Itu tidak perlu.

Melakukan survei singkat pada beberapa minggu terakhir riwayat obrolan LLM saya menunjukkan (yang, seperti saya sebutkan di atas, bukanlah analisis kuantitatif yang memadai dengan ukuran apa pun) bahwa lebih dari 80 persen waktu terdapat kesalahan perkakas, LLM dapat membuat kemajuan yang bermanfaat tanpa saya menambahkan ide apa pun. Sekitar separuh waktu, dia dapat menyelesaikan masalah sepenuhnya tanpa saya mengatakan sesuatu yang penting. Saya hanya bertindak sebagai pembawa pesan.