Une équipe de développeurs a couplé OpenSearch avec SQLite FTS5 et a réduit le taux de recherches vidéo sans résultat de 11,4 % à 2,1 %, tout en maintenant une latence inférieure à 20 ms. Désormais, les utilisateurs qui tapent « blackpink jenny solo stag » voient le résultat correct « BLACKPINK Jennie SOLO stage » au lieu d'une liste vide.

Pourquoi ce changement était nécessaire

Les journaux de recherche d'une plateforme d'hébergement de vidéos ont révélé un problème récurrent : une seule faute de frappe dans un titre en caractères latins pouvait annuler tous les résultats. L'extension FTS5 de SQLite, prisée pour sa capacité à faire correspondre des sous-chaînes dans les textes chinois, japonais et coréens (CJK), ne permet pas la recherche floue (fuzzy matching). Un seul caractère mal orthographié dans un nom ou un titre de chanson suffit à briser entièrement la requête.

Le pipeline existant traitait SQLite comme l'unique index. Il gérait bien les requêtes CJK mais n'offrait aucun filet de sécurité pour les fautes de frappe en caractères latins. L'équipe a donc cherché un moteur de recherche complémentaire capable de tolérer les fautes de frappe sans abandonner la couche FTS5 éprouvée.

Comment OpenSearch a été ajouté

OpenSearch fonctionne comme service de recherche de première ligne ; SQLite reste la source de vérité. Les deux systèmes fonctionnent en parallèle : OpenSearch reçoit d'abord la requête de l'utilisateur et, s'il répond suffisamment vite, ses résultats sont affichés. Si OpenSearch subit un dépassement de délai (timeout) ou une erreur, la requête bascule sur l'index SQLite FTS5. Cette conception de type « sécurité intégrée » (fail-safe) garantit qu'un incident réseau ne laissera jamais la barre de recherche vide.

Mapping multi-champs

Chaque titre de vidéo est indexé de trois manières dans OpenSearch :

  • title.std – traité par un analyseur standard avec repliement ASCII (ASCII folding). Cela normalise les caractères accentués et gère la plupart des fautes de frappe en caractères latins.
  • title.cjk – traité par un analyseur CJK qui crée des bigrammes (jetons de deux caractères). Cela préserve la force de la correspondance de sous-chaînes que FTS5 offre pour les écritures asiatiques.
  • title.keyword – stocké tel quel pour les recherches par correspondance exacte et le tri.

Des champs distincts permettent à la requête d'appliquer l'analyse appropriée à chaque script sans mélanger les stratégies de tokenisation.

Niveaux de boost

Au lieu d'une requête monolithique unique, l'équipe a construit une requête hiérarchisée qui classe les résultats automatiquement :

  1. Les correspondances de phrases exactes sur title.keyword reçoivent le boost le plus élevé, garantissant que les correspondances parfaites dominent la liste.
  2. Les correspondances de bigrammes CJK sur title.cjk reçoivent un boost moyen, préservant la qualité des recherches en langues asiatiques.
  3. Les correspondances latines floues (fuzzy) sur title.std reçoivent un boost inférieur, permettant aux résultats tolérants aux fautes de frappe d'apparaître sans éclipser les résultats exacts.

L'approche hiérarchisée simplifie le réglage : l'ajustement d'une valeur de boost modifie l'importance relative de toute une classe de correspondances.

Fuzziness intelligente

La fuzziness — qui permet un nombre limité de modifications de caractères — s'applique uniquement au champ latin. L'équipe a désactivé la fuzziness pour title.cjk car un seul changement de caractère en CJK modifie souvent entièrement le sens. Pour le texte latin, la requête utilise le paramètre de fuzziness AUTO d'OpenSearch, qui ajuste la distance d'édition autorisée en fonction de la longueur du mot, trouvant ainsi un équilibre entre tolérance et pertinence.

Performance et logique de repli

La routine de recherche enveloppe l'appel OpenSearch dans un bloc try-catch :

  • Si OpenSearch répond en moins de 400 ms, ses résultats sont affichés.
  • Si l'appel lève une exception ou dépasse le délai d'attente, le système réexécute immédiatement la requête sur SQLite FTS5.

Cela garantit que la latence du réseau ou les interruptions de service ne dégradent jamais l'expérience utilisateur. La latence de recherche est restée inférieure à 20 ms.

Impact mesurable

  • Le taux de résultats nuls pour les requêtes en caractères latins est passé de 11,4 % à 2,1 %.
  • La qualité de recherche pour les requêtes CJK est restée inchangée, confirmant que le nouvel analyseur CJK a préservé les points forts de l'index FTS5 original.
  • La latence de bout en bout est restée confortablement en dessous de l'objectif de 20 ms, ce qui signifie que la couche ajoutée n'a pas ralenti l'interface utilisateur.

Leçons et compromis

  • Séparer le repliement et la fuzziness – Le repliement (folding, normalisation des caractères) et la fuzziness (gestion des fautes de frappe) répondent à des problèmes différents. Les maintenir sur des champs distincts évite les interactions imprévues.
  • Ne pas traiter l'index de recherche comme la source de vérité – SQLite reste le magasin canonique ; OpenSearch est une vue dérivée et actualisable. Cela évite la dérive de l'index et simplifie la récupération après une panne.
  • Les niveaux de boost simplifient le réglage – Le regroupement des correspondances liées sous un seul facteur de boost réduit le nombre de paramètres à ajuster.

Prochaines étapes à surveiller

L'expérience prouve qu'une modeste couche OpenSearch peut considérablement améliorer la tolérance aux fautes de frappe pour les titres de vidéos multilingues, sans sacrifier les capacités CJK éprouvées de SQLite FTS5. Pour les plateformes où la pertinence de la recherche influence directement le temps de visionnage, cette amélioration se traduit par un gain tangible en matière d'expérience utilisateur.