Data sintetis untuk AI adalah data buatan yang dirancang untuk mewakili karakteristik atau skenario tertentu. Tim dapat memakainya ketika contoh nyata terbatas, sulit dibagikan, atau tidak mencakup kondisi langka. Namun, data yang terlihat masuk akal belum tentu cukup mewakili pekerjaan nyata, dan status sintetis tidak otomatis membuktikan bebas informasi sensitif.
Bagi perusahaan, pertanyaan pertama adalah tujuan penggunaannya: melatih model, menguji aplikasi, atau menguji ketahanan alur kerja AI? Data yang cocok untuk menguji format API belum tentu tepat untuk menilai kemampuan model memahami bahasa pelanggan.
Bedakan Data Buatan, Data Tersamarkan, dan Data Nyata
AWS menjelaskan data sintetis sebagai data yang dibuat secara artifisial untuk meniru karakteristik data nyata. Pembuatan dapat menggunakan aturan, simulasi, atau model generatif. Pemilihan metode bergantung pada hubungan yang perlu dipertahankan.
Mengganti nama dalam tiket pelanggan merupakan penyamaran sebagian, bukan otomatis pembuatan data sintetis. Nomor transaksi, alamat, kutipan percakapan, dan kombinasi tanggal masih dapat mengungkap identitas. Sebaliknya, tiket yang ditulis dari aturan skenario tanpa menyalin catatan individu bisa menjadi contoh sintetis, tetapi mungkin kurang mencerminkan variasi bahasa di lapangan.
Mulai dari Daftar Kasus yang Ingin Diuji
Gunakan contoh ilustratif: tim ingin menguji AI yang mengelompokkan tiket gangguan aplikasi. Pemilik layanan menyusun kategori, tingkat dampak, informasi wajib, dan kondisi eskalasi. Tim kemudian membuat variasi tiket yang mencakup salah ketik, singkatan, dua masalah dalam satu pesan, serta pengguna yang belum menyebut cabang.
Tentukan jawaban acuan sebelum meminta model membuat teks. Jika label ditentukan belakangan oleh model yang sama, tim berisiko hanya mengukur kesesuaian model dengan dirinya sendiri. Peninjau manusia perlu mengoreksi skenario ambigu dan menyisakan kategori “informasi belum cukup”.
- Kasus rutin: masalah yang cukup jelas dan sering ditangani.
- Kasus batas: dua kategori mirip dengan satu detail pembeda yang penting.
- Kasus negatif: pesan di luar layanan yang seharusnya dialihkan.
- Kasus berisiko: instruksi berbahaya di dalam pesan atau permintaan tindakan tanpa wewenang.
Simulasi seperti ini membantu menguji alur penanganan. Frekuensi kasus buatan tidak boleh diperlakukan sebagai estimasi pola jumlah dan jenis tiket perusahaan. Membuat seribu tiket darurat tidak berarti tiket darurat memang dominan di operasi nyata.
Periksa Data Buatan Sebelum Menguji AI
Hubungan Antarkolom Harus Masuk Akal
Untuk data berbentuk tabel, validasi hubungan seperti tanggal selesai sesudah tanggal masuk, jumlah rincian sesuai total, dan cabang yang cocok dengan unit layanan. Pemeriksaan otomatis cocok untuk aturan ini. Staf yang memahami proses bisnis tetap diperlukan untuk kewajaran kombinasi yang tidak mudah ditulis sebagai rumus.
Keragaman Harus Mencakup Variasi yang Relevan
Jangan hanya mengganti nama dan angka pada satu pola kalimat. Sertakan gaya bahasa, urutan informasi, dan tingkat kelengkapan yang berbeda. Bandingkan cakupan terhadap daftar skenario, bukan sekadar menghitung jumlah baris. Simpan versi alat pembuat data, instruksi, aturan validasi, dan revisi hasil pemeriksaan agar kumpulan data dapat dibuat ulang.
Jaga Batas Privasi dan Hak Penggunaan
Jika alat pembuat data menggunakan catatan nyata sebagai contoh, tinjau izin, lokasi pemrosesan, lama penyimpanan, serta kemungkinan salinan muncul kembali. Periksa kemiripan langsung dan kombinasi atribut langka. Tidak ditemukannya nama asli dalam sampel bukan bukti bahwa seluruh kumpulan data aman dibagikan.
Gunakan pemeriksaan risiko privasi sesuai sensitivitas dan tujuan distribusi. Untuk data berisiko tinggi, libatkan pemilik data dan tim yang berwenang sebelum membuat atau membagikan kumpulan data. Klaim anonimitas membutuhkan penilaian tersendiri; nama metode tidak menggantikannya.
Nilai Model dengan Pembanding yang Independen
Sisihkan kumpulan evaluasi yang tidak berasal dari alat pembuat data latihan. Bila diizinkan, gunakan sampel nyata yang sudah dikelola dengan benar dan diberi kategori jawaban acuan oleh staf yang memahami proses bisnis. Laporkan hasil data sintetis dan data nyata secara terpisah. Skor tinggi pada contoh buatan dapat menutupi kegagalan terhadap kalimat pelanggan yang tidak rapi.
Ukur cakupan skenario, persentase contoh yang ditolak peninjau, duplikasi, kesalahan label, serta perubahan hasil pada evaluasi independen. Jika model membaik di data sintetis tetapi memburuk di sampel lapangan, hentikan perluasan dan periksa perbedaan pola data.
Gunakan panduan kumpulan data evaluasi AI untuk menyusun penilaian. Siapkan daftar skenario dan batas penggunaan data, lalu diskusikan kebutuhan data uji coba dengan Layana.ID. Pemetaan solusi AI bisnis sebaiknya menetapkan bukti kegunaan dan risiko data sebelum menambah volume contoh.