Abisearch: búsqueda vectorial en documentos en húngaro

En los últimos años nos topamos con el mismo problema en varios proyectos de atención al cliente y bases de conocimiento: la búsqueda no encuentra lo que el usuario busca, porque no usa las mismas palabras que el documento. En húngaro esto es especialmente doloroso. De esa experiencia nació Abisearch, nuestra propia API SaaS de búsqueda vectorial, disponible en abisearch.abigel.ai. En esta entrada describimos el trasfondo técnico y nuestras decisiones.

Significado en lugar de palabras clave

La búsqueda tradicional por palabras clave (índice invertido, ranking BM25) funciona bien cuando la forma de las palabras de la consulta y del documento coincide. Para la consulta “zapatillas de correr cómodas” no encuentra la descripción “calzado ligero de entrenamiento para hacer footing”, aunque el usuario busca exactamente eso.

La búsqueda vectorial funciona con otro principio. Un modelo de embeddings convierte cada fragmento de texto en un vector numérico de varios cientos de dimensiones, de forma que los vectores de textos con significado parecido quedan cerca unos de otros. La búsqueda entonces no mira coincidencias de palabras, sino distancias entre vectores. El modelo es multilingüe, así que una consulta en húngaro encuentra también el documento en inglés, y viceversa.

Esto no sustituye del todo la búsqueda por palabras clave: en identificadores, referencias de artículo y expresiones exactas la coincidencia sigue siendo importante. Por eso Abisearch trabaja en modo híbrido: complementa los resultados vectoriales con señales de palabras clave, y el orden final lo da la combinación de ambos.

Las dificultades del húngaro

El húngaro es una lengua aglutinante: a una sola raíz pueden unirse docenas de sufijos, y las formas “cipő”, “cipőt”, “cipőben”, “cipőjükkel” son cuatro palabras distintas para un sistema de palabras clave. La lematización (stemming) ayuda en parte, pero a menudo es demasiado agresiva o errónea, y las palabras compuestas (“futócipő”, “edzőcipő”) son un problema aparte.

Los modelos de embeddings multilingües son notablemente mejores en esto, porque la tokenización es a nivel de subpalabra y el modelo ha aprendido el significado, no la forma de la palabra. Lo que en la práctica tuvimos que tratar de todos modos:

• las frases largas en húngaro usan más tokens que su equivalente en inglés, por lo que ajustamos el tamaño de la fragmentación (chunking) según el idioma,
• la escritura con y sin acentos (“cipo” y “cipő”) requiere normalización en la rama de palabras clave,
• el vector de las búsquedas cortas, de una o dos palabras, es “ruidoso”, así que en esos casos la rama de palabras clave recibe más peso.

Estas reglas no las tiene que configurar el cliente; la API reconoce el idioma y trabaja en consecuencia.

Carga de datos y API

Nuestro objetivo era que fuera utilizable sin conocimientos de aprendizaje automático. Por eso la carga de datos acepta dos formatos: JSON (un array de registros con campos arbitrarios) y una hoja de Excel (un registro por fila, un campo por columna). Al cargar se puede indicar qué campos entran en el texto de búsqueda y cuáles quedan como metadatos filtrables.

La búsqueda es un único endpoint REST: la petición es la consulta en lenguaje natural más filtros opcionales, la respuesta es la lista de resultados con puntuación de relevancia y el registro original. Se puede llamar desde cURL, Python, JavaScript o PHP igual que cualquier API HTTP. La clave de API va en una cabecera y las respuestas incluyen la cuota restante.

Por detrás, la fragmentación de los documentos, el cálculo de los embeddings y la actualización del índice se hacen de forma asíncrona, en una cola, para que una carga grande no ralentice las búsquedas de los demás clientes. Es el mismo patrón multi-tenant del que ya escribimos: límites y colas por inquilino, infraestructura compartida.

Reranking

La distancia vectorial por sí sola no siempre da el mejor orden: entre los primeros veinte resultados suele estar la respuesta correcta, pero no necesariamente en el primer puesto. Por eso ofrecemos un paso opcional de reordenación (re-ranking): un modelo de lenguaje grande (Gemini) vuelve a evaluar los mejores candidatos en el contexto de la consulta, y el orden final lo determina este.

El reranking es más lento y más caro que la búsqueda básica, por lo que se activa por petición. En bases de conocimiento y artículos de atención al cliente merece la pena activarlo; para el filtrado rápido de un catálogo de productos a menudo basta la lista básica de resultados.

Operación, tratamiento de datos, precios

Abisearch corre íntegramente en un centro de datos dentro de la Unión Europea; los datos cargados y los índices también se quedan allí. El tratamiento de datos se hace conforme al RGPD; el conjunto de datos cargado puede borrarse en cualquier momento, y el borrado lo elimina también del índice.

El precio se basa en el uso: cada cuenta recibe 100 peticiones gratis al día, y por encima de eso cobramos 0,001 euros por petición. No hay mínimo mensual ni paquete que haya que comprar por adelantado. Es una decisión consciente: así los proyectos pequeños (un repositorio interno de documentos, una tienda online con unos cientos de productos) pueden probarlo sin coste, y los grandes pagan según el tráfico real.

Si alguien lo prueba en abisearch.abigel.ai y quiere compartir cualquier experiencia o error, lo esperamos en info@procats.hu. Nuestros próximos pasos apuntan hacia los sistemas de voz, donde la búsqueda será solo un componente dentro de la conversación.