Timu ya watengenezaji ilichanganya OpenSearch na SQLite FTS5 na kupunguza utafutaji wa video usio na matokeo kutoka asilimia 11.4 hadi asilimia 2.1, huku ikidhibiti kuchelewa (latency) chini ya ms 20. Sasa watumiaji wanaopiga “blackpink jenny solo stag” wanaona “BLACKPINK Jennie SOLO stage” sahihi badala ya orodha tupu.

Kwa nini mabadiliko yalihitajika

Kumbukumbu za utafutaji (search logs) kutoka jukwaa la kuhifadhi video zilionyesha tatizo linalojirudia: kosa moja la kimaandishi (typo) katika kichwa cha habari cha herufi za Kilatini (Latin-script) kingeweza kufuta matokeo yote. Kiambatisho cha FTS5 cha SQLite, kinachothaminiwa kwa uwezo wake wa kulinganisha sehemu za maneno (substrings) katika maandishi ya Kichina, Kijapani na Kikorea (CJK), hakifanyi utafutaji wa fuzzy matching. Herufi moja iliyoandikwa vibaya katika jina au kichwa cha wimbo inaharibu utafutaji mzima.

Mfumo uliokuwepo ulichukulia SQLite kama injini ya utafutaji (index) pekee. Ulishughulikia vizuri maswali ya CJK lakini haukutoa kinga dhidi ya makosa ya kimaandishi ya herufi za Kilatini. Kwa hivyo, timu ilitafuta injini ya utafutaji ya ziada ambayo ingeweza kutoa uwezo wa kuvumilia makosa ya kimaandishi (typo tolerance) bila kuacha tabaka la FTS5 lililothibitika.

Jinsi OpenSearch ilivyoongezwa

OpenSearch inafanya kazi kama huduma ya kwanza ya utafutaji; SQLite inabaki kama chanzo cha ukweli (source of truth). Mifumo hii miwili inafanya kazi kwa pamoja: OpenSearch inapokea swali la mtumiaji kwanza, na ikiwa itajibu kwa haraka ya kutosha, matokeo yake huonyeshwa. Ikiwa OpenSearch itachelewa sana (timeout) au itatoa hitilafu, ombi linahamia kwenye injeni ya SQLite FTS5. Muundo huu wa “fail-safe” unahakikisha kuwa hitilafu ndogo ya mtandao haitaacha sehemu ya utafutaji ikiwa tupu.

Ramani ya nyanja nyingi (Multi-field mapping)

Kila kichwa cha video kinawekwa kwenye injeni (indexed) kwa njia tatu ndani ya OpenSearch:

  • title.std – inachakatwa na mchambuzi wa kawaida (standard analyzer) wenye ASCII folding. Hii huweka herufi zenye alama (accented characters) katika hali ya kawaida na kushughulikia makosa mengi ya kimaandishi ya herufi za Kilatini.
  • title.cjk – inachakatwa na mchambuzi wa CJK unaounda bigrams (tokeni za herufi mbili). Hii inadumisha nguvu ya kulinganisha sehemu za maneno (substring-matching) ambayo FTS5 hutoa kwa maandishi ya Asia.
  • title.keyword – huhifadhiwa bila mabadiliko kwa ajili ya utafutaji wa maneno kamili na upangaji.

Nyanja hizi tofauti huruhusu utafutaji kutumia uchambuzi sahihi kwa kila aina ya maandishi bila kuchanganya mbinu za kugawa maneno (tokenisation strategies).

Ngazi za kuongeza uzito (Boost tiers)

Badala ya utafutaji mmoja mkubwa, timu ilijenga utafutaji wa ngazi ambao unapanga matokeo kiotomatiki:

  1. Matokeo ya maneno kamili kwenye title.keyword hupata uzito (boost) mkubwa zaidi, kuhakikisha matokeo yanayoendana kikamilifu yanatawala orodha.
  2. Matokeo ya CJK bigram kwenye title.cjk hupata uzito wa wastani, ikidumisha ubora wa utafutaji wa lugha za Asia.
  3. Matokeo ya fuzzy ya Kilatini kwenye title.std hupata uzito mdogo, ikiruhusu matokeo yanayovumilia makosa ya kimaandishi kuonekana bila kufunika matokeo sahihi.

Mbinu hii ya ngazi inafanya marekebisho kuwa rahisi: kurekebisha thamani moja ya uzito (boost value) hubadilisha umuhimu wa kundi zima la matokeo yanayolingana.

Fuzziness ya akili (Smart fuzziness)

Fuzziness—kuruhusu idadi fulani ya marekebisho ya herufi—inatumika kwenye nyanja ya Kilatini pekee. Timu ilizima fuzziness kwa title.cjk kwa sababu mabadiliko ya herufi moja katika CJK mara nyingi hubadilisha maana kabisa. Kwa maandishi ya Kilatini, utafutaji unatumia mipangilio ya AUTO fuzziness ya OpenSearch, ambayo hurekebisha umbali wa marekebisho unaoruhusiwa kulingana na urefu wa neno, ikipata uwiano kati ya uvumilivu na uhusiano (relevance).

Utendaji na mantiki ya kurudi nyuma (fallback logic)

Utaratibu wa utafutaji unajumuisha wito wa OpenSearch ndani ya kizuizi cha try-catch:

  • Ikiwa OpenSearch itarudisha matokeo ndani ya ms 400, matokeo yake huonyeshwa.
  • Ikiwa wito huo utatoa hitilafu (exception) au utazidi muda uliowekwa (timeout), mfumo unarudia utafutaji mara moja dhidi ya SQLite FTS5.

Hii inahakikisha kuwa kuchelewa kwa mtandao au hitilafu za huduma haziharibu uzoefu wa mtumiaji. Kuchelewa kwa utafutaji (search latency) kulibaki chini ya ms 20.

Athari inayopimika

  • Viwango vya utafutaji usio na matokeo kwa maswali ya herufi za Kilatini vilishuka kutoka 11.4% hadi 2.1%.
  • Ubora wa utafutaji kwa maswali ya CJK haukubadilika, ikithibitisha kuwa mchambuzi mpya wa CJK alidumisha nguvu za injeni ya FTS5 ya awali.
  • Kuchelewa kwa mwisho hadi mwisho (end-to-end latency) kulibaki chini ya lengo la ms 20, ikimaanisha kuwa tabaka lililoongezwa halikupunguza kasi ya UI.

Mafunzo na mabadiliko ya kulinganisha (Lessons and trade-offs)

  • Kutenganisha folding na fuzziness – Folding (kuweka herufi katika hali ya kawaida) na fuzziness (kushughulikia makosa ya kimaandishi) zinatatua matatizo tofauti. Kuziweka kwenye nyanja tofauti kunazuia mwingiliano usiotarajiwa.
  • Usichukulie injeni ya utafutaji kama chanzo cha ukweli – SQLite inabaki kama hifadhi kuu; OpenSearch ni mtazamo uliotolewa na unaoweza kuhuishwa. Hii inazuia mabadiliko yasiyotarajiwa ya injeni (index drift) na kurahisisha urejesho baada ya hitilafu.
  • Ngazi za kuongeza uzito (boost tiers) hurahisisha marekebisho – Kuunganisha matokeo yanayohusiana chini ya kigezo kimoja cha uzito hupunguza idadi ya vigezo vinavyohitaji marekebisho.

Nini cha kufuatilia baadaye

Jaribio linathibitisha kuwa tabaka dogo la OpenSearch linaweza kuboresha kwa kiasi kikubwa uwezo wa kutambua makosa ya kimaandishi kwa vichwa vya video vya lugha nyingi bila kuathiri uwezo uliothibitishwa wa CJK wa SQLite FTS5. Kwa majukwaa ambapo umuhimu wa matokeo ya utafutaji huathiri moja kwa moja muda wa kutazama, uboreshaji huo unatafsiriwa kuwa ushindi unaoonekana katika uzoefu wa mtumiaji.