Lors de la construction de bibliothèques locales professionnelles de musique et de matériel audio, les architectures de recherche traditionnelles rencontrent souvent de graves défis. Lorsqu’un utilisateur tape “élan épique et massif” ou “piano tranquille” dans le champ de recherche, les recherches en base de données basées sur la division des mots-clés (comme SQLite FTS5) ne peuvent faire correspondre précisément que les pistes contenant exactement ces mots dans leurs champs. Cela fait qu’un océan de documents audio dotés de tags riches (mais d’une terminologie différente) tombe dans l’oubli.
Pour résoudre complètement ce problème, lors de notre dernière refonte des couches inférieures, nous avons entièrement migré vers une architecture de Recherche Hybride (Hybrid Search) combinant la base de données vectorielle LanceDB et le modèle edge BGE-M3.
I. Briser les Limites de SQLite FTS5
Dans les versions précédentes de PureLab, la recherche principale reposait entièrement sur le module de recherche en texte intégral de SQLite (FTS5). Cette architecture est simple et extrêmement rapide, mais elle a rencontré des goulots d’étranglement dans des scénarios commerciaux réels :
- Le Fossé Sémantique : Les termes de recherche des utilisateurs ne correspondent souvent pas parfaitement aux tags audio réels (par ex., chercher “heureux” pourrait rater des pistes taguées “joyeux”).
- Faible Correspondance Multilingue : Les métadonnées musicales sont extrêmement fragmentées dans des descriptions multilingues. Un simple tokenizer ne peut pas établir d’associations sémantiques entre les langues.
II. Recherche à Deux Voies et Architecture Hybride
Pour introduire une couche sémantique, nous n’avons pas abandonné la recherche lexicale. Au lieu de cela, nous avons adopté un modèle de Recherche à Deux Voies & RRF (Reciprocal Rank Fusion), en intégrant profondément LanceDB au-dessus de l’architecture SQLite existante.
1. Tables de Projection Indépendantes et Embeddings BGE-M3
Pour chaque bibliothèque d’utilisateur normalisée (Root), nous avons établi une table de projection indépendante text_vectors dans son répertoire .lancedb/.
- Inférence ONNX Locale : Lorsque le mécanisme de reconstruction de l’index est déclenché (Phase B), le système planifie un moteur en arrière-plan basé sur
ort, transmet le texte des métadonnées au modèle local BGE-M3 Int8 ONNX, produit des vecteursf32de haute qualité à 1024 dimensions et les insère dans la base de données. - Registre et Mécanisme de Relance (Ledger) : Pour éviter que les tâches massives de vectorisation ne soient interrompues de force en raison des limites de performance de l’appareil, nous avons conçu une table
text_vector_index_ledgerdans SQLite. Elle suit l’état de chaque ligne de texte (pending,indexed,failed), permettant au système de reprendre en douceur et de réessayer à partir du point d’interruption même en cas de redémarrage inattendu du programme.
2. Double Fournisseurs : Lexical et Sémantique
Lorsqu’un utilisateur tape une recherche, l’architecture se divise en deux fournisseurs principaux en arrière-plan :
- LexicalRetrievalProvider : Fournit toujours une correspondance forte et stricte via FTS5 (garantissant que les recherches directes de noms de fichiers et de tags clairs sont rappelées à 100 %).
- SemanticRetrievalProvider : Charge l’environnement d’inférence BGE, calcule le vecteur de la requête de l’utilisateur (Query) et le transmet à l’ANN (Approximate Nearest Neighbor) de LanceDB pour une recherche sémantique.
III. L’Art de la Fusion des Classements : RRF avec Priorité au Texte
Combiner les résultats des deux voies et présenter la liste finale (ResultList) est le véritable défi.
Plutôt que d’utiliser un re-classeur Cross-encoder à forte latence, nous utilisons un algorithme Text-Priority RRF (Reciprocal Rank Fusion) optimisé pour le post-traitement :
$$
Score_{RRF} = \frac{1}{K + \text{Rank}{Lexical}} + \frac{W{Semantic}}{K + \text{Rank}_{Semantic}}
$$
[!NOTE]
Dans notre implémentation :
- $K = 60$
- Poids de la correspondance lexicale $W_{Lexical} = 1.0$
- Poids de la correspondance sémantique $W_{Semantic} = 0.95$
En appliquant une légère décote de pondération (0.95) du côté sémantique, nous garantissons que lorsque les termes lexicaux d’un fichier audio sont directement trouvés, il sera toujours mieux classé que ceux qui sont simplement “sémantiquement similaires”. Cela maximise la restauration des attentes traditionnelles en matière de “recherche” tout en complétant avec des joyaux cachés sémantiquement pertinents dans la longue traîne.
IV. Parallélisme Double Bibliothèque : Filtrage Musique et Matériels
Les différents scénarios d’application ont des exigences d’indexation complètement différentes. Dans les résultats récupérés par LanceDB (TextVectorSearchHit), nous avons lié les caractéristiques avec le library_type (“music” ou “material”) et le surface.
Cela signifie que même si un utilisateur gère simultanément des centaines de gigaoctets d’albums de musique sans perte et des collections de matériel d’effets sonores, le pipeline de recherche peut exécuter une division précise des caractéristiques lors de la recherche ANN, garantissant que les effets sonores environnementaux ne se glissent jamais dans vos playlists de genres musicaux.
Conclusion
Le défi de la recherche dans une bibliothèque locale d’un million de pistes consiste essentiellement à trouver le juste équilibre entre la précision et l’exhaustivité avec des ressources informatiques limitées à la périphérie (Edge). L’architecture de recherche hybride, combinant LanceDB avec un modèle ONNX léger, préserve non seulement la confidentialité des données de l’utilisateur, mais élève également l’expérience de recherche à des niveaux sans précédent. Dans les futures versions, nous prévoyons également d’explorer le découpage en blocs (chunking) des métadonnées pour prendre en charge la recherche de champs de description plus longs.