Cara Saya Menambahkan Pencarian Toleran-Tipografi dengan OpenSearch dan CJK
Kueri tanpa hasil (zero-result queries) merusak waktu tonton kami.
Selama setahun, TopVideoHub menggunakan SQLite FTS5 untuk pencarian. Ini berfungsi untuk pencocokan eksak. Namun, ini gagal saat pengguna melakukan kesalahan ketik (typo).
Orang-orang mencari "demon slyer" alih-alih "demon slayer." Mereka menambahkan spasi yang tidak perlu pada judul bahasa Jepang atau Korea. Karena FTS5 mencocokkan token secara eksak, satu kesalahan ketik saja berarti nol hasil. Pengguna tidak akan mencari lagi. Mereka langsung pergi.
Saya memindahkan pencarian judul kami ke OpenSearch. Berikut adalah cara saya menyelesaikannya untuk audiens multibahasa.
Masalah dengan Fuzziness Standar
Kebanyakan tutorial menyarankan penggunaan "fuzziness" untuk memperbaiki kesalahan ketik. Ini berhasil untuk bahasa Inggris, tetapi gagal untuk teks Mandarin, Jepang, dan Korea (CJK).
- Jarak edit (edit distance) buruk untuk CJK. Kesalahan ketik dalam CJK sering kali berarti penggunaan karakter yang sepenuhnya salah.
- Fuzziness standar menghasilkan sampah semantik. Ini mungkin mencocokkan "fire" dengan "water" karena keduanya hanya terpaut satu perubahan edit.
- Tokenisasi itu sulit. Bahasa CJK tidak menggunakan spasi di antara kata.
Solusinya: Pendekatan Multi-Field
Saya berhenti memperlakukan semua teks dengan cara yang sama. Saya membuat satu field judul logis yang mengindeks dengan tiga cara berbeda:
- Latin dan Romaji: Saya menggunakan tokenisasi standar dengan fuzziness diaktifkan. Saya mengatur prefix length sebesar 1. Ini memastikan "demon" cocok dengan "demn" tetapi "lemon" tidak cocok dengan "demon."
- Teks CJK: Saya menggunakan CJK bigram analyzer dan ICU normalizer. Saya mematikan (OFF) fuzziness. Sebagai gantinya, saya menggunakan ambang batas kecocokan minimum (minimum match threshold) sebesar 70%.
- Autocomplete: Saya menggunakan field edge-ngram untuk mendukung hasil pencarian saat mengetik (search-as-you-type).
Arsitektur dan Keamanan Data
Saya tetap menggunakan SQLite sebagai satu-satunya sumber kebenaran (single source of truth). OpenSearch bertindak sebagai indeks yang cepat dan dapat dibangun kembali (rebuildable).
- Saya menggunakan PHP untuk mendorong pembaruan ke OpenSearch dalam batch besar.
- Saya tidak pernah menjalankan pengindeksan selama permintaan pengguna (user request).
- Saya menjalankan skrip Python untuk memeriksa "drift". Ini memastikan jumlah di OpenSearch sesuai dengan jumlah di SQLite.
Hasilnya
Perubahannya sangat besar:
- Kueri tanpa hasil turun dari 14% menjadi di bawah 3%.
- Sesi pencarian menjadi lebih lama karena pengguna segera menemukan apa yang mereka inginkan.
- Latensi tetap rendah, sekitar 40ms.
Jika Anda melayani audiens multibahasa, ingatlah: toleransi kesalahan ketik dan pencocokan CJK adalah dua masalah yang berbeda. Anda membutuhkan dua solusi yang berbeda.