Pilih model berdasarkan bukti

Tentukan keputusan yang diperlukan

Perbandingan model memerlukan penggunaan yang spesifik. Model yang menjelaskan fungsi kecil dengan baik belum tentu sama baiknya dalam menangani perubahan repositori besar. Model berbiaya lebih rendah mungkin memenuhi persyaratan kualitas untuk transformasi rutin. Penyelidikan sulit mungkin memerlukan kemampuan penalaran yang lebih tinggi.

Tuliskan tugas dan batasannya terlebih dahulu. Sertakan data yang diizinkan, alat yang diperlukan, waktu respons, dan biaya maksimum yang dapat diterima. Sebagian batasan bersifat wajib. Jangan mengabaikan pembatasan penanganan data melalui perhitungan rata-rata hanya karena skor lain tinggi.

Gunakan tugas yang mewakili pekerjaan nyata

Buat kumpulan evaluasi kecil dari pekerjaan yang benar-benar dilakukan tim. Hapus data sensitif kecuali lingkungan evaluasi disetujui untuk data tersebut. Sertakan tugas sederhana, tugas sulit, dan tugas yang respons tepatnya adalah meminta informasi yang belum tersedia.

Untuk layanan pelaporan fiktif, gunakan cacat tanggal yang sudah diketahui, fitur filter kecil, dan penjelasan aturan otorisasi. Siapkan hasil yang diharapkan sebelum menjalankan perbandingan. Sertakan pengujian negatif yang menolak cacat yang sudah diketahui.

Pisahkan sebagian tugas dari proses pengembangan prompt. Jika prompt terus disesuaikan menggunakan setiap contoh, skor akhir dapat melebih-lebihkan kinerja umum. Kumpulan terpisah membantu menunjukkan apakah prompt yang diperbaiki juga bekerja di luar contoh yang digunakan untuk membuatnya.

Jaga perbandingan tetap adil

Catat versi model yang tepat, prompt, konteks yang diberikan, alat, dan izin. Gunakan kondisi awal yang setara. Jika satu model menerima repositori lengkap dan model lain menerima satu file, hasilnya membandingkan alur kerja sekaligus model.

Perbandingan alur kerja dapat berguna. Beri label yang tepat. Produk agen mencakup lebih dari model: pemilihan konteks, alat, batas eksekusi, dan perilaku pemulihan dapat memengaruhi hasil.

Jalankan berulang kali jika variasi output berpengaruh. Catat percobaan yang gagal alih-alih melaporkan hanya hasil terbaik. Untuk kriteria subjektif, gunakan rubrik tertulis dan lebih dari satu peninjau jika memungkinkan.

Nilai kualitas sebelum kecepatan

Periksa kriteria penerimaan wajib terlebih dahulu. Apakah perubahan memenuhi persyaratan? Apakah kontrol akses dipertahankan? Apakah pengujian yang relevan lulus? Dapatkah peninjau memahami diff?

Kemudian bandingkan upaya, waktu keseluruhan, dan biaya untuk hasil yang dapat diterima. Sertakan percobaan ulang dan peninjauan manusia. Respons murah yang memerlukan perbaikan berulang dapat menjadi mahal pada tingkat tugas.

Benchmark publik dapat membantu mengidentifikasi kandidat. Benchmark menggunakan kumpulan tugas dan metode penilaian tertentu. Jangan perlakukan skor benchmark sebagai pengukuran langsung produktivitas tim.

Catat keputusan dan kondisi yang membuatnya perlu ditinjau ulang

Hasilnya dapat berupa rekomendasi dengan cakupan terbatas. Misalnya: “Gunakan model ini untuk penambahan pengujian kecil dalam repositori ini, dengan persyaratan peninjauan yang berlaku.” Tidak perlu menggunakan satu model untuk setiap tugas.

Nyatakan hal yang memerlukan evaluasi ulang. Contohnya meliputi perubahan versi model, konfigurasi alat berbeda, kategori data baru, atau pola kegagalan yang terus berulang. Siapkan alternatif untuk tugas yang melebihi kemampuan model terpilih.

Tujuan evaluasi adalah mengurangi ketidakpastian dalam keputusan nyata. Hindari kompetisi model tanpa akhir yang menghabiskan lebih banyak upaya daripada pekerjaan yang didukungnya.