Evaluasi sebelum rilis

Ringkasan: Siapkan pertanyaan nyata, kasus tepi, dan pertanyaan yang seharusnya ditolak. Ukur dukungan sumber, kesalahan, biaya dan latensi dengan cara konsisten. Pelajaran ini memperdalam Evaluasi sebelum rilis dengan contoh prototipe yang dapat diperiksa, bukan hanya definisi teknis.

Ini adalah pelajaran 6/7 dalam Tingkat 8: Membangun Aplikasi AI. Pengguna awam dapat mengikuti arsitektur dan tata kelolanya; implementasi kode perlu menyesuaikan dokumentasi platform yang dipilih.

Masalah yang diselesaikan

Siapkan pertanyaan nyata, kasus tepi, dan pertanyaan yang seharusnya ditolak. Ukur dukungan sumber, kesalahan, biaya dan latensi dengan cara konsisten.

Sebuah aplikasi AI selalu terdiri dari kebutuhan pengguna, masukan, data yang berhak diakses, model atau algoritma, kontrol yang dijalankan perangkat lunak, serta keluaran yang dapat dinilai. Kualitas jawaban model hanyalah satu bagian. Kesalahan bisa berasal dari dokumen, integrasi, antarmuka, izin, atau pengaturan versi.

Contoh penerapan

Buat paket 30 pertanyaan uji untuk chatbot peraturan simulasi, termasuk pertanyaan tanpa jawaban. Jangan hanya menilai jawaban yang terdengar sopan.

Anggap kasus tersebut sebagai spesifikasi latihan, bukan produk yang sudah diuji di lapangan. Sebelum menulis kode, ubah kebutuhan menjadi test case: apa yang harus muncul ketika input benar, tidak lengkap, bertentangan, atau di luar cakupan? Hasil yang tidak ditemukan di sumber harus dinyatakan tidak tersedia.

Langkah pembuatan yang dapat diikuti

1. Rancang: Tetapkan rubrik klaim berbukti, menolak bila data kurang, latensi, biaya dan kesalahan berbahaya. Simpan versi prompt.
2. Batasi data: petakan asal berkas, hak baca, masa simpan dan informasi yang tidak boleh terkirim.
3. Bangun prototipe: mulai dari satu fungsi kecil, validasi input dan output, dan siapkan jalur respons saat model gagal.
4. Evaluasi: bandingkan dengan jawaban rujukan, baseline sederhana, biaya dan waktu respons; simpan bukti semua kegagalan.
5. Pelihara: catat perubahan model, prompt, data dan versi aplikasi agar dapat ditelusuri serta dibatalkan bila perlu.

Produk akhir pembelajaran

Artefak: laporan evaluasi dengan hasil per kasus, bukan hanya nilai rata-rata.

Penyerahan yang baik harus memuat cara menjalankan ulang tes, batasan hasil, dan penanggung jawab koreksi. Bila prototipe memakai sumber bergerak seperti kebijakan atau katalog, buat aturan pemutakhiran dan tentukan bagaimana sistem mendeteksi data yang sudah tidak berlaku.

Keamanan dan keterbatasan

Skor keseluruhan tinggi dapat menutup kegagalan pada satu jenis pertanyaan penting.

Hindari menaruh kunci API pada halaman publik atau memberi aplikasi hak administrator bila hanya perlu membaca. Amankan dokumen unggahan dari instruksi yang tidak dipercaya, beri batas permintaan dan biaya, serta rancang penghentian aman. Aplikasi dengan konsekuensi tinggi membutuhkan tinjauan manusia dan pengujian tambahan.

Latihan dan kuis

Tulis tujuan serta batas sistem untuk Evaluasi sebelum rilis dalam tiga kalimat.
Buat minimal lima test case: normal, input kosong, data konflik, permintaan di luar cakupan, dan kegagalan alat.
Tandai data yang diperlukan dan bedakan yang boleh disimpan dari yang tidak.
Jelaskan apa yang dilakukan sistem ketika bukti tidak tersedia dan siapa yang bertanggung jawab.

Mengapa demo bukan bukti produksi siap?

Demo hanya menunjukkan beberapa contoh terpilih. Produksi memerlukan pengujian kasus gagal, kontrol akses, performa, privasi dan kemampuan rollback.

Apa indikator berhasilnya materi ini?

Pembaca dapat menyerahkan artefak Evaluasi sebelum rilis dengan tujuan, contoh, sumber data, metrik, dan prosedur pemeriksaan yang dapat diulang.

Referensi

Transparansi: modul disusun dengan bantuan AI berdasarkan dokumentasi teknis; studi kasus merupakan simulasi. Tidak ada klaim uji perangkat lunak nyata atau keamanan yang telah diaudit.