Fitur AI pertama di sebuah produk hampir selalu dirilis dengan cara yang sama: seseorang mencobanya dua puluh kali, hasilnya terlihat bagus, lalu fiturnya dinyalakan. Test suite-nya hijau — tetapi yang hijau adalah kode di sekelilingnya, bukan bagian yang baru. Bagian yang baru tidak diuji siapa pun, karena tidak jelas bagaimana cara mengujinya.
Ini bukan kemalasan. Alat yang biasa dipakai memang berhenti bekerja di sini, dan alasannya layak dipahami sebelum menggantinya.
Kenapa assertion berhenti bekerja
Sebuah unit test berdiri di atas satu asumsi: masukan yang sama menghasilkan keluaran yang sama, dan keluaran yang benar hanya satu. Dua-duanya tidak berlaku untuk keluaran model bahasa.
Masukan yang sama tidak menghasilkan keluaran yang sama — dan menurunkan suhu ke nol tidak sepenuhnya menghilangkannya, karena penyedia model juga mengubah apa yang berjalan di belakang nama model yang sama. Lebih menentukan lagi: keluaran yang benar tidak tunggal. Sebuah ringkasan tiket dukungan bisa ditulis dengan lima puluh cara yang seluruhnya benar. Membandingkannya dengan satu string yang diharapkan akan menandai empat puluh sembilan di antaranya sebagai kegagalan.
Jadi yang perlu diganti bukan kerangka pengujiannya, melainkan bentuk pertanyaannya. Bukan lagi “apakah keluarannya persis ini”, melainkan “apakah keluarannya memenuhi syarat yang membuatnya berguna”.
Kumpulan contoh, bukan kumpulan asumsi
Semua yang dijelaskan di bawah bergantung pada satu bahan: sekumpulan masukan nyata beserta apa yang seharusnya terjadi pada masing-masing. Ini yang biasanya disebut eval set.
Ambil isinya dari lalu lintas produk Anda yang sesungguhnya, bukan dari contoh yang Anda karang di meja. Contoh karangan selalu lebih rapi daripada kenyataan: kalimatnya utuh, tidak ada salah ketik, tidak ada dua pertanyaan yang ditumpuk dalam satu kalimat, tidak ada tempelan potongan email berisi tanda tangan tiga baris. Fitur yang lulus pada contoh karangan dan gagal di produksi hampir selalu gagal pada bentuk masukan yang tidak pernah terbayang.
Jangan tanya berapa banyak yang cukup — tanya bentuk kegagalan apa saja yang sudah terwakili. Kumpulan yang berisi banyak contoh dari satu bentuk lebih lemah daripada kumpulan yang lebih kecil tetapi mencakup masukan kosong, masukan yang sangat panjang, masukan dalam bahasa yang tidak Anda antisipasi, dan masukan yang seharusnya ditolak fitur itu.
Bila fitur Anda memproses data pribadi pengguna, kumpulan contoh itu ikut memuatnya, dan ia tunduk pada kewajiban yang sama seperti data produksi lainnya — termasuk saat ia ikut terkirim ke model yang servernya di luar negeri. Perinciannya ada di tulisan tentang transfer data ke luar Indonesia.
Tiga jenis pemeriksaan yang menggantikannya
1. Pemeriksaan bentuk, dan ini tetap deterministik
Jenis ini paling sering dilewati karena terdengar terlalu sederhana, padahal ia menangkap porsi kegagalan yang besar dan berjalan tanpa biaya model sama sekali. Ia memeriksa hal-hal yang punya jawaban benar-salah:
- Apakah keluarannya JSON yang sah, dan apakah setiap field yang Anda butuhkan ada?
- Apakah setiap ID, nama produk, atau nomor dokumen yang disebut benar-benar ada di basis data Anda?
- Apakah panjangnya masuk akal — bukan kosong, bukan sepuluh kali lipat dari yang diminta?
- Apakah kategori yang dipilihnya termasuk dalam daftar kategori yang sah?
- Apakah ada data pribadi yang muncul di tempat yang seharusnya tidak memuatnya?
Pemeriksaan kutipan pada butir kedua adalah yang paling berharga dari semuanya. Model yang mengarang nomor faktur akan mengarangnya dalam format yang sempurna, dan mata manusia yang menelaah dua puluh contoh tidak akan menyadarinya. Kode yang mencocokkannya ke basis data akan menyadarinya setiap kali.
2. Pemeriksaan terhadap sumber
Untuk fitur yang menjawab dari dokumen Anda sendiri, pertanyaan yang paling menentukan bukan “apakah jawabannya bagus” melainkan “apakah jawabannya ada di dokumen itu”. Keduanya berbeda, dan yang kedua bisa diperiksa jauh lebih tegas.
Untuk tiap contoh, catat fakta yang wajib muncul dan potongan sumber tempat fakta itu berada. Pemeriksaannya kemudian menanyakan dua hal terpisah: apakah fakta wajib itu ada, dan apakah ada pernyataan lain yang tidak berasal dari sumber mana pun. Kegagalan pada pertanyaan kedua — pernyataan tambahan yang tidak bersumber — adalah bentuk kegagalan yang paling merusak kepercayaan pengguna, sekaligus yang paling jarang diuji.
3. Penilaian oleh model, dengan kesadaran akan batasnya
Sisa pertanyaannya — apakah nadanya sesuai, apakah jawabannya menjawab yang ditanyakan, apakah ringkasannya menangkap hal yang penting — tidak punya pemeriksaan mekanis. Di sinilah model kedua dipakai untuk memberi skor terhadap rubrik yang Anda tulis.
Cara ini bekerja, dengan dua syarat yang sering diabaikan. Pertama, rubriknya harus berupa pertanyaan tertutup, bukan permintaan menilai “kualitas” dalam skala satu sampai sepuluh — skor semacam itu tidak stabil dan tidak bisa dibandingkan antar-rilis. Tanyakan hal yang jawabannya ya atau tidak: apakah jawaban ini menyebut nama produk yang salah? Apakah ia menjanjikan sesuatu yang tidak ada di kebijakan?
Kedua, penilainya punya kelemahan yang sama dengan yang dinilai. Ia bisa salah, dan ia cenderung salah pada kasus yang sama. Karena itu ia dipakai untuk pertanyaan yang tidak punya jalan lain — bukan untuk menggantikan dua jenis pemeriksaan sebelumnya, yang lebih murah sekaligus lebih dapat diandalkan.
Angka yang keluar tidak berarti apa-apa tanpa dua hal
Sebuah eval yang melaporkan bahwa 87 persen contoh lulus tidak memberi tahu Anda apa pun tentang layak atau tidaknya fitur itu dirilis. Angka itu baru punya arti setelah ada dua hal di sebelahnya.
Sebuah baseline. Berapa angkanya kemarin, sebelum perubahan yang sedang Anda uji? Nilai sebenarnya dari eval bukan angka mutlaknya, melainkan arah geraknya. Perubahan prompt yang menaikkan satu jenis keluaran dan menurunkan jenis lain terlihat seperti perbaikan bila Anda hanya memeriksanya dengan tangan, dan terlihat seperti apa adanya bila ada angka pembanding.
Sebuah ambang yang ditetapkan lebih dulu. Ambang yang ditentukan setelah melihat hasilnya bukan ambang, melainkan pembenaran. Tetapkan sebelum eval dijalankan, dan tetapkan per jenis kegagalan, bukan satu angka gabungan — karena tidak semua kegagalan setara. Kesalahan nada dapat ditoleransi; nomor faktur yang dikarang tidak. Menggabungkan keduanya ke satu persentase menyembunyikan justru yang tidak boleh disembunyikan.
Yang paling sering dilewatkan
Eval dijalankan terhadap versi yang dipakai saat mengembangkan, lalu yang dirilis adalah versi lain: model yang berbeda karena yang satu lebih murah, prompt yang disunting sedikit di menit terakhir, atau nama model yang sama tetapi penyedianya sudah memperbaruinya di belakang layar.
Kunci konfigurasi yang diuji — nama model, versinya bila penyedia Anda menyediakannya, prompt, dan parameternya — lalu jalankan ulang eval-nya terhadap konfigurasi yang benar-benar akan berangkat. Ini juga alasan eval bukan pekerjaan sekali jadi: ia perlu dijalankan ulang secara berkala meski Anda tidak mengubah apa pun, karena yang di hulu berubah tanpa memberi tahu Anda. Menjaga hal semacam ini tetap berjalan setelah fiturnya menyala adalah pekerjaan tersendiri, dan itu yang kami maksud dengan mengelola AI setelah ia hidup.
Dua pertanyaan untuk menguji kesiapan
- Bila seseorang di tim Anda mengubah satu kalimat di prompt besok pagi, berapa lama sampai Anda tahu apakah perubahan itu memperbaiki atau merusak sesuatu — dan apakah jawabannya berasal dari data atau dari kesan?
- Bentuk kegagalan mana yang Anda anggap tidak dapat ditoleransi sama sekali, dan apakah ada satu pemeriksaan yang secara khusus mencarinya?
Bila fitur yang ingin Anda uji belum ada bentuknya, halaman Solusi memuat enam bentuk fitur AI yang paling sering dibutuhkan produk SaaS, dan pengembangan solusi AI menjelaskan bagaimana Pintarin membangunnya bersama tim Anda.