Antarmuka pemrograman aplikasi (API) memainkan peran yang semakin penting baik di dunia virtual maupun fisik berkat perkembangan teknologi seperti arsitektur berorientasi layanan, komputasi awan, dan Internet of things (IoT). Hari ini, kolega kami dari divisi Microsoft Research membagikan praktik terbaik mereka di bidang Natural Language Interfaces (antarmuka bahasa alami). Bergabunglah sekarang!
Layanan web berbasis cloud yang didedikasikan untuk cuaca, olahraga, dan keuangan melalui API web menyediakan data dan layanan kepada pengguna akhir, sementara perangkat IoT memungkinkan perangkat lain di jaringan untuk menggunakan fungsionalitasnya.
Biasanya, API digunakan dalam berbagai perangkat lunak: aplikasi desktop, situs web, dan aplikasi seluler. Mereka juga melayani pengguna melalui antarmuka pengguna grafis (GUI). Antarmuka grafis telah memberikan kontribusi besar untuk mempopulerkan komputer, tetapi, dengan perkembangan teknologi komputer, banyak keterbatasan mereka menjadi lebih jelas. Ketika perangkat menjadi lebih kecil, lebih mobile, dan lebih pintar, semakin banyak tuntutan ditempatkan pada tampilan grafis di layar, misalnya, dengan perangkat portabel atau perangkat yang terhubung ke IoT.
Pengguna juga dipaksa untuk terbiasa dengan berbagai antarmuka grafis saat menggunakan berbagai layanan dan perangkat. Karena jumlah layanan dan perangkat yang tersedia meningkat, demikian juga biaya pelatihan dan adaptasi pengguna. Natural Language Interfaces (NLI) menunjukkan potensi signifikan sebagai alat cerdas tunggal untuk berbagai layanan dan perangkat sisi server. NLI memiliki kemampuan luar biasa untuk menentukan maksud pengguna dan mengenali informasi kontekstual, yang membuat aplikasi, seperti asisten virtual, jauh lebih nyaman bagi pengguna.
Kami mempelajari antarmuka bahasa alami untuk API (NL2API). Tidak seperti NLI tujuan umum seperti asisten virtual, kami mencoba memahami cara membuat NLI untuk masing-masing API web, seperti API layanan kalender. Di masa depan, NL2API ini akan dapat mendemokratisasikan API, membantu pengguna berinteraksi dengan sistem perangkat lunak. Mereka juga dapat memecahkan masalah skalabilitas asisten virtual tujuan umum dengan memungkinkan pengembangan terdistribusi. Kegunaan asisten virtual sangat tergantung pada luasnya kemampuannya, yaitu, pada jumlah layanan yang didukungnya.
Namun, mengintegrasikan layanan web menjadi asisten virtual satu per satu adalah pekerjaan yang sangat melelahkan. Jika masing-masing penyedia layanan web memiliki cara mudah untuk membuat NLI untuk API mereka, biaya integrasi dapat dikurangi secara signifikan. Asisten virtual tidak perlu menangani antarmuka yang berbeda untuk layanan web yang berbeda. Akan cukup baginya untuk hanya mengintegrasikan NL2API individu, yang mencapai keseragaman berkat bahasa alami. NL2API juga dapat memfasilitasi pengembangan layanan web, pemrograman sistem rekomendasi, dan bantuan untuk API. Dengan demikian, Anda tidak harus menghafal sejumlah besar API web yang tersedia dan sintaksisnya.
Gambar 1. Cara membuat antarmuka bahasa alami untuk API. Kiri: metode tradisional mengajarkan model persepsi bahasa untuk mengenali niat dalam bahasa alami, model lain belajar mengekstrak sel yang terkait dengan setiap niat, dan kemudian mencocokkannya secara manual dengan permintaan API. Kanan: metode kami dapat menerjemahkan bahasa alami langsung ke permintaan API.Tugas utama NL2API adalah mengenali ekspresi dalam bahasa alami pengguna dan menerjemahkannya ke dalam permintaan API. Untuk lebih tepatnya, kami fokus pada API web yang dibuat dalam rupa arsitektur REST, yaitu RESTful API. RESTful APIs banyak digunakan dalam layanan web, perangkat untuk IoT, serta dalam aplikasi untuk smartphone. Contoh dari Microsoft Graph API ditunjukkan pada Gambar 1.
Sisi kiri gambar menunjukkan metode tradisional membangun bahasa alami, di mana kami mengajarkan model persepsi bahasa untuk mengenali niat, dan model lain untuk mengekstraksi sel yang terkait dengan masing-masing niat, dan kemudian secara manual mencocokkannya dengan permintaan API dengan menulis kode. Alih-alih (seperti yang diperlihatkan di sisi kanan gambar), kita dapat mempelajari cara menerjemahkan ekspresi dari bahasa alami langsung ke permintaan API. Sebagai bagian dari penelitian, kami menggunakan sistem kami untuk API dari paket
Microsoft Graph API . Microsoft Graph Web API memungkinkan pengembang untuk mengakses data yang meningkatkan produktivitas: surat, kalender, kontak, dokumen, direktori, perangkat, dan banyak lagi.
Gambar 2. Microsoft Graph Web API memungkinkan pengembang mengakses data yang memberikan peningkatan produktivitas: surat, kalender, kontak, dokumen, direktori, perangkat, dan banyak lagi.Salah satu persyaratan untuk model yang kami kembangkan adalah kemampuan untuk membuat antarmuka pengguna yang terperinci. Kebanyakan NLI yang ada tidak banyak membantu pengguna jika tim tidak dikenali dengan benar. Kami menyarankan bahwa pengalaman pengguna yang lebih rinci dapat membuat NLI jauh lebih nyaman.
Kami mengembangkan model modular yang bekerja berdasarkan “dari urutan ke urutan” (lihat Gambar 3) untuk memberikan interaksi terperinci dengan NLI. Untuk melakukan ini, kami menggunakan arsitektur yang bekerja pada prinsip "dari urutan ke urutan", tetapi pada saat yang sama kami memecah hasil dekripsi menjadi beberapa unit yang ditafsirkan, yang disebut modul.
Setiap modul mencoba memprediksi hasil yang telah ditentukan, misalnya, dengan menggunakan parameter tertentu berdasarkan pernyataan yang diterima di NL2API. Setelah perbandingan sederhana, pengguna dapat dengan mudah memahami hasil perkiraan setiap modul dan berinteraksi dengan sistem pada tingkat modular. Setiap modul dalam model kami menghasilkan hasil yang konsisten, bukan keadaan kontinu.
Gambar 3. Model modular yang bekerja dari urutan ke urutan. Kontroler mengaktifkan beberapa modul, yang masing-masing membuat parameter.Modul: Pertama kita mendefinisikan apa itu modul. Modul adalah jaringan saraf khusus yang dirancang untuk melakukan tugas tertentu dalam memprediksi urutan. Dalam NL2API, modul yang berbeda sesuai dengan parameter yang berbeda. Misalnya, dalam GET-Messages API, modul-modulnya adalah FILTER (pengirim), FILTER (isRead), SELECT (lampiran), ORDERBY (acceptDateTime), SEARCH, dll. Tugas modul ini adalah untuk mengenali pernyataan yang masuk dan membuat parameter penuh jika diaktifkan. Untuk ini, modul harus menentukan nilai parameternya berdasarkan pernyataan yang masuk.
Misalnya, jika pernyataan yang masuk terdengar seperti "surat yang belum dibaca tentang disertasi doktoral," modul SEARCH harus memprediksi bahwa nilai parameter SEARCH adalah "disertasi doktoral" dan menghasilkan parameter "disertasi doktoral SEARCH" lengkap sebagai urutan output. Dengan analogi, modul FILTER (isRead) harus mengingat frasa seperti "email yang belum dibaca", "email yang belum dibaca" dan "email yang belum dibaca" menunjukkan bahwa nilai parameternya harus "Salah" .
Wajar jika langkah selanjutnya adalah pembuatan modul decoder yang menentukan apa yang menjadi fokus, seperti pada model “from sequence to sequence” yang biasa. Namun, alih-alih satu decoder, yang digunakan untuk semuanya, kami sekarang memiliki beberapa decoder, yang masing-masing mengkhususkan diri dalam memprediksi parameter tertentu. Selain itu, karena setiap modul memiliki terminologi yang jelas, menjadi lebih mudah untuk mengkonfigurasi interaksi pengguna di tingkat modul.
Moderator: Hanya beberapa modul yang akan digunakan untuk setiap frase pengantar. Tugas regulator adalah menentukan modul mana yang akan dijalankan. Dengan demikian, regulator juga merupakan dekoder yang menentukan apa yang layak difokuskan. Dengan mengkode pernyataan dan mengubahnya menjadi input, itu menciptakan urutan modul yang disebut sirkuit. Kemudian modul membuat parameter yang sesuai dengan mereka, dan, akhirnya, parameter digabungkan untuk membentuk permintaan akhir ke API.
Dengan memecah proses peramalan yang rumit dalam model “urutan ke urutan” standar menjadi unit peramalan kecil yang sangat khusus yang disebut modul, model peramalan akan mudah dijelaskan kepada pengguna. Kemudian, dengan menggunakan umpan balik dari pengguna, dimungkinkan untuk memperbaiki kemungkinan kesalahan perkiraan di tingkat terendah. Dalam penelitian kami, kami menguji hipotesis kami dengan membandingkan NLI interaktif dengan versi non-interaktifnya, baik melalui simulasi maupun melalui eksperimen yang melibatkan orang yang menggunakan API yang benar-benar berfungsi. Kami dapat menunjukkan bahwa dengan NLI interaktif, pengguna mencapai kesuksesan lebih sering dan lebih cepat, menghasilkan tingkat kepuasan pengguna yang lebih tinggi.
Segera, kami akan menerbitkan
artikel yang merinci pembuatan antarmuka bahasa alami untuk API web. Tetap disini!