Bagaimana Amp di Amazon menggunakan data untuk meningkatkan keterlibatan pelanggan, Bagian 2: Membangun platform rekomendasi acara yang dipersonalisasi menggunakan Amazon SageMaker

ampli adalah aplikasi radio langsung baru dari Amazon. Dengan Amp, Anda dapat menyelenggarakan acara radio Anda sendiri dan memutar lagu dari katalog Amazon Music, atau mendengarkan dan mendengarkan acara yang dihosting oleh pengguna Amp lainnya. Dalam lingkungan di mana konten berlimpah dan beragam, penting untuk menyesuaikan pengalaman pengguna dengan selera masing-masing pengguna, sehingga mereka dapat dengan mudah menemukan acara yang mereka sukai dan menemukan konten baru yang akan mereka nikmati.

Amp menggunakan pembelajaran mesin (ML) untuk memberikan rekomendasi yang dipersonalisasi untuk acara Amp langsung dan yang akan datang di halaman beranda aplikasi. Rekomendasi dihitung menggunakan model Hutan Acak menggunakan fitur yang mewakili popularitas suatu acara (seperti jumlah pendengar dan suka), popularitas pencipta (seperti jumlah total berapa kali acara baru-baru ini diputar), dan kedekatan pribadi pengguna dengan topik acara dan pembuatnya. Afinitas dihitung baik secara implisit dari data perilaku pengguna atau secara eksplisit dari topik yang diminati (seperti musik pop, baseball, atau politik) seperti yang disediakan di profil pengguna mereka.

Ini adalah Bagian 2 dari seri tentang penggunaan analitik data dan ML untuk Amp dan membuat platform daftar rekomendasi acara yang dipersonalisasi. Platform ini telah menunjukkan peningkatan 3% pada metrik keterlibatan pelanggan yang dilacak (menyukai acara, mengikuti pembuat konten, mengaktifkan pemberitahuan acara mendatang) sejak diluncurkan pada Mei 2022.

Lihat bagian 1 untuk mempelajari bagaimana data perilaku dikumpulkan dan diproses menggunakan sistem data dan analitik.

Ikhtisar solusi

Rekomendasi acara berbasis ML untuk Amp memiliki lima komponen utama, seperti yang diilustrasikan dalam diagram arsitektur berikut:

1. Aplikasi seluler Amp.
2. Layanan back-end yang mengumpulkan data perilaku, seperti suka dan mengikuti, serta informasi terkait acara siaran seperti pembaruan status saat acara ditayangkan.
3. Penyerapan data perilaku dan acara secara real-time, dan komputasi dan penyimpanan fitur real-time (online).
4. Batch (offline) fitur komputasi dan penyimpanan.
5. Sistem Rekomendasi yang menangani permintaan masuk dari backend aplikasi untuk mendapatkan daftar acara. Ini termasuk inferensi waktu nyata untuk memeringkat acara berdasarkan fitur yang dipersonalisasi dan yang tidak dipersonalisasi.

Posting ini berfokus pada bagian 3, 4, dan 5 dalam upaya untuk merinci hal-hal berikut:

Diagram berikut menunjukkan arsitektur tingkat tinggi dan komponennya.

Di bagian berikut, kami memberikan detail lebih lanjut mengenai komputasi fitur waktu nyata, komputasi fitur batch, inferensi waktu nyata, kesehatan operasional, dan hasil yang kami amati.

Komputasi fitur waktu nyata

Beberapa fitur, seperti jumlah suka dan dengar untuk sebuah acara, perlu dialirkan secara terus menerus dan digunakan apa adanya, sedangkan yang lain, seperti jumlah sesi mendengarkan yang lebih lama dari 5 menit, juga perlu diubah secara real time sebagai data mentah. untuk sesi dialirkan. Jenis fitur di mana nilai perlu dihitung pada waktu inferensi disebut sebagai titik waktu (PIT) fitur. Data untuk fitur PIT perlu diperbarui dengan cepat, dan versi terbaru harus ditulis dan dibaca dengan latensi rendah (di bawah 20 milidetik per pengguna untuk 1,000 pertunjukan). Data juga harus disimpan dalam penyimpanan yang tahan lama karena data yang hilang atau sebagian dapat menyebabkan rekomendasi yang memburuk dan pengalaman pelanggan yang buruk. Selain latensi baca/tulis, fitur PIT juga membutuhkan waktu refleksi yang rendah. Waktu refleksi adalah waktu yang diperlukan agar fitur tersedia untuk dibaca setelah peristiwa yang berkontribusi dipancarkan, misalnya, waktu antara pendengar yang menyukai acara dan fitur PIT LikeCount diperbarui.

Sumber data adalah layanan backend yang langsung melayani aplikasi. Beberapa data diubah menjadi metrik yang kemudian disiarkan melalui Layanan Pemberitahuan Sederhana Amazon (Amazon SNS) ke pendengar hilir seperti saluran transformasi fitur ML. Basis data dalam memori seperti MemoryDB adalah layanan ideal untuk penyimpanan yang tahan lama dan kinerja ultra-cepat pada volume tinggi. Komponen komputasi yang mengubah dan menulis fitur ke MemoryDB adalah Lambda. Lalu lintas aplikasi mengikuti pola puncak dan penurunan harian dan mingguan tergantung pada waktu dan hari. Lambda memungkinkan penskalaan otomatis ke volume acara yang masuk. Sifat independen dari setiap transformasi metrik individu juga membuat Lambda, yang merupakan layanan tanpa kewarganegaraan, cocok untuk masalah ini. Menempatkan Layanan Antrian Sederhana Amazon (Amazon SQS) antara Amazon SNS dan Lambda tidak hanya mencegah hilangnya pesan tetapi juga bertindak sebagai buffer untuk ledakan lalu lintas yang tidak terduga yang mungkin tidak cukup untuk dilayani oleh batas konkurensi Lambda yang telah dikonfigurasi sebelumnya.

Komputasi fitur batch

Fitur yang menggunakan data perilaku historis untuk mewakili selera pengguna yang terus berkembang lebih kompleks untuk dihitung dan tidak dapat dihitung secara real time. Fitur-fitur ini dihitung dengan proses batch yang berjalan sangat sering, misalnya sekali sehari. Data untuk fitur batch harus mendukung kueri cepat untuk pemfilteran dan agregasi data, dan dapat berlangsung dalam jangka waktu yang lama, sehingga volumenya akan lebih besar. Karena fitur batch juga diambil dan dikirim sebagai input untuk inferensi waktu nyata, fitur tersebut tetap harus dibaca dengan latensi rendah.

Mengumpulkan data mentah untuk komputasi fitur batch tidak memiliki persyaratan waktu refleksi sub-menit yang dimiliki fitur PIT, yang membuatnya layak untuk menyangga peristiwa lebih lama dan mengubah metrik dalam batch. Solusi ini menggunakan Kinesis Data Firehose, layanan terkelola untuk menyerap data streaming dengan cepat ke beberapa tujuan, termasuk Layanan Penyimpanan Sederhana Amazon (Amazon S3) untuk metrik yang bertahan pada data lake S3 yang akan digunakan dalam komputasi offline. Kinesis Data Firehose menyediakan buffer peristiwa dan integrasi Lambda untuk mengumpulkan, mengubah batch, dan mempertahankan metrik ini dengan mudah ke Amazon S3 untuk digunakan nanti oleh komputasi fitur batch. Penghitungan fitur batch tidak memiliki persyaratan baca/tulis latensi rendah yang sama dengan fitur PIT, yang menjadikan Amazon S3 pilihan yang lebih baik karena menyediakan penyimpanan berbiaya rendah dan tahan lama untuk menyimpan metrik bisnis volume besar ini.

Model ML awal kami menggunakan 21 fitur batch yang dihitung setiap hari menggunakan data yang diambil dalam 2 bulan terakhir. Data ini mencakup riwayat pemutaran dan keterlibatan aplikasi per pengguna, dan bertambah seiring dengan jumlah pengguna dan frekuensi penggunaan aplikasi. Rekayasa fitur pada skala ini memerlukan proses otomatis untuk menarik data input yang diperlukan, memprosesnya secara paralel, dan mengekspor hasilnya ke penyimpanan persisten. Infrastruktur pemrosesan diperlukan hanya selama durasi komputasi. Pengolahan SageMaker menyediakan image Docker bawaan yang menyertakan Apache Spark dan dependensi lain yang diperlukan untuk menjalankan tugas pemrosesan data terdistribusi dalam skala besar. Infrastruktur dasar untuk pekerjaan Pemrosesan sepenuhnya dikelola oleh SageMaker. Sumber daya cluster disediakan selama pekerjaan Anda, dan dibersihkan saat pekerjaan selesai.

Setiap langkah dalam proses batch—pengumpulan data, rekayasa fitur, persistensi fitur—adalah bagian dari alur kerja yang memerlukan penanganan kesalahan, percobaan ulang, dan transisi status di antaranya. Dengan Fungsi Langkah AWS, Anda dapat membuat mesin status dan membagi alur kerja Anda menjadi beberapa langkah prapemrosesan dan pascapemrosesan, serta langkah untuk mempertahankan fitur ke dalam SageMaker Feature Store atau data lainnya ke Amazon S3. Mesin status dalam Fungsi Langkah dapat dipicu melalui Jembatan Acara Amazon untuk mengotomatiskan komputasi batch agar berjalan pada jadwal yang ditetapkan, seperti sekali setiap hari pada pukul 10:00 UTC.

Setelah fitur dihitung, fitur tersebut perlu diversi dan disimpan untuk dibaca selama inferensi serta pelatihan ulang model. Daripada membangun penyimpanan fitur dan layanan manajemen Anda sendiri, Anda dapat menggunakan Toko Fitur SageMaker. Feature Store adalah repositori yang dibuat khusus untuk menyimpan, berbagi, dan mengelola fitur untuk model ML. Ini menyimpan riwayat fitur ML di toko offline (Amazon S3) dan juga menyediakan API ke toko online untuk memungkinkan pembacaan latensi rendah dari fitur terbaru. Toko offline dapat menyajikan data historis untuk pelatihan dan eksperimen model lebih lanjut, dan toko online dapat dipanggil oleh API yang dihadapi pelanggan Anda untuk mendapatkan fitur inferensi waktu nyata. Saat kami mengembangkan layanan kami untuk menyediakan konten yang lebih dipersonalisasi, kami mengantisipasi pelatihan model ML tambahan dan dengan bantuan Feature Store, cari, temukan, dan gunakan kembali fitur di antara model-model ini.

Inferensi waktu nyata

Inferensi waktu nyata biasanya memerlukan model ML hosting di belakang titik akhir. Anda dapat melakukannya menggunakan server atau wadah web, tetapi ini memerlukan upaya rekayasa ML dan infrastruktur untuk mengelola dan memeliharanya. SageMaker memudahkan penerapan model ML ke titik akhir waktu nyata. SageMaker memungkinkan Anda melatih dan mengunggah model ML dan menghostingnya dengan membuat dan mengonfigurasi titik akhir SageMaker. Inferensi waktu nyata memenuhi persyaratan latensi rendah untuk pertunjukan peringkat saat dijelajahi di halaman beranda Amp.

Selain hosting terkelola, SageMaker menyediakan penskalaan titik akhir terkelola. Inferensi SageMaker memungkinkan Anda menentukan kebijakan penskalaan otomatis dengan jumlah instans minimum dan maksimum serta pemanfaatan target untuk memicu penskalaan. Dengan cara ini, Anda dapat dengan mudah memperbesar atau memperkecil saat permintaan berubah.

kesehatan operasional

Jumlah kejadian yang ditangani sistem ini untuk komputasi fitur real-time berubah sesuai dengan pola alami penggunaan aplikasi (lalu lintas lebih tinggi atau lebih rendah berdasarkan waktu atau hari dalam seminggu). Demikian pula, jumlah permintaan yang diterimanya untuk skala inferensi waktu nyata dengan jumlah pengguna aplikasi secara bersamaan. Layanan ini juga mendapatkan puncak lalu lintas yang tidak terduga karena promosi diri di media sosial oleh pembuat konten populer. Meskipun penting untuk memastikan sistem dapat ditingkatkan dan diturunkan untuk melayani lalu lintas masuk dengan sukses dan hemat, penting juga untuk memantau metrik operasional dan waspada terhadap masalah operasional yang tidak terduga untuk mencegah hilangnya data dan layanan kepada pelanggan. Memantau kesehatan layanan ini sangat mudah menggunakan amazoncloudwatch. Metrik kesehatan layanan penting seperti kesalahan dan latensi operasi serta metrik pemanfaatan seperti penggunaan memori, disk, dan CPU tersedia langsung dari kotak menggunakan CloudWatch. Tim pengembangan kami menggunakan dasbor metrik dan pemantauan otomatis untuk memastikan kami dapat melayani klien kami dengan ketersediaan tinggi (99.8%) dan latensi rendah (kurang dari 200 milidetik ujung ke ujung untuk mendapatkan acara yang direkomendasikan per pengguna).

Mengukur hasil

Sebelum rekomendasi acara berbasis ML yang dijelaskan dalam posting ini, algoritme heuristik yang lebih sederhana memberi peringkat acara Amp berdasarkan topik minat pribadi pengguna yang dilaporkan sendiri di profil mereka. Kami menyiapkan pengujian A/B untuk mengukur dampak peralihan ke pemberi rekomendasi berbasis ML dengan data pengguna dari interaksi aplikasi mereka sebelumnya. Kami mengidentifikasi peningkatan dalam metrik seperti durasi mendengarkan dan jumlah tindakan keterlibatan (menyukai acara, mengikuti pembuat acara, mengaktifkan notifikasi) sebagai indikator keberhasilan. Pengujian A/B dengan 50% pengguna yang menerima rekomendasi acara yang diberi peringkat untuk mereka melalui pemberi rekomendasi berbasis ML telah menunjukkan peningkatan 3% pada metrik keterlibatan pelanggan dan peningkatan 0.5% pada durasi pemutaran.

Kesimpulan

Dengan layanan yang dibuat khusus, tim Amp dapat merilis API rekomendasi acara yang dipersonalisasi seperti yang dijelaskan dalam posting ini ke produksi dalam waktu kurang dari 3 bulan. Sistem ini juga menskalakan dengan baik untuk beban tak terduga yang dibuat oleh pembawa acara terkenal atau kampanye pemasaran yang dapat menghasilkan gelombang pengguna. Solusinya menggunakan layanan terkelola untuk pemrosesan, pelatihan, dan hosting, yang membantu mengurangi waktu yang dihabiskan untuk pemeliharaan sistem sehari-hari. Kami juga dapat memantau semua layanan terkelola ini melalui CloudWatch untuk memastikan kesehatan sistem yang berkelanjutan dalam produksi.

Pengujian A/B versi pertama dari pemberi rekomendasi berbasis ML Amp terhadap pendekatan berbasis aturan (yang mengurutkan berdasarkan topik minat pelanggan saja) telah menunjukkan bahwa pemberi rekomendasi berbasis ML memaparkan pelanggan ke konten berkualitas lebih tinggi dari topik yang lebih beragam , yang menghasilkan jumlah pengikut yang lebih tinggi dan notifikasi yang diaktifkan. Tim Amp terus berupaya meningkatkan model untuk memberikan rekomendasi yang sangat relevan.

Untuk informasi lebih lanjut tentang Feature Store, kunjungi Toko Fitur Amazon SageMaker dan lihat kasus penggunaan pelanggan lainnya di Blog Pembelajaran Mesin AWS.

---

Tentang penulis

Tulip Gupta adalah Arsitek Solusi di Amazon Web Services. Dia bekerja dengan Amazon untuk merancang, membangun, dan menerapkan solusi teknologi di AWS. Dia membantu pelanggan dalam mengadopsi praktik terbaik saat menerapkan solusi di AWS, dan merupakan penggemar Analytics dan ML. Di waktu luangnya, dia suka berenang, mendaki gunung, dan bermain papan permainan.

David Kuo adalah Arsitek Solusi di Amazon Web Services. Dia bekerja dengan pelanggan AWS untuk merancang, membangun, dan menerapkan solusi teknologi di AWS. Dia bekerja dengan pelanggan Media dan Hiburan dan memiliki minat dalam teknologi pembelajaran mesin. Di waktu luangnya, dia bertanya-tanya apa yang harus dia lakukan dengan waktu luangnya.

Manolya McCormick adalah Insinyur Pengembangan Perangkat Lunak Senior untuk Amp di Amazon. Dia mendesain dan membangun sistem terdistribusi menggunakan AWS untuk melayani aplikasi yang dihadapi pelanggan. Dia suka membaca dan memasak resep baru di waktu luangnya.

Jeff Christophersen adalah Insinyur Data Senior untuk Amp di Amazon. Dia bekerja untuk merancang, membangun, dan menerapkan solusi Big Data di AWS yang mendorong wawasan yang dapat ditindaklanjuti. Dia membantu tim internal dalam mengadopsi solusi yang skalabel dan otomatis, dan merupakan penggemar Analytics dan Big Data. Di waktu luangnya, ketika dia tidak sedang bermain ski, Anda dapat menemukannya di atas sepeda gunungnya.