Saltar al contenido principal
Zubnet AIAprenderWiki › Reclasificación
Herramientas

Reclasificación

También conocido como: Reranking, Re-ranking, Cross-Encoder Reranking
Una segunda pasada de puntuación en un pipeline de recuperación que reordena un conjunto inicial de documentos candidatos con un modelo de relevancia más preciso — y más caro. Una primera etapa rápida, como la búsqueda vectorial o por palabras clave, devuelve las primeras decenas de candidatos, y el reclasificador puntúa cada uno frente a la consulta para producir un orden final mejor.

Por qué importa

La recuperación de primera etapa está optimizada para la velocidad, no para la precisión, por lo que el mejor fragmento suele terminar en la posición 12 en vez de la 1 — y lo que queda arriba es lo que el LLM realmente ve en su prompt. La reclasificación compra una gran mejora de relevancia por un costo de latencia modesto, razón por la que se ha convertido en una etapa estándar de los sistemas RAG en producción.

En profundidad

La reclasificación existe porque la recuperación rápida y la recuperación precisa son problemas distintos. La primera etapa de un pipeline de RAG o búsqueda semántica debe examinar millones de fragmentos en milisegundos, por lo que depende de métodos aproximados: un modelo de Embedding bi-encoder convierte de forma independiente la consulta y cada documento en vectores, o BM25 puntúa la coincidencia de palabras clave sin comprender en absoluto el significado. Estos métodos suelen incluir el documento correcto en algún lugar de los 50 primeros, pero el orden dentro de esos 50 es ruidoso. Un reclasificador toma ese conjunto de candidatos y aplica un modelo que sería demasiado lento para ejecutarlo sobre todo el corpus — normalmente un cross-encoder que lee juntos la consulta y un documento —, y vuelve a ordenar la lista para que los fragmentos verdaderamente pertinentes suban a la cima. El top-k final, a menudo de apenas 3–10 fragmentos, es lo que se ensambla en el prompt.

Bi-encoders frente a cross-encoders

La diferencia de rendimiento entre las dos etapas procede de la arquitectura. Un bi-encoder produce un vector por texto: la consulta se convierte en embedding una vez, cada documento se convierte en embedding una vez (normalmente sin conexión y por adelantado), y la relevancia es solo la Similitud del coseno entre dos puntos. Esto es extremadamente rápido con índices aproximados de vecinos más cercanos, pero el modelo nunca ve juntos la consulta y el documento, por lo que no puede modelar cómo interactúan palabras específicas de uno con palabras específicas del otro. Un cross-encoder hace lo opuesto: la consulta y un único documento candidato se concatenan y pasan por un Transformer como una sola entrada, y el modelo produce directamente una puntuación de relevancia. Como cada token puede prestar atención a cada token de ambos textos, detecta matices — negación, restricciones exactas, formulaciones de varios saltos — que la similitud de embeddings suele pasar por alto.

La trampa es el costo. Puntuar 50 candidatos implica 50 pasadas hacia adelante distintas, y los pares no pueden precalcularse porque la consulta solo se conoce en el momento de la solicitud. Por eso los cross-encoders nunca se ejecutan sobre un corpus completo de millones de documentos y por eso existe en primer lugar la división en dos etapas: el trabajo del bi-encoder es el recall (introducir los documentos correctos en el conjunto de candidatos) y el del cross-encoder es la precisión (ponerlos en el orden correcto).

Reclasificadores en la práctica

Hay dos maneras comunes de añadir un reclasificador. Las API alojadas como Rerank de Cohere y el endpoint de reclasificación de Voyage AI reciben una consulta más una lista de documentos en una sola solicitud y devuelven puntuaciones — sin infraestructura que ejecutar, pero con una llamada de red adicional y precio por solicitud. Los modelos de pesos abiertos, encabezados por la familia bge-reranker de BAAI y los reclasificadores de Jina AI, están disponibles en Hugging Face y pueden ejecutarse en una sola GPU o incluso en una CPU para conjuntos pequeños de candidatos, lo cual mantiene los datos dentro de la organización y hace predecibles los costos.

El patrón de integración es el mismo en ambos casos: recupera un conjunto generoso de candidatos (los primeros 20–100, a menudo mediante búsqueda híbrida sobre una Base de datos vectorial más BM25), reclasifícalo, conserva los primeros 3–10 y descarta el resto. Algunos equipos omiten por completo el modelo dedicado y piden a un Modelo de lenguaje grande que clasifique los candidatos zero-shot; funciona, y los reclasificadores LLM por listas pueden ser sólidos, pero un cross-encoder especializado suele ser entre uno y dos órdenes de magnitud más barato por consulta.

No puede arreglar una mala recuperación

Una idea equivocada común es que añadir un reclasificador rescatará un pipeline de búsqueda débil. No puede hacerlo, porque la reclasificación solo reordena lo que la primera etapa ya devolvió: si el fragmento pertinente nunca entró en el conjunto de candidatos, el reclasificador no lo ve y ninguna puntuación precisa podrá recuperarlo. La primera etapa impone un techo rígido de recall a todo lo posterior. Esto tiene una consecuencia práctica para la depuración: cuando la calidad de recuperación de extremo a extremo es mala, mide las etapas por separado. Comprueba si el fragmento correcto aparece en algún lugar de los 50 primeros (un problema de recuperación — corrige los embeddings, la fragmentación o añade búsqueda híbrida) o si aparece pero está demasiado abajo (un problema de reclasificación). Los equipos que omiten esta distinción suelen pasar semanas ajustando un reclasificador para obtener mejoras que la primera etapa ya había limitado.

El presupuesto de latencia

La reclasificación es un intercambio: mejor orden a cambio de Latencia y costo adicionales. Un cross-encoder autoalojado que puntúa 50 pares consulta-documento suele añadir del orden de decenas a unos cientos de milisegundos según el tamaño del modelo y la longitud de los documentos; una API alojada añade además un viaje de ida y vuelta por la red. Los controles son sencillos: reclasificar menos candidatos (los primeros 20 en vez de 100), truncar los documentos antes de puntuarlos, usar un modelo más pequeño o guardar en caché las puntuaciones de consultas repetidas.

Que el intercambio valga la pena depende de la aplicación. Para un asistente orientado al usuario cuyas respuestas ya tardan segundos en generarse, 100–300 ms adicionales suelen ser invisibles, y la mejora de relevancia reduce directamente la Alucinación causada por contexto ajeno al tema. Para la búsqueda de estilo autocompletado o servicios internos con gran QPS, los equipos suelen reservar la reclasificación para consultas que parecen difíciles — largas, ambiguas o con baja confianza en la primera etapa — y dejan pasar directamente las fáciles. El valor predeterminado pragmático en sistemas de recuperación en producción es: reclasifica siempre, a menos que puedas demostrar que no puedes permitírtelo.

← Todos los términos
ESC