Demo lancar belum cukup: menguji agent AI sebelum menangani retur pelanggan

2026-10-18 · Agus Ramdan

Agent AI menjawab pertanyaan retur dengan sopan, menemukan pesanan, lalu menyiapkan balasan dalam demonstrasi singkat. Pemilik toko pun ingin segera menghubungkannya ke layanan pelanggan. Masalahnya, demonstrasi itu mungkin hanya memakai pesanan yang lengkap dan permintaan yang mudah dipahami. Pelanggan sungguhan sering mengirim cerita setengah jadi, mengganti topik, atau meminta pengecualian.

Sebelum memberi agent tanggung jawab lebih besar, tim perlu mengetahui batas kemampuannya. Evaluasi membantu menjawabnya lewat kumpulan kasus dan aturan penilaian yang bisa diulang. Ini bukan kegiatan khusus perusahaan besar. UMKM dapat memulai dari tabel sederhana, data buatan, dan pemeriksaan staf yang memahami kebijakan toko.

Contoh retur dalam tulisan ini adalah rancangan hipotetis, bukan laporan sistem yang sudah diterapkan atau hasil pengujian suatu usaha. Tujuannya memberi cara kerja yang dapat disesuaikan, tanpa menjanjikan penghematan atau akurasi tertentu.

Tentukan pekerjaan yang benar-benar akan diuji

Mulailah dengan batas yang sempit: agent membaca permintaan retur, mencari pesanan yang berhak diakses, memeriksa kebijakan, lalu menyusun rekomendasi untuk staf. Agent belum mengembalikan uang atau mengubah status pesanan. Batas tersebut membuat kesalahan lebih mudah ditemukan sebelum berdampak pada transaksi.

Panduan Evaluation best practices dari OpenAI menyarankan evaluasi yang spesifik terhadap tugas. Nilai model pada tolok ukur umum tidak otomatis menjawab apakah ia memahami kebijakan toko Anda. Jawaban yang enak dibaca juga belum membuktikan keputusan bisnisnya benar.

Tuliskan hasil yang diharapkan sebelum mencoba prompt. Untuk permintaan yang memenuhi syarat, agent harus memberi rekomendasi sesuai kebijakan. Untuk informasi yang belum lengkap, agent meminta klarifikasi yang diperlukan. Untuk kasus di luar kewenangan, agent menyerahkan keputusan kepada staf tanpa memberi janji persetujuan.

Bangun kumpulan kasus dari variasi pekerjaan

Tabel awal dapat berisi kolom permintaan pelanggan, data pesanan dummy, versi kebijakan, keputusan yang diharapkan, tindakan yang dilarang, serta alasan penilaian. Staf yang biasa menangani retur sebaiknya meninjau jawaban acuan. Jika kebijakannya sendiri belum jelas, perjelas dahulu; jangan meminta model menebak aturan usaha.

Masukkan kasus rutin dan kasus yang berpotensi membingungkan. Contohnya, pelanggan meminta retur dalam jangka waktu yang diizinkan, barang berada di luar masa retur, nomor pesanan belum diberikan, atau deskripsi kerusakan bertentangan dengan catatan yang tersedia. Tambahkan percakapan ketika pelanggan berpindah dari pertanyaan ongkir ke pengajuan retur.

Gunakan bahasa yang benar-benar mungkin ditemui toko: singkatan, salah ketik, kalimat pendek, atau campuran bahasa. Panduan OpenAI juga menekankan variasi input dan kompleksitas konteks sebagai bagian evaluasi. Kasus yang terlalu rapi dapat memberi gambaran kemampuan yang lebih baik daripada kenyataan.

Data buatan tetap perlu diperiksa manusia. Pembuat kasus dan pembuat jawaban bisa membawa asumsi keliru yang sama. Untuk tahap awal, gunakan identitas fiktif dan hindari memasukkan percakapan pelanggan asli ke layanan eksternal tanpa dasar izin serta perlindungan data yang sesuai.

Nilai keputusan dan tindakan secara terpisah

Satu skor keseluruhan sering menyembunyikan masalah. Agent dapat menulis balasan ramah sambil mencari pesanan yang salah. Ia juga dapat mengambil data dengan benar tetapi menyimpulkan bahwa semua permintaan harus ditolak. Kedua kegagalan itu membutuhkan perbaikan berbeda.

Pisahkan setidaknya pemeriksaan keputusan, penggunaan alat, dan isi balasan. Keputusan dinilai terhadap kebijakan yang berlaku. Penggunaan alat diperiksa dari pilihan fungsi dan argumennya, termasuk apakah agent memakai nomor pesanan yang benar. Balasan dinilai dari ketepatan fakta dan kejelasan langkah berikutnya bagi pelanggan.

Beberapa pemeriksaan dapat dibuat tegas. Apakah agent mencoba tindakan pengembalian dana meskipun tugasnya hanya menyusun rekomendasi? Apakah ia menyebut pesanan lain yang tidak tersedia dalam konteks berizin? Perilaku seperti itu harus dicatat sebagai kegagalan kritis, bukan ditutupi oleh nilai bahasa yang tinggi.

Hindari menuntut susunan kata yang persis sama untuk semua jawaban. Dua balasan dapat berbeda kalimat tetapi sama-sama benar. Sebaliknya, nilai yang tampak mirip belum tentu berarti sama: janji bahwa retur “sudah disetujui” berbeda dari keterangan bahwa pengajuan “akan diperiksa staf”.

Periksa jejak kerja ketika hasilnya keliru

Saat agent memberi rekomendasi salah, membaca kalimat terakhir saja tidak cukup. Periksa urutan kerjanya: informasi apa yang tersedia, alat apa yang dipanggil, hasil apa yang diterima, dan pada bagian mana kesimpulan mulai menyimpang. Simpan catatan yang diperlukan untuk diagnosis, dengan penyamaran data sensitif dan pembatasan akses.

Dokumentasi OpenAI tentang evaluasi alur agent menjelaskan bahwa trace merekam rangkaian panggilan model, alat, pemeriksaan pengaman, dan serah-terima dalam satu proses. Jejak tersebut membantu membedakan masalah pengambilan data dari masalah penalaran atau penerapan instruksi.

Misalnya, agent menolak retur karena membaca kebijakan lama. Mengubah gaya balasan tidak akan menyelesaikannya. Tim perlu memeriksa sumber kebijakan dan cara sistem memilih versi. Jika datanya benar tetapi kesimpulannya salah, perbaikan dapat diarahkan pada instruksi atau langkah pemeriksaan keputusan.

Jangan menyerahkan seluruh penilaian kepada model lain

Penilai berbasis model dapat membantu memeriksa banyak jawaban, terutama bila kriterianya jelas. Namun, ia juga dapat keliru. Panduan OpenAI mencatat bias seperti kecenderungan menyukai jawaban lebih panjang dan pengaruh urutan jawaban dalam perbandingan.

Untuk fakta terstruktur, gunakan pemeriksaan biasa jika memungkinkan. Nomor pesanan, label keputusan, dan keberadaan tindakan terlarang lebih mudah diperiksa dengan aturan daripada opini penilai. Untuk kesopanan atau keterbacaan, gunakan rubrik dengan contoh jawaban yang diterima dan ditolak.

Bandingkan penilaian otomatis dengan penilaian staf pada sebagian kasus. Ketika keduanya berbeda, baca alasannya sebelum memperluas penggunaan penilai. Perselisihan dapat menunjukkan rubrik yang kabur, jawaban acuan yang salah, atau kelemahan penilai. Jangan langsung menganggap skor otomatis lebih objektif.

Bandingkan perubahan dengan kondisi yang sama

Ketika mengganti prompt, model, atau alat pencarian, jalankan kembali kumpulan kasus yang sama. Catat versi kebijakan dan konfigurasi pengujian agar perbandingan masuk akal. Jangan sekaligus mengubah banyak komponen bila tujuan Anda mencari penyebab perbaikan atau penurunan.

Pisahkan kasus untuk menyusun perbaikan dari kasus pemeriksaan yang tidak terus-menerus dipakai mengutak-atik prompt. Jika semua contoh sudah dihafal melalui instruksi khusus, skor dapat meningkat tanpa menunjukkan kemampuan menangani permintaan baru. Tambahkan kasus dari pola kegagalan baru setelah ditinjau dan disamarkan.

Karena keluaran generatif dapat bervariasi, satu keberhasilan belum menunjukkan konsistensi. Ulangi kasus penting sesuai kemampuan biaya tim, lalu laporkan variasinya. Catat juga waktu respons dan penggunaan sumber daya. Jangan menyebut angka sebagai hasil pengujian bila pengujiannya belum dijalankan.

Gunakan hasil evaluasi untuk membatasi perluasan

Tentukan syarat penggunaan sebelum melihat hasil. Kegagalan yang menyangkut akses data atau tindakan di luar izin perlu menghalangi perluasan otomatisasi. Untuk kualitas bahasa, tim bisa menetapkan toleransi yang berbeda selama fakta dan keputusan tetap benar. Syaratnya mengikuti risiko usaha, bukan angka contoh dari artikel lain.

Setelah hasil awal memadai, agent dapat dicoba sebagai pembuat rekomendasi yang diperiksa staf. Perbedaan antara saran agent dan keputusan staf menjadi bahan evaluasi berikutnya. Persetujuan awal tidak berarti semua kasus mendatang aman, apalagi bila kebijakan atau alat berubah.

Pemilik UMKM tidak harus memulai dengan dasbor rumit. Mulailah dari satu pekerjaan, kumpulan kasus yang masuk akal, dan catatan kegagalan yang bisa ditindaklanjuti. Sebelum memberi agent hak tambahan, tunjukkan dulu keputusan mana yang sudah terbukti andal dan mana yang masih perlu diperiksa orang.

Sumber