Un team di sviluppatori ha affiancato OpenSearch a SQLite FTS5, riducendo le ricerche video senza risultati dall'11,4% al 2,1%, mantenendo al contempo la latenza sotto i 20 ms. Ora, gli utenti che digitano "blackpink jenny solo stag" vedono il risultato corretto "BLACKPINK Jennie SOLO stage" invece di un elenco vuoto.

Perché era necessario il cambiamento

I log di ricerca di una piattaforma di video hosting hanno mostrato un problema ricorrente: un singolo errore di battitura in un titolo in caratteri latini poteva annullare tutti i risultati. L'estensione FTS5 di SQLite, apprezzata per la sua capacità di trovare sottostringhe in testi cinesi, giapponesi e coreani (CJK), non esegue il fuzzy matching. Un singolo carattere errato in un nome o nel titolo di una canzone interrompe completamente la query.

La pipeline esistente trattava SQLite come l'unico indice. Gestiva bene le query CJK, ma non offriva alcuna rete di salvataggio per gli errori di battitura nei caratteri latini. Il team ha quindi cercato un motore di ricerca complementare che potesse fornire tolleranza agli errori senza scartare lo strato FTS5 già collaudato.

Come è stato aggiunto OpenSearch

OpenSearch opera come servizio di ricerca di prima linea; SQLite rimane la fonte di verità. I due sistemi funzionano in parallelo: OpenSearch riceve per prima la query dell'utente e, se risponde abbastanza velocemente, i suoi risultati vengono visualizzati. Se OpenSearch va in timeout o restituisce un errore, la richiesta passa all'indice SQLite FTS5. Questo design "fail-safe" garantisce che un problema di rete non lasci mai la barra di ricerca vuota.

Mappatura multi-campo

Ogni titolo di video viene indicizzato in tre modi in OpenSearch:

  • title.std – elaborato da un analyzer standard con ASCII folding. Questo normalizza i caratteri accentati e gestisce la maggior parte degli errori di battitura nei caratteri latini.
  • title.cjk – elaborato da un analyzer CJK che crea bigrammi (token di due caratteri). Ciò preserva la capacità di ricerca per sottostringhe che FTS5 offre per le scritture asiatiche.
  • title.keyword – memorizzato invariato per ricerche di corrispondenza esatta e ordinamento.

Campi separati consentono alla query di applicare l'analisi corretta a ogni script senza mescolare le strategie di tokenizzazione.

Livelli di boost

Invece di una singola query monolitica, il team ha costruito una query a livelli che classifica automaticamente i risultati:

  1. Le corrispondenze di frase esatta su title.keyword ricevono il boost più alto, garantendo che le corrispondenze perfette dominino l'elenco.
  2. Le corrispondenze di bigrammi CJK su title.cjk ricevono un boost medio, preservando la qualità delle ricerche in lingua asiatica.
  3. Le corrispondenze fuzzy latine su title.std ricevono un boost inferiore, permettendo ai risultati tolleranti agli errori di apparire senza oscurare le corrispondenze esatte.

L'approccio a livelli rende la calibrazione semplice: regolare un valore di boost cambia l'importanza relativa di un'intera classe di corrispondenze.

Fuzziness intelligente

La fuzziness — che consente un numero limitato di modifiche ai caratteri — si applica solo al campo latino. Il team ha disabilitato la fuzziness per title.cjk perché un singolo cambiamento di carattere nei CJK spesso ne altera completamente il significato. Per il testo latino, la query utilizza l'impostazione di fuzziness AUTO di OpenSearch, che scala la distanza di modifica consentita in base alla lunghezza della parola, trovando un equilibrio tra tolleranza e rilevanza.

Prestazioni e logica di fallback

La routine di ricerca racchiude la chiamata a OpenSearch in un blocco try-catch:

  • Se OpenSearch risponde entro 400 ms, i suoi risultati vengono visualizzati.
  • Se la chiamata lancia un'eccezione o supera il timeout, il sistema riesegue immediatamente la query su SQLite FTS5.

Ciò garantisce che la latenza di rete o i disservizi non degradino mai l'esperienza dell'utente. La latenza di ricerca è rimasta sotto i 20 ms.

Impatto misurabile

  • Il tasso di ricerche senza risultati per le query in caratteri latini è sceso dall'11,4% al 2,1%.
  • La qualità della ricerca per le query CJK è rimasta invariata, confermando che il nuovo analyzer CJK ha preservato i punti di forza dell'indice FTS5 originale.
  • La latenza end-to-end è rimasta comodamente al di sotto dell'obiettivo di 20 ms, il che significa che lo strato aggiunto non ha rallentato l'interfaccia utente.

Lezioni e compromessi

  • Separazione di folding e fuzziness – Il folding (normalizzazione dei caratteri) e la fuzziness (gestione degli errori di battitura) affrontano problemi diversi. Mantenerli su campi distinti evita interazioni indesiderate.
  • Non trattare l'indice di ricerca come la fonte di verità – SQLite rimane il repository canonico; OpenSearch è una vista derivata e aggiornabile. Ciò previene il disallineamento dell'indice (index drift) e semplifica il ripristino dopo i guasti.
  • I livelli di boost semplificano la calibrazione – Raggruppare le corrispondenze correlate sotto un singolo fattore di boost riduce il numero di parametri da regolare.

Cosa osservare in seguito

L'esperimento dimostra che un modesto strato OpenSearch può migliorare drasticamente la tolleranza agli errori di battitura per i titoli video multilingue, senza sacrificare le comprovate capacità CJK di SQLite FTS5. Per le piattaforme in cui la rilevanza della ricerca influenza direttamente il tempo di visione, tale miglioramento si traduce in un tangibile vantaggio per l'esperienza utente.