GenZiGenZi® Ceritakan kebutuhanmu ↗

Menguji agen AI sebelum dipakai pelanggan: urutan pemeriksaan yang dijalankan lebih dulu

Agen percakapan tidak gagal dengan cara yang sama seperti formulir. Formulir yang salah isian menolak masukan, sedangkan agen tetap menjawab, dan jawaban yang keliru baru terlihat setelah terkirim. Pengujian sebelum rilis karena itu memeriksa perilaku pada percakapan yang pernah terjadi, bukan daftar fitur.

Agen AI yang menjawab pelanggan tidak gagal dengan cara yang sama seperti formulir biasa. Formulir yang salah isian menolak masukan dan menampilkan pesan galat, sedangkan agen percakapan tetap menjawab. Jawaban yang keliru baru terlihat setelah terkirim, sering setelah pelanggan membacanya. Karena itu pengujian sebelum rilis bukan pemeriksaan fitur, melainkan pemeriksaan perilaku pada percakapan yang pernah terjadi.

Urutan di bawah ini adalah urutan yang dipakai GenZi saat menyiapkan agen percakapan untuk klien. Tidak ada alat khusus yang wajib; yang wajib adalah skenario yang ditulis lebih dulu, hasil yang dicatat, dan keputusan berhenti yang ditetapkan sebelum rilis.

Pemeriksaan yang umum dilakukan adalah memastikan agen bisa membalas, bisa memanggil alat, dan bisa mengirim pesan. Ketiganya hanya membuktikan sistem terhubung, bukan bahwa jawabannya layak dikirim ke pelanggan pada pertanyaan yang canggung, berulang, atau berada di luar cakupan.

Definisi kerja: uji agen percakapan adalah menjalankan satu set percakapan acuan terhadap versi agen tertentu, lalu mencatat jawaban dan tindakannya untuk dibandingkan dengan jawaban acuan yang ditulis manusia.

Tiga hal diperiksa pada setiap percakapan: isi jawaban, tindakan yang diambil agen, dan keputusan berhenti. Yang ketiga paling sering terlewat, padahal paling menentukan pengalaman pelanggan.

Menyusun skenario dari percakapan yang sudah ada

Bahan uji tidak perlu dikarang. Arsip percakapan satu bulan terakhir, dari kanal mana pun yang sudah dipakai, cukup untuk menyusun dua puluh sampai tiga puluh skenario yang mewakili sebagian besar beban kerja. Skenario yang layak masuk daftar adalah yang memuat setidaknya satu dari keadaan berikut:

  • pertanyaan yang jawabannya berubah-ubah, misalnya ketersediaan barang atau jadwal layanan
  • keluhan yang menuntut permintaan maaf, bukan penjelasan teknis
  • pesan setengah jadi, singkatan, salah tulis, atau campuran dua bahasa
  • permintaan di luar cakupan layanan
  • permintaan yang datang berulang dari orang yang sama
  • percakapan yang berakhir tanpa keputusan jelas

Setiap skenario diberi jawaban acuan yang ditulis manusia sebelum agen dijalankan. Jawaban acuan inilah pembandingnya, bukan penilaian rasa saat membaca transkrip. Kalau arsip percakapan tidak tersedia, ketiadaan itu adalah temuan pertama: agen yang diuji tanpa bahan nyata hanya menguji imajinasi penyusunnya.

Tiga jenis kegagalan yang dicatat terpisah

Mencampur semua kesalahan dalam satu kolom "salah" membuat perbaikan berikutnya tidak terarah, karena penyebabnya berbeda.

1. Isi keliru. Agen menyatakan fakta, kebijakan, atau ketersediaan yang tidak sesuai sumber. Perbaikannya ada di bahan rujukan dan instruksi. 2. Tindakan keliru. Agen memanggil alat yang tidak semestinya, mengubah data, atau mengirim pesan ke pihak yang salah. Perbaikannya ada di batas wewenang dan konfirmasi sebelum tindakan. 3. Tidak berhenti. Agen seharusnya menyerahkan percakapan ke manusia tetapi melanjutkan sendiri. Perbaikannya ada di pemicu pengalihan dan kejelasan cakupan.

Ada satu jenis keempat yang tidak masuk hitungan lulus, yaitu jawaban yang benar tetapi tidak berguna. Jawaban seperti ini biasanya panjang, sopan, dan tidak menjawab pertanyaan. Ia tidak dapat ditangkap pemeriksaan otomatis, jadi perlu dibaca manusia pada setiap putaran uji.

Batas pengalihan ke manusia yang dipasang sebelum pengujian dibahas terpisah di batas asisten WhatsApp untuk toko. Tanpa batas itu, jenis kegagalan ketiga tidak punya acuan untuk dinilai.

Mencatat hasil supaya bisa dibandingkan antar versi

Hasil uji tanpa catatan hanya menjadi ingatan, dan ingatan tidak bisa dipakai untuk memutuskan apakah versi kedua lebih baik dari versi pertama. Satu tabel sudah cukup, dengan satu baris per skenario dan kolom berikut:

  • nomor skenario dan cuplikan pesan masuk
  • versi instruksi atau konfigurasi agen yang diuji, beserta tanggalnya
  • jawaban agen dan tindakan yang diambil
  • jawaban acuan manusia
  • keputusan: lulus, lulus dengan catatan, atau gagal, disertai jenis kegagalannya

Angka kelulusan dihitung dari jumlah baris, bukan dari kesan setelah membaca lima transkrip terakhir. Versi baru dianggap lebih baik hanya jika jumlah skenario yang gagal turun tanpa menambah kegagalan baru di skenario yang sebelumnya lulus. Perubahan yang memperbaiki satu skenario dan merusak dua skenario lain tetap dihitung sebagai kemunduran.

Catatan ini juga menjadi bahan pemeriksaan berikutnya saat sumber rujukan berubah. Skenario yang menyentuh sumber tersebut dijalankan ulang lebih dulu, tanpa menunggu putaran uji penuh.

Rilis bertahap dan jalur kembali

Pengujian tidak menghapus kemungkinan gagal di lapangan, karena percakapan nyata selalu lebih beragam daripada dua puluh skenario. Karena itu rilis pertama dibatasi pada tiga hal sekaligus: kanal, jam, dan jumlah percakapan. Contohnya, agen hanya aktif pada satu kanal, hanya di luar jam kerja, dan hanya menangani percakapan baru.

Selama minggu pertama, transkrip dibaca setiap hari, bukan setiap bulan. Dua kriteria berhenti ditetapkan sebelum rilis, misalnya dua keluhan pelanggan mengenai jawaban yang sama, atau satu tindakan yang tidak semestinya. Keduanya harus bisa dijalankan tanpa menunggu jadwal rilis berikutnya, artinya jalur mematikan agen tersedia dan sudah dicoba sebelum hari pertama.

Peralihan ke manusia tetap terlihat di setiap percakapan, bukan hanya saat agen gagal menjawab. Pelanggan yang ingin berbicara dengan orang tidak perlu membuktikan bahwa agen salah lebih dulu.

Kapan pendekatan ini bukan pilihan yang tepat

Pengujian dengan dua puluh sampai tiga puluh skenario masuk akal ketika volume percakapan cukup besar dan isi jawabannya relatif stabil. Di luar keadaan itu, pendekatan ini membuang waktu.

  • Volume percakapan sangat kecil. Kalau percakapan yang masuk hanya beberapa setiap hari, menyusun skenario dan jawaban acuan memakan waktu lebih banyak daripada menjawab langsung oleh orang. Jalur manusia lebih murah dan lebih cepat diperbaiki.
  • Isi jawaban belum stabil. Katalog, kebijakan, atau jadwal yang berubah setiap minggu membuat bahan uji basi sebelum dipakai. Sumber rujukan perlu dirapikan lebih dulu, dan itu pekerjaan yang berbeda dari pengujian agen.
  • Tidak ada yang membaca hasilnya. Uji yang menghasilkan tabel tanpa pembaca hanya formalitas. Keputusan rilis harus benar-benar bergantung pada tabel itu, atau pengujiannya dihentikan.
  • Kegagalan berisiko tinggi. Untuk pertanyaan yang menyangkut keputusan medis, hukum, atau keuangan, pengujian tidak menurunkan risiko sampai nol. Pada keadaan ini cakupan agen dibatasi pada pengumpulan informasi dan penjadwalan, sementara keputusan tetap dipegang manusia.

Penutup

Pengujian tidak menjamin agen bebas kesalahan. Yang dijamin adalah keputusan rilis diambil berdasarkan catatan yang bisa dibuka ulang, bukan berdasarkan kesan satu percakapan yang kebetulan berjalan baik. Tim yang menyimpan tabel uji juga memiliki titik awal saat agen perlu diperiksa ulang setelah sumbernya berubah.

Susunan peran antara agen, pemeriksa, dan pengambil keputusan untuk alur semacam ini dijelaskan pada halaman kapabilitas.