Cuando lo semántico falla: por qué tu RAG necesita seguir buscando por palabras exactas

Hay un momento incómodo en casi todos los proyectos de recuperación aumentada. El sistema funciona bien con preguntas conceptuales, la demo sale redonda, y entonces alguien escribe el nombre de una empresa concreta y el buscador devuelve cualquier cosa menos el artículo donde se habla de ella.

No es un fallo de configuración. Es una limitación conocida de la búsqueda semántica, y en un medio digital aparece antes que en casi ningún otro sitio.

Qué hace bien y qué hace mal la búsqueda por significado

Los vectores capturan de qué trata un texto. Por eso relacionan «ayudas a la reforma» con «deducciones por rehabilitación» aunque no compartan palabras: hablan de lo mismo.

Ese mismo mecanismo es el que falla con lo que no tiene significado semántico propio. Un nombre propio poco frecuente, una sigla, un número de expediente, un artículo de una ley, una cifra concreta. Para el modelo, dos empresas del mismo sector con nombres distintos ocupan posiciones casi idénticas: hablan de lo mismo. Para el lector no son lo mismo en absoluto, son la diferencia entre encontrar la noticia o no.

Y resulta que en un medio, una parte muy grande de las búsquedas reales son exactamente eso: nombres de personas, de empresas, de municipios, referencias normativas, fechas y cantidades.

La solución no es elegir, es sumar

La respuesta estándar a este problema se llama búsqueda híbrida y consiste en algo poco sofisticado: ejecutar las dos búsquedas y combinar los resultados.

Por un lado, la búsqueda léxica de toda la vida, que puntúa la coincidencia literal de términos y es imbatible con nombres y cifras. Por otro, la búsqueda vectorial, que entiende de qué va la pregunta aunque las palabras no coincidan. Después se fusionan las dos listas.

El método más extendido para fusionarlas se llama reciprocal rank fusion y tiene la virtud de no necesitar que las puntuaciones de ambos sistemas sean comparables entre sí: basta con la posición que ocupa cada documento en cada lista. Un documento que aparece razonablemente arriba en las dos gana a uno que arrasa en una sola.

La mejora es de las pocas en este campo que se nota sin necesidad de medirla con instrumentos finos.

El reordenador, el paso que casi nadie da

Hay una tercera pieza que suele quedarse fuera de los proyectos y que rinde mucho: el reordenador o reranker.

La idea es sencilla. La búsqueda recupera, digamos, cincuenta fragmentos candidatos de forma rápida y algo tosca. El reordenador es un modelo más lento pero mucho más preciso que lee cada candidato junto con la pregunta y decide cuáles son realmente pertinentes. De los cincuenta se queda con los cinco mejores, y esos son los que van al modelo que redacta.

Como solo procesa cincuenta fragmentos y no el archivo entero, el coste es asumible. Y el efecto sobre la calidad de la respuesta final es de los más altos por euro invertido de toda la cadena, porque el modelo redactor deja de recibir ruido.

Filtrar antes de buscar

La última pieza no es un algoritmo, son los metadatos. Si la pregunta menciona un año, una sección o un autor, esa restricción debería aplicarse antes de la búsqueda, no confiarse a la similitud.

Es la parte más aburrida y la que más agradece un archivo periodístico bien mantenido. También es donde se paga la factura de años de migraciones con fechas mal importadas y autorías perdidas.

Qué pedir cuando te vendan un RAG

Si alguien ofrece montar esto para un medio, hay tres preguntas que conviene hacer antes de firmar: si la búsqueda es híbrida o solo vectorial, si hay reordenador, y cómo se filtra por fecha y sección.

Las tres tienen respuestas cortas. Si la primera es «solo vectorial», el sistema va a fallar justo en las búsquedas que más importan a un lector de prensa, y va a fallar de una manera que no se ve en la demo.