Busca Semântica
Quando a consulta usa vocabulário diferente do documento, a busca semântica representa pergunta e conteúdo em um espaço vetorial e recupera itens por proximidade de significado. Ela pode combinar embeddings, filtros, busca lexical e reranking. Em casa inteligente, permite localizar “como voltar o sensor ao padrão” mesmo que o manual diga “restauração de fábrica”. A técnica melhora recall, mas pode aproximar frases semanticamente parecidas e operacionalmente opostas; códigos, números, negações e versões exigem busca híbrida e filtros estruturados.
Quando uma pessoa formula a mesma necessidade com palavras diferentes das usadas no documento, a busca semântica tenta recuperar pelo significado aprendido em vez de exigir correspondência literal. A técnica ganhou maturidade com encoders de linguagem e embeddings de sentenças, capazes de projetar consulta e conteúdo em vetores comparáveis. Em uma implementação prática, a consulta é transformada em vetor, filtrada por metadados e comparada a um índice; um reranker pode reordenar os candidatos. Busca semântica não elimina a busca lexical. Códigos de erro, modelos, números, siglas e negações frequentemente exigem BM25 ou correspondência exata. Em casa inteligente, o melhor resultado costuma vir de uma estratégia híbrida, com fontes, versão e permissões preservadas.
- A diferença principal está no critério de relevância. Uma busca lexical encontra termos iguais ou variantes controladas. A semântica usa uma representação treinada para aproximar expressões relacionadas, como “zerar o dispositivo” e “restaurar configurações de fábrica”. Esse ganho melhora recall em linguagem natural e em corpora heterogêneos. Porém, semântica não significa compreensão operacional perfeita. “Desligar o alarme” e “não desligar o alarme” compartilham muitos sinais. O sistema deve testar negações e verbos. Para comandos, a busca pode ajudar a localizar documentação; não deve decidir a ação. A correspondência de entidades de automação precisa de IDs, cômodos e capacidades estruturadas.
- O pipeline normalmente inclui normalização da consulta, geração de embedding, aplicação de filtros, recuperação top‑k, fusão com resultados lexicais e reranking. Filtros devem vir antes ou durante a busca para impedir manual errado. Se o inventário informa `manufacturer=Acme`, `model=S100` e `firmware=2.4`, esses campos limitam o corpus. O top‑k é ajustado por avaliação, não por hábito. Muitos resultados aumentam ruído e custo de contexto; poucos podem perder a resposta. Um reranker cross-encoder avalia a relação consulta-documento com mais precisão, porém aumenta latência. Para um acervo residencial pequeno, a busca exata pode bastar; para milhões de chunks, índices aproximados são úteis.
- Busca híbrida combina vantagens. BM25 lida bem com “E105”, “NBR 5410”, “10 A” e nomes exatos. Vetores lidam com paráfrases. A fusão pode usar Reciprocal Rank Fusion, soma normalizada ou regras. A escala dos scores não é diretamente comparável entre mecanismos. O sistema deve evitar somar sem calibração. Um resultado lexical de código exato pode receber prioridade. A consulta pode ser expandida com sinônimos, mas isso precisa de controle para não trocar conceito. Em português, acentos, flexões e termos em inglês aparecem juntos. Um glossário de aliases melhora. A avaliação inclui perguntas reais, linguagem informal e termos técnicos.
- A qualidade depende do modelo de embedding e do domínio. Um encoder treinado em texto geral pode não distinguir modelos de sensores, abreviações elétricas ou nomes de ambientes. Fine-tuning contrastivo com pares de consulta e documento pode ajudar. Modelos multilíngues atendem português e inglês, mas devem ser medidos. Métricas incluem recall@k, precision@k, MRR e nDCG. A avaliação humana verifica se o trecho realmente responde. O conjunto de teste precisa de casos sem resposta, documentos conflitantes e versões antigas. Um sistema que sempre retorna algo pode alimentar alucinação. Limiar e resposta “não encontrei” são funções necessárias.
- Privacidade e autorização são aplicadas no mecanismo de recuperação. O filtro por residência, usuário e papel deve impedir que um embedding de consulta atravesse tenants. Não basta pedir ao LLM que não revele. Índices separados ou filtros obrigatórios ajudam. O log pode armazenar a consulta, que contém informações sensíveis; minimização e retenção são necessárias. Resultados também podem conter plantas, rotinas e nomes. O sistema registra IDs, scores e fontes para auditoria. Cache precisa incluir identidade e versão; um resultado de administrador não pode ser entregue a visitante. A busca semântica é uma interface de acesso a dados, não apenas uma função de IA.
- A busca semântica deve ser usada quando as consultas são abertas, o vocabulário varia e existe corpus suficiente. Para poucos comandos fixos, uma tabela ou NLU de intenção pode ser mais simples. Para telemetria atual, SQL, séries temporais ou APIs são superiores. A pergunta “qual foi o pico de potência ontem?” exige cálculo estruturado; embeddings não devem estimar. A pergunta “onde o manual explica o limite de potência?” é adequada. Em RAG, a recuperação alimenta a geração. Sem RAG, pode exibir resultados diretamente. A arquitetura deve manter fonte original, snippet e link. O usuário precisa distinguir busca de resposta gerada.