AI yang menjawab pertanyaan berbahasa Inggris dengan baik belum tentu memahami catatan operasional yang mencampur bahasa Indonesia, singkatan internal, dan istilah pelanggan. Kalimat “jangan reship dulu sebelum retur lama masuk” memuat tindakan, larangan, serta prasyarat. Pilot AI multibahasa perlu menguji apakah makna itu bertahan, bukan hanya apakah jawabannya terdengar lancar.
Use case ini relevan bagi customer operations, procurement support, sales operations, dan tim knowledge management B2B. Tujuan pilot adalah memeriksa tugas bisnis tertentu dalam bahasa yang benar-benar dipakai pengguna. Jangan mengambil skor kemampuan bahasa umum sebagai pengganti bukti bahwa sistem dapat menangani prosedur perusahaan Anda.
Pilih Satu Keputusan yang Bergantung pada Bahasa
Mulailah dengan tugas yang batasnya jelas: mencari prosedur pengiriman ulang, mengklasifikasikan jenis keluhan, atau mengekstraksi prasyarat persetujuan. Tetapkan apa yang dianggap benar, salah, dan perlu klarifikasi. Sistem yang mampu menerjemahkan satu pesan belum otomatis dapat memutuskan tindakan operasional berdasarkan pesan tersebut.
Untuk pilot awal, keluaran dapat berupa usulan jawaban beserta sumber dan status ketidakpastian. Pelaksanaan transaksi tetap di luar lingkup. Chatbot merupakan cara interaksi, workflow menetapkan urutan proses, sedangkan agent dapat memilih alat atau langkah lanjutan dalam batas yang diberikan. Kemampuan multibahasa adalah dimensi evaluasi pada semua bentuk itu, bukan alasan menyebut sistem agentic.
Bentuk Kelompok Uji Berdasarkan Risiko Makna
Gunakan contoh yang mewakili variasi pekerjaan, bukan sekadar menerjemahkan kumpulan pertanyaan bahasa Inggris. Teks pengguna dapat tidak baku, singkat, atau mengandung dua bahasa dalam satu kalimat. Reviewer yang memahami proses harus memastikan bahwa pasangan contoh memang mempunyai maksud yang sama sebelum hasil model dibandingkan.
- Indonesia formal: istilah sesuai SOP dan struktur kalimat lengkap.
- Indonesia sehari-hari: bentuk singkat, salah ketik, dan urutan kalimat yang umum pada tiket.
- Inggris: istilah pelanggan atau dokumen pemasok.
- Campuran: istilah seperti hold, release, retur, reship, dan approval dalam konteks lokal.
- Makna kritis: negasi, pengecualian, satuan, tanggal, serta pihak yang berwenang.
Jangan menggabungkan semua kelompok menjadi satu nilai tanpa rincian. Rata-rata dapat terlihat baik meskipun sistem sering keliru pada negasi. Catat juga kelompok yang tidak terwakili; pilot untuk dua bahasa tidak membuktikan dukungan seluruh bahasa atau dialek yang mungkin dipakai pelanggan.
Susun Kasus Berpasangan dan Kasus Pembeda
Pasangan dengan Makna yang Sama
Contoh sintetis: “Jangan kirim ulang sebelum barang lama kembali” dipasangkan dengan “Do not reship until the original goods are returned.” Kedua kalimat seharusnya mempertahankan larangan dan kondisi yang sama. Bila hasilnya berbeda, reviewer memeriksa apakah masalah berasal dari retrieval, penafsiran pesan, atau pembentukan jawaban.
Pasangan yang Berbeda pada Satu Unsur
Bandingkan “boleh dilepas setelah supervisor menyetujui” dengan “belum boleh dilepas meskipun supervisor menyetujui; tunggu hasil pemeriksaan”. Perubahan kecil itu sengaja mengubah tindakan yang benar. Sistem perlu menangkap hubungan kondisi, bukan sekadar menemukan kata supervisor dan menyimpulkan persetujuan sudah cukup.
Kasus dengan Istilah Ambigu
Kata “release” dapat berarti melepas quality hold, merilis versi aplikasi, atau melepaskan reservasi stok. Singkatan internal juga dapat berbeda antarunit. Jawaban yang tepat pada kasus ambigu mungkin berupa pertanyaan klarifikasi. Jangan menilai semua klarifikasi sebagai kegagalan karena hal itu mendorong model menebak.
Siapkan Sumber dan Kamus yang Dikelola PIC
Gunakan SOP yang telah disetujui serta glosarium istilah dengan pemilik dan versi. Simpan definisi, contoh penggunaan, konteks unit, dan padanan yang tidak boleh disamakan. Bedakan terjemahan umum dari istilah operasional resmi. Bila dokumen sumber menggunakan bahasa yang berbeda dari pertanyaan, tetap tampilkan sumber yang benar dan penjelasan yang dapat dipahami pengguna.
Integrasi CRM atau ticketing dapat memasok contoh pola bahasa, tetapi data pelanggan perlu diminimalkan dan disamarkan sesuai kewenangan. Gunakan contoh sintetis terlebih dahulu bila data asli belum boleh diproses. Untuk jalur transformasi data, baca penyamaran data RAG. Keberadaan kumpulan uji tidak otomatis memberi izin mengirim isinya kepada penyedia model.
Nilai Hasil dengan Reviewer yang Memahami Proses
Tentukan rubrik sebelum menjalankan pilot. Reviewer menilai ketepatan tindakan, pelestarian negasi dan prasyarat, kecocokan sumber, ketepatan istilah, serta apakah sistem mengetahui kapan perlu bertanya. Penilaian kelancaran bahasa ditempatkan terpisah dari ketepatan bisnis agar kalimat yang rapi tidak menutupi instruksi yang salah.
Buat penilaian independen pada sebagian contoh dan bahas perbedaan reviewer. Jika ahli proses sendiri tidak sepakat, perbaiki definisi kasus atau SOP sebelum menyalahkan model. Simpan versi kumpulan uji, prompt, konfigurasi retrieval, dan identitas model agar perbandingan berikutnya dapat ditelusuri. Jangan mengubah jawaban acuan hanya untuk membuat nilai pilot terlihat lebih baik.
Laporkan jumlah kasus per kelompok, tingkat kesalahan kritis, kebutuhan klarifikasi, ketepatan rujukan, serta waktu review. Ambang kelulusan disepakati sponsor dan pemilik risiko. Contoh angka atau target internal merupakan rancangan pilot, bukan klaim akurasi produk atau hasil proyek Layana.
Pisahkan Perbaikan Bahasa dari Perubahan Sistem
Jika kegagalan berasal dari istilah yang belum ada, perbaiki glosarium. Jika sumber yang benar tidak terambil, periksa retrieval dan pemetaan dokumen. Jika sumber sudah benar tetapi prasyarat dibalik, uji perbaikan prompt atau model pada set regresi yang dikunci. Mengganti model tanpa diagnosis dapat menggeser kegagalan ke kelompok lain.
NIST AI Risk Management Framework menyediakan rujukan pengelolaan risiko AI; rubrik multibahasa dalam artikel ini adalah usulan praktis, bukan pengujian sertifikasi NIST. Pertahankan disiplin uji regresi saat upgrade model dan evaluasi kapan RAG perlu menolak menjawab sebelum memperluas penggunaan.
Putuskan Perluasan dari Bukti per Kelompok
Lanjutkan hanya pada tugas dan kelompok bahasa yang memenuhi ambang yang disepakati. Tahan kelompok berisiko untuk review manusia atau klarifikasi tambahan. Tidak perlu memaksakan satu keputusan go-live untuk semua jenis pesan. Sponsor perlu melihat batas dukungan yang jelas, kegagalan tersisa, dan biaya review sebelum menambah pengguna.
Siapkan satu prosedur, daftar istilah, contoh pesan sintetis, dan PIC penilai. Layanan AI dan Machine Learning Layana dapat menjadi titik awal pemetaan. Diskusikan pilot AI multibahasa untuk menyepakati tugas, integrasi, data yang boleh dipakai, dan ukuran kelulusan yang sesuai operasi Anda.