Bagaimana kami mengajarkan kecerdasan buatan untuk menjawab pertanyaan dukungan. Pengalaman Yandex.Taxi

Tidak ada layanan yang ideal - terkadang pengguna memiliki pertanyaan tentang dukungan teknis. Sulit untuk mengatakan bahwa dalam kasus seperti itu, lebih tidak menyenangkan untuk mencoba menggabungkan kombinasi replika bot templat yang dapat menyelesaikan masalah, atau menunggu tanggapan spesialis yang akan menghubungi Anda sudah setengah hari.

Di Yandex.Taxi, dari dua opsi, kami memilih yang ketiga - menggunakan kecerdasan mesin untuk membuat dukungan teknis dengan wajah manusia. Nama saya Tatyana Savelyeva, grup saya terlibat dalam pembelajaran mesin pada data yang tidak terstruktur. Di bawah cut - saya berbagi wawasan pengguna, memberi tahu cara mengotomatiskan proses yang kompleks, mengatur kerja tim yang sangat berbeda dan, tentu saja, menerapkan pembelajaran mendalam dan peretasan teknis dalam praktik (tanpa mereka).



Mengapa mengotomatiskan apa saja?


Tampaknya, mengapa menciptakan struktur dukungan multi-tahap - mempekerjakan lebih banyak orang. Mungkin ini akan berhasil jika sekitar 10 permintaan per hari datang mendukung. Tetapi ketika jumlah panggilan pengguna cenderung satu juta (yang merupakan persentase kecil dari perjalanan untuk Taksi Yandex, tapi itu benar-benar mengesankan), kita harus memikirkan taktik yang lebih andal: menemukan dan melatih sejumlah operator yang memadai yang dapat mengatasi masalah atipikal dalam volume seperti itu setidaknya lebih sulit. .

Beberapa waktu lalu, industri memutuskan untuk menyelesaikan masalah ini dengan bantuan beberapa level dukungan. Pada tahap pertama, pertanyaan-pertanyaan yang paling sederhana dan dapat diprediksi disaring: jika jawaban siap tidak cocok, masalahnya diklasifikasikan dan diteruskan ke pakar yang lebih berkualitas. Elegan, tapi ada nuansa.

Jumlah panggilan bertambah - butuh lebih banyak waktu untuk memprosesnya. Throughput operator, faktor manusia - apakah ada banyak alasan yang memperlambat sistem, ke mana tagihan berjalan selama beberapa menit? Banyak dari pembatasan ini dapat diatasi dengan bantuan mesin: itu tidak akan salah jika lelah, dan itu membuat keputusan lebih cepat.

Sekitar setahun yang lalu, kami mulai menggunakan pembelajaran mesin untuk segera menanyakan skenario interaksi yang mungkin dilakukan operator. Pelanggan sekarang mendapatkan jawaban lebih cepat. Tetapi tidak ada batasan untuk kesempurnaan!

Di mana untuk memulai?


Misalkan Anda kurang beruntung: pengemudi tidak datang dan tidak menghubungi Anda. Apa yang akan terjadi dengan Anda menghubungi dukungan Yandex.Taxi?



Apa yang bisa dioptimalkan untuk menyelesaikan masalah lebih cepat? Mari kita mulai dari tahap pertama , di mana tiket menuju ke salah satu dari dua baris. Awalnya, pilihan tergantung pada kata kunci dalam kueri - itu berhasil, tetapi akurasi penentuannya agak rendah. Untuk memperbaikinya, penggolong yang didasarkan pada model-encoder jaringan saraf klasik BERT membantu.

Dalam tugas ini, kelengkapan diperbaiki untuk jalur ahli: kasus yang membutuhkan proses tidak boleh lewat mereka. Tetapi jangan lupa tentang perjuangan untuk meningkatkan akurasi: sesedikit mungkin panggilan sederhana harus dilakukan di jalur ahli sehingga waktu respons untuk kasus yang sangat kritis tidak melampaui kesabaran pengguna. Akurasi klasifikasi dengan metode pembelajaran mesin ternyata 2 kali lebih efektif daripada analisis kata kunci. Kecepatan respons terhadap situasi darurat meningkat 1,5 kali.

Mencoba untuk mengotomatiskan pekerjaan garis ahli dalam kerangka teknologi yang ada saat ini penuh: logika apa yang terjadi sulit untuk disistematisasi, dan kesalahan apa pun akan sangat mahal. Mari kita kembali ke query lini pertama yang khas dan telah dipelajari dengan baik - mungkin mempercayakan pemrosesan mereka ke algoritma? Jadi tugas rutin akan diselesaikan lebih cepat, dan karyawan akan dapat lebih memperhatikan kasus kontroversial yang melampaui ruang lingkup templat.

Untuk menguji ide ini, sebuah sujest dikembangkan - sebuah sistem petunjuk yang menawarkan kepada staf pendukung 3 opsi yang paling disukai untuk menjawab permintaan saat ini:



Eksperimen berhasil: dalam 70% kasus, operator memilih salah satu pesan yang diusulkan, yang mengurangi waktu respons sebesar 10%. Tampaknya sudah waktunya untuk mengotomatisasi sepenuhnya baris pertama.

Perlu rencana.Apa yang dilakukan karyawan garis depan ?

  1. Membaca teks, menentukan subjek perawatan.
  2. Memeriksa informasi perjalanan.
  3. Pilih salah satu jawaban yang disiapkan, dengan mempertimbangkan dua poin pertama.

Contoh untuk menembus. Diberikan: permintaan teks untuk pengguna yang tertekan, beberapa informasi perjalanan, staf pendukung yang peduli.



Pertama-tama, karyawan akan menentukan subjek banding: "Mendebit ganda dari kartu." Selanjutnya, periksa metode pembayaran, status dan jumlah yang dibebankan. Uang dihapuskan sekali: apa alasannya? Ya, ini dia: dua notifikasi berturut-turut.

Apa yang harus dilakukan sistem jawab otomatis?

Semua sama. Bahkan persyaratan utama untuk jawaban tidak akan berubah:

Kualitas

Jika pengguna mengeluh tentang aplikasi, tidak perlu berjanji untuk meminta pengemudi untuk mencuci mobil. Tidak cukup hanya memahami apa masalahnya, kita harus menjelaskan secara rinci bagaimana menyelesaikannya.

Kecepatan
Terutama jika situasinya kritis dan jawabannya penting saat ini.

Fleksibilitas dan skalabilitas.

Tugas dengan tanda bintang: meskipun penciptaan sistem pendukung dengan Taxi telah dimulai, ada baiknya mentransfer hasilnya ke layanan lain: Yandex.Food atau Yandex.Lavka, misalnya. Yaitu, ketika mengubah logika dukungan - templat respons, topik panggilan, dll. - Saya ingin mengkonfigurasi ulang sistem dalam hitungan hari, bukan bulan.

Bagaimana penerapannya


Tahap 1. Kami menentukan subjek teks menggunakan ML.

Pertama, kami menyusun pohon topik referensi dan melatih classifier untuk menavigasi mereka. Ada sekitar 200 kemungkinan masalah: dengan perjalanan (pengemudi tidak datang), dengan aplikasi (saya tidak dapat melampirkan kartu), dengan mobil (mobil kotor), dll.

Seperti disebutkan di atas, kami menggunakan model pra-dilatih berdasarkan BERT. Artinya, untuk mengklasifikasikan teks kueri, perlu untuk menyajikannya dalam bentuk vektor sehingga kalimat yang serupa dalam arti terletak berdampingan di ruang yang dihasilkan.

BERT telah dilatih sebelumnya pada dua tugas dengan teks yang tidak terisi. Pada yang pertama, 15% token diganti secara acak dengan [MASK], dan jaringan, berdasarkan konteks, memprediksi token awal - ini memberikan model dengan "bi-directionality" alami. Tugas kedua mengajarkan kita untuk menentukan hubungan antara proposal: apakah dua entri diajukan dalam satu baris atau tersebar di seluruh teks?

Setelah menyelesaikan arsitektur BERT pada sampel permintaan untuk dukungan teknis Yandex.Taxi, kami mendapatkan jaringan yang mampu memprediksi subjek pesan, disesuaikan dengan spesifikasi layanan kami. Namun, frekuensi topik dan topik itu sendiri berubah: agar jaringan dapat diperbarui dengan mereka, kami secara terpisah akan melatih hanya lapisan bawah model pada data terbaru - selama beberapa minggu terakhir. Jadi pengetahuan tentang fitur-fitur dari teks pendukung dipertahankan, dan probabilitas untuk kelas yang mungkin didistribusikan secara memadai hingga hari ini.

Sedikit lagi tentang kecukupan: untuk semua layanan kami - termasuk Taxi - seluruh perpustakaan modul arsitektur model dan metode untuk memvalidasi ambang probabilitas telah dikembangkan. Ini memungkinkan Anda untuk:

  • , : , — ;
  • , . , . , , , .

Tahap 2. Kami bekerja dengan informasi tentang perjalanan: kami meresepkan aturan bisnis untuk setiap templat.

Staf pendukung ditawari sebuah antarmuka di mana, untuk setiap templat respons, diperlukan beberapa peraturan wajib. Bagaimana tampilannya, misalnya, untuk kasus pembayaran ganda:

Templat: "Halo! Saya memeriksa semuanya: perjalanan dibayar sekali. Uang pertama kali "dibekukan" pada kartu Anda dan baru kemudian didebit, karena ini bank dapat dua kali menginformasikan tentang satu transaksi. Silakan periksa laporan bank Anda untuk memastikan. Jika Anda melihat dua jumlah penghapusan di sana, silakan kirim pindaian atau foto pernyataan "

Aturan: payment_type adalah" kartu "dan transaction_status adalah" clear_success "dan transaction_sum == order_cost

Hanya untuk templat dukungan pelanggan, para ahli kami telah menyelesaikan lebih dari 1,5 ribu aturan.

Tahap 3. Kami memilih jawabannya: kami menggabungkan topik teks yang sesuai dan aturan bisnis untuk templat.Setiap

topik dicocokkan dengan templat respons yang sesuai: topik ditentukan oleh metode ML, dan templat yang meresponsnya diperiksa kebenarannya dengan aturan dari paragraf sebelumnya. Pengguna akan menerima respons, verifikasi yang mengembalikan nilai "Benar". Jika ada beberapa opsi seperti itu, yang paling populer di antara staf pendukung akan dipilih.



Omong-omong, proses interaksi dengan driver di Yandex.Taxi tidak berubah sama sekali: model hanya memilih template yang diinginkan untuk operator dan menjawab pengguna secara independen.

Menyelesaikan


Hore! Sistem dirancang, peluncuran berlangsung, optimasi menunjukkan hasil yang sangat baik, tetapi terlalu dini untuk bersantai. Autoresponders harus berfungsi secara stabil tanpa intervensi konstan dan dapat dengan mudah diskalakan - sendiri atau dalam mode semi-manual. Ini kami raih berkat struktur tiga bagian sistem:

  1. Pengembangan offline - pada tahap ini, model berubah, aturan disiapkan;
  2. Layanan produksi - layanan mikro yang mengambil pembaruan, menerapkannya dan merespons pengguna secara real time;
  3. Analisis hasil selanjutnya untuk memastikan bahwa model baru berfungsi dengan benar, pengguna senang dengan jawaban otomatis.



Dan lagi pada contoh-contohnya. Bagian atas Daftar Keinginan pelanggan yang paling populer (dan bagaimana kami menghadapinya tanpa menulis kode):

Taksi memiliki jawaban otomatis yang keren: Saya menginginkan hal yang sama di Yandex.Ed

Untuk menghubungkan dukungan apa pun ke sistem kami, Anda memerlukan empat langkah sederhana:

  1. Buat pohon topik untuk teks;
  2. Cocokkan setiap tema dengan pola;
  3. Isi seperangkat aturan dengan templat di panel admin kami;
  4. Berikan tabel korespondensi antara permintaan pengguna dan jawaban dukungan.

Jika semua ini ada di sana, kami akan menetapkan jalur ke unggahan baru, model akan belajar dari data yang diterima dan menarik ke layanan microser kami bersama dengan semua aturan yang ditetapkan (mengintegrasikan dengan tema ML tertentu). Harap dicatat: tidak ada logika baru yang ditulis, semua dalam kerangka proses yang ada!

Logika dukungan telah berubah, kami menginginkan aturan baru.

Tolong - isi aturan baru di panel admin kami. Sistem akan menganalisis bagaimana perubahan akan memengaruhi persentase jawaban otomatis *, dengan mempertimbangkan seberapa menuntut aturan itu. Jika semuanya berjalan dengan baik, aturan yang selesai diubah menjadi konfigurasi dan dimuat ke layanan ML. Hore! Kurang dari satu jam telah berlalu, dan aturan bisnis telah diperbarui dalam produksi, tidak ada satu baris kode pun yang ditulis, programmer tidak terganggu.

* Sepertinya ini tidak terlalu jelas, jadi mari kita tambahkan contoh ke contoh. Misalkan, para ahli memperkenalkan aturan: penggunaan templat respons tertentu hanya mungkin untuk pesanan yang bernilai lebih dari 200 rubel. Jika pembatasan ini berhasil, tiket untuk perjalanan dengan jumlah yang lebih kecil akan tetap tertutup, proporsi jawaban yang dipilih secara otomatis akan berkurang, dan efisiensi seluruh sistem akan berkurang. Untuk mencegah hal ini terjadi, penting untuk mencegat aturan yang gagal pada waktunya dan mengirimkannya untuk direvisi.

Kami menambahkan tema baru, kami ingin mengubah model, kami membutuhkan segalanya untuk bekerja besok.

Seringkali, spesialis konten ingin menambahkan topik baru, membaginya menjadi yang sudah ada, atau menghapus yang tidak relevan. Tidak masalah - Anda perlu mengubah korespondensi antara topik dan template respons di panel admin.

Jika topik baru atau yang diubah telah muncul dalam jawaban karyawan pendukung lini pertama, model, dengan pelatihan ulang reguler, akan secara otomatis mengencangkan data ini dan menghitung ambang batas untuknya (untuk data dari minggu lalu, kecuali untuk set yang ditangguhkan untuk pengujian).

Pada sampel uji, model lama dan baru dibandingkan sesuai dengan metrik khusus - akurasi, bagian tersebut diperbaiki secara otomatis. Jika perubahan positif, model baru diluncurkan dalam produksi.

Kami menganalisis metrik: jangan tenggelam, jangan putus


Kami akan fokus pada dua kriteria - peringkat rata-rata dari autoresponse oleh pengguna dan munculnya pertanyaan tambahan. Perubahan dipantau dalam ab-eksperimen, tidak ada penarikan metrik yang signifikan secara statistik diamati, apalagi, sering pengguna menilai tinggi hasil model karena kecepatan respons.

Namun, tidak peduli seberapa keras kami berusaha, metode pembelajaran mesin terkadang menghasilkan reaksi yang absurd. Setelah pembaruan berikutnya dari model, kami menangkap kasus seperti itu:

Pengguna: Berkat pengemudi, mobil tiba tepat waktu, pengemudi bekerja dengan baik, semuanya berjalan dengan sempurna! Dukungan
: Kami akan menghukum pengemudi, ini tidak akan terjadi lagi.

Peluncuran, untungnya, adalah ujian. Dan masalahnya adalah ini: model belajar menanggapi ulasan dengan peringkat kurang dari 4, dan terkadang kami keliru menunjukkan ulasannya dengan bintang 4 dan 5. Tentu saja, karena keterbatasan belajar, tidak ada lagi neuron cerdas yang bisa menjawab. Ketika diimplementasikan, kasus-kasus seperti itu jarang terjadi (0,1% dari total) - kami melacaknya dan mengambil langkah-langkah yang tepat: jaringan saraf akan menanggapi pesan berulang pengguna.

Kesimpulan dan rencana untuk masa depan


Setelah menghubungkan sistem respons otomatis, kami mulai merespons lebih cepat terhadap permintaan pengguna dan memberi perhatian maksimal pada kasus-kasus yang sangat rumit yang memerlukan penyelidikan terperinci. Kami berharap ini akan membantu kami meningkatkan kualitas Yandex.Taxi dan meminimalkan jumlah insiden yang tidak menyenangkan.

Model perbaikan otomatis menutup sekitar 60% dari baris pertama, tanpa menyia-nyiakan nilai rata-rata pengguna. Kami berencana untuk mengembangkan metode ini lebih lanjut dan meningkatkan persentase jawaban otomatis di baris pertama menjadi 99,9%. Dan, tentu saja, terus membantu Anda - mendukung aplikasi kami dan berbagi pengalaman tentang hal itu di Habré.

All Articles