Jinsi Nilivyoongeza Utafutaji Unaovumilia Makosa ya Tahajia (Typo-Tolerant) kwa Kutumia OpenSearch na CJK
Maswali yasiyopata matokeo yalikuwa yakiharibu muda wetu wa kutazamwa (watch time).
Kwa mwaka mmoja, TopVideoHub ilitumia SQLite FTS5 kwa ajili ya utafutaji. Ilifanya kazi vizuri kwa maneno yaliyolingana sawia. Ilifeli pale watumiaji walipofanya makosa ya tahajia.
Watu walitafuta "demon slyer" badala ya "demon slayer." Waliongeza nafasi (spaces) zisizohitajika kwenye vichwa vya habari vya Kijapani au Kikorea. Kwa sababu FTS5 hulinganisha tokeni sahihi, kosa moja la tahajia lilimaanisha matokeo sifuri. Watumiaji hawakutafuta tena. Waliondoka tu.
Nilihamishia utafutaji wetu wa vichwa vya habari kwenye OpenSearch. Hivi ndivyo nilivyotatua tatizo hilo kwa hadhira inayozungumza lugha nyingi.
Tatizo la Fuzziness ya Kawaida
Mafunzo mengi yanakushauri utumie "fuzziness" ili kurekebisha makosa ya tahajia. Hii inafanya kazi kwa Kiingereza, lakini inafeli kwa maandishi ya Kichina, Kijapani, na Kikorea (CJK).
- Umbali wa marekebisho (Edit distance) ni mbaya kwa CJK. Kosa la tahajia katika CJK mara nyingi linamaanisha kutumia alama (character) isiyo sahihi kabisa.
- Fuzziness ya kawaida hutengeneza maandishi yasiyo na maana ya kimantiki (semantic garbage). Inaweza kulinganisha "fire" na "water" kwa sababu ziko hatua moja tu ya marekebisho mbali.
- Tokenization ni ngumu. Lugha za CJK hazitumii nafasi (spaces) kati ya maneno.
Suluhisho: Mbinu ya Nyanja Nyingi (Multi-Field Approach)
Niliacha kutendea maandishi yote kwa namna moja. Nilitengeneza nyanja moja ya kimantiki ya kichwa cha habari (logical title field) ambayo inaweka kumbukumbu (index) kwa njia tatu tofauti:
- Latin na Romaji: Nilitumia tokenization ya kawaida huku fuzziness ikiwa imewashwa. Niliweka urefu wa kiambishi (prefix length) wa 1. Hii inahakikisha "demon" inalingana na "demn" lakini "lemon" hailingani na "demon."
- Maandishi ya CJK: Nilitumia CJK bigram analyzer na ICU normalizer. Nilizima (OFF) fuzziness. Badala yake, nilitumia kiwango cha chini cha ulinganishaji (minimum match threshold) cha 70%.
- Autocomplete: Nilitumia edge-ngram field ili kuwezesha matokeo ya "search-as-you-type".
Usanifu na Usalama wa Data
Niliendelea kutumia SQLite kama chanzo kikuu cha ukweli (single source of truth). OpenSearch inafanya kazi kama index ya haraka inayoweza kujengwa upya.
- Ninatumia PHP kusukuma maboresho kwenye OpenSearch kwa makundi makubwa (bulk batches).
- Sifanyi indexing wakati wa ombi la mtumiaji (user request).
- Ninatumia script ya Python kuangalia "drift." Hii inahakikisha idadi ya OpenSearch inalingana na idadi ya SQLite.
Matokeo
Mabadiliko yalikuwa makubwa:
- Maswali yasiyopata matokeo yalishuka kutoka 14% hadi chini ya 3%.
- Vipindi vya utafutaji viliongezeka muda kwa sababu watumiaji walipata walichotaka mara moja.
- Latency inabaki kuwa ndogo, takriban ms 40.
Ikiwa unahudumia hadhira inayozungumza lugha nyingi, kumbuka: uvumilivu wa makosa ya tahajia (typo tolerance) na ulinganishaji wa CJK ni matatizo mawili tofauti. Unahitaji suluhisho mbili tofauti.