Keterampilan B2B Alice: dari prototipe hingga rubel pertama disimpan

Belum lama ini, di St. Petersburg, konferensi Percakapan kedua diadakan, didedikasikan untuk AI percakapan, di mana saya beruntung berbicara sebagai pembicara. Topiknya adalah mengembangkan keterampilan prototipe B2B untuk perusahaan besar. Laporan tersebut menggambarkan bagaimana mereka berhasil “berteman” dengan layanan web yang relatif lambat dan infrastruktur perusahaan yang tertutup. Ini akan dibahas di bawah potongan.

Jika tiba-tiba Anda tidak tahu apa keterampilan Alice, lihat di bawah spoiler: itu menjelaskan secara singkat apa itu.

Ide

Bagaimana semuanya dimulai? Pada 13 Maret 2018, mereka mengumumkan pengujian beta platform Yandex.Dialogs (keterampilan Alice). Pada saat itu, banyak yang sudah tertarik pada asisten virtual, yang berarti itu adalah peluang bagus untuk bekerja dengan audiens yang cukup besar. Gagasan tentang satu bot obrolan telah berputar di kepala saya untuk waktu yang lama, jadi saya memutuskan akan menarik untuk membuat beberapa keterampilan dalam waktu luang berdasarkan itu. Dan jika dia juga dapat membawa manfaat di tempat kerja - itu umumnya akan sangat baik.

Perusahaan kami menyediakan berbagai layanan di bidang pariwisata bisnis, yang berarti Anda dapat membuat keterampilan yang membantu pengguna untuk melakukan perjalanan bisnis.
Kemudian saya berada di tim untuk pengembangan aplikasi mobile, dengan mana Anda dapat menemukan opsi penerbangan dan hotel untuk perjalanan bisnis, dan mengatur yang sesuai. Salah satu indikator utama, yang sulit kami perjuangkan, adalah jumlah unduhan. Gagasan muncul bahwa jika keterampilan akan mengarahkan pengguna ke aplikasi, maka itu akan membantu kami meningkatkan indikator ini. Ini diperlukan untuk memverifikasi menggunakan proyek ini.

Agar keterampilan bermanfaat bagi siapa pun, keterampilan harus menyelesaikan tugas tertentu dari pengguna. Dalam hal ini, cari opsi untuk perjalanan bisnis. Artinya, keterampilan harus mengumpulkan informasi tentang ke mana harus pergi, dan menunjukkan hasilnya dalam aplikasi seluler. Dengan demikian, pengguna akan menerima opsi yang diinginkan menggunakan interaksi suara yang menarik dan terus bekerja di aplikasi kami, yang berarti pengembang akan menerima peningkatan kinerja yang diinginkan.

Ternyata skill tersebut seharusnya bekerja seperti ini: salam pengguna; temukan namanya; ajukan pertanyaan klarifikasi dan, dengan demikian, dapatkan parameter perjalanan yang diperlukan: kota (dari mana dan di mana) dan tanggal. Selanjutnya tunjukkan parameter yang dikenali. Jika semuanya benar, mulailah mencari dan berikan tautan ke aplikasi.

Sumberdaya dan Keterbatasan

Untuk menyelesaikan tugasnya, keterampilan harus berinteraksi dengan API internal kami, dan layanan webnya harus dipublikasikan di suatu tempat. Di satu sisi, itu dapat ditempatkan di tempat kerja, tetapi, sebagaimana telah disebutkan, pengembangan dilakukan di waktu luang, oleh karena itu saya tidak ingin bergantung pada sumber daya perusahaan yang dialokasikan secara khusus. Jadi, Anda harus mengambil keuntungan dari apa yang tersedia secara default.

Misalnya, server uji. Pengembang memiliki hak yang cukup untuk menyebarkan aplikasi web di dalamnya, tetapi itu hanya akan tersedia di jaringan internal perusahaan, karena server tidak menonjol. Pada saat yang sama, ia memiliki akses ke Internet, yang berarti bahwa ini dapat digunakan.

Layanan web skill harus dapat diakses dari luar (sehingga Alice memiliki tempat untuk mengirim permintaan), sehingga harus ditempatkan pada hosting eksternal.

Agar keterampilan untuk memenuhi tugasnya, Anda memerlukan layanan web perusahaan yang dapat mencari profil dan kota, dan dapat diakses dari luar. API aplikasi seluler cocok untuk ini, meskipun memiliki nuansa tersendiri. Mereka terdiri dari fakta bahwa Anda dapat terhubung ke API atas nama hanya satu pengguna tertentu, yang berarti bahwa kisaran profil yang tersedia untuk pencarian akan terbatas. Dan hal yang paling tidak menyenangkan - hasil pencarian yang diluncurkan melalui API hanya akan datang ke pengguna ini. Namun demikian, ia memiliki fungsionalitas yang diperlukan, yang berarti Anda dapat bekerja dengannya.

Jadi, keterampilan hosting eksternal akan berinteraksi dengan API. Ini tentu saja cukup cepat, tetapi kadang-kadang, menurut hasil tes, jawabannya tidak punya waktu untuk tiba di 1500 ms yang diperlukan (ini adalah persyaratan platform Yandex.Dialogs). Dan untuk tetap mengirimkan hasil ke pengguna yang tepat, Anda harus menjalankan layanan pencarian atas namanya, yang hanya tersedia di jaringan internal. API, sayangnya, tidak akan membantu dalam hal ini, yang berarti bahwa Anda perlu mentransfer permintaan dari skill langsung ke infrastruktur internal.
Kami akan menyelesaikan masalah ini saat tersedia.

Tahapan Masalah dan Solusi

Untuk memulainya, agar dapat secara umum menerapkan skenario yang dijelaskan, keterampilan harus menyimpan keadaan di suatu tempat: panggung, nama pengguna, kota, dan tanggal. Tidak ada banyak informasi, jadi Anda tidak boleh menggunakan seluruh database untuk itu, terutama karena ada terlalu banyak keributan dengannya. Anda dapat menyimpan status dalam cache.

Pilihan ada pada Redis . Dia menunjukkan dirinya dengan baik dalam tes respons, dan kami juga menggunakannya dengan ketat di tempat kerja, yang berarti bahwa jika berhasil, proyek ini dapat dengan mudah ditransfer ke perusahaan (dan spoiler - kami memindahkannya). Sebagai kunci, Anda bisa menggunakan pengidentifikasi pengguna dalam skill (ditunjukkan dalam permintaan), dan menyimpan data status dalam format JSON dalam nilai. Salinan Redis gratis dapat digunakan di Heroku , dan untuk beberapa waktu sekarang telah didukung di Yandex.Cloud .

Sekarang kita akan menganalisis tahapan keterampilan secara lebih rinci. Pada awal pertama, pengguna melihat frasa sambutan biasa. Selanjutnya, ia harus menyebutkan namanya, yang menurutnya keterampilan tersebut akan mencari profil.



Jika ada, maka namanya harus ditulis ke dalam status, dan karena cache digunakan, maka sisa informasi yang diperlukan tentang profil dapat dimasukkan ke dalamnya. Sekarang, ketika klien kembali ke keterampilan, dia akan melihat salam pribadi. Jika orang yang sama masuk dari perangkat lain dan menyebutkan namanya, profilnya juga akan ditemukan di cache, yang berarti kita akan menghindari pencarian lagi melalui API, yang menghemat waktu pemrosesan permintaan.

Selanjutnya, parameter perjalanan diterima. Sebagai pengguna keterampilan suara, saya ingin memberi nama kota dan tanggal sesuai keinginan, misalnya, "Peter", dan "dalam seminggu". Keterampilan harus dapat mengenali frasa tersebut untuk mentransfer nama lengkap kota di API dan melakukan pencarian pada hari yang diinginkan. Sekarang layanan web skill segera menerima informasi ini langsung dalam permintaan:



Tetapi fitur seperti itu muncul sekitar Oktober 2018, dan keterampilan itu dikembangkan sedikit lebih awal, sehingga Dialogflow dipilih untuk memahami bahasa alami. Ini memiliki sistem markup yang sangat baik, dan dari waktu ke waktu Anda dapat melatihnya, menunjukkan apa yang dimaksud pengguna dalam frasa yang diberikan.

Jadi, klien memberi nama kota dan tanggal dengan caranya sendiri, keterampilan menyampaikan kata-katanya ke Dialogflow, dan mengirimkan nama kota yang dikenal ke API, dari mana ia menerima pengidentifikasi yang diperlukan. Rantai ini panjang dan karenanya kemungkinan besar tidak akan memenuhi 1500 ms yang diperlukan.

Solusi yang jelas adalah melakukan cache. Dan sebagai kunci, Anda dapat menentukan dengan tepat apa yang dikatakan pengguna, dan di nilai menyimpan pengidentifikasi kota dari sistem kami. Kemudian dalam cache ada beberapa entri untuk satu kota, misalnya, untuk kata "Peter" dan "St. Petersburg". Tetapi ini tidak penting jika nilainya tidak menunjukkan terlalu banyak informasi. Bagaimanapun, pendekatan ini akan memungkinkan mengisi cache dengan kota-kota populer yang diminta oleh pengguna lain, atau "menghangatkannya" terlebih dahulu. Ini akan memungkinkan Anda untuk menggunakan Dialogflow dan API lebih jarang di masa depan, yang akan menghemat waktu lagi.

Langkah paling menarik adalah memulai pencarian. Ada semua parameter yang diperlukan, tetapi agar hasilnya datang ke orang yang tepat, Anda harus “menarik” layanan pencarian internal. Selain itu, pencarian itu sendiri membutuhkan waktu yang cukup lama, dan operasi jangka panjang paling baik dilakukan bukan dalam layanan web yang sama, tetapi dalam aplikasi terpisah.

Sudah waktunya untuk menggunakan server perusahaan yang tersedia. Di dalamnya Anda dapat menggunakan aplikasi yang entah bagaimana akan "mengambil" informasi dari luar dan melakukan tugas jangka panjang, termasuk memulai pencarian.

Aplikasi semacam itu bisa menjadi layanan latar belakang.

Dari namanya jelas bahwa ini adalah aplikasi tanpa UI, yang harus mulai bekerja bersamaan dengan memulai server dan melakukan tindakan yang direncanakan, atau tindakan pada perintah (pesan) tertentu. Kami biasanya mengatur layanan seperti itu pada kerangka Topshelf , dan itu dapat menerima perintah, misalnya, dari antrian pesan berdasarkan protokol AMQP .

Singkatnya, antriannya berfungsi seperti ini: ada broker di mana pengirim menambahkan pesan dari jenis tertentu. Dan ada pembaca yang terhubung ke broker dan mendapatkan informasi yang diperlukan.
Deskripsi yang lebih terperinci dapat ditemukan, misalnya, dalam artikel ini .

Solusi cloud yang baik ditemukan di Internet, memberikan antrian pesan sebagai layanan - CloudAMQP . Dia memiliki tarif gratis, tetapi berfungsi dengan stabil. Argumen lain untuk pilihannya adalah bahwa layanan ini bekerja berdasarkan RabbitMQ , yang juga sangat kami gunakan di tempat kerja.

Jadi, mari kita lihat pekerjaan keterampilan secara keseluruhan: layanan web keterampilan berinteraksi dengan API aplikasi seluler dan Dialogflow. Hasil panggilan ke mereka di-cache di Redis, dan status disimpan di sana. Setelah mengkonfirmasikan parameter perjalanan, keterampilan mengirim pesan ke broker dengan semua informasi yang diperlukan. Layanan latar belakang pada server pengujian terhubung, dan ketika sebuah pesan muncul, memulai pencarian, dan hasilnya dikirim ke aplikasi seluler.


Ketika klien mengunduh dan menginstalnya, klien akan menemukannya dalam permintaannya:



Ini melengkapi pekerjaan keterampilan.

Ringkasan

Apa yang terjadi selanjutnya? Keahlian ini ditunjukkan kepada beberapa pelanggan untuk mendapatkan umpan balik, dan inilah yang kami temukan: pengguna sendiri enggan untuk beralih ke aplikasi seluler, tidak peduli seberapa keren itu. Lebih mudah bagi sebagian dari mereka untuk menghubungi agen kami di telepon dan memintanya untuk mencari apa yang dia butuhkan.

Seperti yang ditunjukkan oleh praktik, dalam kasus khusus ini, pengguna lebih tertarik berinteraksi dengan asisten suara. Dalam hal ini, ia menggantikan agen, yang memungkinkannya menghemat sedikit waktu, dan pada saat yang sama memotivasi pelanggan untuk mengunduh aplikasi agar dapat terus bekerja dengan opsi di dalamnya.

Ternyata, berkat keterampilan, dimungkinkan untuk menghemat sumber daya tertentu dan meningkatkan beberapa indikator utama, yaitu asumsi manfaat keterampilan untuk perusahaan kami telah dikonfirmasi.

Saya ingin menekankan beberapa kesimpulan. Jelas: untuk menjaga dengan 1500 ms, hindari membuat permintaan yang tidak perlu untuk layanan web, cache. Anda dapat menggunakan kunci cache yang berbeda untuk informasi yang sama. Ini dibenarkan jika setidaknya satu orang masuk ke cache yang dihasilkan oleh pengguna lain. Dan yang paling penting: lebih baik melakukan operasi yang panjang dalam layanan latar belakang yang terpisah: selain fakta bahwa ia memberikan desentralisasi keterampilan, itu akan memiliki lebih sedikit masalah dengan multithreading, dan jika perlu, itu dapat "digunakan" di dalam jaringan tertutup perusahaan dan "mengambil" pesan dari luar.

Alih-alih sebuah epilog

Chatbots dan skill sering ditulis dalam JavaScript dan Python (dilihat dari jumlah repositori di GitHub untuk “chatbot”). Ini juga karena publikasi yang mudah di server. Proyek ini ditulis dalam C # di bawah .net core. Dalam kasus kerangka .net klasik, ada beberapa kesulitan tertentu dalam penerbitan (terutama bekerja di bawah Windows, dll.), Tetapi banyak yang telah berubah dengan munculnya inti .net. Untuk setiap layanan atau kerangka kerja yang disebutkan di atas, ada perpustakaan yang sepenuhnya mendukung teknologi ini. Berkat ini, keterampilan berpotensi dijalankan di server Linux, dan bahkan lebih lagi pada hosting apa pun yang mendukung Docker. Jika tiba-tiba Anda berada dalam pencarian yang kreatif, saya sarankan memperhatikan kerangka ini, itu menjadi alternatif yang baik untuk mengembangkan bot obrolan.

PS
UPD 08/01/2019: mulai sekarang, batas waktu untuk skill adalah 3 detik .