Praktik terbaik penggunaan layanan

Panduan ini memberikan praktik terbaik untuk menggunakan layanan Dialogflow. Pedoman 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 dalam produksi, pastikan untuk menerapkan praktik terbaik berikut:

Mengaktifkan log audit

Aktifkan log audit Akses Data untuk Dialogflow API di project Anda. Hal ini dapat membantu Anda melacak perubahan waktu desain di agen Dialogflow yang ditautkan ke project ini.

Versi agen

Anda harus selalu menggunakan versi agen untuk traffic produksi. Lihat Versi dan lingkungan untuk mengetahui detailnya.

Membuat cadangan agen

Simpan cadangan agen yang diekspor dan terbaru. Hal ini akan memungkinkan Anda pulih dengan cepat jika Anda atau anggota tim Anda tidak sengaja menghapus agen atau project.

Penggunaan kembali klien

Anda dapat meningkatkan performa aplikasi dengan menggunakan kembali instance library klien *Client selama masa aktif eksekusi aplikasi.

Yang terpenting, Anda dapat meningkatkan performa panggilan API deteksi intent dengan menggunakan kembali instance library klien SessionsClient.

Lihat referensi Sesi.

Untuk mengetahui informasi selengkapnya, lihat panduan Praktik Terbaik dengan Library Klien.

Update batch ke agen

Jika Anda mengirim banyak permintaan API update agen individual dalam waktu singkat, permintaan Anda mungkin akan di-throttle. Metode API waktu desain ini tidak diimplementasikan untuk menangani kecepatan update tinggi untuk satu agen.

Beberapa jenis data memiliki metode batch untuk tujuan ini:

  • Daripada mengirim banyak EntityTypes create, patch, atau delete permintaan, gunakan metode batchUpdate atau batchDelete.
  • Daripada mengirim banyak Intents create, patch, atau delete permintaan, gunakan metode batchUpdate atau batchDelete.

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:

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 , percobaan ulang error Cloud API dengan backoff eksponensial akan diimplementasikan untuk Anda.

Jika Anda telah mengimplementasikan library klien sendiri menggunakan REST atau gRPC, Anda harus mengimplementasikan percobaan ulang untuk klien. Untuk mengetahui informasi tentang error yang harus atau tidak boleh Anda coba ulang, lihat Proposal Peningkatan API: Konfigurasi percobaan ulang otomatis.

Error webhook

Jika panggilan API Anda memicu panggilan webhook, webhook Anda mungkin menampilkan error. Meskipun Anda menggunakan library klien yang disediakan Google, error webhook tidak akan dicoba ulang secara otomatis. Kode Anda harus mencoba ulang 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

Sebaiknya lakukan pengujian beban untuk sistem Anda sebelum merilis kode ke produksi. Pertimbangkan poin-poin berikut sebelum menerapkan pengujian beban:

Ringkasan Detail
Meningkatkan beban. Pengujian beban harus meningkatkan beban yang diterapkan ke layanan Dialogflow. Layanan ini tidak dirancang untuk menangani lonjakan beban yang tiba-tiba, yang jarang dialami 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 dikenai biaya untuk panggilan API selama pengujian, dan panggilan akan dibatasi oleh kuota project.
Menggunakan duplikat pengujian. Anda mungkin tidak perlu memanggil API selama pengujian beban. Jika tujuan pengujian beban adalah untuk menentukan cara sistem Anda menangani beban, sebaiknya gunakan duplikat pengujian sebagai pengganti panggilan sebenarnya ke API. Duplikat pengujian dapat mensimulasikan perilaku API di bawah beban.
Menggunakan percobaan ulang. Pengujian beban harus melakukan percobaan ulang 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 di perangkat secara langsung dan untuk kunci hard coding di aplikasi. Saat aplikasi klien 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. Jika 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 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 operasi Dialogflow yang umum:

Tindakan Catatan
Deteksi intent (teks) Operasi cepat
Deteksi parameter (teks) Operasi cepat
Pengenalan ucapan (streaming) Data diproses dan respons ditampilkan sesegera mungkin. Total waktu eksekusi terutama ditentukan oleh panjang audio input. Mengukur latensi menggunakan total waktu eksekusi tidak direkomendasikan.
Sintesis ucapan (streaming) Total waktu eksekusi terutama ditentukan oleh panjang audio output. Data diproses dan respons ditampilkan secepat mungkin.
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 pelatihan. Pelatihan 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. Itulah 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 menyebabkan latensi yang signifikan. Pertimbangkan hal ini dalam desain agen dan ekspektasi pengguna.
  • 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 respons pertama.