Uma equipe de desenvolvedores combinou o OpenSearch com o SQLite FTS5 e reduziu as buscas de vídeo sem resultados de 11,4% para 2,1%, mantendo a latência abaixo de 20 ms. Agora, usuários que digitam “blackpink jenny solo stag” veem o resultado correto “BLACKPINK Jennie SOLO stage” em vez de uma lista vazia.

Por que a mudança foi necessária

Logs de busca de uma plataforma de hospedagem de vídeos mostraram um problema recorrente: um único erro de digitação em um título em alfabeto latino poderia anular todas as correspondências. A extensão FTS5 do SQLite, valorizada por sua capacidade de encontrar substrings em textos de chinês, japonês e coreano (CJK), não realiza busca difusa (fuzzy matching). Um único caractere escrito incorretamente em um nome ou título de música quebra a consulta inteiramente.

O pipeline existente tratava o SQLite como o único índice. Ele lidava bem com consultas CJK, mas não oferecia uma rede de segurança para erros de digitação em alfabetos latinos. Por isso, a equipe buscou um mecanismo de busca complementar que pudesse fornecer tolerância a erros de digitação sem descartar a camada FTS5 já comprovada.

Como o OpenSearch foi adicionado

O OpenSearch funciona como o serviço de busca de linha de frente; o SQLite permanece como a fonte da verdade (source of truth). Os dois sistemas funcionam em paralelo: o OpenSearch recebe a consulta do usuário primeiro e, se responder rápido o suficiente, seus resultados são exibidos. Se o OpenSearch sofrer um timeout ou apresentar erro, a requisição recorre ao índice SQLite FTS5. Esse design de "segurança contra falhas" (fail-safe) garante que uma oscilação na rede nunca deixe a barra de busca vazia.

Mapeamento de múltiplos campos

Cada título de vídeo é indexado de três formas no OpenSearch:

  • title.std – processado por um analisador padrão com ASCII folding. Isso normaliza caracteres acentuados e lida com a maioria dos erros de digitação em alfabetos latinos.
  • title.cjk – processado por um analisador CJK que cria bigramas (tokens de dois caracteres). Isso preserva a força de correspondência de substrings que o FTS5 oferece para escritas asiáticas.
  • title.keyword – armazenado sem alterações para buscas de correspondência exata e ordenação.

Campos separados permitem que a consulta aplique a análise correta para cada escrita sem misturar estratégias de tokenização.

Níveis de impulsionamento (Boost tiers)

Em vez de uma única consulta monolítica, a equipe construiu uma consulta em camadas que classifica os resultados automaticamente:

  1. Correspondências de frase exata em title.keyword recebem o maior impulsionamento (boost), garantindo que correspondências perfeitas dominem a lista.
  2. Correspondências de bigramas CJK em title.cjk recebem um impulsionamento médio, preservando a qualidade das buscas em idiomas asiáticos.
  3. Correspondências latinas difusas (fuzzy) em title.std recebem um impulsionamento menor, permitindo que resultados tolerantes a erros apareçam sem ofuscar os acertos exatos.

A abordagem em camadas torna o ajuste (tuning) simples: ajustar um valor de boost altera a importância relativa de toda uma classe de correspondências.

Busca difusa inteligente (Smart fuzziness)

A busca difusa (fuzziness) — que permite um número limitado de edições de caracteres — aplica-se apenas ao campo latino. A equipe desativou a busca difusa para title.cjk porque uma única mudança de caractere em CJK frequentemente altera o significado por completo. Para textos latinos, a consulta utiliza a configuração de fuzziness AUTO do OpenSearch, que escala a distância de edição permitida com base no comprimento da palavra, encontrando um equilíbrio entre tolerância e relevância.

Desempenho e lógica de fallback

A rotina de busca envolve a chamada do OpenSearch em um bloco try-catch:

  • Se o OpenSearch retornar dentro de 400 ms, seus resultados são exibidos.
  • Se a chamada lançar uma exceção ou exceder o tempo limite (timeout), o sistema executa imediatamente a consulta novamente contra o SQLite FTS5.

Isso garante que a latência de rede ou interrupções no serviço nunca degradem a experiência do usuário. A latência de busca permaneceu abaixo de 20 ms.

Impacto mensurável

  • As taxas de resultados zero para consultas em alfabeto latino caíram de 11,4% para 2,1%.
  • A qualidade da busca para consultas CJK permaneceu inalterada, confirmando que o novo analisador CJK preservou os pontos fortes do índice FTS5 original.
  • A latência de ponta a ponta permaneceu confortavelmente abaixo da meta de 20 ms, o que significa que a camada adicionada não atrasou a interface do usuário (UI).

Lições e compensações (trade-offs)

  • Separação de folding e fuzziness – O folding (normalização de caracteres) e a fuzziness (tratamento de erros de digitação) resolvem problemas diferentes. Mantê-los em campos distintos evita interações indesejadas.
  • Não trate o índice de busca como a fonte da verdade – O SQLite permanece como o armazenamento canônico; o OpenSearch é uma visualização derivada e atualizável. Isso evita a deriva do índice (index drift) e simplifica a recuperação após falhas.
  • Níveis de boost simplificam o ajuste – Agrupar correspondências relacionadas sob um único fator de boost reduz o número de parâmetros que precisam de ajuste.

O que observar a seguir

O experimento prova que uma camada modesta de OpenSearch pode melhorar drasticamente a tolerância a erros de digitação para títulos de vídeos multilíngues, sem sacrificar as comprovadas capacidades CJK do SQLite FTS5. Para plataformas onde a relevância da busca influencia diretamente o tempo de exibição, essa melhoria se traduz em um ganho tangível na experiência do usuário.