Reranking efímero: por qué la recuperación no termina en el vector

Cuando un agente de BiVelio responde sobre los documentos de una empresa, lo primero que ocurre no es generación: es recuperación. Y la calidad de la respuesta está acotada por la calidad de los fragmentos que el agente llega a ver. Si el contexto es ruidoso o está mal ordenado, ningún modelo lo arregla después (Liu et al., 2023).

La intuición ingenua es que basta con buscar por similitud de embeddings. En la práctica, la búsqueda vectorial es excelente para recall —traer rápido un conjunto razonable de candidatos— y mediocre para precisión —ordenar esos candidatos por relevancia real. Por eso la recuperación seria se hace en dos etapas. Y la segunda, el reranking, es donde se gana la respuesta.

El problema que viven los desarrolladores

El primer reflejo cuando un RAG falla es subir el top_k: traer más fragmentos. Es una trampa. Con k pequeño te dejas fuera el documento correcto; con k grande inundas la ventana de contexto — y los modelos pierden la información que cae en el medio (Liu et al., 2023). Más contexto no es mejor contexto.

El segundo reflejo es confiar todo a los embeddings densos. Otra trampa: en evaluación zero‑shot sobre dominios nuevos, los recuperadores densos pueden rendir por debajo del viejo BM25 (Thakur et al., 2021). La similitud vectorial sola no generaliza tan bien como se cree.

¿La causa de fondo? Un cross‑encoder —el modelo que de verdad juzga la relevancia mirando la consulta y el documento juntos— es preciso pero costosísimo: hay que ejecutarlo una vez por cada par (consulta, documento). Reimers y Gurevych midieron que comparar exhaustivamente 10.000 frases con un cross‑encoder lleva unas 65 horas; con embeddings independientes, unos 5 segundos (Reimers & Gurevych, 2019). No puedes pasar el cross‑encoder por todo el corpus. Pero su precisión es justo lo que necesitas. La solución a esa tensión son dos etapas.

Recuperación en dos etapas

La primera etapa recupera, de forma aproximada, los $k$ fragmentos más afines a la consulta. Trabaja sobre embeddings densos (Karpukhin et al., 2020) y mide cercanía con similitud coseno:

Es barata y escala a millones de fragmentos, pero el embedding comprime cada documento en un único vector: pierde matices que solo se aprecian comparando la consulta y el documento palabra a palabra.

La segunda etapa —el reranker— reordena solo esos $k$ candidatos con un cross‑encoder que sí mira el par de forma conjunta (Nogueira & Cho, 2019). El salto de calidad es enorme: en el benchmark estándar MS MARCO, reordenar con BERT más que duplica el MRR@10 frente a BM25 (Nguyen et al., 2016; Nogueira & Cho, 2019).

El reranker asigna a cada candidato una puntuación $s_i$ y la convierte en una distribución sobre el conjunto recuperado:

Y el patrón generaliza: en BEIR, la combinación BM25 + cross‑encoder es la mejor de media frente a recuperación léxica o densa por separado, ganando en 16 de 18 dominios (Thakur et al., 2021). Cuando hay varias fuentes de recall (léxica y densa), se fusionan por rango con Reciprocal Rank Fusion antes de rerankear (Cormack et al., 2009).

El coste oculto del reranking

Si el reranking es tan bueno, ¿por qué no lo usa todo el mundo a tope? Por el coste. Un cross‑encoder ejecuta una pasada del modelo por cada par, así que reordenar es caro y lento. Las cifras de ColBERT lo dejan claro: reordenar los candidatos de una sola consulta con un cross‑encoder BERT‑large tarda unos 33 segundos; la interacción tardía de ColBERT logra calidad comparable en 61 milisegundos (Khattab & Zaharia, 2020).

La salida habitual es mantener un índice de reranking especializado y caliente de forma permanente — una GPU servida 24/7, o un índice multivector enorme (ColBERT necesitaba 154 GiB para MS MARCO, reducidos a 16–25 GiB solo con compresión (Santhanam et al., 2022)). El problema: ese índice es caro de mantener y la mayor parte del tiempo está ocioso, esperando consultas que llegan a ráfagas.

Reranking efímero

Nuestra apuesta —lo que internamente llamamos Turbovec— es invertir la ecuación: construir el índice de reranking bajo demanda, justo cuando llega la consulta, y descartarlo cuando termina.

async function retrieve(query: string, projectId: string) {
  // Etapa 1 — recall barato sobre el índice vectorial persistente
  const candidates = await vectorSearch(query, projectId, { k: 50 })
 
  // Etapa 2 — índice de reranking efímero, vive solo esta consulta
  const boost = await buildEphemeralIndex(candidates)
  const scored = await boost.rerank(query, candidates)
 
  return scored
    .sort((a, b) => b.score - a.score)
    .slice(0, 8) // solo lo mejor entra en la ventana del agente
}

El índice efímero no compite con el almacenamiento persistente: lo complementa. La búsqueda vectorial garantiza que el candidato correcto esté entre los 50; el reranker garantiza que llegue al top‑8 que el agente realmente lee. Y como el reranking se aplica solo a esos 50 candidatos —no a todo el corpus—, el coste escala con $k$ (controlable), no con $N$ (inabordable). Pagas precisión solo cuando hay una pregunta, no por tener una GPU encendida esperando.

Cómo se posiciona el panorama

El reranking se ha vuelto un commodity excelente, pero casi todas las opciones asumen un servicio o índice permanente:

Son piezas magníficas. Pero casi todas te piden algo encendido todo el rato: una API que tarifas por consulta, una GPU servida o un índice especializado que hay que mantener fresco. El reranking efímero por consulta no es el modelo para el que fueron diseñadas.

Cómo pensamos ser los mejores

No competimos por tener el cross‑encoder más grande: competimos por dar precisión de cross‑encoder sin pagar el coste de mantenerlo caliente. Ahí enfocamos la ventaja:

1. Coste proporcional al uso. Sin GPU ociosa: el índice de precisión existe solo durante la consulta. Pagas por preguntas, no por tiempo de espera.
2. Recall híbrido, precisión enfocada. Combinamos señales léxicas (Robertson & Zaragoza, 2009) y densas (Karpukhin et al., 2020), fusionadas por rango (Cormack et al., 2009), y solo entonces aplicamos el reranking — el patrón que la evidencia premia (Thakur et al., 2021).
3. Menos contexto, mejor ordenado. Entregamos al agente el top‑8, no el top‑50: atacamos directamente el "perdido en el medio" (Liu et al., 2023) en lugar de inundar la ventana.
4. Reranking con contexto de la operación. No reordenamos fragmentos a ciegas: lo combinamos con el grafo de conocimiento de la empresa, la idea que desarrollamos en El grafo como contexto ambiente.
5. Trazabilidad. Cada resultado reordenado conserva su origen y su puntuación: se puede auditar por qué un fragmento llegó al agente.

Nota: las cifras de este artículo provienen de la literatura citada (Reimers & Gurevych, Nogueira & Cho, Khattab & Zaharia, Santhanam et al., Thakur et al., Liu et al.) y describen el reranking en general. Son la motivación de nuestro diseño, no un benchmark cerrado de producto.

Referencias