WRNOTE: Latihan Menentukan Solusi: Rule, Model, atau Generative AI?

Tiga kebutuhan dalam satu layanan tidak harus memakai satu jenis AI. Mulai dari keluaran dan batas yang dibutuhkan, lalu uji pilihan.

Satu tim, tiga kebutuhan berbeda

Sebuah toko peralatan rumah tangga fiktif ingin memperbaiki layanan purnajual. Tim memiliki tiga kebutuhan: memeriksa kelengkapan permintaan servis, memperkirakan tiket yang berisiko terlambat, dan menyiapkan draf jawaban berdasarkan prosedur.

Sebelum membaca pembahasan, tulis pilihan awal untuk setiap kebutuhan. Apakah cukup aturan, perlu model prediktif, atau cocok memakai generative AI? Tambahkan alasan serta informasi yang masih kurang. Tidak perlu menebak merek produk atau layanan cloud.

Ini latihan orisinal untuk menerapkan AI Fundamentals and Literacy, bukan salinan soal resmi atau gambaran aktivitas berlangganan. Tujuannya memeriksa cara memilih dan memperbarui keputusan ketika kondisi berubah.

Diagram orisinal. Skenario fiktif untuk pembelajaran.

Kebutuhan pertama: periksa kelengkapan formulir

Tim perlu memastikan nomor pesanan, kategori produk, dan bukti pembelian terisi sebelum tiket masuk antrean. Syarat kelengkapan sudah ditulis dan disetujui. Untuk kebutuhan yang jelas ini, aturan validasi merupakan titik awal yang masuk akal.

Aturan dapat memeriksa kolom wajib dan nilai yang diizinkan tanpa belajar dari riwayat tiket. Hasilnya lebih mudah ditelusuri: permintaan tertahan karena kolom tertentu belum lengkap, bukan karena skor model yang belum dipahami.

Sekarang ubah kondisinya. Bukti pembelian berupa foto dengan format beragam. Ekstraksi dokumen mungkin membantu mengambil data, tetapi hasil ekstraksi tetap perlu diperiksa. Menggunakan AI pada satu langkah tidak menghapus aturan kelengkapan di langkah berikutnya.

Kebutuhan kedua: perkirakan risiko keterlambatan

Tim ingin mengenali tiket yang berpotensi melewati batas layanan agar petugas dapat memeriksa lebih awal. Hasil yang dibutuhkan berupa perkiraan risiko, bukan paragraf yang terdengar meyakinkan. Model prediktif dapat menjadi kandidat jika data yang relevan dan layak tersedia.

Periksa apa arti terlambat, apakah catatan historis konsisten, dan informasi mana yang tersedia saat perkiraan dibuat. Status akhir tiket tidak boleh diam-diam dipakai untuk memprediksi masa sebelum tiket selesai. Itu membuat evaluasi terlihat bagus dengan informasi yang seharusnya belum ada.

Bandingkan kandidat dengan aturan sederhana yang berlaku sebagai baseline. Bila data belum layak, aturan antrean dan perbaikan pencatatan mungkin lebih tepat sebagai langkah awal. Skor risiko bukan alasan otomatis untuk mengabaikan tiket lain atau mengurangi hak pelanggan.

Kebutuhan ketiga: buat draf jawaban berbasis prosedur

Petugas ingin draf penjelasan untuk pelanggan dengan bahasa yang lebih mudah dipahami. Karena keluaran yang dibutuhkan adalah teks baru, generative AI dapat dipertimbangkan. Sumber prosedur yang disetujui dan sesuai akses menjadi bagian penting dari aplikasi.

RAG dapat membantu mengambil informasi yang relevan sebelum model menyusun draf. Tetap periksa kesesuaian sumber, versi, dan isi jawaban. Kutipan sumber membantu penelusuran, tetapi tidak membuktikan bahwa setiap kalimat telah didukung dengan benar.

Mulai dari draf yang diperiksa petugas, bukan langsung janji otomatis ke pelanggan. Uji kasus ketika sumber tidak ditemukan, bertentangan, atau tidak boleh dilihat pengguna tertentu. Menahan jawaban dan meneruskan kasus juga perlu dinilai sebagai perilaku yang benar.

Apakah semuanya perlu digabung menjadi agent?

Belum tentu. Validasi, skor risiko, pencarian prosedur, dan draf jawaban bisa dihubungkan oleh alur kerja biasa. Menambah otonomi hanya berguna jika ada kebutuhan langkah dinamis yang jelas dan kontrol yang memadai.

Jika suatu saat aplikasi perlu memakai alat, pisahkan hak baca dari hak mengubah data. Tetapkan persetujuan untuk tindakan berdampak, catatan aktivitas, dan jalur penghentian. Jangan menganggap semua alat boleh dipakai hanya karena tersedia dalam sistem.

Pada latihan ini, keputusan awal dapat berupa aturan untuk kelengkapan, eksperimen terbatas untuk prediksi, dan draf berbasis sumber untuk jawaban. Ini kombinasi yang masuk akal berdasarkan kondisi kasus, bukan jawaban tunggal untuk setiap organisasi.

Uji lagi setelah satu syarat berubah

Coba tiga perubahan: kebijakan servis berganti setiap minggu, data riwayat tidak mencatat waktu secara konsisten, dan pelanggan mengirim permintaan yang dapat menimbulkan biaya besar. Pilihan mana yang masih berlaku? Bukti apa yang perlu ditambah?

Jelaskan perubahan alasan, bukan sekadar mengganti label solusi. Pembaruan kebijakan menuntut pengelolaan sumber; catatan waktu yang buruk melemahkan evaluasi prediksi; dampak biaya memperketat kewenangan dan review. Model yang lebih besar tidak otomatis menyelesaikan ketiganya.

Simpan keputusan, asumsi, baseline, dan hasil uji dalam catatan singkat. Kemajuan belajar terlihat ketika kita tahu kapan pilihan bekerja, kapan perlu diperiksa, dan kapan belum ada cukup bukti untuk melanjutkan. Tidak ada klaim bahwa latihan ini memprediksi kelulusan ujian.