Reclasificación en RAG: La ventana estrecha en la que los codificadores cruzados realmente son útiles

Un codificador cruzado ayuda a un pipeline RAG únicamente dentro de un rango estrecho: el nivel de recuperación en la primera etapa debe ser lo suficientemente alto, y la cantidad de candidatos que se entregan debe mantenerse lo suficientemente baja. Fuera de ese rango, el reordenador ya no tiene nada que corregir o comienza a causar problemas. A continuación se explica el mecanismo, un modo de fallo denominado “Phantom Hits”, y una forma de medir todo esto con los propios datos.

Imagínese un sistema RAG que encontró la respuesta correcta. No hubo errores ni documentos perdidos. La respuesta se encuentra simplemente en la posición 37 de la lista de resultados, mientras que el LLM solo lee las cinco primeras, por lo que, en la práctica, no existe. No se activa ninguna alerta, ya que según todas las métricas de monitoreo la solicitud tuvo éxito.

Eso no es una peculiaridad de una implementación concreta. Se debe a la forma en que está construida la arquitectura. La búsqueda vectorial está diseñada para mostrar la respuesta correcta entre los 50 y 200 resultados principales, no necesariamente en la posición más alta, por lo que un proceso que termina en la recuperación deja la calidad de la respuesta al azar.

El reflejo habitual es añadir un mecanismo de reclasificación. Eso implica un codificador cruzado, aproximadamente doce líneas de código, un ligero aumento en el índice nDCG, y el problema queda resuelto. Ese reflejo no está mal porque la reclasificación falla; está mal porque funciona dentro de un estrecho rango operativo que casi nadie mide. A continuación, verá cómo funciona esta segunda etapa más costosa, dónde se encuentra cada extremo de ese rango y cómo averiguar en una tarde en qué lado de cada extremo se encuentra su sistema.

La reclasificación no es una mejor búsqueda vectorial

Un reordenador es una arquitectura diferente que se activa solo después de la recuperación y se aplica a un pequeño grupo de candidatos.

El bi-encoder de tu búsqueda vectorial actual codifica la consulta y cada documento de forma independiente, con antelación y de forma offline. Eso lo hace rápido y le permite escalar a millones de documentos. El precio a pagar es que nunca considera la consulta y el documento juntos.

El cross-encoder hace lo contrario: lee ambos al mismo tiempo, token por token, lo que le permite detectar negaciones, contradicciones numéricas y matices que un bi-encoder no puede ver. A cambio, debe repetir ese trabajo para cada candidato por separado, en el momento de la consulta.

Eso da lugar al conocido proceso en dos etapas. La recuperación reduce de forma económica el campo a entre 50 y 200 candidatos, buscando la recuperación total: no perder la respuesta correcta. Luego, el reclasificado ordena ese pequeño grupo con un costo mayor, buscando la precisión: entre los que quedan, elegir al verdaderamente mejor.

Tampoco la segunda capa representa una mejora gratuita. Más allá de un cierto número de candidatos, el codificador cruzado comienza a tratar el ruido como señal y la calidad realmente disminuye. Decidir si incluir el reclasificado es un cálculo de ingeniería que debe realizarse con los datos propios, no una decisión automática.

Por qué la recuperación no puede ser el último paso

Un síntoma que aparece constantemente en los sistemas RAG en producción es el siguiente: “el modelo genera alucinaciones, aunque la información está en nuestra base de datos”. En la mayoría de los casos investigados hasta el final, el modelo no estaba inventando nada por su cuenta. El documento correcto se encontraba entre los cincuenta primeros resultados devueltos, pero no entre los cinco primeros que se mostraron al generador.

La causa es de tipo arquitectónico. El bi-encoder calcula el embedding de un documento en el momento de indexación, antes de que exista ninguna pregunta. En el momento de la búsqueda, compara dos resúmenes comprimidos, en lugar del texto real de la consulta, con el texto real del documento.

Un ejemplo clásico de lo que se pierde: la consulta dice “barato” y el documento indica “$500 por noche”. Para los vectores, ambos se refieren al precio de una habitación de hotel, por lo que terminan cerca uno del otro. La contradicción solo se hace visible cuando alguien lee los dos uno al lado del otro, y un bi-encoder, por diseño, nunca lo hace.

Un modelo de embedding mejor no solucionará esto, porque se trata de un compromiso intencional. La recuperación maximiza la precisión de recuperación, es decir, la probabilidad de que el documento correcto esté en el conjunto de resultados devueltos, y lo hace de forma económica con millones de documentos. Colocar el documento correcto en la parte superior simplemente no forma parte de sus funciones.

Recall@50 y precision@5 miden cosas diferentes y responden a preguntas distintas. Confundirlos es cómo los equipos terminan pagando por una segunda capa para resolver algo que no puede abordar.

La debilidad radica en que el bi-encoder nunca analiza la pareja conjuntamente, así que veamos qué ventajas obtiene un modelo que sí lo hace.

El bi-encoder cataloga, el cross-encoder lee

Imagínense el proceso de contratación. El bi-encoder actúa como un reclutador que clasifica mil currículos en carpetas antes incluso de que exista la descripción del puesto: de forma rápida, superficial y terminando pronto. El cross-encoder actúa como el gerente de contrataciones con diez finalistas, leyendo cada currículo junto con el anuncio, línea por línea. Solo en ese momento aparecen las incoherencias que el reclutador no pudo detectar.

Mecánicamente, la diferencia es evidente. Un cross-encoder combina la consulta y el documento en una sola secuencia, con la estructura canónica [CLS] consulta [SEP] documento [SEP], y la pasa por un único transformador.

Dentro de este proceso, la atención cruzada es la que realiza el trabajo: cada token de consulta puede prestar atención directamente a cada token de documento y viceversa. El resultado no es un vector para comparar, sino un único logit, un número bruto no normalizado que expresa cuán seguro está el modelo de que esta pareja específica es relevante.

Así, el bi-encoder genera una representación mientras que el cross-encoder emite un veredicto. Se trata de una diferencia en lo que el modelo puede percibir en general, no de una diferencia en grado.

De esto se deriva inmediatamente una consecuencia: la puntuación del cross-encoder no puede calcularse ni indexarse de antemano, ya que depende de la pareja específica de consulta y documento, y no solo del documento en sí. Cada consulta requiere un proceso completo por cada candidato, lo que hace que el costo por pareja sea de diez a cien veces mayor que en el caso de una comparación de vectores.

La figura que explica el diseño en dos etapas aclara la escala necesaria. Según el artículo de 2019 de Reimers y Gurevych sobre Sentence-BERT, encontrar la pareja más similar entre 10,000 oraciones requiere aproximadamente 50 millones de comparaciones, lo que equivale a unas 65 horas con un modelo BERT completo y unos 5 segundos con una arquitectura de tipo SBERT.

Recuerde esta cifra en su forma exacta, ya que circulan variantes redondeadas, como “10 millones de documentos y 50 horas”. La diferencia es cualitativa: el cuello de botella radica en la cantidad de pares que deben evaluarse, no en el tamaño del corpus.

Por eso un codificador cruzado nunca sirve como primera etapa. No es peor, simplemente es demasiado costoso de ejecutar en todo el corpus. Y dado que su costo es por par, todo depende de cuántos pares se le proporcionen y de dónde se ubique dentro del proceso.

Dos etapas, dos presupuestos

El reordenador se encuentra después de la recuperación de resultados y antes del LLM. La búsqueda devuelve los k mejores candidatos, donde k es la cantidad de documentos que una etapa transfiere a la siguiente, generalmente entre 50 y 200. El reordenador luego reorganiza esa lista y envía los resultados al generador en alguna posición entre la 3 y la 20.

Esta secuencia de procesos no surgió con los LLM, lo que demuestra su madurez. El enfoque de “filtro económico y luego juez costoso” proviene de la era del Learning-to-Rank, cuando la segunda etapa consistía en un conjunto de árboles de decisión basados en características diseñadas manualmente, en lugar de un transformador. El motor cambió, pero la arquitectura no.

El reordenamiento neuronal tiene una fecha de nacimiento específica. En 2019, el artículo “Passage Re-ranking with BERT” utilizó a BERT como clasificador binario para pares de consultas y pasajes, mejorando el MRR@10 en un 27 por ciento con respecto al mejor resultado disponible en ese momento. Fue entonces cuando la segunda etapa dejó de ser una fase de optimización para convertirse en una capa independiente.

La implementación comercial más conocida hoy en día es el reordenador estrella de Cohere. A lo largo de las versiones, lo que más cambió fue un parámetro: la ventana de entrada pasó de unos pocos cientos de tokens a más de 32,000, deteniéndose en 4,096 para las versiones v3 y v3.5. Se trata de un verdadero cambio de diseño, ya que aumenta el tamaño de los fragmentos que pueden evaluarse sin truncación, lo que permite un procesamiento menos agresivo y se pierde menos contexto.

Los proveedores hablan menos sobre lo que vendrá después. Los precios cotizados para el mismo modelo varían diez veces o más según las fuentes externas, desde una fracción de centavo hasta dos dólares y medio por mil búsquedas, dependiendo de quién haga el cálculo y qué incluya en una “búsqueda”.

Se aplica una regla sencilla: si no puedes reproducir la aritmética del proveedor con tu propio tráfico, no tienes un cálculo, solo una suposición. También existe una trampa en la facturación: los documentos más largos que el límite establecido se dividen en partes, y cada parte se factura por separado, por lo que una sola solicitud lógica de reclasificación puede convertirse en varias facturaciones.

La forma que hay que recordar es esta: recuperar datos de forma económica a gran escala, realizar un reclasificación costosa con un conjunto reducido de resultados, y permitir que el LLM vea solo aquello que sobrevive a ambos procesos. Parece una opción segura por defecto, pero existe un umbral más allá del cual deja de funcionar, en una dirección que casi nadie espera.

Hitos fantasma y el punto en el que la reclasificación comienza a perjudicar

La opinión convencional sostiene que cuanto más candidatos se le den al sistema de reclasificación, más seguros estaremos. Dado que el modelo es más preciso que la búsqueda vectorial, con K de 500 o 1,000 seguramente no puede fallar. Esa intuición es incorrecta, y existen pruebas documentadas en contra de ella.

El artículo de 2024 “Drowning in Documents” (Jacob y colaboradores) señaló que a medida que K aumenta, la calidad del reordenador mejora, alcanza un pico y luego disminuye de manera notable. Cuando toda la colección se escaneó de forma ciega, el algoritmo BM25 simple logró superar a un codificador cruzado considerado el mejor disponible. Hay que tener en cuenta una advertencia: ese resultado proviene de escaneos ciegos en conjuntos de datos académicos y empresariales, y dice poco sobre un flujo de trabajo típico en el que K es, como máximo, de unos pocos cientos.

Este fallo tiene un nombre: “Phantom Hits”. El reordenador asigna con confianza su puntuación más alta a un documento que no tiene ninguna conexión con la consulta, ni léxica ni semántica.

Los autores proponen una posible fuente y se esfuerzan por calificarla como una hipótesis, no como una causa confirmada. Se refieren a la configuración de entrenamiento, a la que denominan sesgo de exposición. Los sistemas de reclasificación se entrenan de forma contrastiva con negativos difíciles, documentos que parecen ser la respuesta correcta pero que en realidad son erróneos en su contenido, por lo que el modelo se vuelve experto en diferencias microscópicas.

En la producción, esa pericia resulta contraproducente. Ante un negativo sencillo, simplemente ruido que apenas había visto durante el entrenamiento, el modelo no cuenta con ningún punto de referencia y comienza a adivinar. Un modelo entrenado para distinguir gemelos se queda indefenso cuando entra un desconocido.

El extremo opuesto es igualmente real y no anula al primero. Algunos análisis independientes sitúan el umbral mínimo de equilibrio para el reordenamiento en torno a recall@50 = 0,85. Por debajo de esa cifra no hay nada que valga la pena clasificar, ya que el documento correcto nunca llegó al conjunto de datos. Los umbrales exactos difieren entre fuentes debido a las diferencias en los corpus, y su origen es importante: blogs y experiencia práctica, no revisiones por pares. Úsalos como hipótesis para probar con tus propios datos y nunca como hechos establecidos.

Los dos hallazgos no entran en conflicto. Son los dos extremos de una misma ventana operativa. Por debajo del umbral de recall, el reordenamiento no tiene nada con qué trabajar. Por encima del umbral K, comienza a causar daños. El reordenamiento no representa una mejora monotónica, y asumir que siempre es mejor repetir el error de confiar ciegamente en los puntos de referencia de un proveedor, ya que ambos sustituyen la medición por creencias populares.

Dado que demasiados reordenamientos pueden ser perjudiciales y pocos pueden no ser suficientes, necesitamos una visión clara del límite de lo que esta capa puede corregir.

El límite de la recuperación y lo que realmente representa el 67 por ciento

Un reordenador es un editor, no un periodista. Puede reorganizar material ya recopilado, pero no puede crear algo que nadie haya aportado.

Ese principio, el límite de la recuperación, parece trivial hasta que se compara con la estadística más destacada de la industria. Anthropic describió en su informe sobre recuperación contextual un proceso de 2024 en el que la tasa de fallos en la recuperación de los 20 mejores resultados disminuyó del 5,7 al 1,9 por ciento, lo que representa una reducción del 67 por ciento.

Esa cifra se cita con frecuencia en apoyo de los reordenamientos. Sin embargo, al desglosarla por etapas, se cuenta otra historia, aunque no porque sea falsa.

El camino seguido fue el siguiente: los embeddings contextuales redujeron la tasa al 3,7 por ciento; al añadir BM25, esta bajó a 2,9 por ciento, y solo entonces el reordenamiento logró un 1,9 por ciento. Por lo tanto, el reordenamiento por sí solo cubre la última etapa, desde el 2,9 hasta el 1,9 por ciento. Ambos valores son válidos porque miden ámbitos diferentes: el 67 por ciento es el resultado de todo el conjunto de técnicas y no de una sola capa.

Esa distinción tiene una gran importancia operativa. Antes de presentar el “67 por ciento” en una revisión de arquitectura, tenga en cuenta que está prometiendo el efecto de cuatro cambios combinados, tres de los cuales se producen antes que el reordenamiento y son los responsables de la mayor parte de la mejora.

Los autores mismos señalan la limitación: la figura es un promedio de diferentes dominios, y la variación entre ellos es grande. Otra advertencia basada en las pruebas disponibles: cada número de calidad de los herramientas de reclasificación comercial es proporcionado por los propios vendedores, con sus propios conjuntos de datos y su propio proceso de recuperación inicial. No existe una evaluación independiente a nivel de mercado.

Ningún punto de referencia externo le indicará cómo se comporta la reclasificación en su sistema, por lo que debe probarla usted mismo.

Un cálculo que puede realizar el lunes por la mañana

Toda la complejidad de este tema se reduce a un procedimiento repetible. La razón por la que los equipos lo realizan tan raramente es la causa por la cual persiste el debate sobre si la reclasificación realmente ayuda.

Paso uno: mida el recall@50 y la precisión@5 en unas cien consultas de producción etiquetadas. Utilice sus propios registros y su propia combinación de términos e intenciones, no un punto de referencia público. Si el recall@50 está claramente por debajo de 0.85, solucione primero el problema de recuperación mediante fragmentación, búsqueda híbrida o embeddings, en lugar de añadir una segunda capa encima.

Paso dos: busque la firma característica. Un alto recall@50 combinado con una baja precisión@5 es precisamente el perfil para el cual existe el reordenamiento de resultados. El documento correcto está en el conjunto de resultados, pero ocupa una posición demasiado baja.

Paso tres: elija el modelo de forma deliberada. Una API alojada en la nube permite un inicio rápido y cero operaciones, pero sus datos salen de su infraestructura. Un reordenador autogestionado brinda control sobre los costos y la privacidad, pero implica el manejo de GPUs y mantenimiento. Se trata más bien de una decisión relacionada con el cumplimiento normativo y el presupuesto que de una cuestión de calidad del modelo.

Probarlo también es económico. El reordenamiento local cabe en unas doce líneas aproximadamente:

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-large", max_length=512)

def rerank(query, docs):
    pairs = [(query, d.page_content) for d in docs]   # pair: query + candidate
    scores = reranker.predict(pairs)                  # one logit per pair
    return sorted(zip(docs, scores), key=lambda x: x[1], reverse=True)

Tres errores aparecen con mayor frecuencia. Uno es inflar los valores de K “solo por seguridad”. Otro es volver a ordenar los resultados después de que el contexto se ha truncado, lo que hace que el modelo evalúe un prefijo en lugar del documento completo. El tercero es tratar las puntuaciones del codificador cruzado como umbrales absolutos que se comparan entre consultas, lo cual es especialmente problemático porque funciona en las pruebas pero falla en producción.

También hay uno menos obvio: la afirmación de que “el reordenador no ayuda” a veces se debe a un error numérico y no a una deficiencia en la arquitectura. Un caso documentado en la guía de migración de Sentence-Transformers involucraba una función sigmoide calculada en bfloat16 que se saturaba, lo que hacía que las puntuaciones más altas se acercaran entre sí y, de hecho, aleatorizaba su orden. Una vez que se utilizó float32 en lugar de bfloat16 para la activación, el ordenamiento volvió a ser normal, dejando de ser casi aleatorio.

Todo esto solo requiere mediciones, sin necesidad de cambios en la arquitectura.

Qué significa esto para el arquitecto

Volvamos a la posición 37. El documento que quedó atascado allí nunca fue un problema del modelo generador. Fue un problema de ordenamiento.

• Un codificador cruzado no es una representación mejor. Es una arquitectura separada que se activa después de la recuperación, la cual lee la consulta y el documento juntos y devuelve un veredicto en lugar de una representación. No hay mejora en la calidad de la representación que permita obtener lo que se logra al leer el par uno al lado del otro.
• El reclasificación debe realizarse en un solo lugar. La recuperación sigue siendo económica y amplia, mientras que la reclasificación sigue siendo costosa y limitada; la estructura de costos de esta secuencia es precisamente la idea central.
• Tener más candidatos no es una opción segura por defecto. Más allá de un cierto valor K, la calidad disminuye realmente, y la explicación radica en la forma en que se entrenan estos modelos.
• El techo es firme. Lo que la primera etapa no recuperó no puede ser recuperado por un sistema de reclasificación, sin importar lo que afirme el material promocional del proveedor.
• Tus datos son el punto de referencia. Una tarde dedicada a calcular el recall@50 y la precisión@5 en cien consultas etiquetadas pone fin a un debate que de lo contrario podría prolongarse durante semanas.

Muchos equipos consideran la reclasificación como algo estándar, algo que se añade a todo sistema RAG de la misma manera que se añade una caché. Eso es un hábito erróneo. La imagen más clara surge cuando se observan ambos umbrales juntos: un límite inferior por debajo del cual la capa no tiene nada que reparar, y un techo por encima del cual comienza a dañar los resultados. En resumen, la reclasificación es condicional, nunca automática.

Queda un vacío por llenar. En el material analizado aquí, no se presentaron métricas específicas para el polaco en el contexto de los sistemas de reclasificación, y cada cifra multilingüe es un promedio de docenas de idiomas. Para un corpus en polaco o cualquier idioma menos extendido, medir con datos propios no solo es recomendable: es la única opción.

Leer más

• Reclasificación en RAG: Codificadores cruzados frente a evaluadores basados en LLM y su latencia — Cómo un sistema de reclasificación en segunda etapa corrige el orden de los resultados en RAG, comparando codificadores cruzados con evaluadores basados en LLM, los costos de latencia, los modos de fallo y cómo evaluarlos.
• Recuperación contextual para RAG: Qué oculta la cifra del 67%, cuánto cuesta y cuándo falla — Cómo la ubicación de prefijos soluciona los fragmentos huérfanos, por qué el aumento del 67% se debe a tres intervenciones sucesivas, qué ahorra el caché de prompts y cuatro casos en los que la técnica no da resultados.
• Notas prácticas: Los límites de la búsqueda vectorial en RAG — Similitud coseno y — Guía práctica de Notas prácticas: Los límites de la búsqueda vectorial en RAG — Similitud coseno y el: contratos, verificaciones y espacios de código listos para usar para los equipos que implementan este patrón.
• Auditoría de la recuperación RAG para fragmentos obsoletos, desviaciones y contexto ruidoso — Un script de auditoría en Python para la recuperación RAG: consultas de referencia, control de relevancia mediante coseno, verificaciones de desviación Kolmogorov-Smirnov y eficiencia del contexto, además de cómo leer su informe.
• Cinco técnicas de reclasificación para RAG: de la recuperación rápida al contexto preciso — Por qué la recuperación en la primera etapa no encuentra respuestas y cómo solucionarlo: codificadores cruzados, RRF, Cohere Rerank, ColBERT y LLM como juez, además de un pipeline en capas para comenzar.
• Por qué la reclasificación es la solución más económica y efectiva en un pipeline RAG — Obtener 50 resultados y reclasificarlos a 5: cómo los codificadores cruzados mejoran el ranking en RAG, cuáles son las ventajas y el tiempo de respuesta, cuándo omitir este paso y qué herramienta de reclasificación utilizar.