Ao construir bibliotecas de materiais locais e música de nível profissional, as arquiteturas tradicionais de pesquisa geralmente enfrentam grandes desafios. Quando um usuário digita “momento épico massivo” ou “piano tranquilo” na caixa de busca, as pesquisas de banco de dados baseadas em divisão de palavras-chave (como o SQLite FTS5) só podem corresponder com precisão às faixas que contêm exatamente essas palavras em seus campos. Isso faz com que um oceano de materiais de áudio com tags ricas (mas terminologias diferentes) afunde no esquecimento.
Para resolver completamente esse problema, em nossa última refatoração de baixo nível, migramos completamente para uma arquitetura de Pesquisa Híbrida (Hybrid Search) que combina o banco de dados vetorial LanceDB e o modelo edge BGE-M3.
I. Quebrando os Limites do SQLite FTS5
Em versões anteriores do PureLab, a pesquisa central dependia totalmente do módulo de busca de texto completo do SQLite (FTS5). Esta arquitetura é simples e extremamente rápida, mas atingiu gargalos em cenários de negócios reais:
- A Lacuna Semântica: Os termos de pesquisa dos usuários geralmente não se alinham perfeitamente com as tags de áudio reais (por exemplo, pesquisar por “feliz” pode deixar passar faixas com a tag “alegre”).
- Correspondência Fraca entre Idiomas: Os metadados de música são extremamente fragmentados em descrições em vários idiomas. Um simples tokenizador não consegue estabelecer associações semânticas entre os idiomas.
II. Recuperação de Duas Vias e Arquitetura Híbrida
Para introduzir uma camada semântica, não abandonamos a recuperação léxica. Em vez disso, adotamos um modelo de Recuperação de Pista Dupla e Fusão RRF (Reciprocal Rank Fusion), integrando profundamente o LanceDB sobre a arquitetura SQLite existente.
1. Tabelas de Projeção Independentes e Embeddings BGE-M3
Para cada biblioteca de usuário normalizada (Root), estabelecemos uma tabela de projeção text_vectors independente em seu diretório .lancedb/.
- Inferência ONNX Local: Quando o mecanismo de reconstrução do índice é acionado (Fase B), o sistema programa um motor em segundo plano baseado em
ort, passa o texto dos metadados para o modelo BGE-M3 Int8 ONNX local, produz vetoresf32de alta qualidade de 1024 dimensões e os insere/atualiza no banco de dados. - Livro-Razão e Mecanismo de Repetição (Ledger): Para evitar que tarefas de vetorização massiva sejam interrompidas à força devido a limitações de desempenho do dispositivo, projetamos uma tabela
text_vector_index_ledgerno SQLite. Ela rastreia o status de cada linha de texto (pending,indexed,failed), permitindo que o sistema retome perfeitamente e tente novamente do ponto de interrupção, mesmo se o programa for reiniciado inesperadamente.
2. Fornecedores Duplos: Léxico e Semântico
Quando um usuário digita uma pesquisa, a arquitetura se divide em dois provedores principais no backend:
- LexicalRetrievalProvider: Continua fornecendo correspondência rígida forte via FTS5 (garantindo que as pesquisas diretas de nome de arquivo e tags claras sejam lembradas em 100%).
- SemanticRetrievalProvider: Carrega o ambiente de inferência do BGE, calcula o vetor da Consulta (Query) do usuário e o entrega à ANN (Approximate Nearest Neighbor) do LanceDB para pesquisa semântica.
III. A Arte da Fusão de Classificações: RRF com Prioridade de Texto
Combinar os resultados de ambas as pistas e apresentar a lista final (ResultList) é o verdadeiro desafio.
Em vez de usar um reranqueador Cross-encoder de alta latência, usamos um algoritmo ajustado de Text-Priority RRF (Reciprocal Rank Fusion) para pós-processamento:
$$
Score_{RRF} = \frac{1}{K + \text{Rank}{Lexical}} + \frac{W{Semantic}}{K + \text{Rank}_{Semantic}}
$$
[!NOTE]
Em nossa implementação:
- $K = 60$
- Peso de correspondência léxica $W_{Lexical} = 1.0$
- Peso de correspondência semântica $W_{Semantic} = 0.95$
Ao aplicar um pequeno desconto no peso (0.95) ao lado semântico, garantimos que, quando os termos léxicos de um arquivo de áudio são encontrados diretamente, ele sempre será classificado acima daqueles que são meramente “semanticamente semelhantes”. Isso maximiza a restauração das expectativas tradicionais para a “pesquisa”, enquanto suplementa com joias ocultas semanticamente relevantes na cauda longa.
IV. Paralelismo de Duas Bibliotecas: Filtragem para Música e Materiais
Cenários de aplicativos diferentes têm requisitos de indexação completamente diferentes. Nos resultados recuperados pelo LanceDB (TextVectorSearchHit), vinculamos recursos com o library_type (“music” ou “material”) e a surface.
Isso significa que, mesmo que um usuário gerencie simultaneamente centenas de GB de álbuns de música sem perdas e coleções de materiais de efeitos sonoros, o pipeline de pesquisa pode executar uma separação de recursos precisa durante a recuperação de ANN, garantindo que os efeitos sonoros ambientais nunca entrem nas suas listas de reprodução de gêneros musicais.
Conclusão
O desafio de pesquisa de uma biblioteca local de um milhão de faixas consiste essencialmente em encontrar o equilíbrio entre precisão e abrangência em recursos de computação limitados no edge. A arquitetura de pesquisa híbrida, combinando o LanceDB com um modelo ONNX leve, não apenas preserva a privacidade dos dados do usuário, mas também eleva a experiência de pesquisa a níveis sem precedentes. Em versões futuras, também planejamos explorar a segmentação de metadados (chunking) para dar suporte à pesquisa em campos de descrição mais longos.