Panduan ini memberikan praktik terbaik umum untuk mendesain semua jenis agen.
Anda juga akan melihat panduan desain agen suara khusus untuk mendesain agen suara, dan panduan praktik terbaik untuk menggunakan layanan Dialogflow.
Saran umum
Membuat agen secara iteratif
Jika agen Anda besar atau kompleks, mulai dengan membuat dialog yang hanya menangani permintaan tingkat atas. Setelah struktur dasar terbentuk, iterasi jalur percakapan untuk memastikan Anda mencakup semua kemungkinan rute yang dapat diambil pengguna akhir.
Sementara agen Anda berkembang, pertimbangkan untuk menggunakan fitur kasus pengujian untuk pengembangan berbasis pengujian.
Agen prebuilt
Dialogflow menawarkan template agen untuk membantu Anda memulai. Agen siap pakai mencakup kasus penggunaan umum seperti jasa keuangan, telekomunikasi, dan perjalanan. Agen ini dilengkapi dengan intent dan entity untuk mencakup kueri pengguna yang paling umum. Tambahkan rute dan fulfillment khusus untuk bisnis Anda, dan Anda akan dengan cepat membangun agen yang berfungsi.
Integrasi dan menghubungkan layanan Anda
Ada beberapa cara untuk berintegrasi dengan agen Dialogflow. Bagian ini memberikan praktik terbaik untuk memilih cara melakukan integrasi.
Integrasi
Integrasi Dialogflow menyediakan antarmuka pengguna yang siap digunakan untuk agen Anda. Jika menggunakan integrasi, Anda tidak perlu langsung memanggil Dialogflow API, karena integrasi akan menangani hal ini untuk Anda. Integrasi ini dapat menyediakan agen teks yang dapat Anda sematkan di situs, terhubung dengan platform pesan lain, atau menyediakan antarmuka telepon.
Dialogflow API
Jika tidak ada integrasi siap pakai yang cocok, atau Anda ingin menyesuaikan antarmuka untuk sistem, Anda dapat menggunakan Dialogflow API secara langsung. Dengan pendekatan ini, Anda harus menerapkan antarmuka pengguna untuk agen Anda, atau menggunakan antarmuka pengguna yang sudah ada.
Webhook
Kecuali agen Anda dapat sepenuhnya ditentukan dengan data statis, Anda harus menggunakan webhook untuk menghubungkan layanan dan menyediakan agen yang dapat menangani skenario dinamis. Hal ini berlaku baik jika Anda menggunakan integrasi maupun Dialogflow API.
Resource agen
Resource agen Dialogflow dapat digunakan dengan berbagai cara untuk mencapai hasil yang diinginkan. Bagian ini memberikan saran untuk memilih resource yang tepat untuk skenario yang tepat.
Flow dan halaman
Alur dan halaman memberikan struktur bagi agen Anda. Anda dapat menganggap halaman sebagai node di mesin status, dan flow sebagai grup halaman terkait. Anda mengontrol transisi antara node dengan pengendali status, yang dipanggil saat intent cocok, kondisi terpenuhi, atau peristiwa dipanggil.
Agen sederhana mungkin berfungsi dengan baik dengan satu alur, tetapi agen yang kompleks hampir selalu dirancang lebih baik dengan beberapa alur. Setiap alur harus mewakili topik tingkat tinggi untuk agen Anda, dengan setiap halaman yang terkait dengan alur tersebut membantu menangani topik. Selain itu, setiap alur dapat memiliki beberapa setelannya sendiri, dan dapat dimiliki oleh sebagian anggota tim, yang membantu membagi pekerjaan saat mendesain agen besar.
Saat mendesain agen yang besar dan kompleks, Anda harus mempertimbangkan batas"alur per agen" dan "halaman per alur". Batasan ini membantu menjaga performa agen Anda.
Jika desain agen Anda memiliki terlalu banyak alur per agen, gabungkan topik terkait dalam satu alur. Misalnya, Anda dapat menggabungkan topik berikut ke dalam satu alur "Dapatkan keseimbangan":
- Dapatkan cek saldo
- Dapatkan saldo tabungan
- Dapatkan saldo hipotek
- Dapatkan saldo kredit
Jika desain agen Anda memiliki terlalu banyak halaman per alur, gabungkan halaman terkait dan gunakan banyak rute per halaman.
Jika Anda masih mengalami kesulitan dengan batas alur dan halaman, hal ini mungkin karena Anda memiliki terlalu banyak logika bisnis yang disertakan dalam agen itu sendiri. Sebaiknya pindahkan logika ini ke webhook.
Berikut ini daftar perincian kontrol percakapan dari resource agen dalam meningkatkan urutan perincian:
- Agen (satu agen menangani semua percakapan)
- Alur (satu alur menangani satu atau beberapa topik percakapan terkait)
- Halaman (satu halaman untuk satu atau beberapa percakapan terkait)
- Rute (satu rute menangani pemeriksaan intent atau kondisi pengguna)
Parameter intent versus parameter formulir
Cara utama yang digunakan sistem Anda untuk mendapatkan data terstruktur dari pengguna akhir adalah dengan parameter. Anda dapat menggunakan parameter untuk intent (parameter intent) atau halaman (parameter formulir).
Tujuan utama dari beberapa halaman adalah untuk mengumpulkan informasi spesifik dari pengguna akhir. Misalnya, sebuah halaman mungkin didesain untuk mengumpulkan informasi kontak pengguna akhir. Dalam hal ini, Anda harus selalu menggunakan parameter formulir untuk mengumpulkan informasi ini.
Dalam beberapa kasus, Anda mungkin ingin mengambil informasi pengguna akhir saat melakukan transisi dari satu halaman ke halaman lainnya. Misalnya, jika pengguna akhir meminta produk tertentu di awal percakapan, Anda ingin mengambil produk yang diinginkan saat bertransisi ke halaman pesanan yang sesuai. Dalam hal ini, gunakan parameter intent sebagai bagian dari rute intent.
Ada juga situasi ketika penggunaan parameter intent dan parameter formulir menjadi pilihan yang ideal. Misalnya, jika pengguna akhir meminta kemeja kecil di awal percakapan, sebaiknya Anda mengambil parameter ukuran yang diinginkan (kecil) saat bertransisi ke halaman pesanan kemeja. Halaman pesanan kemeja dapat meminta informasi tambahan, seperti warna yang diinginkan. Halaman pesanan kemeja harus memiliki parameter formulir untuk ukuran dan warna. Dalam contoh ini, parameter ukuran sudah diberikan dan diterapkan, sehingga agen hanya akan meminta warna. Namun, percakapan lain mungkin mengikuti jalur yang berbeda, dengan pengguna akhir tidak memberikan ukuran yang diinginkan saat halaman pesanan kemeja aktif. Dengan menentukan parameter ini melalui kedua cara tersebut, agen Anda akan lebih fleksibel dalam mengekstrak informasi.
Rute dan grup rute
Jika Anda ingin bertransisi ke halaman lain, mengantrekan pesan respons, atau memanggil webhook saat intent cocok atau kondisi terpenuhi, gunakan rute.
Jika Anda menggunakan kumpulan rute yang sama di beberapa halaman, gunakan grup rute. Ini akan menghindari duplikasi yang tidak perlu dalam desain agen Anda.
Penggunaan ulang intent
Jika Anda menentukan beberapa intent dengan frasa pelatihan yang serupa, pertimbangkan untuk menggunakan kembali intent di beberapa halaman. Idealnya, Anda harus menentukan beberapa intent tujuan umum yang digunakan di banyak halaman, dan beberapa intent spesifik yang hanya digunakan di satu halaman. Ini akan menghindari duplikasi yang tidak perlu dalam desain agen Anda.
Misalnya,
intent konfirmasi biasanya paling tepat ditetapkan sebagai intent yang dapat digunakan kembali.
Intent confirmation.yes dapat memiliki frasa pelatihan seperti:
- ya
- ya
- ya
- oke
- iya
- benar
- benar-benar
- iya dong
Intent confirmation.no dapat memiliki frasa pelatihan seperti:
- tidak ada
- nggak
- tidak
- tidak mungkin
- bukan untukku
- sama sekali tidak
- tidak, terima kasih
Intent konfirmasi yang dapat digunakan kembali ini dapat digunakan dalam banyak skenario untuk agen Anda.
Dalam beberapa kasus,
Anda juga harus mempertimbangkan untuk membuat intent konfirmasi khusus.
Misalnya, saat mengonfirmasi pesanan, Anda mungkin ingin memiliki intent order.confirmation.yes khusus dengan frasa pelatihan seperti:
- pesanannya oke
- Saya menyetujui pesanan ini
Dan, intent order.confirmation.no khusus
dengan frasa pelatihan seperti:
- Saya tidak ingin pesanan ini
- Saya tidak menerima pesanan ini
Saat halaman konfirmasi pesanan Anda aktif, rute intent untuk keempat intent ini harus berada dalam cakupan. Hal ini memastikan bahwa setiap konfirmasi umum atau spesifik dari pengguna akhir akan ditangani dengan tepat.
Niat negatif default
Anda harus mengisi intent negatif default dengan frasa yang mungkin diucapkan pengguna akhir, tetapi tidak boleh cocok dengan intent apa pun dalam agen Anda.
Pemenuhan pemesanan
Ada banyak opsi untuk menggunakan fulfillment untuk merespons pengguna akhir. Selama giliran percakapan, agen dapat menambahkan beberapa pesan ke antrean respons, dan antrean sambungan akan dikirim ke pengguna akhir di akhir sesi percakapan. Bagian ini menjelaskan setiap opsi untuk membuat pesan individual.
- Fulfillment entri halaman:
Fulfillment ini dipanggil saat halaman pertama kali aktif.
Fungsi ini berguna jika Anda menginginkan pesan yang menjelaskan tujuan halaman,
dan hanya boleh dikatakan sekali saat halaman aktif.
Misalnya:
- Apa yang ingin Anda ketahui tentang rekening giro Anda?
- Jenis produk apa yang ingin Anda beli?
- Saya perlu mengumpulkan beberapa informasi tentang kemeja yang ingin Anda pesan.
- Rute:
Fulfillment ini dipanggil saat rute intent atau rute kondisi
dengan fulfillment dipanggil.
Hal ini berguna saat Anda menginginkan pesan yang merespons pengguna akhir tentang pencocokan intent, kondisi terpenuhi (yang mungkin berupa kondisi penyelesaian formulir), atau transisi.
Contoh:
- Ya, paket internasional Anda termasuk Jepang. (pencocokan maksud)
- Yakin ingin membeli 300 kemeja? (kondisi perbandingan terpenuhi)
- Oke, janji temu Anda besok pukul 07.00. (pengisian pengisian formulir)
- Oke, sekarang mari kita bicara tentang aardvarks. (transisi)
- Pengendali peristiwa:
Fulfillment ini dipanggil saat peristiwa dipanggil.
Fungsi ini berguna ketika Anda menginginkan pesan yang merespons peristiwa.
Misalnya:
- Saham yang Anda pertimbangkan untuk dibeli baru saja meningkat nilainya sebesar 10%. (peristiwa kustom)
- Bisakah Anda mengulanginya? (peristiwa yang tidak cocok)
- Perintah awal untuk formulir:
Fulfillment ini dipanggil saat agen melakukan pengisian formulir.
Pesan tersebut harus mengajukan pertanyaan spesifik kepada pengguna akhir.
Setiap parameter formulir memiliki fulfillment perintah awalnya sendiri.
Misalnya:
- Mau pakai kemeja ukuran apa?
- Mau pakai warna apa?
- Pengendali ulang formulir:
Fulfillment ini dipanggil saat agen melakukan pengisian formulir,
dan tidak memahami pilihan pengguna akhir untuk parameter saat ini.
Fulfillment ini hanya diperlukan jika Anda ingin pesan permintaan ulang
berbeda dengan pesan perintah awal.
Jika tidak ada pengendali permintaan ulang,
agen hanya akan menggunakan perintah awal sebagai pesan permintaan ulang.
Misalnya:
- Saya tidak mengerti. Dapatkah Anda memberikan warna kemeja yang valid?
Penamaan
Bagian ini berisi saran untuk penamaan resource agen.
Penamaan intent
Jika agen memiliki banyak intent, Anda harus mempertimbangkan skema penamaan yang membantu Anda menjaganya tetap teratur. Mengelompokkan nama intent dengan tanda baca adalah hal yang umum, dengan kekhususan meningkat dari kiri ke kanan. Selain itu, nama intent harus mencerminkan niat pengguna akhir untuk percakapan percakapan.
Ada banyak skema penamaan yang baik, tetapi berikut ini adalah satu contoh:
- phone-service.order.cancel
- phone-service.order.create?hl=id
- phone-service.order.change
- {i>tv-service.order.cancel<i}
- {i>tv-service.order.create<i}
- {i>tv-service.order.change<i}
- account.balance.get
- account.balance.pay
- account.address.get
- account.address.update
Transisi
Transisi yang ditentukan dalam pengendali status memberikan kontrol atas percakapan dengan mengubah halaman aktif. Bagian ini memberikan saran untuk mengatur transisi agen Anda.
Transisi bebas biaya
Saat menentukan rute yang memicu transisi, pertimbangkan bahwa mungkin ada rute komplementer atau terbalik.
Contoh:
- Jika Anda memiliki rute intent untuk confirmation.yes, sebaiknya tentukan rute lain untuk confirmation.no.
- Jika Anda menentukan rute kondisi dengan operator
=boolean, sebaiknya tentukan rute lain yang menggunakan!=.
Menangani input pengguna akhir
Bagian ini memberikan panduan untuk intent dan frasa latihan, sehingga agen Anda dapat menangani dan memproses input pengguna akhir secara optimal.
Tentukan setidaknya 20 frasa latihan
Anda harus memiliki minimal 20 frasa pelatihan untuk setiap intent. Jika tidak, model NLU mungkin tidak memiliki cukup informasi untuk mencocokkan intent Anda. Ini adalah pedoman minimum. Idealnya, Anda harus menentukan lebih banyak, terutama untuk intent head agen besar, dengan sekitar 50 yang diinginkan.
Menyadari bias niat
Jika satu atau beberapa intent memiliki lebih banyak frasa pelatihan yang jauh lebih banyak daripada intent lainnya, hal ini menyebabkan model NLU cenderung mendukung intent yang lebih besar karena data yang tidak seimbang. Bias intent ini dapat terjadi jika kuantitas frasa pelatihan berbeda menurut urutan besarannya atau lebih besar.
Dalam beberapa kasus, ini adalah perilaku yang diinginkan, karena Anda mungkin menentukan beberapa intent yang harus lebih sering dicocokkan daripada intent yang lain, karena sesuai dengan input pengguna akhir lebih sering diamati dalam traffic langsung.
Dalam kasus lain, perilaku ini mungkin tidak diinginkan, karena Anda tidak menginginkan bias yang mendukung intent yang lebih besar ini. Jika demikian, kurangi jumlah frasa pelatihan untuk intent yang lebih besar ini agar memiliki urutan magnitudo yang sama dengan intent lainnya. Contoh:
| Intent A frasa latihan | Frasa latihan Intent B | Bias untuk intent B |
|---|---|---|
| 20 | 50 | Tidak |
| 20 | 200 | Berbatas |
| 20 | 2.000 | Ya |
Penggunaan entitas dan jumlah frasa pelatihan
Untuk semua jenis entity yang digunakan dalam intent:
- Anotasikan setiap contoh jenis entity.
- Untuk setiap jenis entity, berikan setidaknya lima frasa pelatihan yang berisi contoh yang dianotasi.
- Menyediakan frasa pelatihan setidaknya tiga kali lebih banyak dari jenis entity. Misalnya, jika menggunakan 10 jenis entity berbeda untuk anotasi dalam suatu intent, Anda harus memiliki setidaknya 30 frasa pelatihan.
Frasa latihan harus natural
Frasa latihan harus komunikatif dan alami; mereka harus cocok dengan apa yang sebenarnya dikatakan orang. Jika memungkinkan, gunakan input pengguna akhir yang telah terjadi di lingkungan production sebagai data pelatihan, dengan memberikan perhatian khusus pada input yang paling umum.
Variasi frasa pelatihan yang diperlukan
Sertakan variasi pertanyaan, perintah, kata kerja, dan sinonim untuk kata benda umum guna memastikan frasa Anda mencakup kemungkinan permintaan yang luas.
Sebaiknya sertakan beberapa frasa yang lebih pendek seperti "bayar tagihan saya", serta frasa dan kalimat yang lebih panjang seperti "Saya baru saja menerima sesuatu di pos yang bertuliskan saya harus membayar saldo tagihan". Tidak ada proporsi yang direkomendasikan untuk frasa pendek ke panjang, tetapi Anda harus mendasarkan proporsi ini pada input pengguna akhir sebenarnya yang dikirim ke agen Anda dalam produksi.
Menentukan frasa pelatihan dengan panjang, frasa, dan struktur kalimat yang bervariasi sangat penting untuk memastikan pelatihan yang baik bagi agen Anda. Demi variasi, Anda tidak perlu menambahkan variasi, tetapi Anda harus menyediakan variasi yang cukup sehingga model NLU berhasil mendeteksi intent pengguna akhir dari berbagai input pengguna akhir. Jika Anda tidak memiliki variasi yang cukup, ada bahaya overfit. Dengan kata lain, ada bahaya bahwa model akan terkait terlalu erat dengan contoh tertentu yang Anda berikan dan tidak akan menggeneralisasi secara memadai ke contoh lain.
Variasi kapitalisasi
Dalam kasus yang jarang terjadi, Anda mungkin perlu menambahkan frasa pelatihan yang hanya memiliki huruf besar yang bervariasi. Hal ini biasanya berlaku pada situasi saat Anda mengharapkan pengguna akhir memberikan input teks yang menggunakan huruf besar semua.
Pendekatan alternatif dapat berupa:
- Menurunkan batas klasifikasi ML
- Menurunkan input pengguna akhir sebelum mengirimnya ke Dialogflow
Variasi frasa pelatihan yang tidak perlu
Hindari variasi yang sederhana dalam frasa pelatihan, karena memberikan informasi duplikat ke model NLU. Misalnya, jangan menyertakan varian yang hanya berbeda berdasarkan:
- Kapitalisasi (kecuali kasus yang jarang terjadi): Misalnya, "Pesan tiket" dan "pesan tiket".
- Kata pengisi: Misalnya, "oke, pesan tiket" dan "pesan tiket".
- Tanda baca: Misalnya, "dapatkah Anda membantu?" dan "bisa membantu!?"
Konsistensi anotasi
Bagian frasa pelatihan yang dipilih untuk anotasi harus menyertakan semua, dan tidak lebih dari, teks yang diperlukan untuk mencocokkan entity. Selain itu, pastikan bagian yang serupa dari frasa pelatihan dianotasi untuk seluruh intent.
Misalnya,
tabel berikut menunjukkan cara yang baik dan buruk
untuk menganotasi dengan entity sistem @sys.date:
| Baik | Buruk |
|---|---|
| Keberangkatan 7 September | Keberangkatan 7 September |
| Berangkat pada 4 Juli | Berangkat pada 4 Juli |
Menggunakan anotasi yang bermakna secara semantik untuk entity sistem
Makna semantik dari bagian frasa pelatihan yang dipilih untuk anotasi dapat dipengaruhi oleh teks lainnya dalam frasa pelatihan. Contoh:
| Frasa pelatihan yang dianotasi | Makna semantik dari teks yang dianotasi |
|---|---|
| Usia saya 7 tahun | Usia seseorang |
| Kontrak ini berlaku selama 7 tahun | Durasi waktu |
Model machine learning Dialogflow mempertimbangkan makna semantik saat mencocokkan entity sistem. Makna semantik dari bagian frasa pelatihan harus cocok dengan makna semantik yang dimaksudkan dari entitas sistem.
Misalnya, jangan gunakan entity sistem @sys.duration
untuk anotasi contoh "7 tahun" pertama di atas.
Arti semantik "7 tahun" tidak cocok dengan durasi waktu yang sederhana.
Sebagai gantinya, Anda harus memilih "7" untuk anotasi
dan menggunakan entity sistem @sys.number.
Menentukan intent untuk menangani jawaban pengisian formulir yang tidak mematuhi kebijakan
Pertimbangkan untuk menentukan intent untuk menangani jawaban pengisian formulir yang tidak mematuhi kebijakan. Misalnya, agen Anda mungkin bertanya "kapan Anda melakukan perjalanan?", diikuti dengan jawaban pengguna akhir "Saya belum tahu". Jawaban ini tidak memenuhi perintah parameter formulir, tetapi jika agen Anda memiliki rute intent dalam cakupan yang dapat cocok dengan jawaban ini, agen Anda dapat menangani situasi ini dengan baik.
Hindari @sys.any
Hindari penggunaan jenis entity sistem @sys.any.
Tindakan ini hanya boleh digunakan jika Anda telah sepenuhnya menggunakan semua cara,
termasuk membuat entity kustom.
Jenis entitas ini sangat luas dan dapat menyebabkan perilaku yang tidak diinginkan.
Jika Anda menggunakan jenis entity ini, hindari menganotasi beberapa bagian dari satu frasa pelatihan dengan jenis entity ini, karena akan menimbulkan ambiguitas, dan perilaku agen tidak akan ditentukan.
Penggunaan @sys.any dengan parameter formulir tidak terlalu berbahaya
karena agen mengharapkan informasi spesifik
saat meminta parameter formulir.
Anotasi harus menyertakan berbagai nilai entity
Saat menentukan frasa pelatihan yang dianotasi, Anda harus menggunakan berbagai contoh nilai entity dalam frasa. Anda tidak boleh menggunakan contoh entity yang sama secara konsisten untuk anotasi. Contoh berikut menunjukkan anotasi yang baik dan buruk untuk jenis entity produk:
| Baik | Buruk |
|---|---|
| Saya ingin membeli kemeja | Saya ingin membeli kemeja |
| Pesan topi baru | Pesan kemeja baru |
| Tambahkan jam tangan ke keranjang saya | Tambahkan kemeja ke keranjang saya |
Entitas kustom harus menyertakan variasi
Entitas kustom harus mencakup berbagai contoh. Model NLU akan memberikan variasi untuk bentuk tata bahasa, tetapi Anda harus menyertakan semua item yang memungkinkan.
Hindari entitas yang cocok secara agresif
Jangan tentukan entitas yang cocok dengan hampir semua hal. Hal ini menurunkan performa dan kualitas ML. Hampir semua yang ada di setiap frasa pelatihan akan dievaluasi sebagai kecocokan yang mungkin.
Entitas peta dan daftar harus berfokus pada nilai yang berbeda
Jenis entity peta dan daftar harus memiliki cakupan terbatas yang menangkap nilai berbeda dari satu jenis informasi. Buat entitas Anda tetap fokus, singkat, dan simpel.
Jika nilai entity Anda rumit, mungkin karena frasa pelatihan intent lebih cocok dengan situasi Anda. Misalnya, pertimbangkan input pengguna akhir seperti:
- "Bagaimana cara melakukan panggilan internasional dengan Paket A?"
- "Menggunakan roaming data internasional dengan Plan B."
Jangan membuat jenis entity untuk tindakan dan rencana, seperti berikut:
| Jenis entitas tindakan | Jenis entitas paket |
|---|---|
| "Bagaimana cara melakukan panggilan internasional" | "Rencana A" |
| "Menggunakan roaming data internasional" | "Rencana B" |
Sebagai gantinya, Anda harus menggunakan frasa pelatihan dan pencocokan intent untuk menangkap tindakan dan entity guna mencatat rencana.
Menggunakan entitas regexp untuk mendapatkan ID non-kata
Saat mengambil input pengguna akhir yang melibatkan ID non-kata, Anda harus menggunakan entity regexp. Misalnya, untuk mengambil ID produk seperti "AA-256" atau "AC-436", gunakan entitas regexp seperti "[A-Z]{2}-\d{3}".
Menghindari penyusunan bertingkat entity gabungan
Jangan gunakan lebih dari satu level nesting dalam entitas gabungan. Setiap tingkat pembuatan grafik bertingkat akan menurunkan kualitas secara signifikan.
Hindari intent serupa
Setiap intent harus menangkap intent pengguna akhir. Jika Anda menentukan intent yang berbeda dengan frasa pelatihan yang serupa, pencocokan mungkin tidak dapat diandalkan, karena model NLU tidak dapat menentukan dengan keyakinan yang memadai, intent mana yang akan dicocokkan.
Jika dua frasa pelatihan mewakili intent yang sama, keduanya harus termasuk dalam intent yang sama. Misalnya, "mengubah batas waktu tagihan saat ini" dan "lebih banyak waktu untuk membayar" harus termasuk dalam intent yang sama, karena keduanya meminta perubahan batas waktu. Namun, "Dapatkah saya melakukan panggilan internasional dengan Paket A?" dan "Dapatkah saya menggunakan roaming data internasional dengan Paket A?" dapat berasal dari intent yang berbeda, karena pengguna akhir menginginkan hal yang berbeda dalam setiap kasus.
Hindari jenis entity serupa
Sebaiknya hindari menetapkan beberapa jenis entity yang memiliki entri entity serupa, karena hal ini dapat menimbulkan ambiguitas untuk model NLU.
Gunakan peristiwa yang tidak cocok dalam produksi untuk meningkatkan intent Anda
Saat menjalankan agen dalam produksi, tidak dapat dihindari bahwa beberapa input pengguna akhir akan menghasilkan peristiwa tidak ada kecocokan. Anda dapat menggunakan peluang ini untuk meningkatkan peserta dengan salah satu dari tiga cara berikut:
- Tambahkan input pengguna akhir sebagai frasa pelatihan ke intent yang diinginkan. Namun, ini tidak selalu menjadi pilihan terbaik. Jika Anda melakukan hal ini berkali-kali untuk intent, hal tersebut dapat menyebabkan bias intent.
- Membersihkan frasa pelatihan untuk intent yang diinginkan, sehingga semuanya mencerminkan intent secara akurat. Dalam beberapa kasus, intent dengan frasa pelatihan yang berbeda dapat mencegah pencocokan intent.
- Jika intent yang tidak boleh dicocokkan untuk input pengguna akhir memiliki frasa pelatihan yang mungkin cocok dengan input pengguna akhir, hapus frasa pelatihan ini.
Hindari karakter khusus
Karakter khusus dalam frasa pelatihan ({, _, #, [, dan seterusnya) akan diabaikan.
Pengecualian untuk hal ini adalah untuk emotikon,
yang berfungsi seperti yang diharapkan.
Hindari kata pengisi
Kata pengisi adalah kata yang dapat Anda abaikan dan masih dapat memahami teksnya. Contoh:
- memohon
- bisa tolong nggak
- hmmm
- gimana kalau
Menggunakan kata pengisi dalam frasa pelatihan tidak diperlukan tetapi tidak berbahaya, karena akan diabaikan oleh model NLU. Namun, Anda tidak boleh menentukan frasa latihan yang hanya bervariasi berdasarkan kata pengisi.
Jangan pernah menentukan entitas yang terdiri dari kata pengisi.
Bereksperimen dengan setelan ML
Setelan ML dapat digunakan untuk menyesuaikan cara pemrosesan input pengguna akhir. Pada umumnya, setelan {i>default<i} berfungsi dengan baik. Namun, Anda mungkin perlu menyesuaikan setelan untuk meningkatkan performa agen.
Merespons pengguna akhir
Bagian ini memberikan panduan penggunaan fulfillment untuk merespons pengguna akhir.
Sambut pengguna akhir
Agen yang baru dibuat memiliki rute intent yang dibuat secara otomatis untuk intent selamat datang. Anda harus mengedit rute ini untuk menyertakan pesan fulfillment yang menyambut pengguna akhir. Pesan ini harus mendeskripsikan agen dan memberikan gambaran kepada pengguna akhir tentang kemampuannya.
Menyatakan informasi pengguna akhir
Sebaiknya ulangi informasi yang diberikan oleh pengguna akhir dalam respons. Hal ini memberi tahu pengguna akhir bahwa agen memahami permintaannya.
Saat intent dicocokkan, dan terjadi transisi, beri tahu pengguna akhir bahwa percakapan sedang berlangsung berdasarkan permintaannya. Contoh:
| Dialog | Deskripsi |
|---|---|
| Pengguna akhir: Saya memiliki pertanyaan tentang rekening giro saya. Agen: Oke, apa yang ingin Anda ketahui tentang rekening giro Anda? |
Input pengguna akhir menghasilkan pencocokan intent, dan rute diikuti yang menyertakan pesan pemenuhan dan transisi ke halaman yang menangani pertanyaan pemeriksaan akun. Perhatikan bahwa agen mengonfirmasi bahwa pengguna akhir ingin mengetahui tentang rekening giro mereka. |
Setelah pengisian formulir selesai, ulangi data yang diberikan oleh pengguna akhir. Contoh:
| Dialog | Deskripsi |
|---|---|
| Pengguna akhir: Besok Agen: Oke, potong rambut Anda dijadwalkan besok pukul 19.00. Butuh bantuan lain? |
Pengguna akhir memberikan parameter formulir tanggal, yang merupakan parameter formulir terakhir di halaman aktif. Agen tersebut mengonfirmasi waktu dan tanggal potong rambut yang dijadwalkan. |
Pandu percakapan
Agen harus selalu memandu percakapan dengan pengguna akhir. Hal ini mudah dilakukan dengan mengakhiri setiap respons dengan pertanyaan seperti:
- Butuh bantuan lain?
- Apa yang ingin Anda ketahui tentang beagle?
- Apakah Anda ingin membatalkan atau mengirimkan pesanan tersebut?
- Apa yang bisa saya bantu hari ini?
- Apakah Anda bepergian sendiri atau dengan seseorang?
Saat mendefinisikan pertanyaan-pertanyaan ini, berhati-hatilah untuk menghindari banyak pertanyaan seperti:
- Anda masih di sini? Layanan apa yang Anda tanyakan?
- Masih menginginkan pesanan ini? Ada yang mau ditambahkan?
Pengguna akhir mungkin hanya merespons salah satu pertanyaan, dan agen Anda mungkin tidak menangani situasi tersebut dengan benar.
Menangani error dan input pengguna akhir yang tidak terduga
Bagian ini memberikan saran tentang penanganan error dan input pengguna akhir yang tidak terduga.
Membuat pengendali peristiwa untuk peristiwa bawaan
Anda harus membuat pengendali peristiwa untuk peristiwa bawaan sebagaimana berlaku. Menangani peristiwa ini mirip dengan menangkap pengecualian dalam pemrograman software. Bergantung pada situasinya, Anda mungkin ingin menangani peristiwa dengan pengendali peristiwa khusus parameter, pengendali peristiwa khusus halaman, atau pengendali peristiwa khusus alur.
Menangani error webhook
Jika layanan webhook mengalami kegagalan, agen Anda harus dapat menangani kegagalan tersebut dengan baik. Anda mencapai hal ini dengan menentukan pengendali peristiwa untuk peristiwa bawaan khusus webhook. Berikut adalah pendekatan yang direkomendasikan untuk menangani error webhook:
- Jangan memberikan target transisi dari pengendali status yang memicu panggilan webhook. Jika tidak, pengendali peristiwa error webhook tidak akan dipanggil. Sebagai gantinya, tetapkan target transisi dalam respons webhook dari layanan webhook.
Pilih halaman tempat penghitung error dapat diinisialisasi ke nol. Halaman ini harus aktif sebelum halaman yang memicu panggilan webhook. Fulfillment entri untuk halaman ini harus menginisialisasi penghitung error ke
0menggunakan preset parameter fulfillment. Contoh:Parameter Nilai webhook-error-count0Buat halaman error webhook yang menangani peristiwa error webhook:
Fulfillment entri harus mengonfirmasi kegagalan untuk pengguna akhir, dan akan menambah parameter sesi penghitung error menggunakan preset parameter fulfillment. Contoh:
Parameter Nilai webhook-error-count$sys.func.ADD($session.params.webhook-error-count, 1)Tentukan rute kondisi yang memiliki kondisi bahwa jumlah error kurang dari jumlah maksimum yang diizinkan. (misalnya,
$session.params.webhook-error-count <= 3). Rute ini harus memiliki fulfillment yang memberi tahu pengguna akhir bahwa agen akan mencoba lagi. Rute ini harus memiliki target transisi yang ditetapkan ke PREVIOUS_PAGE, atau ke halaman apa pun yang dapat melakukan upaya lain untuk memanggil webhook.Tentukan rute kondisi yang memiliki kondisi bahwa jumlah error lebih besar dari jumlah maksimum yang diizinkan (misalnya,
$session.params.webhook-error-count > 3). Rute ini harus memiliki fulfillment yang memberi tahu pengguna akhir bahwa agen tidak akan mencoba lagi. Rute ini harus memiliki target transisi yang ditetapkan ke halaman yang tidak akan memicu percobaan ulang webhook.
Pengendali peristiwa webhook harus memiliki target transisi yang bertransisi ke halaman error webhook.
Alat
Bagian ini memberikan saran tentang penggunaan alat untuk meningkatkan desain agen.
Menggunakan alat validasi
Anda harus selalu menggunakan alat validasi untuk memeriksa agen Anda. Alat ini menemukan beberapa masalah yang dijelaskan dalam panduan ini.
Menggunakan fitur kasus pengujian
Anda harus selalu menentukan kasus pengujian untuk agen Anda. Kasus pengujian ini dapat membantu mencegah regresi saat agen Anda berevolusi untuk menangani lebih banyak skenario.