Riordinamento dei chunk recuperati

Il retrieval di prima fase (denso o sparso) ottimizza il recall su larga scala: trovare il chunk di riferimento da qualche parte nei primi 50. È veloce, ma grossolano. Un re-ranker di seconda fase riordina quindi quella rosa di candidati per la precisione, portando in cima i chunk realmente rilevanti.

Questo pattern, che consiste nel recuperare in modo ampio e poi eseguire un re-ranking preciso, è la struttura portante del RAG avanzato.

Un bi-encoder codifica query e documento separatamente in vettori e li confronta tramite il coseno: è veloce e indicizzabile, ma perde l'interazione tra query e documento. Un cross-encoder passa invece query e candidato insieme attraverso il modello e restituisce un punteggio di rilevanza, cogliendo le interazioni a grana fine.

I cross-encoder sono molto più accurati, ma non possono essere precalcolati, quindi vengono eseguiti solo sulla rosa di candidati.

Il re-ranker assegna un punteggio a ogni candidato rispetto alla query, quindi li ordina in senso decrescente. Poiché il cross-encoder presta attenzione congiuntamente a query e documento, risolve aspetti sottili della rilevanza che il bi-encoder non coglie: negazioni, esigenze di corrispondenza esatta e distinzione tra risposta e argomento.

Questa fase aumenta in genere l'accuratezza delle risposte più di qualsiasi altro singolo miglioramento del RAG.

Quando nessun cross-encoder addestrato è adatto al proprio dominio, è possibile usare un LLM per il re-ranking. Il prompting listwise chiede al modello di ordinare un elenco di passaggi in base alla rilevanza con un'unica chiamata; quello pointwise assegna un punteggio a ogni passaggio in modo indipendente.

Il listwise coglie i confronti relativi ed è efficiente in termini di token, ma presti attenzione al bias di posizione e si assicuri che l'analisi dell'output sia robusta rispetto all'omissione o alla duplicazione degli ID da parte del modello.

Il costo del re-ranking cresce con la dimensione della rosa di candidati. Applicare un cross-encoder a 50 candidati è molto meno costoso che applicarlo a 500. Scelga un k della prima fase abbastanza grande da includere il chunk di riferimento (convalidi il recall@k), ma abbastanza piccolo da consentire il re-ranking entro il budget di latenza.

Raggruppi i punteggi delle coppie in batch ed esegua l'operazione su hardware accelerato; i cross-encoder si parallelizzano bene tra le coppie.

Il recall più elevato si ottiene con una prima fase ibrida (recupero denso e BM25 fusi), che alimenta una singola lista ristretta deduplicata per il reranker. Il recupero denso individua le parafrasi; quello sparso recupera gli identificatori esatti; il cross-encoder ordina quindi l'unione in base alla rilevanza effettiva.

Questa combinazione è robusta con diversi tipi di query, dalle domande in linguaggio naturale alle ricerche di corrispondenze letterali.

I punteggi del reranker possono essere calibrati. Invece di selezionare sempre i primi n risultati, applicare una soglia di rilevanza: mantenere i chunk che superano un determinato punteggio e, se nessuno la supera, restituire esplicitamente l'assenza di una risposta. In questo modo si evita di riempire il prompt con contenuti debolmente pertinenti.

Regolare la soglia su un set di validazione per bilanciare la copertura delle domande a cui è possibile rispondere e l'inclusione di elementi fuorvianti.

Un ordinamento basato esclusivamente sulla rilevanza può restituire diversi chunk quasi duplicati dello stesso documento, sprecando il budget di contesto. Applicare MMR o limiti per documento dopo il reranking, così da garantire che il set finale copra aspetti e fonti distinti.

Questo è importante per le domande multi-hop, la cui risposta si estende su diversi documenti.

Dopo aver selezionato i chunk migliori, posizionarli in modo da sfruttare l'attenzione. Considerato l'effetto della perdita nel mezzo, collocare il singolo chunk con il punteggio più alto all'inizio o alla fine del contesto, senza seppellirlo tra gli altri.

Alcune pipeline ordinano i chunk in base alla rilevanza crescente, così che il migliore si trovi più vicino alla domanda, rispecchiando la strategia di recency dei prompt few-shot.

Misurare il reranker con metriche di ranking, principalmente NDCG e MRR, sulla rilevanza etichettata tra query e chunk, e successivamente con l'accuratezza della risposta. Un reranker che migliora l'NDCG ma non le risposte potrebbe limitarsi a riordinare chunk che il generatore gestiva già correttamente.

Chiudere sempre il ciclo valutando la qualità del compito finale, non soltanto le metriche di ranking.

Dall'inizio alla fine: recuperare 50 candidati con un approccio ibrido, deduplicare, applicare il reranking con un cross-encoder, applicare una soglia di punteggio, diversificare per documento, ordinare i chunk in base all'attenzione e generare la risposta con le citazioni. Utilizzare la soglia come condizione per restituire esplicitamente l'assenza di una risposta.

Memorizzare nella cache gli embedding e i punteggi del reranker per ogni coppia (query, chunk) quando il traffico ripete le stesse richieste, così da ridurre i costi.

Scegliere l'architettura di reranking corretta.

Punti chiave:

• Recuperare ampiamente per ottenere recall, quindi applicare il reranking alla lista ristretta per ottenere precisione.
• I cross-encoder valutano congiuntamente le coppie query-documento (accurati, ma non indicizzabili); i bi-encoder sono veloci, ma approssimativi.
• Il reranking listwise/pointwise con LLM è un'opzione di ripiego; prestare attenzione al bias di posizione e al parsing.
• Regolare la dimensione della lista ristretta fino a saturare il recall entro il budget di latenza; combinarla con il recupero ibrido nella prima fase.
• Applicare soglie di punteggio, diversificare per documento, ordinare i chunk in base all'attenzione e valutare con NDCG e accuratezza della risposta a valle.