Dukung pengalaman pencarian

Pertanyaan

Bagaimana pencarian tetap berguna saat pengguna mengetik setengah kata, salah ketik, atau menulis query yang terlalu ketat?

Setelah baca ini, kamu bisa memilih antara prefix query, edge n-gram, dan completion index, membatasi fuzzy matching dengan angka, dan menjelaskan kapan query boleh dilonggarkan.

Prasyarat dan contoh

Kamu sudah paham inverted index dan ranking BM25 (M11.01, M11.02).

Pengguna mengetik "rendan" di toko resep. Ada tiga kemungkinan: dia belum selesai mengetik "rendang", dia salah ketik, atau memang mau "rendan" (nama bumbu daerah). Mesin pencarian yang hanya mencocokkan token utuh mengembalikan nol hasil untuk dua kasus pertama. Tapi mesin yang terlalu longgar akan mengembalikan "rendam", "renang", dan "rendah" sebagai hasil.

Pengalaman pencarian adalah kumpulan keputusan terkontrol tentang seberapa jauh query boleh ditafsirkan, dan siapa yang membayar biayanya (indeks, latensi, atau relevansi).

Mekanisme

1. Pencarian awalan. Karena kamus term terurut, semua term berawalan "rend" membentuk satu rentang berurutan. Cari batas bawah lewat binary search lalu telusuri sampai awalan nggak cocok. Biayanya sebanding dengan jumlah term yang cocok. Awalan pendek seperti "r" bisa cocok dengan puluhan ribu term, jadi tetapkan panjang awalan minimum (misalnya 2 atau 3 huruf) dan batas jumlah term yang diperluas (misalnya 50).

2. Edge n-gram. Pada saat indeks, simpan awalan tiap term sebagai term sendiri. "rendang" dengan panjang 2 sampai 7 menghasilkan re, ren, rend, renda, rendan, rendang. Query awalan jadi pencarian term biasa, lebih cepat saat query, tapi indeksnya membesar. Untuk 10 juta term unik dengan panjang rata-rata 8, pada n-gram 2 sampai 8 satu term menghasilkan sampai 7 entri, jadi kamus bisa membesar beberapa kali lipat.

3. Autocomplete. Dua sumber saran:

• Dari dokumen: judul dan term yang ada di korpus. Gampang, tapi saran bisa menuju hasil yang jarang dicari.
• Dari log query: query nyata yang diurutkan berdasarkan frekuensi dan kebaruan. Lebih berguna, tapi butuh pembersihan: buang query pribadi, query yang menghasilkan nol hasil, dan teks sensitif.

Struktur umum untuk saran adalah trie atau finite state transducer yang menyimpan skor di tiap simpul akhir. Latensi harus tetap di bawah kira-kira 100 ms per ketikan termasuk jaringan. Karena itu klien biasanya menunda permintaan 100 sampai 150 ms setelah ketikan terakhir (debounce) dan membatalkan permintaan sebelumnya.

4. Toleransi typo. Jarak Levenshtein menghitung jumlah sisip, hapus, dan ganti karakter. "rendan" ke "rendang" berjarak 1. Pola umum untuk membatasi biaya:

| panjang term | jarak maksimum | | ------------ | -------------- | | 1 sampai 2 | 0 | | 3 sampai 5 | 1 | | 6 atau lebih | 2 |

Aturan ini mencegah "sate" cocok dengan "satu" (jarak 1) di term pendek, dan mencegah ledakan kandidat di term panjang. Tambahkan aturan: huruf pertama harus sama, karena kesalahan ketik jarang terjadi di huruf pertama.

5. Pelonggaran query. Kalau ayam AND madura AND pedas hanya menghasilkan 1 dokumen, turunkan syaratnya secara bertahap: cocokkan minimal 2 dari 3 term, lalu minta ranking. Aturannya harus eksplisit.

• Longgarkan hanya jika hasil di bawah ambang (misalnya kurang dari 3).
• Beri tahu pengguna: "Menampilkan hasil yang cocok sebagian."
• Urutkan hasil yang cocok penuh di atas yang cocok sebagian.

6. Koreksi sebagai saran. Alternatif yang lebih aman daripada fuzzy otomatis adalah "Maksud kamu: rendang?". Pengguna memutuskan, dan hasil asli nggak tersembunyi.

Saat rancangan ini gagal

• Awalan terlalu pendek. Setiap ketikan satu huruf memperluas ribuan term, dan latensi p99 melonjak pada pencarian yang paling sering dipakai.
• Fuzzy menutupi hasil benar. Query "iphone 12" yang dibuat fuzzy bisa cocok dengan "iphone 13" dan menggantikan kecocokan yang diinginkan. Angka, kode produk, dan ID jangan dibuat fuzzy.
• Autocomplete membocorkan. Saran yang dibangun dari log semua pengguna bisa menampilkan query orang lain (nama, alamat, nomor). Saran juga perlu disaring dengan otorisasi yang sama dengan hasil (M11.06).
• Saran basi. Saran yang diperbarui seminggu sekali nggak menangkap tren hari ini. Tentukan kesegaran saran sebagai target, bukan kebetulan.

Contoh tandingan: pencarian internal dengan 2.000 dokumen dan 50 pengguna. Cukup pakai prefix query dan satu halaman hasil. Edge n-gram, log query, dan fuzzy menambah komponen yang nggak sebanding dengan manfaatnya.

Latihan

Kamu mengatur pencarian katalog 5 juta produk. Tiga permintaan masuk: (a) autocomplete setelah 2 huruf, (b) toleransi typo untuk nama produk, (c) kode SKU seperti "KP-20931" harus cocok persis. Untuk tiap permintaan, tentukan mekanisme, batas angkanya, dan satu risiko.

Lihat pembahasan+

(a) Autocomplete setelah 2 huruf. Pakai completion index (FST) dari nama produk dan query populer 30 hari terakhir, bukan prefix query pada seluruh kamus. Batasi 8 saran, debounce 120 ms. Risiko: saran dari log mengandung query pribadi. Filter dengan ambang minimal (misalnya muncul di minimal 20 pengguna berbeda) dan buang pola data pribadi.

(b) Typo untuk nama produk. Fuzzy dengan jarak 1 untuk term 3 sampai 5 huruf, jarak 2 untuk 6 huruf atau lebih, huruf pertama harus sama, hasil fuzzy diberi skor lebih rendah daripada hasil eksak. Risiko: "sepatu" dan "sepasu" mungkin dua merek berbeda, jadi eksak harus selalu di atas.

(c) SKU. Jangan fuzzy dan jangan stemming. Simpan sebagai field keyword terpisah dan cocokkan persis (dengan normalisasi huruf besar-kecil dan tanda hubung). Risiko: pengguna mengetik "KP20931" tanpa tanda hubung. Selesaikan dengan normalisasi saat indeks, bukan dengan fuzzy.

Jawaban yang bagus memisahkan field yang boleh ditafsirkan dari field yang harus eksak.

Terkait

• Sebelumnya: M11.02 Urutkan hasil teks.
• Lanjut ke M11.04 Jaga indeks tetap mutakhir.
• Filter otorisasi pada saran dan hitungan dibahas di M11.06.
• Rancangan D10 (layanan pencarian dengan autocomplete) memakai semua mekanisme ini. Belum tersedia.

Catatan

• Asumsi: bahasa Indonesia dengan huruf Latin, dan pengguna mengetik lewat keyboard biasa.
• Yang nggak dibahas: transliterasi, query suara, koreksi berbasis model bahasa, dan personalisasi.
• Ambang (panjang awalan, jarak edit, batas saran) adalah titik awal yang umum dipakai, bukan angka universal. Ukur pada query nyata.
• Terakhir ditinjau: 26 Oktober 2026.