Transformers.js y embeddings: búsqueda semántica sin infraestructura de servidor

Un error clásico de la búsqueda: el usuario escribe «portátil barato» y obtiene resultados vacíos, porque en la base de datos el producto se llama «laptop económico». Machine Learning Mastery publica un análisis detallado de cómo sustituir la búsqueda por palabras clave por una búsqueda semántica, usando Transformers.js y sentence embeddings directamente en el navegador, sin backend de servidor.

¿Cuál es el problema de la búsqueda tradicional?

La búsqueda estándar por palabras clave compara caracteres, no significado. Si la consulta y el documento no coinciden literalmente, no hay resultado, aunque las palabras sean sinónimas. Es un fallo que los equipos reproducen una y otra vez: añaden sinónimos a mano, ajustan las stop words, conectan ElasticSearch y, aun así, se les escapan las formulaciones poco habituales.

El problema es sistémico. Los usuarios no piensan en cómo se llama el producto en la base de datos: describen lo que necesitan. «Ventilador silencioso», «portátil para estudiar», «teléfono con buena cámara» son consultas que un motor de palabras clave no entenderá o para las que devolverá un resultado irrelevante.

La búsqueda semántica aborda la tarea de otra manera: convierte el texto en un vector numérico (embedding) que refleja su significado. «Portátil barato» y «laptop económico» quedarán cerca en el espacio vectorial, porque son semánticamente próximos. En lugar de comparar cadenas, el motor calcula la similitud del coseno entre los vectores de la consulta y los de los documentos.

¿Cómo funciona Transformers.js?

Transformers.js es un port a JavaScript de la librería Transformers de Hugging Face. Ejecuta modelos de lenguaje directamente en el navegador o en Node.js, sin API de servidor. Los modelos se cargan como pesos ONNX y se ejecutan mediante WebAssembly o WebGPU.

Para la búsqueda semántica hacen falta modelos de sentence embeddings, entrenados para convertir frases en vectores densos de dimensión fija. Una opción popular para empezar es `all-MiniLM-L6-v2`, de Sentence-Transformers: pesa unos 25 MB, no requiere GPU y es lo bastante rápido para código en el cliente.

Arquitectura básica de la búsqueda:

• Se inicializa el pipeline: `pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2')`
• Se indexa la base: cada documento pasa por el modelo y se guardan los vectores
• Al recibir una consulta: se vectoriza el texto del usuario de la misma manera
• Se calcula la similitud del coseno entre el vector de la consulta y todos los vectores del índice
• Se devuelven los N documentos con mayor índice de cercanía

En bases pequeñas (hasta unos pocos miles de registros), el índice se guarda directamente en memoria o en `localStorage`: no se necesita ninguna infraestructura de servidor.

Ventajas y límites reales

La principal ventaja es el backend cero. Todo funciona en el cliente: el modelo se descarga una sola vez y los embeddings se calculan en local. Encaja en portales de documentación, blogs estáticos, dashboards internos y cualquier proyecto que viva sin un servidor permanente.

Las limitaciones también son importantes. El recorrido lineal O(n) empieza a ralentizarse con decenas de miles de documentos; ahí hace falta indexación HNSW mediante librerías como `hnswlib-node`. Los modelos de embeddings de propósito general pueden equivocarse con vocabulario muy especializado: en esos casos funciona mejor un modo híbrido, con BM25 para la coincidencia exacta y embeddings para la semántica.

Qué significa esto

La barrera para implantar una búsqueda inteligente ha bajado de forma notable. Antes exigía un stack de Python en el servidor, una base de datos vectorial y una API aparte. Ahora un desarrollador de frontend puede añadir búsqueda semántica a un sitio estático con unas pocas líneas de JavaScript, y funcionará incluso sin conexión.