El reranker mentiroso

Capítulo 3 — El reranker mentiroso

En el argot técnico del RAG hay una figura clave, poco glamurosa y poco contada: el reranker. Imagina la búsqueda empresarial como la entrada de una discoteca. La base de datos vectorial es el portero: mira rápidamente a la multitud y deja entrar a treinta candidatos que, a simple vista, se parecen a lo que buscas. El reranker es el gorila de la puerta: toma a esos treinta, los mira con calma, selecciona cinco —aquellos que el LLM realmente leerá para construir la respuesta— y devuelve a los otros veinticinco. Es una función pequeña pero enorme: si él se equivoca, todos se equivocan. Si el gorila no sabe leer las caras, el local se llenará de las personas equivocadas y nadie entenderá por qué la noche salió mal.

En 2025 aparecieron en el mercado varios servicios en la nube que ofrecían rerankers como API. Envías una pregunta y una lista de documentos, te devuelven puntuaciones. Cómodo, escalable, sin GPUs que comprar, sin modelos que descargar. Un famoso proveedor europeo de modelos —sin nombrar, pero sabéis a qué nombres nos estamos refiriendo— exponía un modelo prometedor de la familia Qwen, de cuatro mil millones de parámetros, etiquetado "Reranker". El precio era razonable, la latencia aceptable. Cualquiera, en ese momento histórico, lo habría elegido. Muchos lo eligieron.

Salvo que las puntuaciones eran incorrectas. No "ligeramente" incorrectas, como puede ocurrir con cualquier modelo: incorrectas estructuralmente. Documentos palmariamente relevantes recibían 0.2, documentos fuera de tema recibían 0.8. Las primeras sospechas, como siempre en estos casos, se dirigieron a los habituales sospechosos: el modelo de embedding, el chunking, la formulación de la query, el preprocesamiento de los documentos. Semanas de investigaciones sobre pistas equivocadas. Solo comparando sistemáticamente las respuestas del reranker en la nube con las de un reranker local de referencia — la misma entrada, los mismos documentos, puntuaciones puestas lado a lado en una hoja de Excel — emergió la incómoda verdad: el modelo expuesto a través de la API estaba roto. Tal vez un error de deploy, tal vez una versión incorrecta cargada por error, tal vez un bug en la serialización de las puntuaciones. El proveedor nunca lo admitió formalmente. El problema, sin embargo, simplemente desapareció un día, después de una actualización silenciosa y sin cambios en las notas.

El punto de esta historia no es "los servicios en la nube se equivocan" — todos se equivocan, incluso los modelos locales se equivocan. El punto es más sutil: en un RAG serio, el reranker es una pieza a la que debes poder echar un vistazo dentro. Si es una caja negra de pago, y si sus resultados son números que parecen plausibles incluso cuando son aleatorios — y las puntuaciones de un reranker parecen siempre plausibles, porque son números entre cero y uno con algunos decimales—, no tienes ninguna forma de entender qué falla en tu sistema. Y dado que el reranker está "hacia el final" de la pipeline, su error contamina cada evaluación aguas arriba: parece que la búsqueda es lenta, la consulta incorrecta, los embeddings pobres. En realidad, es el portero que no sabe leer las caras, y tú estás cuestionando los cristales de la puerta.

La elección contracorriente de algunos equipos, en estos meses — en lugar de avanzar hacia más cloud, volver atrás — ha sido traer el reranker a casa. Un modelo de código abierto de la familia BGE, no gigantesco, ejecutado en GPU local (incluso en Apple Silicon, con algunas precauciones sobre los drivers). Más trabajo de gestión, es cierto. Pero la posibilidad de realizar experimentos controlados, de entender cuándo falla, de comparar versiones, de mantener un histórico. Y — no en último lugar — de no pagar a la API una fracción de céntimo por cada búsqueda de usuario. Fracción que, multiplicada por decenas de miles de consultas al mes, deja rápidamente de ser una fracción y se convierte en una partida presupuestaria.

Cuando un componente es tan crítico que su mal funcionamiento corrompe toda tu capacidad de medir el resto, entonces delegarlo a una caja negra no es eficiencia. Es un acto de fe. Y los actos de fe, en producción, se pagan con interés compuesto.