Panduan ini memberikan praktik terbaik untuk menggunakan layanan Dialogflow. Panduan ini dirancang untuk meningkatkan efisiensi dan akurasi serta waktu respons yang optimal dari layanan.
Anda juga harus melihat panduan desain agen umum untuk semua jenis agen, dan panduan desain agen suara khusus untuk mendesain agen suara.
Produksi
Sebelum menjalankan agen Anda dalam produksi, pastikan untuk menerapkan praktik terbaik berikut:
- Menggunakan versi agen
- Menggunakan kembali klien sesi
- Menerapkan penanganan error dengan percobaan ulang
Mengaktifkan log audit
Aktifkan log audit Akses Data untuk Dialogflow API di project Anda. Mirip dengan fitur Histori perubahan, log audit dapat membantu Anda melacak perubahan waktu desain di agen Dialogflow CX yang terkait dengan project.
Versi agen
Anda harus selalu menggunakan versi agen untuk traffic produksi. Lihat Versi dan lingkungan untuk mengetahui detailnya.
Membuat cadangan agen
Menyimpan cadangan agen yang diekspor dan selalu diupdate. Dengan begitu, Anda dapat memulihkan dengan cepat jika Anda atau anggota tim Anda tidak sengaja menghapus agen atau project.
Penggunaan ulang klien
Anda dapat meningkatkan performa aplikasi dengan menggunakan kembali instance library klien *Client selama masa aktif eksekusi aplikasi Anda.
Yang terpenting, Anda dapat meningkatkan performa panggilan API deteksi maksud dengan menggunakan kembali instance library klien SessionsClient.
Pilih protokol dan versi untuk Referensi sesi:
| Protokol | V3 | V3beta1 |
|---|---|---|
| REST | Resource sesi | Resource sesi |
| RPC | Antarmuka sesi | Antarmuka sesi |
| C++ | SessionsClient | Tidak tersedia |
| C# | SessionsClient | Tidak tersedia |
| Go | SessionsClient | Tidak tersedia |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | Tidak tersedia | Tidak tersedia |
| Python | SessionsClient | SessionsClient |
| Ruby | Tidak tersedia | Tidak tersedia |
Untuk mengetahui informasi selengkapnya tentang hal ini, lihat panduan Praktik Terbaik dengan Library Klien.
Percobaan ulang error API
Saat memanggil metode API, Anda mungkin menerima respons error. Ada beberapa error yang harus dicoba ulang, karena sering kali disebabkan oleh masalah sementara. Ada dua jenis error:
- Error Cloud API.
- Error yang dikirim dari layanan webhook.
Selain itu, Anda harus menerapkan backoff eksponensial untuk percobaan ulang. Hal ini memungkinkan sistem Anda menemukan kecepatan yang dapat diterima saat layanan API mengalami beban berat.
Error Cloud API
Jika Anda menggunakan library klien yang disediakan Google, coba lagi error Cloud API dengan penundaan eksponensial diimplementasikan untuk Anda.
Jika telah menerapkan library klien Anda sendiri menggunakan REST atau gRPC, Anda harus menerapkan percobaan ulang untuk klien Anda. Untuk mengetahui informasi tentang error yang harus atau tidak boleh dicoba lagi, lihat Saran Peningkatan Kualitas API: Konfigurasi percobaan ulang otomatis.
Error webhook
Jika panggilan API Anda memicu panggilan webhook,
webhook Anda dapat menampilkan error.
Meskipun Anda menggunakan library klien yang disediakan Google, error webhook tidak akan dicoba lagi secara otomatis.
Kode Anda harus mencoba lagi error 503 Service Unavailable
yang diterima dari webhook Anda.
Lihat dokumentasi
layanan webhook
untuk mengetahui informasi tentang jenis error webhook
dan cara memeriksanya.
Pengujian beban
Melakukan pengujian beban untuk sistem Anda sebelum merilis kode ke produksi adalah praktik terbaik. Pertimbangkan poin-poin berikut sebelum menerapkan pengujian beban:
| Ringkasan | Detail |
|---|---|
| Tingkatkan beban. | Uji beban Anda harus meningkatkan beban yang diterapkan pada layanan Dialogflow. Layanan ini tidak dirancang untuk menangani lonjakan beban yang tiba-tiba, yang jarang terjadi dengan traffic sebenarnya. Layanan memerlukan waktu untuk menyesuaikan diri dengan permintaan beban, jadi tingkatkan kecepatan permintaan secara perlahan, hingga pengujian Anda mencapai beban yang diinginkan. |
| Panggilan API dikenai biaya. | Anda akan ditagih untuk panggilan API selama pengujian, dan panggilan akan dibatasi oleh kuota project. |
| Gunakan dummy pengujian. | Anda mungkin tidak perlu memanggil API selama pengujian beban. Jika tujuan pengujian beban Anda adalah untuk menentukan cara sistem Anda menangani beban, sebaiknya gunakan test double sebagai pengganti panggilan sebenarnya ke API. Pengujian ganda Anda dapat menyimulasikan perilaku API saat beban. |
| Gunakan percobaan ulang. | Pengujian beban Anda harus melakukan coba lagi dengan backoff. |
Memanggil Dialogflow dengan aman dari perangkat pengguna akhir
Anda tidak boleh menyimpan kunci pribadi yang digunakan untuk mengakses Dialogflow API di perangkat pengguna akhir. Hal ini berlaku untuk menyimpan kunci langsung di perangkat dan untuk menyandikan kunci secara permanen dalam aplikasi. Saat aplikasi klien Anda perlu memanggil Dialogflow API, aplikasi tersebut harus mengirim permintaan ke layanan proxy milik developer di platform yang aman. Layanan proxy dapat melakukan panggilan Dialogflow yang sebenarnya dan diautentikasi.
Misalnya, Anda tidak boleh membuat aplikasi seluler yang memanggil Dialogflow secara langsung. Untuk melakukannya, Anda harus menyimpan kunci pribadi di perangkat pengguna akhir. Aplikasi seluler Anda harus meneruskan permintaan melalui layanan proxy yang aman.
Performa
Bagian ini menguraikan informasi performa untuk berbagai operasi dalam Dialogflow. Memahami latensi penting untuk mendesain agen yang responsif dan menetapkan ekspektasi performa yang realistis, meskipun nilai ini bukan bagian dari SLA Dialogflow.
Saat membuat alat pemantauan dan pemberitahuan, perhatikan bahwa Model Bahasa Besar (LLM) dan pemrosesan ucapan biasanya ditangani menggunakan metode streaming. Respons dikirim ke klien sesegera mungkin, sering kali jauh lebih awal daripada total durasi panggilan metode. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik dengan model bahasa besar (LLM).
Performa per operasi
Tabel berikut memberikan informasi tentang performa umum operasi Dialogflow:
| Tindakan | Catatan |
|---|---|
| Tindakan alur: pengendali status | Operasi tercepat |
| Alur: deteksi maksud (teks) | Operasi tercepat |
| Alur: deteksi parameter (teks) | Pengoperasian cepat |
| Pengenalan ucapan (streaming) | Data diproses dan respons ditampilkan sesegera mungkin. Total waktu eksekusi terutama ditentukan oleh durasi audio input. Mengukur latensi menggunakan total waktu eksekusi tidak direkomendasikan. |
| Sintesis ucapan (streaming) | Total waktu eksekusi terutama ditentukan oleh durasi audio output. Data diproses dan respons dikembalikan secepat mungkin. |
| Penyimpanan data: AI generatif dinonaktifkan | Waktu sebenarnya bergantung pada ukuran penyimpanan data. |
| Penyimpanan data: diaktifkan untuk AI generatif | Performa bergantung pada ukuran penyimpanan data, model bahasa yang digunakan, dan panjang output serta input perintah, dalam urutan tersebut. |
| Penggantian respons generatif | Performa bergantung pada bahasa yang digunakan serta panjang output dan input perintah, dalam urutan tersebut. |
| Generator | Performa bergantung pada model bahasa yang digunakan, kompleksitas input perintah dan panjang output, serta jumlah generator dalam giliran. Beberapa generator dalam satu giliran akan menghasilkan beberapa panggilan ke model bahasa. |
| Eksekusi playbook | Performa bergantung pada kompleksitas playbook, jumlah perintah, dan waktu eksekusi alat yang dipanggil. Panjang output dan input perintah memengaruhi performa ini. Beberapa perintah model bahasa dapat dieksekusi secara berurutan, sehingga menambah total waktu panggilan. |
| Playbook: alat | Performa bergantung pada eksekusi alat yang mendasarinya. |
| Panggilan webhook | Performa ditentukan langsung oleh waktu eksekusi kode Anda di webhook. |
| Agen Impor / Ekspor | Performa bergantung pada ukuran agen. |
| Pelatihan agen | Performa bergantung pada jumlah alur, intent, dan frasa latihan. Melatih agen besar dapat memerlukan waktu puluhan menit. |
| Pembuatan lingkungan | Membuat lingkungan melibatkan pelatihan agen, sehingga total waktu akan bergantung pada ukuran dan kompleksitas agen. |
Catatan Penting:
- Streaming: Untuk panggilan streaming (pengenalan dan sintesis ucapan), data diproses saat tiba, dan respons ditampilkan sesegera mungkin. Artinya, respons awal biasanya jauh lebih cepat daripada total waktu panggilan.
- Playbook: Perintah LLM dibuat berdasarkan petunjuk playbook, konteks percakapan, dan input alat. Beberapa perintah LLM dapat dieksekusi dalam satu panggilan playbook. Inilah sebabnya eksekusi playbook bervariasi, bergantung pada jumlah perintah yang dikeluarkan dan kompleksitas panggilan.
Pertimbangan Latensi Penting
- Tidak Ada Jaminan Latensi: SLA Dialogflow tidak mempertimbangkan latensi, bahkan dalam Throughput yang Disediakan.
- Latensi LLM: Perlu diketahui bahwa pemrosesan LLM dapat menimbulkan latensi yang signifikan. Pertimbangkan hal ini dalam desain agen dan ekspektasi pengguna Anda.
- Pemantauan dan Pemberitahuan: Saat menyiapkan pemantauan dan pemberitahuan, perhitungkan sifat respons yang di-streaming dari LLM dan layanan ucapan. Jangan menganggap waktu respons penuh sama dengan waktu untuk respons pertama.