Cara membangun set evaluasi dari lalu lintas nyata

Mengapa tidak menulis pertanyaan dari dokumentasi

Dokumentasi menjelaskan sistem sesuai dengan pemahaman penulisnya. Pertanyaan yang dihasilkan dari dokumentasi berbagi asumsi penulis, muncul dalam korpus pengambilan sebagai paraphrase, dan berkumpul di sekitar bagian produk yang didokumentasikan dengan baik daripada bagian yang digunakan. Suite yang dihasilkan mudah dilewati dan lambat berubah.

Lalu lintas nyata memiliki distribusi yang berlawanan, itulah sebabnya patut dilakukan upaya untuk mengumpulkannya.

Empat sumber, berdasarkan urutan kegunaan

Log pencarian. Query yang sebenarnya diketik oleh pengguna, termasuk yang tidak menghasilkan apa-apa. Query tanpa hasil adalah sumber termurah dari item evaluasi berharga yang ada, karena telah difilter sebelumnya untuk topik yang belum ditangani sistem.

Tiket dukungan dan pertanyaan internal. Setiap kali manusia ditanya dan menjawab pertanyaan yang seharusnya ditangani sistem, itu adalah pertanyaan dengan jawaban yang benar dan biaya yang telah diidentifikasi. Item-item ini juga kemungkinan besar difrasakan dengan cara pengguna nyata.

Sesi yang ditinggalkan. Pengguna yang memulai, mengetik sesuatu, dan meninggalkan tanpa menyelesaikan. Lebih sulit diinterpretasikan, tetapi mereka menandai batas di mana sistem saat ini gagal dengan cara yang data kepuasan tidak bisa.

Pengingatan ahli, dengan sengaja dibatasi. Duduk dengan dua atau tiga orang yang melakukan pekerjaan dan tanyakan apa yang paling sering mereka tanyakan dan apa yang jawabannya bergantung. Gunakan ini untuk mengisi kesenjangan yang tidak dapat ditunjukkan log, seperti pertanyaan yang diajukan dalam pertemuan dan tidak pernah diketik. Batasi waktu yang dihabiskan di sini; tujuannya adalah cakupan, bukan volume.

Menulis item yang bertahan dari penilaian ulang

• Simpan pertanyaan tepat seperti yang difrasakan pengguna, termasuk kesalahan ketik dan singkatan. Menulis ulang menjadi bahasa yang bersih menghilangkan bagian yang sulit.
• Nyatakan jawaban yang diharapkan dan alasan mengapa jawaban itu benar. Alasan itu membuat item dapat dinilai ulang oleh orang lain dan mencegah kriteria bergeser secara diam-diam.
• Catat apa yang seharusnya dilakukan ketika jawaban tidak ada dalam korpus. Sekitar seperlima item seharusnya tidak dapat dijawab, dan menolak dengan bersih seharusnya dinilai sebagai lulus.
• Berikan tag pada setiap item dengan kemampuan yang dilatih — pengambilan, aritmatika atas nilai yang diambil, sintesis multi-dokumen, penolakan — sehingga kegagalan menunjuk pada komponen bukan pada sistem.
• Catat sumber dan tanggal. Item yang diambil dari insiden sementara berhenti valid ketika data insiden meninggalkan korpus.

Menjalankannya sebagai kebiasaan

Contoh bulanan, bukan sekali. Tinjau suite secara triwulanan dan hapus apa yang tidak lagi mencerminkan produk. Simpan satu irisan yang dinilai manusia secara permanen, karena itu adalah bagian satu-satunya yang memperhatikan ketika definisi jawaban yang baik bergeser.

Run pertama akan tidak nyaman. Suite yang dibangun dari lalu lintas biasanya melaporkan kualitas yang jauh lebih rendah daripada suite yang dihasilkan dari dokumentasi yang digantikannya, dan kesenjangan itu adalah jumlah kualitas yang suite lama sembunyikan. Laporkan kedua angka secara berdampingan, atributkan perbedaan pada perubahan kriteria, dan kemudian kerja dari baseline yang jujur.