Rubrik evaluasi adalah teori tentang pekerjaan yang baik

Balasan tentang pesanan yang dikembalikan tampak siap dikirim: tata bahasanya benar, ramah, dan singkat. Dalam kasus ilustratif ini, penilaian otomatis memberinya nilai penuh. Asisten juga mengatakan kepada pelanggan bahwa pengembalian dana telah dilakukan, padahal tidak ada yang memeriksa sistem pembayaran.

Kesalahannya bukan kalimat yang buruk. Kesalahannya adalah definisi baik yang buruk.

Dalam demonstrasi evaluasi yang dipelajari, sebuah tim membuat skor untuk agen yang menulis dokumentasi perangkat lunak. Saat yang menarik adalah ketika orang yang memahami pekerjaan menjelaskan makna kualitas, lalu sebuah alat mengubah penjelasan itu menjadi kriteria. Kemudian, skor rendah memicu keraguan yang tepat: mungkin agen perlu diperbaiki, atau mungkin evaluasinya.

Rubrik adalah teori tentang tugas. Uji teorinya.

Mulailah dari kesalahan yang menggugurkan

Tim sering memulai dari aspek yang mudah dinilai: kejelasan, nada, struktur, kelengkapan. Aspek itu berguna. Namun, jarang cukup.

Untuk balasan pengembalian dana ilustratif, “jangan pernah mengklaim dana sudah dikembalikan tanpa bukti pembayaran” lebih penting daripada mutu prosa. Untuk sinkronisasi data, “jangan petakan email penagihan ke email pemilik akun” lebih penting daripada kelancaran penjelasan pemetaan bidang.

Mintalah ahli ranah menyediakan tiga jenis kasus: satu yang jelas baik, satu yang jelas salah, dan satu yang dapat diperdebatkan oleh orang-orang yang sama-sama memahami tugas. Simpan catatan sumber dan alasan tiap penilaian. Jika kasus bergantung pada aturan yang dapat berubah, beri versi pada aturan beserta labelnya.

Putaran pertama boleh kecil. Namun, tidak boleh kabur.

1. Penanggung jawab tugas

   kasus baik, buruk, dan diperdebatkan

   mendasari
2. Pemeriksaan pasti identitas · izin · tujuan

   kode menegakkan fakta

   mendasari
3. Rubrik semantik

   nilai hanya yang perlu ditafsirkan

   mendasari
4. Tinjauan ketidaksepakatan

   perbaiki label dan kriteria

Pemeriksaan	Penanggung jawab yang lebih tepat	Mengapa
Izin wajib tersedia	Kode dan catatan resmi	Faktanya pasti dan berdampak
ID tujuan cocok dengan identitas sumber	Kode dan catatan uji	Model tidak boleh menebak pengenal
Balasan menjawab pertanyaan pelanggan	Rubrik yang ditinjau manusia, mungkin model penilai	Makna perlu ditafsirkan
Nada sesuai dengan situasi	Rubrik yang ditinjau manusia, mungkin model penilai	Ada lebih dari satu bentuk yang dapat diterima

Panduan penerapan AI dalam alur kerja yang sudah ada menempatkan penilaian model di dalam alur yang mempunyai kendali dan hasil nyata. Pada batas ini, kode harus menjaga nilai asli serta memeriksa aturan setelah model memilih kemungkinan. Keyakinan model tidak berubah menjadi izin.

Skor mewarisi titik buta rubrik

Keberatan yang wajar adalah: “Manusia tidak dapat meninjau setiap eksekusi agen. Kami membutuhkan penilai yang dapat bekerja pada banyak kasus.” Ya. Pertanyaannya adalah apa yang diperbanyak oleh penilai itu.

Jika rubrik menghargai jawaban yang rapi tetapi tidak pernah memeriksa apakah pesanan benar-benar dikembalikan dananya, otomatisasi akan memperbanyak kelalaian itu. Angka dengan dua tempat desimal tampak presisi. Angka itu masih dapat mengukur hal yang salah.

Dokumentasi Google Cloud tentang evaluasi model penilai menggambarkan pemeriksaan praktis: siapkan kasus dengan nilai manusia, jalankan ukuran berbasis model, lalu bandingkan skornya dengan nilai tersebut. Intinya bukan bahwa pendapat satu orang tidak pernah salah. Model memerlukan acuan dari luar sebelum skornya diberi bobot.

Periksa perbedaan penilaian, bukan hanya rata-rata kesesuaian. Jika model meloloskan balasan yang ditolak pemimpin dukungan, tanyakan kriteria apa yang hilang. Jika dua ahli berbeda pendapat, simpan kedua label dan temukan aturan yang mereka tafsirkan secara berbeda. Jangan meratakan sengketa secara diam-diam.

Pemilihan sampel sama pentingnya dengan redaksi kriteria. Kumpulan keberhasilan rutin dapat membuat penilai terlihat andal sambil mengabaikan kasus sulit. Sertakan catatan tidak lengkap, instruksi bertentangan, dan kasus ketika jawaban benar adalah berhenti lalu bertanya. Simpan kumpulan kasus terpisah yang tidak dipakai penulis rubrik untuk penyesuaian, agar perubahan yang memperbaiki contoh familier juga harus membuktikan dirinya di tempat lain. Ketika aturan bisnis berubah, perbarui label dan hasil yang diharapkan; kumpulan uji beku dapat menghargai kebijakan kemarin.

Hubungkan evaluasi dengan hasil

Rubrik untuk agen sinkronisasi harus mengikuti hasil bagi pelanggan. Apakah kontak yang benar berubah? Apakah persetujuan dihormati? Dapatkah catatan gagal diputar ulang tanpa mengulang tindakan yang berdampak?

Panduan konektor Brevo menjelaskan mengapa panggilan API yang berhasil dapat beriringan dengan atribut yang hilang. Evaluasi yang hanya memeriksa pemanggilan titik akses akan melewatkan hasil. Evaluasi yang hanya memeriksa sistem tujuan mungkin melewatkan jalur terlarang yang kebetulan berakhir pada nilai tepat. Keduanya penting ketika jalur membawa risiko.

Mulailah dari satu tugas sempit dan beberapa cara gagal. Beri label kasus bersama orang yang bertanggung jawab atas tugas. Tempatkan pemeriksaan pasti dalam kode dan gunakan model penilai hanya ketika bahasa atau penilaian benar-benar memerlukannya. Jalankan kasus yang sama setelah prompt, model, atau alat berubah. Catat apa yang diajarkan kegagalan berikutnya tentang rubrik.

Biayanya adalah waktu ahli di awal. Manfaatnya adalah setiap skor berikutnya mempunyai makna yang dapat dijelaskan.

Dasbor dapat menampilkan skor. Hanya rubrik yang memberi tahu apa yang dihitung.