Menyusun 50 pertanyaan evaluasi yang memprediksi kualitas produksi

Apa yang terjadi

Sebuah tim membangun set evaluasi lima puluh pertanyaan, mendapat skor bagus, merilis, lalu melihat kepuasan pengguna menurun perlahan selama dua bulan tanpa satu metrik pun bergerak. Set-nya tidak salah; ia tidak representatif. Ia mengambil sampel pertanyaan yang jawabannya sudah diketahui pembuatnya — yang menurut konstruksinya justru yang paling baik ditangani sistem.

Mengapa ini penting bagi tim deployment

Set evaluasi adalah instrumen statistik, dan satu-satunya tugasnya adalah memprediksi perilaku pada traffic yang belum pernah Anda lihat. Set yang dibangun dari imajinasi tim akan melebih-lebihkan kualitas tepat pada dimensi yang dipahami tim, dan membisu pada yang tidak mereka pahami: jargon, kueri yang tidak berbentuk, pertanyaan yang melintasi dua dokumen, dan pertanyaan yang sama sekali tidak bisa dijawab korpus.

Cara membangunnya

Ambil dari kenyataan sedapat mungkin — tiket support, log pencarian, pertanyaan yang sering ditanyakan ke sales. Kalau tidak bisa, minta orang yang melakukan pekerjaan itu setiap hari yang menulisnya, bukan orang yang membangun sistemnya. Lalu paksa komposisinya. Sekitar empat puluh harus bisa dijawab, tersebar di berbagai tingkat kesulitan. Lima harus tidak bisa dijawab dari korpus, untuk menguji apakah sistem menolak, bukan mengarang. Lima lagi sebaiknya punya dokumen pengecoh yang tampak relevan padahal tidak.

Menjaganya tetap jujur

Segarkan set-nya tiap kuartal dan jangan pernah biarkan model melihatnya selama pengembangan, atau Anda akan men-tune ke arahnya. Catat sampel kueri live tiap minggu dan periksa apakah masih mirip dengan set Anda; saat tidak mirip lagi, set-nya sudah kedaluwarsa. Dan anggap regresi lebih dari lima poin pada context recall sebagai kegagalan build, karena metrik yang tidak ditegakkan adalah metrik yang akan diabaikan pada minggu sebelum tenggat.