Un equipo de desarrolladores combinó OpenSearch con SQLite FTS5 y redujo las búsquedas de video sin resultados del 11,4 por ciento al 2,1 por ciento, manteniendo la latencia por debajo de los 20 ms. Ahora, los usuarios que escriben “blackpink jenny solo stag” ven el resultado correcto “BLACKPINK Jennie SOLO stage” en lugar de una lista vacía.

Por qué era necesario el cambio

Los registros de búsqueda de una plataforma de alojamiento de videos mostraron un problema recurrente: un solo error tipográfico en un título en alfabeto latino podía eliminar todas las coincidencias. La extensión FTS5 de SQLite, valorada por su capacidad para coincidir con subcadenas en texto chino, japonés y coreano (CJK), no realiza búsquedas difusas (fuzzy matching). Un solo carácter mal escrito en un nombre o título de canción rompe la consulta por completo.

El flujo de trabajo existente trataba a SQLite como el único índice. Gestionaba bien las consultas CJK, pero no ofrecía una red de seguridad para los errores tipográficos en alfabeto latino. Por ello, el equipo buscó un motor de búsqueda complementario que pudiera proporcionar tolerancia a errores sin descartar la probada capa de FTS5.

Cómo se añadió OpenSearch

OpenSearch funciona como el servicio de búsqueda de primera línea; SQLite sigue siendo la fuente de verdad. Ambos sistemas se ejecutan en paralelo: OpenSearch recibe primero la consulta del usuario y, si responde con la suficiente rapidez, se muestran sus resultados. Si OpenSearch agota el tiempo de espera o produce un error, la solicitud recurre al índice SQLite FTS5. Este diseño de "seguridad ante fallos" garantiza que un contratiempo de red nunca deje la barra de búsqueda vacía.

Mapeo de campos múltiples

Cada título de video se indexa de tres formas en OpenSearch:

  • title.std – procesado por un analizador estándar con ASCII folding. Esto normaliza los caracteres con acentos y gestiona la mayoría de los errores tipográficos en alfabeto latino.
  • title.cjk – procesado por un analizador CJK que crea bigramas (tokens de dos caracteres). Esto preserva la capacidad de coincidencia de subcadenas que FTS5 proporciona para los alfabetos asiáticos.
  • title.keyword – se almacena sin cambios para búsquedas de coincidencia exacta y ordenación.

El uso de campos separados permite que la consulta aplique el análisis adecuado a cada alfabeto sin mezclar las estrategias de tokenización.

Niveles de potenciación (boost tiers)

En lugar de una única consulta monolítica, el equipo construyó una consulta por niveles que clasifica los resultados automáticamente:

  1. Las coincidencias de frase exacta en title.keyword reciben la mayor potenciación (boost), asegurando que las coincidencias perfectas dominen la lista.
  2. Las coincidencias de bigramas CJK en title.cjk reciben una potenciación media, preservando la calidad de las búsquedas en idiomas asiáticos.
  3. Las coincidencias difusas en latín en title.std reciben una potenciación menor, permitiendo que aparezcan resultados con tolerancia a errores sin eclipsar los aciertos exactos.

El enfoque por niveles facilita el ajuste: modificar un valor de potenciación cambia la importancia relativa de toda una clase de coincidencias.

Fuzziness inteligente

La fuzziness —que permite un número limitado de ediciones de caracteres— se aplica solo al campo latino. El equipo desactivó la fuzziness para title.cjk porque un solo cambio de carácter en CJK suele alterar el significado por completo. Para el texto latino, la consulta utiliza la configuración de fuzziness AUTO de OpenSearch, que escala la distancia de edición permitida según la longitud de la palabra, logrando un equilibrio entre tolerancia y relevancia.

Rendimiento y lógica de respaldo

La rutina de búsqueda envuelve la llamada a OpenSearch en un bloque try-catch:

  • Si OpenSearch responde en menos de 400 ms, se muestran sus resultados.
  • Si la llamada lanza una excepción o supera el tiempo de espera, el sistema vuelve a ejecutar inmediatamente la consulta contra SQLite FTS5.

Esto garantiza que la latencia de red o las interrupciones del servicio nunca degraden la experiencia del usuario. La latencia de búsqueda se mantuvo por debajo de los 20 ms.

Impacto mensurable

  • Las tasas de resultados cero para consultas en alfabeto latino cayeron del 11,4 % al 2,1 %.
  • La calidad de la búsqueda para consultas CJK se mantuvo sin cambios, confirmando que el nuevo analizador CJK preservó las fortalezas del índice FTS5 original.
  • La latencia de extremo a extremo se mantuvo cómodamente por debajo del objetivo de 20 ms, lo que significa que la capa añadida no ralentizó la interfaz de usuario.

Lecciones y compensaciones

  • Separar el folding y la fuzziness – El folding (normalización de caracteres) y la fuzziness (gestión de errores tipográficos) abordan problemas diferentes. Mantenerlos en campos distintos evita interacciones no deseadas.
  • No tratar el índice de búsqueda como la fuente de verdad – SQLite sigue siendo el almacén canónico; OpenSearch es una vista derivada y actualizable. Esto evita la deriva del índice (index drift) y simplifica la recuperación tras fallos.
  • Los niveles de potenciación simplifican el ajuste – Agrupar coincidencias relacionadas bajo un único factor de potenciación reduce el número de parámetros que necesitan ajuste.

Qué observar a continuación

El experimento demuestra que una modesta capa de OpenSearch puede mejorar drásticamente la tolerancia a errores tipográficos en títulos de videos multilingües sin sacrificar las probadas capacidades CJK de SQLite FTS5. Para las plataformas donde la relevancia de la búsqueda influye directamente en el tiempo de visualización, esa mejora se traduce en un beneficio tangible para la experiencia del usuario.