Módulo 4: Re-ranking — la segunda etapa que transforma retrieval mediocre en excelente

Módulo 4: Re-ranking — la segunda etapa que transforma retrieval mediocre en excelente

Siguiente →

Descripción del módulo

Hasta este punto, todas las técnicas que cubrimos manipulan la query (M03: optimization), los documentos (M02: chunking), o la métrica de búsqueda. Re-ranking es estructuralmente distinto: agrega una segunda etapa de scoring después del retrieval inicial. La idea es simple pero poderosa: el retrieval con cosine similarity es rápido pero ruidoso. En vez de pelear contra esa limitación, aceptamos su naturaleza y agregamos un segundo paso que refina los candidatos con un modelo más preciso.

                    Query
                      │
                      ▼
    ┌──────────────────────────────────┐
    │ Etapa 1: retrieval con cosine    │
    │ Top-30 candidatos (rápido pero   │
    │ con ruido — algunos irrelevantes)│
    └─────────────┬────────────────────┘
                  │
                  ▼
    ┌──────────────────────────────────┐
    │ Etapa 2: re-ranking              │
    │ Re-evaluar cada par (query, doc) │
    │ con modelo más sofisticado       │
    └─────────────┬────────────────────┘
                  │
                  ▼
              Top-5 finales
              (alta precision)

Esta arquitectura de dos etapas — bi-encoder rápido + cross-encoder preciso — es el patrón "estado del arte" en RAG production. Mejora típica: precision sube 15-25 puntos. Esta cápsula introduce el módulo, los tres tipos de re-ranker que vas a comparar (cross-encoder local, LLM-based, Cohere managed), y cómo decidir cuál usar.

Al finalizar este módulo serás capaz de:

  • ✅ Explicar por qué cosine similarity tiene un límite intrínseco que justifica re-ranking
  • ✅ Implementar las tres técnicas principales: cross-encoder local, LLM-based, Cohere Rerank
  • ✅ Optimizar trade-offs operativos (n_results, batching, caching)
  • ✅ Aplicar un decision framework para elegir la técnica correcta según contexto
  • ✅ Construir un sistema de re-ranking production-ready con A/B testing y métricas

Tiempo estimado del módulo: 3-4 horas (8 cápsulas).

Por qué re-ranking es la mejora con mejor ROI

Si tu sistema RAG está en producción y la calidad necesita mejorar, re-ranking suele ser la primera intervención con mejor ratio mejora/esfuerzo. Comparado con otras opciones:

TécnicaMejora típica precisionEsfuerzo ingenieríaCosto recurrente
Cambiar de modelo de embeddings (small → large)+3-5%1 día + re-ingestEmbeddings más caros
Mejorar chunking+5-10%2-3 días + re-ingest$0
Query optimization+5-15% (varía)1-2 semanas$20-200/mes
Re-ranking (cross-encoder)+15-25%1 día$0
Hybrid search+5-15%1-2 semanas + re-index$0

Re-ranking típicamente da más mejora con menos esfuerzo. Por eso es la segunda intervención más común después de chunking razonable. La razón es estructural: cosine similarity tiene un techo inherente, y agregar una segunda etapa de scoring rompe ese techo.

El problema concreto: cosine similarity tiene techo

Imagina esta query y los top-5 que devuelve cosine similarity:

Query: "¿cómo implemento autenticación OAuth2 en FastAPI?"

Top-5 con cosine:

#1  cosine: 0.85  "FastAPI OAuth2 implementation guide"
                  ✅ Relevante: específico sobre la query

#2  cosine: 0.83  "OAuth2 authentication overview"
                  ❌ Irrelevante: genérico, no menciona FastAPI

#3  cosine: 0.82  "FastAPI security dependencies"
                  ✅ Relevante: cubre OAuth2 dentro de security

#4  cosine: 0.80  "OAuth2 specification (RFC 6749)"
                  ❌ Irrelevante: spec teórica, no implementación

#5  cosine: 0.79  "FastAPI authentication tutorial"
                  ✅ Relevante: implementation-focused

Precision@5: 3/5 = 60%

Los scores de cosine son todos similares (0.79-0.85). La métrica no diferencia "FastAPI específico" de "OAuth2 genérico" — ambos hablan del tema, ambos rankean alto.

Re-ranking con cross-encoder:

Top-5 después del rerank (sobre top-30 candidatos):

#1  score: 9.2   "FastAPI OAuth2 implementation guide"        ✅
#2  score: 8.8   "FastAPI security dependencies"               ✅
#3  score: 8.5   "FastAPI authentication tutorial"             ✅
#4  score: 8.1   "OAuth2 with FastAPI code examples"           ✅
#5  score: 7.4   "Securing FastAPI endpoints with OAuth2"      ✅

Precision@5: 5/5 = 100%

El cross-encoder analiza el par (query, doc) como una unidad. Detecta que "específico de FastAPI" responde la query, "genérico de OAuth2" no. Score absoluto refleja relevancia real.

Resultado: los falsos positivos (docs sobre OAuth2 genérico, RFC) se filtran. El LLM downstream recibe contexto enfocado.

Las tres técnicas que vas a aprender

Técnica 1: cross-encoder local (default razonable)

from sentence_transformers import CrossEncoder
model = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-12-v2')
scores = model.predict([(query, doc) for doc in candidates])
  • ✅ Gratis (corre local)
  • ✅ Latencia ~150ms para 20 candidatos
  • ✅ Calidad +20% precision típica
  • ❌ Multilingual subóptimo (modelo entrenado en inglés)

Cuándo: producción típica con corpus monolingüe inglés. Es la opción default que cubre 80% de los casos.

Cápsula 03 lo cubre en detalle.

Técnica 2: LLM-based (calidad máxima, costoso)

score = llm_rerank_pair(query, document)  # GPT-4o-mini scorea 0-10
  • ✅ Calidad +24% precision típica
  • ❌ Latencia +1500ms para 20 candidatos
  • ❌ Costo +$0.002/query
  • ✅ Multilingual excelente

Cuándo: dominios críticos (legal, médico, financiero) donde 3-5% extra de precision justifica el costo.

Cápsula 04 lo cubre.

Técnica 3: Cohere Rerank (managed, intermedio)

import cohere
co = cohere.Client(api_key)
results = co.rerank(query=query, documents=docs, top_n=5)
  • ✅ Calidad +21% precision típica
  • ✅ Latencia ~250ms
  • ⚠️ Costo ~$0.002 por 1K docs
  • ✅ Multilingual excelente

Cuándo: equipos sin MLE para mantener cross-encoder local, o corpus multilingüe.

Cápsula 05 lo cubre.

Mapa del módulo

CápsulaTemaTiempo
01 (estás acá)Introducción al módulo10-15 min
02Por qué cosine similarity tiene techo30 min
03Cross-encoder re-ranking (default)30 min
04LLM-based re-ranking (premium)30 min
05Cohere Rerank API (managed)25 min
06Trade-offs y optimizaciones operativas25 min
07Decision framework — qué técnica elegir30 min
08Proyecto integrador — sistema de re-ranking45 min

Total estimado: 3-4 horas. Es uno de los módulos con mejor ROI del path.

Conexión con módulos previos y siguientes

Módulos previos:
  ├─ M01: RAG Pipeline → re-ranking se inserta después del retrieval inicial
  ├─ M02: Chunking → mejor chunking + re-ranking se complementan
  └─ M03: Query Optimization → query optimization mejora retrieval; re-ranking refina output

Este módulo prepara para:
  ├─ M05: Hybrid Search → hybrid search + re-ranking es el patrón "estado del arte"
  ├─ M06: Metadata Filtering → re-ranking se aplica después del filtering
  ├─ M07: Production con Pinecone → Pinecone tiene rerank nativo
  └─ M08: Evaluation → cómo medir si rerank mejora vs solo agrega complejidad

Patrón "estado del arte" en RAG production (mayo 2026):

Query
  ↓
Query optimization (M03)
  ↓
Hybrid search (M05) — BM25 + cosine
  ↓
Metadata filter (M06)
  ↓
Re-ranking (este módulo)
  ↓
LLM generation

Este módulo es uno de los tres pilares (junto con chunking y hybrid search) que separan un RAG "MVP" de un RAG "production-ready".

Mejora acumulativa esperada

Si pasas por todos los módulos del path, la calidad del sistema mejora cumulativamente:

Punto de partida (sistema "MVP"):
  Cosine + recursive chunk + sin optimization = ~68% precision@5

Después de M02 (chunking optimizado):           +5-10 pts → 73-78%
Después de M03 (query optimization):            +5-10 pts → 78-88%
Después de M04 (re-ranking) ← ESTÁS ACÁ:        +15-25 pts → 88-95%
Después de M05 (hybrid search):                 +3-8 pts → 91-95%
Después de M06 (metadata filter):               +2-5 pts → 93-97%

Re-ranking solo es responsable de la mayor parte de la mejora. Por eso muchos equipos lo agregan primero, antes de invertir en optimizaciones más complejas.

Casos concretos: cuándo cada técnica gana

Para anclar las decisiones que vas a tomar al final del módulo, tres ejemplos:

Caso A: chatbot de soporte interno, 200K docs, equipo de 3

  • Restricciones: corpus inglés, sin MLE dedicado, latencia <500ms.
  • Recomendación esperada: Cohere Rerank ($5-15/mes, 0 maintenance, calidad cercana a LLM).
  • Por qué no cross-encoder: sin MLE, mantener modelos local agrega overhead operacional.
  • Por qué no LLM: $200/mes para chatbot interno no se justifica vs Cohere a $15.

Caso B: asistente jurídico SaaS LATAM, 500K casos multilingües

  • Restricciones: español + portugués + inglés, precision crítica, presupuesto generoso.
  • Recomendación esperada: cascada cross-encoder + LLM para queries marcadas "high stakes".
  • Por qué cascada: cross-encoder filtra rápido (multilingual model), LLM refina los top-15 con calidad máxima.
  • Por qué no Cohere solo: dominio crítico justifica el costo extra del LLM.

Caso C: buscador interno Stack Overflow para startup

  • Restricciones: 10M docs (gran escala), volumen alto, presupuesto limitado.
  • Recomendación esperada: cross-encoder local (gratis a escala).
  • Por qué no Cohere: $30/mes es manejable, pero crece con volumen. Cross-encoder fijo en costo de infra.
  • Por qué no LLM: prohibitivo a 10M docs / 50K queries diarias.

Estos tres casos cubren los patrones típicos. El módulo te enseña a derivar la decisión correcta para tu caso específico.

Pre-requisitos antes de empezar el módulo

Asegúrate de tener:

  • ✅ Pipeline RAG funcional con cosine retrieval (cubierto en M01)
  • ✅ Chunking razonable (recursive con chunk_size=500, overlap=50 mínimo) — M02
  • ✅ Eval set propio con al menos 30 queries y ground truth — para validar mejora
  • ✅ Acceso a OpenAI API (para cápsula 04 de LLM rerank)
  • ✅ Cuenta Cohere (gratis trial disponible) — para cápsula 05

Si te falta el eval set, constrúyelo antes de empezar el módulo. Sin él, los benchmarks que vas a hacer en cada cápsula son ciegos.

Setup técnico para el módulo

# Cápsulas 03 (cross-encoder local)
pip install sentence-transformers

# Cápsula 04 (LLM-based)
pip install openai pydantic

# Cápsula 05 (Cohere)
pip install cohere

Variables de entorno:

# .env
OPENAI_API_KEY=sk-...
COHERE_API_KEY=...

Auto-verificación antes de avanzar

Antes de empezar la cápsula 02, asegúrate de poder responder:

  1. ¿Por qué re-ranking típicamente da más mejora con menos esfuerzo que otras técnicas?
  2. ¿Cuál es la diferencia estructural entre bi-encoder (cosine) y cross-encoder (rerank)?
  3. ¿Cuándo NO necesitarías re-ranking en tu sistema RAG?
Respuestas

  1. Porque cosine similarity tiene un techo inherente (mide overlap semántico, no relevancia real). Agregar una segunda etapa de scoring rompe ese techo. La mejora viene de la arquitectura (dos etapas), no de optimización marginal de un componente. Esfuerzo bajo: agregar una librería + 30 líneas de código. Beneficio alto: 15-25 puntos de precision.

  2. Bi-encoder (cosine) procesa query y documento independientemente, produciendo dos vectores que luego se comparan con cosine similarity. Rápido pero superficial. Cross-encoder (rerank) procesa el par (query, doc) juntos, atendiendo a interacciones token-a-token. Más lento pero captura la relación que el bi-encoder no puede ver.

  3. MVP con dataset chico (<10K docs): cosine alcanza, los falsos positivos no se acumulan. Sistema con SLA estricto (<200ms total): la latencia extra del rerank rompe el SLA. Cuando precision actual ya es >92% sobre eval set: la mejora marginal no justifica el costo extra. Cuando los falsos positivos no impactan al usuario (ej: el LLM downstream es lo suficientemente robusto para ignorarlos).

Próximo paso: Cápsula 02

La siguiente cápsula entra en el "por qué" detallado de los modos de falla de cosine similarity. Sin entender esos modos concretamente, las técnicas de re-ranking suenan a optimización innecesaria. Con ellos entendidos, el resto del módulo se vuelve obviamente útil.

Recursos

  1. Sentence Transformers — Cross-Encoders — Documentación oficial
  2. Pinecone — Re-ranking Guide — Tutorial visual
  3. Cohere Rerank Documentation — Para cápsula 05
  4. BEIR Benchmark — Comparaciones empíricas
  5. Anthropic — Contextual Retrieval — Técnica complementaria
  6. Khattab & Zaharia — ColBERT Paper — Late interaction como evolución del cross-encoder

Tiempo estimado: 10-15 minutos Siguiente: 02-problems-with-cosine-similarity.md

← AnteriorProyecto: Query Optimizer SystemSiguiente →Cápsula 02: Cosine similarity es buena, no perfecta — el límite que justifica re-ranking