Tim IT yang mau membangun chatbot sendiri biasanya berhenti di satu pertanyaan, dari mana dataset chatbot yang layak dipakai untuk melatih model. Dataset chatbot adalah kumpulan data percakapan, pasangan tanya jawab, atau dialog berlabel yang dipakai untuk melatih dan menguji model AI percakapan. Membangun dataset yang benar benar merepresentasikan pola percakapan pelanggan nyata ternyata jauh lebih berat daripada sekadar mengunduh file CSV dari internet.
Artikel ini membahas jenis dataset chatbot yang tersedia, dan cara membangun dataset sendiri. Artikel ini juga membahas studi kasus nyata dari tim AI Qiscus yang membangun dataset dari nol untuk riset mereka sendiri. Di akhir, ada perbandingan build vs buy supaya keputusan tim lebih berdasar data, bukan asumsi.
Apa Itu Dataset Chatbot dan Jenis Jenisnya
Dataset chatbot adalah kumpulan pesan teks, dialog, atau pasangan tanya jawab yang dipakai untuk melatih dan menguji model AI percakapan. Kualitas dataset ini langsung menentukan seberapa baik model memahami konteks dan intent penggunanya.
1. Dataset Open Domain
Dataset open domain berisi percakapan bebas dan kasual, misalnya dari subtitle film atau thread media sosial, yang dipakai untuk melatih bot percakapan umum. Jenis dataset ini cocok untuk chatbot yang perlu terdengar natural, tapi kurang cocok untuk kasus bisnis yang butuh presisi tinggi.
2. Dataset Task Oriented
Dataset task oriented berisi dialog terstruktur yang dirancang untuk tujuan spesifik, seperti memesan tiket atau melakukan reservasi. Setiap giliran percakapan biasanya berkaitan langsung dengan langkah menuju penyelesaian tugas tertentu.
3. Dataset Customer Support
Dataset customer support berisi pasangan tanya jawab yang fokus pada deteksi intent dan penyelesaian masalah pelanggan. Jenis dataset inilah yang paling relevan untuk bisnis yang ingin membangun AI Agent untuk customer service mereka sendiri.
4. Dataset Multibahasa
Bisnis yang melayani pelanggan lintas bahasa membutuhkan dataset yang mencakup variasi bahasa dan dialek yang relevan dengan pasar mereka. Dataset semacam ini biasanya paling sulit didapat secara publik, karena representasi bahasa daerah atau campuran bahasa jarang tersedia dalam jumlah besar. Bisnis Indonesia yang melayani pelanggan berbahasa daerah atau campuran Bahasa Indonesia dan Inggris sering harus membangun dataset sendiri untuk kasus ini. Dataset publik yang tersedia kebanyakan berbahasa Inggris murni, kurang merepresentasikan pola bahasa campuran yang lazim dipakai pelanggan Indonesia.
Cara Membangun Dataset Chatbot dari Nol
Membangun dataset chatbot yang layak pakai untuk produksi memerlukan proses yang jauh lebih panjang daripada sekadar mengumpulkan teks percakapan. Empat tahap berikut adalah alur kerja standar yang biasa dipakai tim data science.
1. Kumpulkan Data Percakapan dari Sumber yang Relevan
Kumpulkan log percakapan nyata dari kanal yang sudah dipakai bisnis, seperti WhatsApp, live chat, atau email. Data sintetis bisa jadi pelengkap, tapi data percakapan nyata tetap lebih merepresentasikan pola bahasa pelanggan yang sebenarnya.
2. Bersihkan dan Anonimkan Data Sensitif
Ganti semua informasi identitas pribadi seperti nama, email, dan nomor telepon dengan data dummy sebelum dataset dipakai untuk pelatihan. Langkah ini wajib dilakukan untuk menjaga privasi pelanggan sekaligus mematuhi regulasi perlindungan data.
3. Anotasi Setiap Percakapan Secara Manual
Setiap pesan dalam dataset perlu dilabeli sesuai kategori yang relevan, misalnya apakah pesan tersebut butuh eskalasi ke manusia atau bisa ditangani otomatis. Proses ini idealnya dilakukan oleh domain expert yang paham konteks bisnis, bukan sekadar anotator umum. Studi kasus QiscusCS menunjukkan pendekatan ini secara langsung. Tiga domain expert dari tim Customer Service dilibatkan khusus untuk memberi label pada setiap utterance. Anotator generik yang tidak familiar dengan konteks layanan pelanggan Qiscus tidak dilibatkan dalam proses ini.
4. Validasi Kualitas Label Sebelum Dipakai untuk Training
Lakukan pengecekan silang antar anotator untuk memastikan label yang dihasilkan konsisten. Dataset dengan label yang tidak konsisten akan menurunkan akurasi model, sekalipun jumlah datanya besar. Skema label biner seperti yang dipakai pada QiscusCS, transferable atau tidak transferable, cenderung lebih mudah divalidasi konsistensinya dibanding skema label dengan banyak kategori.
Proses empat tahap ini adalah gambaran umum. Bisnis yang ingin memahami lebih dalam bagaimana cara melatih AI Agent setelah dataset siap juga perlu mempertimbangkan langkah lanjutan di luar sekadar pengumpulan data.
Studi Kasus, Bagaimana Tim AI Qiscus Membangun Dataset Chatbot Sendiri
Tantangan membangun dataset bukan cerita abstrak. Tim AI Qiscus sendiri pernah mengalaminya secara langsung ketika meneliti proses handover dari chatbot ke agen manusia.
1. Alasan Tim Qiscus Membangun Dataset Sendiri
Penelitian yang dipublikasikan tim AI Qiscus di IEEE mencatat satu kendala penting. Dataset publik untuk tugas handover chatbot ke manusia yang merefleksikan pola percakapan customer service nyata memang belum tersedia. Tim akhirnya membangun dataset sendiri yang diberi nama QiscusCS, diambil dari data percakapan di platform customer engagement Qiscus.
2. Skala dan Proses Anotasi Dataset QiscusCS
Dataset QiscusCS terdiri dari 100 dialog yang mencakup lebih dari 4.000 utterance, tepatnya 4.265 utterance dengan rata rata 44,43 utterance per dialog. Setiap utterance dianotasi manual oleh tiga domain expert dari tim Customer Service Qiscus, dengan label biner transferable atau tidak transferable. Seluruh data identitas pelanggan diganti dengan data dummy sebelum dipakai, untuk menjaga privasi.
3. Struktur Data yang Dipakai Tim Qiscus
Setiap baris dalam dataset QiscusCS menyimpan enam kolom, yaitu nama pengguna, email pengguna, id ruang percakapan, isi pesan, peran pengirim, dan label transferable. Struktur sesederhana ini ternyata cukup untuk melatih model mendeteksi kapan sebuah percakapan perlu dieskalasi ke manusia.
4. Dataset Bagus Saja Tidak Menjamin Performa Model
Dataset QiscusCS yang sama dipakai untuk membandingkan dua arsitektur, Single-Agent dan Multi-Agent. Hasilnya arsitektur Multi-Agent dengan Gemini 2.5 Flash mencatat Macro F1-Score 0,6260. Angka itu jauh di atas arsitektur Single-Agent dengan model yang sama, yang hanya mencatat 0,3333. Dataset-nya identik, tapi performanya bisa berbeda hampir dua kali lipat tergantung arsitektur yang dipakai untuk mengolahnya.
Temuan ini penting untuk tim yang berencana membangun dataset sendiri. Investasi waktu pada anotasi dataset yang rapi bisa jadi sia sia kalau arsitektur model di atasnya tidak dirancang dengan benar.
Apa yang Bisa Dipelajari dari Perbandingan Arsitektur di Studi Kasus Ini
Selisih performa antara Single-Agent dan Multi-Agent pada dataset yang sama memberi pelajaran konkret bagi tim yang sedang mempertimbangkan pendekatan agentic AI untuk kebutuhan mereka.
1. Model Dasar Kurang Berpengaruh pada Sistem Multi-Agent
Pada arsitektur Multi-Agent, model Gemini 2.5 Flash justru mencatat skor sedikit lebih tinggi dibanding GPT 4.1, meski secara umum dianggap model yang lebih ringan. Hasil ini menunjukkan bahwa desain arsitektur bisa lebih menentukan daripada sekadar memilih model dasar yang paling besar.
2. Model Dasar Sangat Berpengaruh pada Sistem Single-Agent
Pada arsitektur Single-Agent, GPT 4.1 mencatat Macro F1-Score 0,5356, jauh di atas Gemini 2.5 Flash yang hanya 0,3333. Pada sistem yang lebih sederhana, kemampuan model dasar menjadi faktor yang jauh lebih menentukan.
3. Waktu Eskalasi Memengaruhi Akurasi pada Kasus Sulit
Model Single-Agent Gemini cenderung menahan percakapan terlalu lama sebelum eskalasi, bahkan kadang tidak eskalasi sama sekali. Pola ini menurunkan presisi pada kasus minoritas yang sebenarnya butuh penanganan ahli.
4. Satu Metrik Saja Tidak Cukup untuk Menilai Kualitas Model
Menariknya, arsitektur Single-Agent OpenAI justru mencatat skor AUC tertinggi di antara keempat setup, yaitu 0,7017, meski Macro F1-Score nya kalah jauh dari Multi-Agent. AUC mengukur kemampuan model membedakan kelas di berbagai ambang batas, sementara Macro F1-Score mengukur keseimbangan presisi dan recall pada satu ambang batas tertentu. Tim yang hanya melihat satu metrik berisiko salah menyimpulkan model mana yang sebenarnya paling siap produksi.
Biaya Tersembunyi Membangun Dataset Chatbot Sendiri
Biaya membangun dataset chatbot jarang berhenti di jam kerja anotasi saja. Beberapa komponen berikut sering luput dari estimasi awal tim.
1. Waktu Domain Expert yang Ikut Teralokasi ke Anotasi
Studi kasus QiscusCS di atas melibatkan tiga domain expert dari tim Customer Service, bukan anotator umum yang bisa disewa lepas. Waktu domain expert yang biasanya menangani pekerjaan operasional harian ikut teralokasi untuk memberi label pada ribuan utterance.
2. Eksperimen Arsitektur yang Butuh Siklus Trial and Error
Seperti terlihat dari perbandingan Single-Agent dan Multi-Agent di atas, satu dataset saja tidak cukup untuk memastikan hasil yang baik. Tim perlu menguji beberapa tipe AI Agent dan model dasar sebelum menemukan kombinasi yang benar benar bekerja untuk kasus bisnis mereka.
3. Pemeliharaan Dataset yang Berkelanjutan
Pola pertanyaan pelanggan berubah seiring waktu, terutama saat ada produk baru atau kebijakan baru. Dataset yang tidak diperbarui secara berkala akan membuat model semakin kurang relevan dengan percakapan nyata yang masuk setiap hari.
Pertimbangan Kepatuhan Data Saat Membangun Dataset Chatbot
Dataset chatbot yang dibangun dari log percakapan pelanggan nyata otomatis berisi data pribadi. Tim yang menyepelekan tahap kepatuhan data berisiko menghadapi masalah hukum, bukan cuma masalah teknis.
1. Anonimisasi Bukan Sekadar Menghapus Nama
Studi kasus QiscusCS menunjukkan pendekatan yang tepat, seluruh data identitas pelanggan diganti dengan data dummy sebelum dipakai untuk riset. Anonimisasi yang benar juga perlu mempertimbangkan kombinasi data yang secara tidak langsung bisa mengidentifikasi seseorang, bukan hanya nama dan email secara terpisah.
2. Kepatuhan terhadap Undang Undang Pelindungan Data Pribadi
Bisnis di Indonesia yang mengumpulkan data percakapan pelanggan untuk keperluan pelatihan model tetap tunduk pada UU Pelindungan Data Pribadi. Persetujuan penggunaan data untuk tujuan pelatihan AI sebaiknya dicantumkan secara eksplisit dalam kebijakan privasi, bukan diasumsikan otomatis termasuk dalam persetujuan layanan pelanggan biasa.
3. Akses Terbatas ke Dataset Mentah
Batasi akses ke dataset mentah hanya untuk anggota tim yang benar benar terlibat dalam anotasi dan pelatihan model. Semakin banyak orang yang bisa mengakses data mentah berisi percakapan pelanggan, semakin besar pula risiko kebocoran data.
Dataset Chatbot Sendiri vs AI Agent Siap Pakai, Mana yang Lebih Masuk Akal
Pertimbangan ini bukan soal mana yang lebih canggih secara teknis, melainkan soal alokasi waktu dan risiko yang bersedia ditanggung tim. Dua contoh berikut menunjukkan bagaimana pertimbangan ini berbeda tergantung skala bisnis.
Bisnis e-commerce dengan volume ribuan percakapan per hari biasanya sudah punya cukup data mentah untuk membangun dataset sendiri. Masalahnya, bisnis semacam ini jarang punya tim data science internal untuk mengolah data itu. Bisnis skala menengah dengan volume lebih kecil biasanya menghadapi masalah sebaliknya. Data mentahnya belum cukup banyak untuk melatih model yang andal, sehingga opsi siap pakai jadi lebih masuk akal sejak awal.
| Aspek | Bangun Dataset Sendiri | AI Agent Siap Pakai |
|---|---|---|
| Waktu ke produksi | Berbulan bulan, termasuk anotasi dan eksperimen arsitektur | Hitungan minggu, tinggal konfigurasi knowledge base |
| Kebutuhan tim | Domain expert untuk anotasi, data engineer untuk eksperimen model | Tim CS atau IT yang mengelola knowledge base |
| Risiko performa | Bergantung pada kualitas dataset dan pilihan arsitektur | Arsitektur sudah diuji, tinggal disesuaikan konteks bisnis |
| Kontrol atas data | Penuh, data dan model sepenuhnya milik tim internal | Data pelanggan tetap dikelola dalam platform yang dipakai |
Kesimpulan praktis dari tabel di atas, membangun dataset sendiri masuk akal untuk tim riset yang memang butuh kontrol penuh atas model. Untuk kebutuhan bisnis yang mengejar waktu implementasi cepat, opsi siap pakai biasanya lebih realistis. Studi kasus QiscusCS di atas menunjukkan bahwa jalur riset ini nyata dan bisa ditempuh. Jalur ini juga menuntut sumber daya yang tidak semua bisnis punya, terutama dari sisi domain expert dan waktu eksperimen.
Cara AI Agent Siap Pakai Menghindarkan Beban Membangun Dataset
Bisnis yang tidak punya tim data science khusus tetap bisa mendapatkan AI Agent yang bekerja baik, tanpa melewati proses membangun dataset dari nol.
1. Knowledge Base Menggantikan Kebutuhan Dataset Percakapan Mentah
AI Agent siap pakai tanpa perlu membangun dataset sendiri bekerja dengan basis knowledge base yang diisi dari dokumen dan FAQ bisnis. Sumber datanya bukan ribuan utterance yang perlu dianotasi manual. Tim cukup mengisi materi yang sudah ada, bukan membangun dataset percakapan dari nol. Beberapa platform bahkan menyediakan template AI Agent siap pakai untuk mempercepat tahap awal ini.
2. Arsitektur Sudah Teruji, Tim Tidak Perlu Eksperimen Sendiri
Studi kasus QiscusCS di atas menunjukkan betapa besarnya selisih performa antar arsitektur. Memakai AI Agent yang arsitekturnya sudah melalui pengujian internal berarti tim bisnis tidak perlu mengulang siklus eksperimen itu dari awal.
3. Fokus Tim Bergeser ke Konteks Bisnis, Bukan Rekayasa Model
Tanpa beban membangun dan memelihara dataset, tim IT dan CS bisa fokus menyempurnakan knowledge base dan alur eskalasi sesuai kebutuhan bisnis. Ini area yang jauh lebih dekat dengan keahlian mereka dibanding rekayasa model machine learning. Memantau KPI AI Agent yang relevan menjadi pekerjaan utama tim, bukan lagi menyusun ulang dataset setiap kali performa menurun.
PCS berhasil bertransformasi dari sekadar auto-responder menjadi AI yang bisa mengambil keputusan setelah beralih dari pendekatan bot sederhana ke AI Agent yang lebih matang. Transformasi ini terjadi tanpa perlu membangun tim data science internal untuk mencapainya.
Pendekatan ini juga relevan untuk tim yang sedang mengevaluasi tantangan implementasi AI Agent secara lebih luas. Kebutuhan dataset sering jadi salah satu hambatan terbesar yang tidak disadari sejak awal proyek.
Cara Memulai, Baik Membangun Sendiri Maupun Evaluasi AI Agent Siap Pakai
Langkah berikut membantu tim menentukan arah yang paling realistis sesuai kapasitas yang tersedia.
1. Audit Kapasitas Tim Data Science Internal
Petakan apakah tim internal punya kapasitas untuk anotasi manual, eksperimen arsitektur, dan pemeliharaan dataset jangka panjang. Kekurangan kapasitas di salah satu area ini biasanya jadi sinyal kuat untuk mempertimbangkan opsi siap pakai. Kalau kapasitas dinilai belum cukup, kriteria memilih AI Agent yang tepat menjadi langkah lanjutan yang perlu dipertimbangkan.
2. Petakan Volume dan Jenis Percakapan yang Perlu Ditangani
Hitung perkiraan volume percakapan harian dan jenis pertanyaan yang paling sering masuk. Data ini berguna baik untuk merancang dataset sendiri maupun untuk mengisi knowledge base AI Agent siap pakai.
3. Bandingkan Estimasi Waktu ke Produksi
Bandingkan estimasi waktu membangun dataset dan menguji arsitektur sendiri dengan waktu implementasi AI Agent siap pakai. Perbedaan waktu ke produksi sering jadi faktor penentu, terutama untuk bisnis yang sudah merasakan dampak operasional dari CS yang kewalahan. Sebagai gambaran kasar, proses anotasi manual untuk seratus dialog saja pada studi kasus QiscusCS melibatkan tiga orang secara paralel. Bisnis yang membutuhkan dataset dengan cakupan topik lebih luas perlu memperhitungkan waktu anotasi yang bertambah proporsional dengan jumlah dialog dan variasi topiknya.
4. Mulai dari Skala Kecil Sebelum Komitmen Penuh
Baik membangun dataset sendiri maupun mengadopsi AI Agent siap pakai, mulai dari cakupan topik yang terbatas sebelum memperluas ke seluruh alur percakapan. Skala kecil memudahkan evaluasi hasil sebelum sumber daya besar dikomit.
5. Tinjau Ulang Keputusan Setiap Beberapa Bulan
Kebutuhan bisnis dan volume percakapan bisa berubah, sehingga keputusan build atau buy di awal tidak harus bersifat permanen. Peninjauan berkala membantu tim menyesuaikan strategi begitu ada perubahan skala atau kompleksitas kebutuhan. Ini juga berlaku untuk tim yang berencana implementasi AI Agent secara bertahap, bukan sekaligus di seluruh kanal.
Dataset Bukan Segalanya, Eksekusi yang Menentukan Hasil
Studi kasus QiscusCS membuktikan satu hal penting. Dataset yang dianotasi dengan baik hanyalah titik awal, bukan jaminan hasil. Arsitektur yang mengolah dataset tersebut, dan konsistensi pemeliharaannya dari waktu ke waktu, sama pentingnya dengan kualitas data itu sendiri. Bisnis yang memahami ketiga faktor ini sejak awal akan lebih siap membuat keputusan build atau buy yang realistis.
Tim yang punya kapasitas riset internal bisa mendapat banyak manfaat dari membangun dataset sendiri. Tim yang mengejar waktu implementasi cepat biasanya lebih diuntungkan oleh AI Agent yang arsitekturnya sudah teruji sejak awal.
Jelajahi solusi customer engagement dari Qiscus untuk melihat bagaimana AI Agent bisa berjalan tanpa membebani tim dengan proyek dataset dari nol. Performanya juga sudah teruji sejak awal, bukan hasil eksperimen internal yang belum pasti.
Pertanyaan yang Sering Ditanyakan tentang Dataset Chatbot
Dataset chatbot adalah kumpulan data percakapan, pasangan tanya jawab, atau dialog berlabel yang dipakai untuk melatih dan menguji model AI percakapan. Kualitas dan relevansi dataset ini langsung memengaruhi seberapa baik model memahami konteks penggunanya.
Dataset chatbot bisa didapat dari repositori publik seperti Kaggle atau GitHub untuk kasus umum, atau dibangun sendiri dari log percakapan internal untuk kasus bisnis yang spesifik. Dataset publik biasanya kurang merepresentasikan konteks bisnis tertentu dibanding dataset yang dibangun langsung dari data percakapan asli perusahaan sendiri.
Tidak ada angka pasti yang berlaku universal, karena kebutuhan volume data bergantung pada kompleksitas kasus yang ingin ditangani. Studi kasus QiscusCS misalnya memakai 100 dialog dengan lebih dari 4.000 utterance untuk riset perbandingan arsitektur, bukan untuk melatih model dari nol.
Tidak selalu. Studi kasus QiscusCS menunjukkan dua arsitektur yang memakai dataset identik bisa menghasilkan performa yang sangat berbeda. Selisihnya hampir dua kali lipat pada Macro F1-Score. Arsitektur pengolahan data sama pentingnya dengan volume dataset itu sendiri.
Bisnis yang tidak punya tim data science internal atau butuh waktu implementasi cepat biasanya lebih diuntungkan oleh AI Agent siap pakai. Membangun dataset sendiri lebih masuk akal untuk tim riset yang memang membutuhkan kontrol penuh atas data dan model.
