oleh Malvina Matlis & Marcos Calvo Lance

Sistem pencarian informasi (IR) ada di mana-mana di hari kita sehari-hari. Mungkin itu menyelesaikan taruhan dengan mencari jawabannya secara online, menemukan produk favorit Anda di Amazon, menemukan email apa pun di Outlook, atau mungkin Anda hanya lapar dan ingin memasak paella otentik yang lezat. Hidup kita mungkin tidak akan semudah (dan tidak terlalu menyenangkan) tanpa semua kotak pencarian yang memungkinkan kita menemukan semua jenis dokumen dan informasi, baik itu tertulis, audio, foto, video, atau yang lainnya. Namun, agar pengguna menganggap sistem IR bermanfaat, sistem perlu memberikan jawaban yang relevan secara tepat waktu. Oleh karena itu, bagaimana kami memastikan mesin telusur menyediakan konten yang relevan kepada pengguna sesuai dengan kueri mereka saat kami memiliki skenario "mulai dingin", yaitu, tidak ada riwayat kueri? Dan bagaimana kami mengevaluasi kinerja langsung sistem IR saat sudah diproduksi?

Dalam posting blog ini kami akan mendemonstrasikan bagaimana kami memilih untuk mengevaluasi sistem seperti itu menggunakan pemantauan online dan analisis log dengan Kusto , alat kueri Microsoft, tetapi konsep ini juga dapat diterapkan ke bahasa lain dan kumpulan teknologi.

Mengevaluasi sistem IR

Evaluasi sistem IR telah dipelajari dan didokumentasikan secara ekstensif, yang berarti bahwa beberapa metrik standar telah ditetapkan, tinjauan yang baik dapat ditemukan di Metrik Evaluasi Untuk Pengambilan Informasi .
Misalnya, beberapa metrik standar ini adalah:

Presisi
Ini menghitung proporsi hasil yang dikembalikan oleh sistem yang relevan untuk kueri (yaitu, istilah pencarian). Misalnya, pada gambar di atas kami mencari resep paella asli. Mesin pencari mengambil 330 juta dokumen. Jika kami memiliki referensi yang mengatakan bahwa 200 juta dokumen tersebut relevan dengan pencarian resep, maka presisi kueri akan menjadi 200/330 = 60,6%.

Ingat
Itu mengukur proporsi hasil yang relevan yang dikembalikan oleh sistem dari kumpulan semua hasil yang relevan. Kembali ke contoh kita, bagaimana jika mesin pencari melewatkan 20 juta dokumen yang relevan? Maka penarikan kembali akan menjadi 200/(200+20) = 90,9%

Reciprocal ranking (RR)
Ini mengukur dimana dalam daftar hasil yang dikembalikan adalah dokumen relevan pertama. Karena nyaman untuk memiliki metrik dengan nilai berkisar antara 0 dan 1, dengan 1 mewakili skor yang lebih baik daripada 0, peringkat timbal balik didefinisikan sebagai 1 di atas indeks tertinggi dokumen yang relevan dengan kueri. Untuk mengukurnya pada sekumpulan kueri, kami hanya merata-ratakan peringkat timbal balik pada kumpulan kueri, dengan cara ini Mean Reciprocal Ranking (MRR), atau dalam bentuk persamaan:

Karena kami masih lapar dan tidak akan membahas lebih dari 330 juta resep, RR akan melihat dokumen pertama yang kami tandai relevan. Katakanlah itu resep ke-5, maka RR kuerinya adalah 1/5.

Lebih mudah diucapkan daripada dilakukan

Untuk sebagian besar masalah pembelajaran mesin, metrik evaluasi biasanya dihitung pada kumpulan data evaluasi offline yang ditentukan sebelumnya, dianotasi, dan dikuratori, yang diharapkan cukup mewakili perilaku sistem di alam bebas . Namun, bagaimana jika tidak tersedia dataset yang cukup mewakili kebutuhan pengguna? Atau bagaimana jika kebutuhan tersebut tidak diketahui?

Metrik online — mari kumpulkan umpan balik
Alternatif untuk menggunakan kumpulan data evaluasi yang telah ditentukan sebelumnya untuk menilai kualitas sistem adalah memanfaatkan informasi tentang penggunaan sistem. Dengan mengumpulkan informasi tentang perjalanan pengguna dalam sistem IR, kami dapat mengevaluasi dan memantau hasil yang dikembalikan. Demi sebuah contoh, mari kita pertimbangkan aliran pengguna berikut dalam sebuah aplikasi:

1. Kueri input: Pengguna memasukkan kueri ("resep paella asli" dalam contoh kami) ke dalam aplikasi, yang diteruskan ke mesin pencari.
2. Penjelajahan dokumen: Sistem mengembalikan daftar dokumen, dan aplikasi menampilkannya berdasarkan relevansinya.
3. Pemeriksaan dokumen: Pengguna menelusuri dokumen yang dikembalikan secara berurutan dan memilih satu untuk memeriksanya lebih lanjut.
4. Berhasil: Jika pengguna senang dengan dokumen yang diperiksa, mereka dapat memberi tahu aplikasi bahwa pencarian telah selesai. Salah satu opsi adalah menilai hasil secara positif. Cara lainnya adalah menggunakan metode proxy untuk menyimpulkan bahwa pencarian berhasil, seperti mengukur waktu yang dihabiskan pengguna untuk memeriksa dokumen.
5. Jika pengguna tidak puas dengan dokumen yang diperiksa, maka mereka kembali menelusuri hasil (poin 4) dan dapat memilih dokumen baru untuk diperiksa.

Kusto untuk menyelamatkan

Mekanisme observasi seperti logging menghasilkan sejumlah besar data, yang menimbulkan tantangan tambahan untuk menanyakannya.

Log dapat diperiksa di portal Azure AppInsights menggunakan Azure Data Explorer dan, khususnya, bahasa kueri Kusto . Jika Anda terbiasa dengan SQL, Anda akan mengenali beberapa poin umum dalam bahasa ini. Namun, ada perbedaan yang signifikan antara Kusto dan SQL — di Kusto, pernyataan dieksekusi secara berurutan, membuat kueri lebih pendek dan lebih mudah dibaca daripada kueri SQL.

Metrik evaluasi menggunakan log peristiwa pengguna

Secara tradisional, penebangan telah banyak digunakan untuk tujuan pemantauan dan rekayasa. Beberapa contoh termasuk mengetahui berapa banyak kueri per unit waktu yang dibutuhkan sistem untuk melayani, berapa banyak pengguna yang menanyakan sistem, atau berapa banyak waktu yang dihabiskan pengguna untuk memeriksa dokumen rata-rata. Namun, Ilmuwan Data juga dapat memperoleh manfaat dari pencatatan yang tepat untuk menghitung Indikator Kinerja Utama (KPI) dan untuk mengevaluasi kinerja sistem secara online secara berkelanjutan.

Peringkat Timbal Balik Rata-Rata (MRR)

Dari metrik evaluasi IR yang disebutkan di atas, Reciprocal Ranking (RR) hanya membutuhkan peringkat hasil relevan pertama dalam daftar dokumen yang disetel ulang, yang dapat kami tentukan melalui interaksi pengguna akhir. Oleh karena itu, ini dapat dihitung pada lalu lintas nyata setelah pencatatan yang sesuai dilakukan. Dalam contoh kami saat peristiwa OnSuccess dipicu, itu berarti pengguna menganggap hasil yang relevan. Dari perspektif pengalaman pengguna, RR untuk kueri tertentu memberi tahu kami seberapa cepat pengguna dapat menemukan dokumen pertama yang relevan dengan kebutuhan mereka.

MRR kemudian dapat dihitung dengan merata-ratakan RR selama periode waktu yang berarti, misalnya satu hari, di seluruh populasi pengguna yang signifikan secara statistik sehingga kueri dan profil pengguna yang berbeda digabungkan dan direpresentasikan dalam metrik. Dengan cara ini kita dapat membandingkan bahwa, misalnya, pengguna dari Spanyol rata-rata menemukan resep pertama yang relevan pada dokumen ke-15 dan pengguna dari Israel rata-rata menemukannya pada dokumen ke-3.

Kueri Kusto berikut menghitung persis seperti itu.

Cheat cepat Kusto ke SQL (dan ingat, Kusto mengeksekusi secara berurutan):

• [Kusto] -> [SQL]
• dimana -> dimana
• proyek -> pilih
• meringkas -> pilih dengan fungsi agregat apa pun seperti jumlah, rata-rata, atau min, bersama dengan grup berdasarkan kolom
• make-series -> fitur yang tidak tersedia di SQL yang mengubah dataset menjadi plot deret waktu
• render -> fitur lain yang tidak tersedia di SQL yang memplot data

Diberikan kueri “resep paella asli” dan 10 dokumen yang dikembalikan oleh mesin pencari, kami mengurutkan dokumen sehingga dokumen yang paling mirip dengan kueri berada di peringkat 1 dan yang paling tidak mirip memiliki peringkat 10. Demi contoh , mari kita asumsikan bahwa dokumen 3, 6 dan 8 dianggap relevan oleh pengguna kita.

arg_max (ExprToMaximize, * | ExprToReturn [, ...])

Metrik corong

Metrik Reciprocal Ranking memberi kita pandangan terbatas tentang bagaimana pengguna berinteraksi dengan sistem, karena hanya melihat dokumen pertama yang relevan. Misalnya, kita dapat melengkapi metrik ini dengan menghitung rata-rata berapa banyak dokumen yang perlu diperiksa pengguna untuk menemukan semua dokumen yang mungkin mereka perlukan. Dalam skenario yang ideal, kami ingin pengguna hanya membuka dokumen yang benar-benar relevan, karena kami akan menghemat banyak waktu pengguna melalui dokumen yang tidak relevan.

Dengan menggunakan logging yang diperkenalkan dalam sistem ini, kita dapat menyusun ulang pertanyaan ini sebagai metrik: dari interaksi tersebut yang menyebabkan peristiwa onNavigate , berapa proporsi yang juga memicu peristiwa onSuccess ? Atau, lebih sederhananya, berapa persentase dokumen yang dibaca pengguna yang berinteraksi dengan mereka? Kita dapat menuliskannya menggunakan Kusto sebagai berikut:

Anda dapat melihat lembar contekan Kusto to SQL lengkap untuk interpretasi kueri.

Menyatukan semuanya — dasbor

Untuk melacak ini dan metrik lainnya, akan lebih mudah untuk membuat dasbor. Dalam contoh kami, kami memantau metrik menggunakan fitur dasbor AppInsights. Kami melacak metrik pemantauan serta metrik kinerja IR dalam satu tampilan karena semua informasi dapat diperoleh dengan mudah dari log sistem. Semua kode disertakan dalam repositori azure-samples berikut

Dasbor ini memungkinkan kami melacak metrik sistem dan kinerja secara bersamaan. Namun, itu tidak serta merta memungkinkan kami untuk mendiagnosis mengapa kinerja metrik kami memburuk. Misalnya, jika “RR Harian” menurun dari waktu ke waktu, apakah karena:

• Kebutuhan pengguna telah berubah?
• Dokumen baru telah diindeks dan konten baru tidak cocok dengan yang lama?
• Pustaka dokumen kita sudah usang dan perlu diperbarui dengan dokumen baru?
• Definisi kesuksesan pengguna telah berubah?
• Perubahan UX memengaruhi cara pengguna berinteraksi dengan hasil? Misalnya, widget topik muncul di halaman hasil dan menampilkan informasi, menghilangkan kebutuhan untuk berinteraksi dengan dokumen tertentu.
• Musiman?
• Lainnya?

Kesimpulan

Kami termotivasi untuk menulis artikel ini karena kami menghadapi skenario di mana data evaluasi beranotasi yang sudah ada sebelumnya untuk mesin telusur tidak tersedia. Kami menemukan bahwa melacak interaksi pengguna dengan sistem dari waktu ke waktu memberikan petunjuk di mana penyesuaian tambahan diperlukan. Reciprocal Ranking memvisualisasikan seberapa jauh pengguna perlu menggulir untuk menemukan dokumen pertama yang relevan, sedangkan rasio antara dokumen yang relevan dan terbuka menyoroti kinerja keseluruhan mesin pencari dan relevansi dokumen yang dikembalikan.

Merancang logging dan analisis aplikasi yang tepat memungkinkan pelacakan kualitas sistem secara real time sejak sistem berjalan dalam produksi. Ini tidak hanya berguna untuk kasus di mana sumber daya evaluasi tidak tersedia, tetapi juga memungkinkan kami menemukan variasi dalam kualitas sistem dari waktu ke waktu, dan karenanya meningkatkan pengalaman pengguna. Dan sekarang, kita akan membuat paella.