Cipő, cipőt, cipőben: así busca Abisearch por significado en documentos en húngaro

Para un buscador por palabras clave, “cipő”, “cipőt”, “cipőben” y “cipőjükkel” son cuatro palabras distintas. Las cuatro son formas de la palabra húngara para zapato. En varios proyectos de atención al cliente y bases de conocimiento nos encontramos con el mismo obstáculo: el usuario busca con palabras diferentes de las del documento y el buscador no devuelve nada. En húngaro ocurre a todas horas. De ahí nació Abisearch, nuestra propia API SaaS de búsqueda vectorial, disponible en abisearch.abigel.ai. Lo que sigue es su trasfondo técnico y las decisiones que tomamos.

Buscar por significado

La búsqueda tradicional por palabras clave (índice invertido, ranking BM25) funciona cuando la consulta y el documento comparten las mismas formas de las palabras. Ante “zapatillas de correr cómodas” no encuentra la descripción “calzado ligero de entrenamiento para hacer footing”, aunque es justo lo que el usuario quiere.

La búsqueda vectorial funciona de otra manera. Un modelo de embeddings convierte cada fragmento de texto en un vector numérico de varios cientos de dimensiones y sitúa cerca unos de otros los textos de significado parecido. El buscador mide entonces la distancia entre vectores y deja de lado si las palabras coinciden. El modelo es multilingüe: una consulta en húngaro encuentra un documento en inglés, y al revés.

Las palabras clave siguen haciendo falta. En identificadores, referencias de artículo y expresiones exactas, la coincidencia literal importa. Por eso Abisearch es híbrido: completa los resultados vectoriales con señales de palabras clave y ordena según la combinación de ambos.

Sufijos, tildes y compuestos

El húngaro es una lengua aglutinante: a una raíz pueden unirse docenas de sufijos. La lematización (stemming) ayuda en parte, pero a menudo es demasiado agresiva o directamente errónea, y las palabras compuestas, como “futócipő” (zapatilla de correr) o “edzőcipő” (zapatilla de entrenamiento), son un problema aparte.

Los modelos de embeddings multilingües lo resuelven mucho mejor, porque tokenizan a nivel de subpalabra y han aprendido el significado más que la forma. Aun así, en la práctica hubo que ocuparse de varias cosas:

• las frases largas en húngaro usan más tokens que su equivalente en inglés, así que el tamaño de la fragmentación (chunking) se ajusta por 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 de una o dos palabras es “ruidoso”, y en esos casos la rama de palabras clave recibe más peso.

El cliente no tiene que configurar nada de esto. La API detecta el idioma y se adapta.

Una hoja de cálculo y un endpoint

El objetivo era que pudiera usarse sin saber nada de aprendizaje automático. La carga acepta dos formatos: JSON (un array de registros con campos arbitrarios) y Excel (un registro por fila, un campo por columna). Al subir los datos se indica qué campos forman parte del texto de búsqueda y cuáles quedan como metadatos filtrables.

La búsqueda es un único endpoint REST. La petición lleva la consulta en lenguaje natural y filtros opcionales; la respuesta, la lista de resultados con su puntuación de relevancia y el registro original. Se puede llamar desde cURL, Python, JavaScript o PHP como cualquier API HTTP. La clave de API va en una cabecera y cada respuesta indica la cuota restante.

La fragmentación de los documentos, el cálculo de los embeddings y la actualización del índice se ejecutan 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 sobre una infraestructura compartida.

Segunda vuelta con Gemini

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

Es más lento y más caro que la búsqueda básica, así que se activa por petición. Compensa en bases de conocimiento y artículos de soporte; para filtrar con rapidez un catálogo de productos suele bastar la lista básica.

Cien peticiones diarias gratis

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

El precio depende del uso. Cada cuenta recibe 100 peticiones gratis al día; a partir de ahí, cada petición cuesta 0,001 euros. No hay mínimo mensual ni paquete que comprar por adelantado. Es una decisión deliberada: los proyectos pequeños, como un repositorio interno de documentos o una tienda online con unos cientos de productos, pueden probarlo sin coste, y los grandes pagan por el tráfico real.

Quien lo pruebe en abisearch.abigel.ai y quiera contar su experiencia o informar de un error puede escribirnos a hello@procats.hu. Nuestros próximos pasos apuntan a los sistemas de voz, donde la búsqueda será un componente más de la conversación.