Pasukan pembangun menggabungkan OpenSearch dengan SQLite FTS5 dan mengurangkan carian video tanpa hasil daripada 11.4 peratus kepada 2.1 peratus, sambil mengekalkan kependaman (latency) di bawah 20 ms. Kini, pengguna yang menaip “blackpink jenny solo stag” akan melihat “BLACKPINK Jennie SOLO stage” yang betul dan bukannya senarai kosong.

Mengapa perubahan ini diperlukan

Log carian daripada platform pengehosan video menunjukkan masalah yang berulang: satu kesilapan taip (typo) dalam tajuk skrip Latin boleh menghapuskan semua padanan. Sambungan FTS5 SQLite, yang dihargai kerana keupayaannya memadankan sub-rentetan dalam teks Cina, Jepun dan Korea (CJK), tidak melakukan pemadanan kabur (fuzzy matching). Satu aksara yang salah eja dalam nama atau tajuk lagu boleh merosakkan keseluruhan pertanyaan (query).

Saluran (pipeline) sedia ada menganggap SQLite sebagai satu-satunya indeks. Ia mengendalikan pertanyaan CJK dengan baik tetapi tidak menawarkan jaring keselamatan untuk kesilapan taip skrip Latin. Oleh itu, pasukan tersebut mencari enjin carian pelengkap yang dapat menyediakan toleransi kesilapan taip tanpa membuang lapisan FTS5 yang telah terbukti.

Bagaimana OpenSearch ditambah

OpenSearch berjalan sebagai perkhidmatan carian barisan hadapan; SQLite kekal sebagai sumber kebenaran (source of truth). Kedua-dua sistem berjalan secara selari: OpenSearch menerima pertanyaan pengguna terlebih dahulu, dan jika ia bertindak balas dengan cukup pantas, hasilnya akan dipaparkan. Jika OpenSearch mengalami masa tamat (timeout) atau ralat, permintaan tersebut akan beralih (fallback) ke indeks SQLite FTS5. Reka bentuk "fail-safe" ini menjamin bahawa gangguan rangkaian tidak akan membiarkan bar carian kosong.

Pemetaan pelbagai medan (Multi-field mapping)

Setiap tajuk video diindeks dengan tiga cara dalam OpenSearch:

  • title.std – diproses oleh penganalisis standard dengan lipatan (folding) ASCII. Ini menormalkan aksara beraksen dan mengendalikan kebanyakan kesilapan taip skrip Latin.
  • title.cjk – diproses oleh penganalisis CJK yang mencipta bigram (token dua aksara). Ini mengekalkan kekuatan pemadanan sub-rentetan yang disediakan oleh FTS5 untuk skrip Asia.
  • title.keyword – disimpan tanpa perubahan untuk carian padanan tepat dan penyusunan.

Medan yang berasingan membolehkan pertanyaan menggunakan analisis yang betul untuk setiap skrip tanpa mencampuradukkan strategi tokenisasi.

Tahap lonjakan (Boost tiers)

Berbanding satu pertanyaan monolitik tunggal, pasukan tersebut membina pertanyaan bertingkat yang menyusun hasil secara automatik:

  1. Padanan frasa tepat pada title.keyword menerima lonjakan tertinggi, memastikan padanan sempurna mendominasi senarai.
  2. Padanan bigram CJK pada title.cjk mendapat lonjakan sederhana, mengekalkan kualiti carian bahasa Asia.
  3. Padanan Latin kabur (fuzzy) pada title.std menerima lonjakan yang lebih rendah, membolehkan hasil yang toleran terhadap kesilapan taip muncul tanpa menenggelamkan padanan tepat.

Pendekatan bertingkat ini memudahkan penalaan: melaraskan satu nilai lonjakan akan mengubah kepentingan relatif bagi keseluruhan kelas padanan.

Kekaburan pintar (Smart fuzziness)

Kekaburan (Fuzziness)—membenarkan jumlah suntingan aksara yang terhad—hanya digunakan untuk medan Latin. Pasukan tersebut menyahaktifkan kekaburan untuk title.cjk kerana perubahan satu aksara dalam CJK sering kali mengubah makna secara keseluruhan. Untuk teks Latin, pertanyaan menggunakan tetapan kekaburan AUTO OpenSearch, yang menskalakan jarak suntingan yang dibenarkan berdasarkan panjang perkataan, sekali gus mencapai keseimbangan antara toleransi dan relevansi.

Prestasi dan logik fallback

Rutin carian membungkus panggilan OpenSearch dalam blok try-catch:

  • Jika OpenSearch kembali dalam masa 400 ms, hasilnya akan dipaparkan.
  • Jika panggilan mencetuskan pengecualian (exception) atau melebihi masa tamat, sistem akan segera menjalankan semula pertanyaan terhadap SQLite FTS5.

Ini memastikan bahawa kependaman rangkaian atau gangguan perkhidmatan tidak akan menjejaskan pengalaman pengguna. Kependaman carian kekal di bawah 20 ms.

Impak yang boleh diukur

  • Kadar tanpa hasil bagi pertanyaan skrip Latin jatuh daripada 11.4% kepada 2.1%.
  • Kualiti carian bagi pertanyaan CJK kekal tidak berubah, mengesahkan bahawa penganalisis CJK baharu mengekalkan kekuatan indeks FTS5 asal.
  • Kependaman hujung-ke-hujung (end-to-end) kekal selesa di bawah sasaran 20 ms, bermakna lapisan tambahan tersebut tidak memperlahankan UI.

Pengajaran dan pertukaran (trade-offs)

  • Pemisahan lipatan (folding) dan kekaburan (fuzziness) – Lipatan (menormalkan aksara) dan kekaburan (mengendalikan kesilapan taip) menangani masalah yang berbeza. Mengekalkannya pada medan yang berbeza mengelakkan interaksi yang tidak diingini.
  • Jangan anggap indeks carian sebagai sumber kebenaran – SQLite kekal sebagai stor kanonikal; OpenSearch adalah paparan terbitan yang boleh dikemas kini. Ini mengelakkan hanyutan indeks (index drift) dan memudahkan pemulihan selepas kegagalan.
  • Tahap lonjakan memudahkan penalaan – Mengelompokkan padanan berkaitan di bawah satu faktor lonjakan mengurangkan bilangan parameter yang perlu dilaraskan.

Apa yang perlu diperhatikan seterusnya

Eksperimen ini membuktikan bahawa lapisan OpenSearch yang ringkas boleh meningkatkan toleransi ralat taip secara drastik bagi tajuk video pelbagai bahasa tanpa mengorbankan keupayaan CJK SQLite FTS5 yang telah terbukti. Bagi platform di mana relevansi carian mempengaruhi masa tontonan secara langsung, penambahbaikan tersebut diterjemahkan kepada kejayaan pengalaman pengguna yang nyata.