Menyusun Set Evaluasi Berbasis Skenario untuk Sistem AI Bisnis

Set evaluasi berbasis skenario harus merekonstruksi pekerjaan yang dibatasi dengan jelas, bukan sekadar menumpuk pertanyaan sulit. Bayangkan asisten internal untuk permintaan pembelian menerima formulir yang tampak lengkap, identitas pemasok yang bertentangan, hasil pencarian kebijakan yang tidak tersedia, dan instruksi tersembunyi di dalam dokumen penawaran. Contoh prompt yang rapi tidak akan membuktikan apakah asisten meminta bukti tambahan, mengabaikan instruksi dalam lampiran, menjaga kewenangannya, dan menyerahkan keputusan kepada pihak yang tepat. Tim membutuhkan kasus yang dapat diulang, aturan penilaian yang sudah ditetapkan, serta pemisahan bukti pengembangan dan bukti rilis.

Apa saja yang harus dicakup oleh set evaluasi berbasis skenario?

Set tersebut harus mencakup pekerjaan representatif sekaligus kondisi tepi penting, kegagalan yang sudah dikonfirmasi, dan perilaku yang secara tegas dilarang. Mulailah dari satu versi sistem, satu alur kerja, aktor dan masukan yang diizinkan, pengetahuan serta alat yang tersedia, lalu nyatakan keputusan yang akan didukung evaluasi. Untuk asisten permintaan pembelian, batasnya dapat berupa pemeriksaan kelengkapan, pencarian kebijakan yang disetujui, penyusunan catatan tindak lanjut, dan penerusan ke persetujuan manusia. Aturan ini hanya contoh; organisasi harus menetapkan batasnya sendiri.

Petakan keluarga tugas dan variasi yang relevan dari bukti alur kerja yang penggunaannya telah diizinkan, seperti catatan operasional, kasus dukungan, riset pengguna, insiden, dan penelusuran bersama ahli domain. Log produksi tidak otomatis lengkap atau representatif, sedangkan skenario sintetis tidak otomatis buruk; keduanya perlu diperiksa izin, kualitas label, dan kemiripannya dengan pekerjaan sasaran. Bila operasi belum memiliki data memadai, tandai komposisi pekerjaan biasa sebagai hipotesis prapeluncuran. Jangan menciptakan angka presisi untuk menutupi ketidakpastian.

Pada contoh pembelian, cakupan biasa dapat memuat paket yang lengkap dan konsisten. Cakupan terarah menambahkan dokumen wajib yang hilang, nominal atau identitas pemasok yang bertentangan, fakta penentu yang tidak tersedia, permintaan melewati persetujuan, instruksi dalam penawaran, serta hasil pengambilan kebijakan yang usang atau gagal. Reproduksi kegagalan terdahulu harus menggunakan isi sintetis, tersamarkan, atau diminimalkan sesuai kewenangan. Tentukan irisan pelaporan, konsekuensi, gerbang perilaku terlarang, dan penggunaan hasil sebelum melihat keluaran agar kriteria tidak mengikuti sistem yang disukai.

Bagaimana setiap skenario evaluasi harus dicatat?

Setiap skenario harus dicatat sebagai kasus yang dapat dibuat ulang oleh evaluator lain dengan keadaan, bukti, batas, dan metode penilaian yang sama. Berikan identitas kasus yang stabil, pemilik, status, riwayat versi, keluarga cakupan, keluarga tugas, tag irisan, tingkat konsekuensi, kategori asal-usul, catatan otorisasi, dan tujuan penempatan dalam set. Catat pula aktor serta tujuannya, keadaan awal alur, permintaan, lampiran, riwayat yang relevan, pengetahuan yang boleh diakses, alat, izin, hasil alat, kondisi lingkungan, dan instruksi sistem.

• Hasil wajib: fakta yang harus disebutkan, status yang harus tercapai, atau tindakan alur yang benar-benar diperlukan.
• Alternatif yang sah: redaksi, urutan, atau jalur berbeda yang tetap memenuhi tujuan dan batas.
• Respons bersyarat: kapan sistem harus meminta klarifikasi, tidak menyimpulkan, menolak, atau melakukan eskalasi.
• Larangan: keluaran, pengungkapan, panggilan alat, tindakan, atau perubahan status yang tidak boleh terjadi.
• Operasi evaluasi: jenis penilai, rubrik, gerbang, solusi acuan, jumlah uji bila diperlukan, aturan agregasi, kualifikasi peninjau, dan jalur adjudikasi.

Jangan mengubah tugas terbuka menjadi pencocokan satu jawaban ideal. Solusi acuan yang diketahui berfungsi berguna untuk menunjukkan bahwa kasus memang dapat diselesaikan dan untuk memeriksa penilai, tetapi alternatif yang memenuhi bukti dan batas harus tetap diterima. Untuk sistem nondeterministik atau bertahap, tetapkan kebutuhan pengulangan dan aturan agregasinya sebelum keluaran dilihat. Simpan versi model, prompt, korpus pengambilan informasi, alat, kebijakan, izin, dan perangkat uji agar perubahan hasil dapat ditelusuri ke konfigurasi yang benar.

Kasus evaluasi yang berguna merekonstruksi pekerjaan terbatas serta membuat keberhasilan, variasi yang sah, dan larangan dapat diperiksa.

Bagaimana menilai setiap skenario tanpa memberi penghargaan pada perilaku yang salah?

Gunakan metode penilaian paling sempit yang masih dapat membedakan keberhasilan dari kegagalan secara valid. Pemeriksaan deterministik cocok untuk jawaban objektif, skema, perhitungan, argumen alat, status rekaman, atau tindakan yang dilarang. Namun pemeriksaan yang presisi tetap dapat salah atau tidak lengkap, sehingga kasus perlu dibuktikan dapat diselesaikan dan kegagalannya perlu diperiksa. Bila fakta atau keadaan akhir terbatas tetapi redaksi dan jalurnya beragam, nilai terhadap fakta wajib atau solusi acuan, bukan kesamaan kata.

• Pakai rubrik per dimensi dengan jangkar yang dapat diamati untuk mutu terbuka seperti kelengkapan, kegunaan, keterandalan pada sumber, atau kejelasan.
• Kalibrasikan penilai berbasis model terhadap pertimbangan manusia yang berkualifikasi dalam konteks tugas; kesepakatan pada contoh pengembangan saja tidak membuktikan validitas.
• Libatkan ahli yang berwenang ketika interpretasi domain atau konsekuensi tidak dapat diputuskan secara sah oleh pemeriksaan otomatis.
• Izinkan kredit parsial untuk komponen tugas yang bermakna, tetapi tampilkan komponen mana yang gagal.

Pisahkan mutu yang dapat dikompensasi dari gerbang perilaku terlarang. Jawaban yang rapi tidak boleh menutupi pengungkapan rahasia, tindakan tanpa kewenangan, atau perubahan status yang telah dilarang sebelumnya. Ini merupakan pilihan desain editorial, bukan ambang universal: pemilik produk dan risiko yang berwenang harus menentukan larangan serta konsekuensi rilis menurut konteks. Bekukan versi rubrik, logika gerbang, irisan, aturan agregasi, dan keputusan rilis sebelum membandingkan keluaran kandidat. Perubahan sesudahnya harus menghasilkan versi evaluasi baru.

Bagaimana peninjau dapat menerapkan kriteria evaluasi secara konsisten?

Peninjau dapat bekerja lebih konsisten jika mereka menerima konteks tugas yang sama, jangkar yang dapat diamati, latihan kalibrasi, dan jalur jelas saat bukti tidak cukup. Sebelum memperlihatkan keluaran, jelaskan tujuan alur, peran pengguna, bukti yang tersedia, perilaku yang diizinkan, batas produk, serta versi rubrik. Untuk setiap tingkat nilai, berikan contoh positif, negatif, dan kasus batas. Sediakan pilihan tidak-dapat-menilai ketika kasus rusak, konteks hilang, atau keadaan akhir sebenarnya tidak dapat dicapai.

1. Jalankan kasus kalibrasi sebelum penilaian langsung dan ulangi bila campuran tugas, kebijakan, rubrik, atau kelompok peninjau berubah.
2. Samarkan identitas sistem dan urutan keluaran bila praktis untuk perbandingan.
3. Kumpulkan nilai dan alasan secara mandiri sebelum diskusi.
4. Selidiki perbedaan sebagai kemungkinan cacat kasus, ambang kabur, konteks hilang, pilihan sah yang jamak, atau keputusan produk yang belum dibuat.
5. Tetapkan pemilik adjudikasi serta simpan label, alasan, versi rubrik, dan hasil akhirnya.

Tujuan adjudikasi bukan memaksa semua orang menyepakati satu jawaban. Bila dua keluaran sama-sama memenuhi batas, rubrik harus mengakui pluralitas itu; bila kebijakan belum memutuskan batas, keputusan produk harus dibuat oleh pemilik yang berwenang, bukan disamarkan sebagai masalah penilai. Pemeriksaan nilai dan jejak juga membantu membedakan kegagalan sistem dari kasus yang ambigu, penilai yang rapuh, atau lingkungan uji yang rusak. Catatan perbedaan menjadi bahan untuk memperbaiki kasus dan mengalibrasi kembali penilai otomatis.

Bagaimana set evaluasi tetap berguna selama pengembangan dan rilis?

Set evaluasi tetap berguna jika kasus pengembangan yang terlihat dipisahkan dari pengujian rilis yang dilindungi, lalu keduanya dipelihara dalam registri berversi. Tim boleh memakai set pengembangan berulang kali untuk memperbaiki prompt, pengambilan informasi, alat, kebijakan, dan alur. Karena tim telah melihat serta mengoptimalkan sistem terhadap kasus tersebut, hasilnya merupakan bukti pengembangan. Tetapkan keanggotaan set saat kasus masuk registri dan sebelum pelaksanaan rutin atau pemeriksaan keluaran memengaruhi pemilihannya.

• Gunakan pengujian rilis secara hemat untuk perbandingan akhir atau keputusan rilis, dengan akses ketat terhadap kasus, jawaban, rubrik, dan hasil.
• Periksa duplikat persis, kemiripan dekat, sumber rekaman yang sama, parafrasa, serta saudara dari templat skenario di antara set.
• Lacak pihak atau proses yang mengakses isi kasus, solusi acuan, rubrik, dan hasil.
• Pindahkan kasus terlindungi ke set pengembangan atau regresi bila kasus tersebut telah membentuk diagnosis atau perubahan.
• Ganti kasus yang terpapar dengan kasus independen, tidak duplikat, dan berversi untuk menguji kelas kegagalan yang sama.

Registri sebaiknya menyimpan pemilik, asal-usul, otorisasi, keanggotaan set, riwayat keterpaparan, versi isi dan label, riwayat peninjauan, alasan perubahan, serta alasan penghentian. Tambahkan kegagalan produksi atau sinyal dukungan hanya setelah perilaku yang diharapkan diverifikasi dan materi sensitif diminimalkan. Tinjau ulang cakupan ketika pengguna, alur, kebijakan, korpus pengetahuan, model, prompt, alat, izin, atau lingkungan operasi berubah secara material. Tidak ada persentase pembagian, jumlah kasus, atau jadwal penyegaran yang berlaku untuk semua sistem.

Laporkan hasil menurut keluarga tugas, keluarga cakupan, irisan, konsekuensi, dan gerbang, bukan hanya satu rata-rata. Kelulusan offline adalah satu sumber bukti keputusan, bukan sertifikat nilai bisnis, keselamatan, keadilan, kepatuhan, atau kesiapan produksi. Pasangkan evaluasi dengan pemantauan, riset pengguna, tinjauan insiden, dan bukti lain yang sesuai. Pertahankan keputusan hukum, medis, keuangan, ketenagakerjaan, keselamatan, keamanan, privasi, dan bidang teregulasi pada orang yang berkualifikasi serta berwenang; fungsi terkait harus meninjau kasus ketika materi atau pertimbangan dalam kewenangannya digunakan.