Praktik terbaik desain agen umum

Panduan ini memberikan praktik terbaik umum untuk mendesain semua jenis agen.

Anda juga harus melihat panduan desain agen suara khusus untuk mendesain agen suara, dan panduan praktik terbaik untuk menggunakan layanan Dialogflow CX.

Saran umum

Membangun agen secara berulang

Jika agen Anda akan besar atau kompleks, mulailah dengan membuat dialog yang hanya menangani permintaan tingkat teratas. Setelah struktur dasar dibuat, lakukan iterasi pada jalur percakapan untuk memastikan Anda mencakup semua kemungkinan rute yang dapat diambil pengguna akhir.

Saat agen Anda berkembang, pertimbangkan untuk menggunakan fitur kasus pengujian untuk pengembangan berbasis pengujian.

Agen bawaan

Dialogflow CX menawarkan template agen untuk membantu Anda memulai. Agen bawaan mencakup kasus penggunaan umum seperti layanan keuangan, telekomunikasi, dan perjalanan. Agen ini dilengkapi dengan maksud dan entitas untuk mencakup kueri pengguna yang paling umum. Tambahkan rute dan pemenuhan 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 CX. Bagian ini memberikan praktik terbaik untuk memilih cara melakukan integrasi.

Integrasi

Integrasi Dialogflow CX menyediakan antarmuka pengguna siap pakai untuk agen Anda. Jika menggunakan integrasi, Anda tidak perlu memanggil Dialogflow CX API secara langsung karena integrasi akan menanganinya untuk Anda. Integrasi ini dapat menyediakan agen teks yang dapat Anda sematkan di situs Anda, terhubung dengan platform pesan lainnya, atau menyediakan antarmuka telepon.

Dialogflow CX API

Jika tidak ada integrasi siap pakai yang sesuai, atau Anda ingin menyesuaikan antarmuka untuk sistem Anda, Anda dapat menggunakan Dialogflow CX API secara langsung. Dengan pendekatan ini, Anda perlu menerapkan antarmuka pengguna untuk agen, atau menggunakan antarmuka pengguna yang ada.

Webhook

Kecuali jika 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 CX API.

Referensi agen

Resource agen Dialogflow CX dapat digunakan dengan berbagai cara untuk mencapai hasil yang diinginkan. Bagian ini memberikan saran untuk memilih resource yang tepat untuk skenario yang tepat.

Alur dan halaman

Alur dan halaman memberikan struktur pada agen Anda. Anda dapat menganggap halaman sebagai node dalam mesin status, dan alur sebagai grup halaman terkait. Anda mengontrol transisi antar-node dengan penangan status, yang dipanggil saat maksud cocok, kondisi terpenuhi, atau peristiwa dipanggil.

Agen sederhana mungkin berfungsi dengan baik dengan satu alur, tetapi agen yang kompleks hampir selalu didesain lebih baik dengan beberapa alur. Setiap alur harus merepresentasikan topik tingkat tinggi untuk agen Anda, dengan setiap halaman yang terkait dengan alur membantu menangani topik tersebut. 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 saldo":

• Mendapatkan saldo rekening giro
• Mendapatkan saldo tabungan
• Mendapatkan saldo hipotek
• Mendapatkan saldo kredit

Jika desain agen Anda memiliki terlalu banyak halaman per alur, gabungkan halaman terkait dan manfaatkan banyak rute per halaman.

Jika Anda masih mengalami kesulitan dengan batas alur dan halaman, mungkin karena Anda memiliki terlalu banyak logika bisnis yang dibangun ke dalam agen itu sendiri. Pertimbangkan untuk memindahkan logika ini ke webhook.

Berikut adalah daftar perincian kontrol percakapan resource agen dalam urutan perincian yang meningkat:

1. Agen (satu agen menangani semua percakapan)
2. Alur (satu alur menangani satu atau beberapa topik percakapan terkait)
3. Halaman (satu halaman menangani satu atau beberapa giliran percakapan terkait)
4. Rute (satu rute menangani pemeriksaan kondisi atau maksud pengguna)

Parameter intent versus parameter formulir

Cara utama sistem Anda mendapatkan data terstruktur dari pengguna akhir adalah dengan parameter. Anda dapat menggunakan parameter untuk maksud (parameter maksud) atau halaman (parameter formulir).

Tujuan utama beberapa halaman adalah mengumpulkan informasi tertentu dari pengguna akhir. Misalnya, halaman dapat dirancang 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 bertransisi dari satu halaman ke halaman lain. Misalnya, jika pengguna akhir meminta produk tertentu di awal percakapan, Anda ingin mendapatkan produk yang diinginkan saat beralih ke halaman pemesanan yang sesuai. Dalam hal ini, gunakan parameter intent sebagai bagian dari rute intent.

Ada juga situasi saat penggunaan parameter intent dan parameter formulir secara bersamaan sangat ideal. Misalnya, jika pengguna akhir meminta kemeja ukuran kecil di awal percakapan, Anda ingin mengambil parameter ukuran yang diinginkan (kecil) saat beralih ke halaman pesanan kemeja. Halaman pemesanan kemeja dapat meminta informasi tambahan, seperti warna yang diinginkan. Halaman pemesanan kemeja harus memiliki parameter formulir untuk ukuran dan warna. Dalam contoh ini, parameter ukuran telah diberikan dan disebarkan, sehingga agen hanya akan meminta warna. Namun, percakapan lain mungkin mengikuti jalur yang berbeda, di mana pengguna akhir belum memberikan ukuran yang diinginkan saat halaman pesanan kaus menjadi aktif. Dengan menentukan parameter ini dalam kedua cara tersebut, agen Anda akan lebih fleksibel dalam cara mengekstrak informasi.

Catatan: Saat Anda menentukan parameter dengan ID atau nama tampilan yang sama dalam berbagai maksud atau formulir, pastikan jenis entity dan setelan lainnya sama untuk semua definisi. Jika jenis entitas atau setelan parameter lainnya berbeda, gunakan ID parameter atau nama tampilan unik untuk setiap definisi.

Rute dan grup rute

Jika Anda ingin melakukan transisi ke halaman lain, mengantrekan pesan respons, atau memanggil webhook saat maksud (intent) cocok atau kondisi terpenuhi, gunakan rute.

Jika Anda menggunakan set rute yang sama di beberapa halaman, gunakan grup rute. Tindakan ini akan menghindari duplikasi yang tidak perlu dalam desain agen Anda.

Penggunaan kembali intent

Jika Anda mendefinisikan beberapa intent dengan frasa pelatihan yang serupa, pertimbangkan untuk menggunakan kembali intent di beberapa halaman. Idealnya, Anda harus menentukan beberapa maksud umum yang digunakan di banyak halaman, dan beberapa maksud spesifik yang hanya digunakan di satu halaman. Tindakan ini akan menghindari duplikasi yang tidak perlu dalam desain agen Anda.

Misalnya, intent konfirmasi biasanya paling baik ditentukan sebagai intent yang dapat digunakan kembali. Intent confirmation.yes dapat memiliki frasa pelatihan seperti:

• ya
• ya
• yep
• oke
• ya, saya mau
• benar sekali
• tentu saja
• iya, tolong ya

Intent confirmation.no dapat memiliki frasa pelatihan seperti:

• tidak
• nah
• tidak
• tidak mungkin
• bukan untuk saya
• 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 maksud konfirmasi khusus. Misalnya, saat mengonfirmasi pesanan, Anda mungkin ingin memiliki order.confirmation.yesintent khusus dengan frasa pelatihan seperti:

• urutan ini sudah tepat
• Saya menerima pesanan ini

Selain itu, ada intent order.confirmation.no khusus dengan frasa pelatihan seperti:

• Saya tidak menginginkan pesanan ini
• Saya tidak menerima pesanan ini

Jika halaman konfirmasi pesanan Anda aktif, rute niat untuk keempat niat ini harus dalam cakupan. Hal ini memastikan bahwa konfirmasi umum atau spesifik dari pengguna akhir akan ditangani dengan tepat.

Intent negatif default

Anda harus mengisi niat negatif default dengan frasa yang mungkin diucapkan pengguna akhir Anda, tetapi tidak boleh cocok dengan niat apa pun di agen Anda.

Fulfillment

Ada banyak opsi untuk menggunakan pemenuhan untuk merespons pengguna akhir. Selama giliran percakapan, agen dapat menambahkan beberapa pesan ke antrean respons, dan antrean yang digabungkan dikirim ke pengguna akhir di akhir giliran percakapan. Bagian ini menjelaskan setiap opsi untuk membuat pesan individual.

• Pengisian entri halaman: Pengisian ini dipanggil saat halaman awalnya menjadi aktif. Hal ini berguna saat Anda menginginkan pesan yang menjelaskan tujuan halaman, dan pesan tersebut hanya boleh diucapkan satu kali saat halaman aktif. Misalnya:
  • Apa yang ingin Anda ketahui tentang rekening giro Anda?
  • Jenis produk apa yang ingin Anda beli?
  • Kami perlu mengumpulkan beberapa informasi tentang kemeja yang ingin Anda pesan.
• Rute: Pemenuhan ini dipanggil saat rute intent atau rute kondisi dengan pemenuhan dipanggil. Hal ini berguna saat Anda menginginkan pesan yang merespons pengguna akhir tentang kecocokan maksud, kondisi yang terpenuhi (yang mungkin berupa kondisi penyelesaian pengisian formulir), atau transisi. Contoh:
  • Ya, paket internasional Anda mencakup Jepang. (pencocokan maksud)
  • Apakah Anda yakin ingin membeli 300 kemeja? (kondisi perbandingan terpenuhi)
  • Oke, janji temu Anda adalah besok pagi pukul 07.00. (penyelesaian pengisian formulir)
  • Oke, sekarang mari kita bahas trenggiling. (transisi)
• Handler peristiwa: Pemenuhan ini dipanggil saat peristiwa dipicu. Hal ini berguna jika Anda menginginkan pesan yang merespons peristiwa. Misalnya:
  • Saham yang Anda pertimbangkan untuk dibeli baru saja meningkat nilainya sebesar 10%. (peristiwa kustom)
  • Bisa ganti pertanyaannya? (peristiwa tidak cocok)
• Perintah awal untuk formulir: Pemenuhan ini dipanggil saat agen mengisi formulir. Pesan ini harus mengajukan pertanyaan spesifik kepada pengguna akhir. Setiap parameter formulir memiliki pengisian perintah awal sendiri. Misalnya:
  • Ukuran kemeja apa yang Anda inginkan?
  • Warna kemeja apa yang Anda inginkan?
• Penanganan permintaan ulang untuk formulir: Pemenuhan ini dipanggil saat agen mengisi formulir, dan tidak memahami pilihan pengguna akhir untuk parameter saat ini. Pemenuhan ini hanya diperlukan jika Anda ingin pesan perintah ulang berbeda dengan pesan perintah awal. Jika tidak ada handler reprompt, agen hanya akan menggunakan perintah awal sebagai pesan reprompt. Misalnya:
  • Saya tidak mengerti. Dapatkah Anda memberikan warna yang valid untuk kemeja tersebut?

Penamaan

Bagian ini memberikan saran untuk penamaan resource agen.

Penamaan intent

Jika agen Anda memiliki banyak intent, Anda harus mempertimbangkan skema penamaan yang membantu Anda tetap teratur. Nama intent biasanya disegmentasikan dengan tanda baca, dengan spesifisitas yang meningkat dari kiri ke kanan. Selain itu, nama intent harus mencerminkan maksud pengguna akhir untuk giliran percakapan.

Ada banyak skema penamaan yang baik, tetapi berikut adalah salah satu contohnya:

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• 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 gratis

Saat menentukan rute yang memicu transisi, pertimbangkan bahwa mungkin ada rute pelengkap atau rute terbalik.

Contoh:

• Jika Anda memiliki rute intent untuk confirmation.yes, pertimbangkan untuk menentukan rute lain untuk confirmation.no.
• Jika Anda menentukan rute kondisi dengan operator boolean =, pertimbangkan untuk menentukan rute lain yang menggunakan !=.

Menangani input pengguna akhir

Bagian ini memberikan panduan untuk maksud dan frasa pelatihan, sehingga agen Anda dapat menangani dan memproses input pengguna akhir secara optimal.

Tentukan minimal 20 frasa pelatihan

Anda harus memiliki minimal 20 frasa pelatihan untuk setiap maksud. Jika tidak, model NLU mungkin tidak memiliki cukup informasi untuk mencocokkan maksud Anda dengan tepat. Ini adalah panduan minimum. Idealnya, Anda harus menentukan lebih banyak, terutama untuk maksud utama agen besar, dengan sekitar 50 maksud utama yang diinginkan.

Waspadai bias niat

Jika satu atau beberapa maksud memiliki frasa pelatihan yang jauh lebih banyak daripada maksud lainnya, hal ini menyebabkan model NLU cenderung lebih memilih maksud yang lebih besar karena data yang tidak seimbang. Bias niat ini dapat terjadi jika jumlah frasa pelatihan berbeda dengan selisih satu tingkat besaran atau lebih.

Dalam beberapa kasus, hal ini adalah perilaku yang diinginkan, karena Anda dapat menentukan beberapa maksud yang harus dicocokkan lebih sering daripada yang lain, karena maksud tersebut sesuai dengan input pengguna akhir yang lebih sering diamati dalam traffic aktif.

Dalam kasus lain, perilaku ini mungkin tidak diinginkan, karena Anda tidak ingin ada bias yang mendukung maksud yang lebih besar ini. Jika demikian, kurangi jumlah frasa pelatihan untuk intent yang lebih besar ini agar memiliki urutan besarnya yang sama dengan intent lainnya. Contoh:

Frasa pelatihan Intent A	Frasa pelatihan Intent B	Bias untuk maksud B
20	50	Tidak
20	200	Berisiko
20	2000	Ya

Penggunaan entity 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 beranotasi.
• Berikan frasa pelatihan setidaknya tiga kali lebih banyak dari jenis entity. Misalnya, jika Anda menggunakan 10 jenis entitas yang berbeda untuk anotasi dalam intent, Anda harus memiliki setidaknya 30 frasa pelatihan.

Frasa pelatihan harus alami

Frasa pelatihan harus bersifat percakapan dan alami; frasa tersebut harus cocok dengan apa yang sebenarnya diucapkan orang. Jika memungkinkan, gunakan input pengguna akhir yang terjadi dalam produksi sebagai data pelatihan Anda, 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 spektrum luas kemungkinan permintaan.

Sebaiknya sertakan beberapa frasa yang lebih pendek seperti "bayar tagihan saya", serta frasa dan kalimat yang lebih panjang seperti "Saya baru saja menerima surat yang menyatakan bahwa saya harus membayar saldo tagihan saya". Tidak ada proporsi frasa pendek dan panjang yang direkomendasikan, tetapi Anda harus mendasarkannya pada input pengguna akhir yang sebenarnya yang dikirim ke agen Anda dalam produksi.

Menentukan frasa pelatihan yang bervariasi dalam panjang, susunan kata, dan struktur kalimat penting untuk memastikan pelatihan yang baik bagi agen Anda. Tidak perlu menambahkan variasi demi variasi, tetapi perlu memberikan variasi yang cukup agar model NLU dapat berhasil mendeteksi maksud pengguna akhir dari berbagai input pengguna akhir. Jika Anda tidak memiliki variasi yang cukup, ada bahaya overfitting. Dengan kata lain, ada bahaya bahwa model akan terlalu terikat erat dengan contoh tertentu yang Anda berikan dan tidak akan cukup menggeneralisasi ke contoh lain.

Variasi kapitalisasi

Sensitivitas huruf kapital bervariasi bergantung pada model NLU yang digunakan agen Anda.

NLU Standar

Model NLU standar tidak peka huruf besar/kecil. Dalam kasus yang jarang terjadi, Anda mungkin perlu menambahkan frasa pelatihan yang hanya berbeda dalam kapitalisasi. Hal ini biasanya berlaku untuk situasi saat Anda mengharapkan pengguna akhir memberikan input teks huruf besar semua.

Pendekatan alternatifnya adalah:

• Menurunkan nilai minimum klasifikasi ML
• Mengubah huruf kecil input pengguna akhir sebelum mengirimkannya ke Dialogflow CX.

NLU Lanjutan

Tidak seperti model NLU standar, model NLU lanjutan bersifat peka huruf besar/kecil. Sebaiknya uji dan tambahkan data pelatihan yang relevan dan ditulis dengan huruf kapital untuk meningkatkan tingkat kecocokan maksud.

Variasi frasa pelatihan yang tidak perlu

Hindari variasi sepele dalam frasa pelatihan, karena memberikan informasi duplikat ke model NLU. Misalnya, jangan sertakan varian yang hanya berbeda berdasarkan:

• Kapitalisasi: Jika Anda menggunakan model NLU standar, hindari frasa duplikat seperti "Pesan tiket" dan "pesan tiket", kecuali dalam kasus yang jarang terjadi. Namun, model NLU lanjutan bersifat peka huruf besar/kecil dan memerlukan lebih banyak frasa pelatihan untuk meningkatkan kecocokan maksud. Lihat bagian variasi kapitalisasi untuk mengetahui detailnya.
• Kata pengisi: Misalnya, "oke, pesan tiket" dan "pesan tiket".
• Tanda baca: Misalnya, "bisa bantu?" dan "bisa bantu!?"

Konsistensi anotasi

Bagian frasa pelatihan yang dipilih untuk anotasi harus mencakup semua, dan tidak lebih dari, teks yang diperlukan untuk mencocokkan entitas. Selain itu, pastikan bagian frasa pelatihan yang serupa diberi anotasi untuk seluruh intent.

Misalnya, tabel berikut menunjukkan cara yang baik dan buruk untuk membuat anotasi dengan entity sistem @sys.date:

Kondisi	Buruk
Keberangkatan 7 September	Keberangkatan 7 September
Berangkat pada 4 Juli	Keluar pada 4 Juli

Menggunakan anotasi yang bermakna secara semantik untuk entity sistem

Makna semantik bagian frasa pelatihan yang dipilih untuk anotasi dapat dipengaruhi oleh teks lainnya dalam frasa pelatihan. Contoh:

Frasa pelatihan yang dianotasi	Makna semantik teks yang diberi anotasi
Saya berusia 7 tahun	Usia seseorang
Kontrak ini berlaku selama 7 tahun	Durasi waktu

Model machine learning Dialogflow CX mempertimbangkan makna semantik saat mencocokkan entity sistem. Makna semantik bagian frasa pelatihan harus cocok dengan makna semantik yang dimaksudkan dari entity sistem.

Misalnya, jangan gunakan entitas sistem @sys.duration untuk anotasi contoh "7 tahun" pertama di atas. Makna semantik "7 tahun" tidak cocok dengan durasi waktu sederhana. Sebagai gantinya, Anda harus memilih "7" untuk anotasi dan menggunakan entitas sistem @sys.number.

Menentukan maksud untuk menangani jawaban pengisian formulir yang tidak sesuai

Pertimbangkan untuk menentukan maksud guna menangani jawaban pengisian formulir yang tidak mematuhi kebijakan. Misalnya, agen Anda dapat bertanya "kapan tanggal perjalanan Anda?", yang diikuti dengan jawaban pengguna akhir "Saya belum tahu". Jawaban ini tidak memenuhi perintah parameter formulir, tetapi jika agen Anda memiliki rute maksud dalam cakupan yang dapat mencocokkan jawaban ini, agen Anda dapat menangani situasi ini dengan baik.

Menghindari @sys.any

Hindari penggunaan jenis entity sistem @sys.any. Fitur ini hanya boleh digunakan jika Anda telah mencoba 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 memberi anotasi pada beberapa bagian dari satu frasa pelatihan dengan jenis entity ini, karena hal ini akan menimbulkan ambiguitas, dan perilaku agen tidak akan ditentukan.

Menggunakan @sys.any dengan parameter formulir tidak terlalu berbahaya, karena agen mengharapkan informasi tertentu saat meminta parameter formulir.

Catatan: Beberapa entity sistem tidak tersedia saat Anda meregionalkan deployment agen, dan @sys.any terkadang direkomendasikan sebagai solusi.

Anotasi harus menyertakan berbagai nilai entity

Saat menentukan frasa pelatihan beranotasi, Anda harus menggunakan berbagai contoh nilai entitas dalam frasa. Anda tidak boleh terus-menerus menggunakan contoh entitas yang sama untuk anotasi. Contoh berikut menunjukkan anotasi yang baik dan buruk untuk jenis entity produk:

Kondisi	Buruk
Saya ingin membeli kaus	Saya ingin membeli kaus
Pesan topi baru	Pesan kaus baru
Tambahkan smartwatch ke keranjang saya	Tambahkan kaus ke keranjang saya

Entitas kustom harus mencakup variasi

Entitas kustom harus mencakup berbagai contoh. Model NLU akan memberikan variasi untuk bentuk tata bahasa, tetapi Anda harus menyertakan semua kemungkinan item.

Menghindari entitas yang cocok secara agresif

Jangan tentukan entity yang cocok dengan hampir semua hal. Hal ini menurunkan performa dan kualitas ML. Hampir semua hal dalam setiap frasa pelatihan akan dievaluasi sebagai kemungkinan kecocokan.

Entitas peta dan daftar harus berfokus pada nilai yang berbeda

Jenis entitas peta dan daftar harus memiliki cakupan terbatas yang mencakup nilai berbeda dari satu jenis informasi. Pastikan entitas Anda fokus, singkat, dan sederhana.

Jika nilai entity Anda rumit, hal ini mungkin karena frasa pelatihan maksud lebih sesuai dengan situasi Anda. Misalnya, pertimbangkan input pengguna akhir seperti:

• "Bagaimana cara melakukan panggilan internasional dengan Paket A?"
• "Menggunakan roaming data internasional dengan Paket B."

Jangan membuat jenis entity untuk tindakan dan rencana, seperti berikut:

Jenis entity tindakan	Jenis entitas paket
"Bagaimana cara melakukan panggilan internasional"	"Plan A" (Rencana A)
"Menggunakan roaming data internasional"	"Rencana B"

Sebagai gantinya, Anda harus menggunakan frasa pelatihan dan pencocokan intent untuk merekam tindakan dan entitas untuk merekam rencana.

Menggunakan entity regexp untuk mengambil ID non-kata

Saat merekam input pengguna akhir yang melibatkan ID non-kata, Anda harus menggunakan entitas ekspresi reguler. Misalnya, untuk mengambil ID produk seperti "AA-256" atau "AC-436", gunakan entity ekspresi reguler seperti "[A-Z]{2}-\d{3}".

Menghindari entitas komposit bertingkat

Jangan gunakan lebih dari satu tingkat penyusunan bertingkat dalam entitas komposit. Setiap level tingkatan menurunkan kualitas secara signifikan.

Hindari maksud yang serupa

Setiap maksud harus menangkap maksud pengguna akhir. Jika Anda menentukan maksud yang berbeda dengan frasa pelatihan yang serupa, pencocokan mungkin tidak dapat diandalkan karena model NLU tidak dapat menentukan dengan keyakinan yang cukup, maksud mana yang harus dicocokkan.

Jika dua frasa pelatihan mewakili maksud yang sama, keduanya harus termasuk dalam maksud yang sama. Misalnya, "ubah tanggal jatuh tempo tagihan saat ini" dan "waktu pembayaran lebih lama" seharusnya termasuk dalam maksud yang sama, karena keduanya meminta perubahan tanggal jatuh tempo. Namun, "Dapatkah saya melakukan panggilan internasional dengan Paket A?" dan "Dapatkah saya menggunakan roaming data internasional dengan Paket A?" dapat termasuk dalam maksud yang berbeda, karena pengguna akhir menginginkan hal yang berbeda dalam setiap kasus.

Hindari jenis entity yang serupa

Anda harus menghindari penentuan beberapa jenis entity yang memiliki entri entity serupa, karena hal ini dapat menyebabkan ambiguitas untuk model NLU.

Menggunakan peristiwa tidak cocok dalam produksi untuk meningkatkan kualitas maksud pengguna Anda

Saat menjalankan agen Anda dalam produksi, beberapa input pengguna akhir pasti akan menghasilkan peristiwa tidak cocok. Anda dapat menggunakan peluang ini untuk meningkatkan kualitas agen Anda dengan salah satu dari tiga cara berikut:

• Tambahkan input pengguna akhir sebagai frasa pelatihan ke maksud yang diinginkan. Namun, hal ini tidak selalu merupakan opsi terbaik. Jika Anda melakukan hal ini berkali-kali untuk intent, hal ini dapat menyebabkan bias intent.
• Bersihkan frasa pelatihan untuk intent yang diinginkan, sehingga semuanya mencerminkan maksud dengan akurat. Dalam beberapa kasus, niat dengan frasa pelatihan yang berbeda dapat mencegah pencocokan untuk maksud tersebut.
• Jika intent yang seharusnya tidak cocok untuk input pengguna akhir memiliki frasa pelatihan yang dapat cocok dengan input pengguna akhir, hapus frasa pelatihan ini.

Hindari karakter khusus

Karakter khusus dalam frasa pelatihan ({, _, #, [, dan sebagainya) diabaikan. Pengecualian untuk hal ini adalah emotikon, yang berfungsi seperti yang diharapkan.

Hindari kata pengisi

Kata pengisi adalah kata yang dapat Anda abaikan dan tetap dapat memahami teksnya. Contoh:

• memohon
• bisa tolong
• hmmm
• bagaimana kalau

Kata pengisi tidak diperlukan, tetapi tidak berbahaya jika digunakan dalam frasa pelatihan, karena kata-kata ini diabaikan oleh model NLU. Namun, Anda tidak boleh menentukan frasa pelatihan yang hanya berbeda berdasarkan kata pengisi.

Jangan pernah menentukan entity yang terdiri dari kata pengisi.

Bereksperimen dengan setelan ML

Setelan ML dapat digunakan untuk menyesuaikan cara pemrosesan input pengguna akhir. Dalam sebagian besar kasus, setelan default berfungsi dengan baik. Namun, Anda dapat menyesuaikan setelan untuk meningkatkan performa agen.

Merespons pengguna akhir

Bagian ini memberikan panduan untuk menggunakan pemenuhan guna merespons pengguna akhir.

Menyambut pengguna akhir

Agen yang baru dibuat memiliki rute intent yang dibuat secara otomatis untuk intent sambutan. Anda harus mengedit rute ini untuk menyertakan pesan pemenuhan yang menyambut pengguna akhir. Pesan ini harus menjelaskan agen dan memberi pengguna akhir gambaran tentang kemampuannya.

Menyatakan informasi pengguna akhir

Sering kali lebih baik mengulangi informasi yang diberikan oleh pengguna akhir dalam respons. Hal ini memberi tahu pengguna akhir bahwa agen memahami permintaannya.

Saat intent cocok, dan transisi terjadi, beri tahu pengguna akhir bahwa percakapan sedang berlangsung berdasarkan permintaan mereka. 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 kecocokan maksud, dan rute diikuti yang mencakup pesan pemenuhan dan transisi ke halaman yang menangani pertanyaan rekening giro. Perhatikan bahwa agen mengonfirmasi bahwa pengguna akhir ingin mengetahui informasi tentang rekening giro mereka.

Setelah pengisian formulir selesai, ulangi data yang diberikan oleh pengguna akhir. Contoh:

Dialog	Deskripsi
Pengguna akhir: Besok Agen: Oke, jadwal potong rambut Anda adalah besok pukul 19.00. Ada hal lain yang dapat kami bantu?	Pengguna akhir memberikan parameter formulir tanggal, yang merupakan parameter formulir terakhir di halaman aktif. Agen mengonfirmasi waktu dan tanggal potong rambut yang dijadwalkan.

Memandu percakapan

Agen harus selalu memandu percakapan dengan pengguna akhir. Hal ini dapat dilakukan dengan mudah dengan mengakhiri setiap respons dengan pertanyaan seperti:

• Ada hal lain yang dapat kami bantu?
• Apa yang ingin Anda ketahui tentang beagle?
• Apakah Anda ingin membatalkan atau mengirimkan pesanan tersebut?
• Ada yang bisa kami bantu?
• Apakah Anda bepergian sendiri atau dengan seseorang?

Saat menentukan pertanyaan ini, berhati-hatilah untuk menghindari mengajukan beberapa pertanyaan seperti:

• Apakah Anda masih di sini? Layanan apa yang Anda tanyakan?
• Apakah Anda masih menginginkan pesanan ini? Apakah Anda ingin menambahkan sesuatu?

Pengguna akhir dapat merespons hanya 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 cara menangani error dan input pengguna akhir yang tidak terduga.

Membuat pengendali peristiwa untuk peristiwa bawaan

Anda harus membuat pengendali peristiwa untuk peristiwa bawaan sebagaimana berlaku. Penanganan peristiwa ini mirip dengan penangkapan pengecualian dalam pemrograman software. Bergantung pada situasinya, Anda mungkin ingin menangani peristiwa dengan penangan peristiwa khusus parameter, penangan peristiwa khusus halaman, atau penangan peristiwa khusus alur.

Menangani error webhook

Jika layanan webhook Anda gagal, agen Anda harus dapat menangani kegagalan tersebut dengan baik. Anda dapat melakukannya dengan menentukan pengendali peristiwa untuk peristiwa bawaan khusus webhook. Berikut adalah pendekatan yang direkomendasikan untuk menangani error webhook:

• Jangan berikan target transisi dari state handler yang memicu panggilan webhook, jika tidak, penangan 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. Pengisian entri untuk halaman ini harus menginisialisasi penghitung error ke 0 menggunakan preset parameter pengisian. Contoh:

  Parameter	Nilai
  webhook-error-count	0

• Buat halaman error webhook yang menangani peristiwa error webhook:

  • Fulfillment entri harus mengakui kegagalan untuk pengguna akhir, dan harus menaikkan 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 maksimum yang diizinkan. (misalnya, $session.params.webhook-error-count <= 3). Rute ini harus memiliki pemenuhan yang memberi tahu pengguna akhir bahwa agen akan mencoba lagi. Rute ini harus memiliki target transisi yang ditetapkan ke PREVIOUS_PAGE, atau ke halaman mana pun yang dapat melakukan upaya lain untuk memanggil webhook.

  • Tentukan rute kondisi yang memiliki kondisi bahwa jumlah error lebih besar daripada jumlah maksimum yang diizinkan (misalnya, $session.params.webhook-error-count > 3). Rute ini harus memiliki pemenuhan 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.

• Webhook event handler 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 berkembang untuk menangani lebih banyak skenario.