Arquitectura de Búsqueda de Vectores Híbrida para Bibliotecas Locales

Al construir bibliotecas de música y materiales locales de nivel profesional, las arquitecturas de búsqueda tradicionales a menudo se enfrentan a graves desafíos. Cuando un usuario escribe “momento épico masivo” o “piano tranquilo” en el cuadro de búsqueda, las búsquedas en la base de datos basadas en la separación de palabras clave (como SQLite FTS5) solo pueden emparejar con precisión las pistas que contienen exactamente esas palabras en sus campos. Esto hace que un océano de materiales de audio con etiquetas ricas (pero con diferente terminología) se hunda en el olvido.

Para resolver este punto de dolor por completo, en nuestra última refactorización de bajo nivel, nos actualizamos por completo a una arquitectura de Búsqueda Híbrida (Hybrid Search) que combina la base de datos vectorial LanceDB y el modelo de borde BGE-M3.

I. Rompiendo los Límites de SQLite FTS5

En versiones anteriores de PureLab, la búsqueda central dependía por completo del módulo de búsqueda de texto completo de SQLite (FTS5). Esta arquitectura es simple y extremadamente rápida, pero se encontró con cuellos de botella en escenarios comerciales reales:

• La Brecha Semántica: Los términos de búsqueda de los usuarios a menudo no se alinean perfectamente con las etiquetas de audio reales (ej., buscar “feliz” podría perder las pistas etiquetadas como “alegre”).
• Emparejamiento Interlingüístico Débil: Los metadatos musicales están extremadamente fragmentados en descripciones en múltiples idiomas. Un simple tokenizador no puede establecer asociaciones semánticas entre idiomas.

II. Recuperación de Doble Vía y Arquitectura Híbrida

Para introducir una capa semántica, no abandonamos la recuperación léxica. En cambio, adoptamos un modelo de Recuperación de Doble Vía y Fusión RRF (Reciprocal Rank Fusion), integrando LanceDB profundamente sobre la arquitectura existente de SQLite.

1. Tablas de Proyección Independientes y Embeddings BGE-M3

Para cada biblioteca de usuario normalizada (Root), establecimos una tabla de proyección independiente text_vectors en su directorio .lancedb/.

• Inferencia Local ONNX: Cuando se desencadena el mecanismo de reconstrucción de índices (Fase B), el sistema programa un motor en segundo plano basado en ort, pasa el texto de los metadatos al modelo local BGE-M3 Int8 ONNX, produce vectores de 1024 dimensiones f32 de alta calidad y los inserta o actualiza en la base de datos.
• Libro Mayor y Mecanismo de Reintento (Ledger): Para evitar que las tareas masivas de vectorización se interrumpan a la fuerza debido a las limitaciones de rendimiento del dispositivo, diseñamos una tabla text_vector_index_ledger en SQLite. Rastrea el estado de cada fila de texto (pending, indexed, failed), permitiendo al sistema reanudar sin problemas y reintentar desde el punto de interrupción incluso si el programa se reinicia inesperadamente.

2. Proveedores Duales: Léxico y Semántico

Cuando un usuario escribe una búsqueda, la arquitectura se divide en dos proveedores principales en el backend:

• LexicalRetrievalProvider: Sigue proporcionando un emparejamiento rígido fuerte a través de FTS5 (asegurando que las búsquedas directas por nombre de archivo y etiquetas claras se recuperen al 100%).
• SemanticRetrievalProvider: Carga el entorno de inferencia de BGE, calcula el vector del Query del usuario y se lo entrega al ANN (Vecino Más Cercano Aproximado) de LanceDB para la búsqueda semántica.

III. El Arte de Fusionar Clasificaciones: RRF con Prioridad en Texto

Combinar los resultados de ambas vías y presentar la lista final (ResultList) es el verdadero desafío.

En lugar de utilizar un reclasificador (reranker) Cross-encoder de alta latencia, utilizamos un algoritmo afinado de Text-Priority RRF (Reciprocal Rank Fusion) para el procesamiento posterior:

$$
Score_{RRF} = \frac{1}{K + \text{Rank}{Lexical}} + \frac{W{Semantic}}{K + \text{Rank}_{Semantic}}
$$

[!NOTE]
En nuestra implementación:

• $K = 60$
• Peso de coincidencia léxica $W_{Lexical} = 1.0$
• Peso de coincidencia semántica $W_{Semantic} = 0.95$

Al aplicar un ligero descuento en el peso (0.95) al lado Semántico, nos aseguramos de que cuando los términos léxicos de un archivo de audio acierten directamente, siempre se clasificarán por encima de aquellos que son simplemente “semánticamente similares”. Esto maximiza la restauración de las expectativas tradicionales para la “búsqueda” mientras complementa con gemas ocultas semánticamente relevantes en la larga cola.

IV. Paralelismo de Doble Biblioteca: Filtrado para Música y Materiales

Diferentes escenarios de aplicación tienen requisitos de indexación completamente diferentes. En los resultados recuperados por LanceDB (TextVectorSearchHit), vinculamos las características con el library_type (“music” o “material”) y el surface.

Esto significa que, incluso si un usuario gestiona simultáneamente cientos de GB de álbumes de música sin pérdida y colecciones de material de efectos de sonido, la tubería de búsqueda puede ejecutar una separación de características precisa durante la recuperación de ANN, garantizando que los efectos de sonido ambientales nunca se cuelen en sus listas de reproducción de géneros musicales.

Conclusión

El desafío de recuperación de una biblioteca local de un millón de pistas se trata esencialmente de encontrar el equilibrio entre la precisión y la exhaustividad bajo recursos computacionales limitados en el borde. La arquitectura de búsqueda híbrida, que combina LanceDB con un modelo ONNX ligero, no solo preserva la privacidad de los datos del usuario, sino que también eleva la experiencia de búsqueda a cotas sin precedentes. En futuras versiones, también planeamos explorar la fragmentación de metadatos (chunking) para soportar la recuperación de campos de descripción más largos.