Reranking efímer: per què la recuperació no acaba al vector

Quan un agent de BiVelio respon sobre els documents d'una empresa, el primer que passa no és generació: és recuperació. I la qualitat de la resposta està acotada per la qualitat dels fragments que l'agent arriba a veure. Si el context és sorollós o mal ordenat, cap model ho arregla després (Liu et al., 2023).

La intuïció ingènua és que n'hi ha prou amb buscar per similitud d'embeddings. A la pràctica, la cerca vectorial és excel·lent per al recall —portar ràpid un conjunt raonable de candidats— i mediocre per a la precisió —ordenar aquests candidats per rellevància real. Per això la recuperació seriosa es fa en dues etapes. I la segona, el reranking, és on es guanya la resposta.

El problema que viuen els desenvolupadors

El primer reflex quan un RAG falla és apujar el top_k: portar més fragments. És una trampa. Amb k petit et deixes fora el document correcte; amb k gran inundes la finestra de context — i els models perden la informació que cau al mig (Liu et al., 2023). Més context no és millor context.

El segon reflex és confiar-ho tot als embeddings densos. Una altra trampa: en avaluació zero‑shot sobre dominis nous, els recuperadors densos poden rendir per sota del vell BM25 (Thakur et al., 2021). La similitud vectorial sola no generalitza tan bé com es creu.

La causa de fons? Un cross‑encoder —el model que de debò jutja la rellevància mirant la consulta i el document junts— és precís però costosíssim: cal executar‑lo una vegada per cada parell (consulta, document). Reimers i Gurevych van mesurar que comparar exhaustivament 10.000 frases amb un cross‑encoder triga unes 65 hores; amb embeddings independents, uns 5 segons (Reimers & Gurevych, 2019). No pots passar el cross‑encoder per tot el corpus. Però la seva precisió és justament el que necessites. La solució a aquesta tensió són dues etapes.

Recuperació en dues etapes

La primera etapa recupera, de manera aproximada, els $k$ fragments més afins a la consulta. Treballa sobre embeddings densos (Karpukhin et al., 2020) i mesura proximitat amb similitud cosinus:

És barata i escala a milions de fragments, però l'embedding comprimeix cada document en un únic vector: perd matisos que només s'aprecien comparant la consulta i el document paraula a paraula.

La segona etapa —el reranker— reordena només aquests $k$ candidats amb un cross‑encoder que sí que mira el parell de manera conjunta (Nogueira & Cho, 2019). El salt de qualitat és enorme: al benchmark estàndard MS MARCO, reordenar amb BERT més que duplica el MRR@10 enfront de BM25 (Nguyen et al., 2016; Nogueira & Cho, 2019).

El reranker assigna a cada candidat una puntuació $s_i$ i la converteix en una distribució sobre el conjunt recuperat:

I el patró generalitza: a BEIR, la combinació BM25 + cross‑encoder és la millor de mitjana enfront de recuperació lèxica o densa per separat, guanyant en 16 de 18 dominis (Thakur et al., 2021). Quan hi ha diverses fonts de recall (lèxica i densa), es fusionen per rang amb Reciprocal Rank Fusion abans de rerankejar (Cormack et al., 2009).

El cost ocult del reranking

Si el reranking és tan bo, per què no l'usa tothom a fons? Pel cost. Un cross‑encoder executa una passada del model per cada parell, així que reordenar és car i lent. Les xifres de ColBERT ho deixen clar: reordenar els candidats d'una sola consulta amb un cross‑encoder BERT‑large triga uns 33 segons; la interacció tardana de ColBERT aconsegueix qualitat comparable en 61 mil·lisegons (Khattab & Zaharia, 2020).

La sortida habitual és mantenir un índex de reranking especialitzat i calent de manera permanent — una GPU servida 24/7, o un índex multivector enorme (ColBERT necessitava 154 GiB per a MS MARCO, reduïts a 16–25 GiB només amb compressió (Santhanam et al., 2022)). El problema: aquest índex és car de mantenir i la major part del temps està ociós, esperant consultes que arriben a ràfegues.

Reranking efímer

La nostra aposta —el que internament anomenem Turbovec— és invertir l'equació: construir l'índex de reranking sota demanda, just quan arriba la consulta, i descartar‑lo quan acaba.

async function retrieve(query: string, projectId: string) {
  // Etapa 1 — recall barat sobre l'índex vectorial persistent
  const candidates = await vectorSearch(query, projectId, { k: 50 })
 
  // Etapa 2 — índex de reranking efímer, viu només aquesta 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) // només el millor entra a la finestra de l'agent
}

L'índex efímer no competeix amb l'emmagatzematge persistent: el complementa. La cerca vectorial garanteix que el candidat correcte estigui entre els 50; el reranker garanteix que arribi al top‑8 que l'agent realment llegeix. I com que el reranking s'aplica només a aquests 50 candidats —no a tot el corpus—, el cost escala amb $k$ (controlable), no amb $N$ (inabordable). Pagues precisió només quan hi ha una pregunta, no per tenir una GPU encesa esperant.

Com es posiciona el panorama

El reranking s'ha tornat un commodity excel·lent, però gairebé totes les opcions assumeixen un servei o índex permanent:

Són peces magnífiques. Però gairebé totes et demanen alguna cosa encesa tota l'estona: una API que tarifes per consulta, una GPU servida o un índex especialitzat que cal mantenir fresc. El reranking efímer per consulta no és el model per al qual van ser dissenyades.

Com pensem ser els millors

No competim per tenir el cross‑encoder més gran: competim per donar precisió de cross‑encoder sense pagar el cost de mantenir‑lo calent. Allà enfoquem l'avantatge:

1. Cost proporcional a l'ús. Sense GPU ociosa: l'índex de precisió existeix només durant la consulta. Pagues per preguntes, no per temps d'espera.
2. Recall híbrid, precisió enfocada. Combinem senyals lèxics (Robertson & Zaragoza, 2009) i densos (Karpukhin et al., 2020), fusionats per rang (Cormack et al., 2009), i només llavors apliquem el reranking — el patró que l'evidència premia (Thakur et al., 2021).
3. Menys context, més ben ordenat. Lliurem a l'agent el top‑8, no el top‑50: ataquem directament el "perdut al mig" (Liu et al., 2023) en lloc d'inundar la finestra.
4. Reranking amb context de l'operació. No reordenem fragments a cegues: ho combinem amb el graf de coneixement de l'empresa, la idea que desenvolupem a El graf com a context ambient.
5. Traçabilitat. Cada resultat reordenat conserva el seu origen i la seva puntuació: es pot auditar per què un fragment va arribar a l'agent.

Nota: les xifres d'aquest article provenen de la literatura citada (Reimers & Gurevych, Nogueira & Cho, Khattab & Zaharia, Santhanam et al., Thakur et al., Liu et al.) i descriuen el reranking en general. Són la motivació del nostre disseny, no un benchmark tancat de producte.

Referències