Riordinamento
Il riordinamento è la seconda fase di una pipeline di recupero: come i bi-encoder e i cross-encoder riordinano i risultati recuperati in base alla rilevanza prima che vengano serviti o passati a un LLM, e cosa questo significa per la visibilità nella ricerca AI.
Lingue
Il riordinamento è la seconda fase di una pipeline di recupero: una prima passata economica e ampia recupera un insieme di candidati di documenti o passaggi, poi un modello più lento e preciso ri-valuta e riordina quella shortlist prima che i risultati vengano serviti o passati a un LLM. Il meccanismo principale è bi-encoder vs cross-encoder: un bi-encoder codifica la query e il documento separatamente in vettori e li confronta (veloce, scalabile, meno preciso), mentre un cross-encoder li codifica insieme e valuta la coppia direttamente (più lento, più accurato). Non puoi valutare un intero corpus di miliardi di pagine con il modello costoso, quindi recuperi ampiamente e riordini la shortlist. Google non usa pubblicamente la parola 'riordinamento', ma i suoi sistemi BERT e di ranking dei passaggi fanno il lavoro, e Microsoft documenta un riordinatore esplicito derivato da Bing in Azure AI Search. Il riordinamento non è la stessa cosa della fusione del rango reciproco. La conseguenza per la SEO: poiché i riordinatori valutano le coppie query-passaggio congiuntamente, i passaggi autocontenuti e non ambigui che si leggono come una risposta diretta ottengono punteggi migliori.
TL;DR — Il reranking è un secondo sguardo. Un sistema di ricerca o AI prima recupera rapidamente e in modo approssimativo un grande mucchio di pagine potenzialmente rilevanti, poi un modello più lento e intelligente ri-valuta quella shortlist e mette le migliori in cima — prima che tu veda i risultati o prima che un’AI scriva la sua risposta. Essere inclusi nella shortlist non basta; devi anche sopravvivere al riordino.
Cos’è il reranking
Il reranking applica una seconda fase di punteggio ai candidati prodotti da un recuperatore iniziale. Evidence for this claim A cross-encoder can score query-document pairs for reranking after an initial retrieval stage. Scope: Sentence-BERT evaluation and related retrieve-then-rerank use; cross-encoders are one reranking approach, not a universal implementation. Confidence: high · Verified: Reimers and Gurevych: Sentence-BERT I cross-encoder sono un approccio, non la definizione di ogni reranker. Evidence for this claim A rerank model can reorder an existing candidate list by relevance to a query. Scope: Cohere's Rerank product behavior; inputs, limits, and scoring semantics are vendor-specific. Confidence: high · Verified: Cohere: Rerank overview
Immagina di dover assumere qualcuno e di ricevere 500 curriculum. Non li leggi tutti e 500 con attenzione — non finiresti mai. Quindi fai prima una rapida scorsa, estrai i 20 che sembrano promettenti, e poi leggi attentamente quei 20 per classificarli. Questo processo in due fasi è esattamente come i moderni sistemi di ricerca e AI trovano contenuti rilevanti.
- Fase uno — recupero. Il sistema fa un passaggio veloce ed economico su un enorme indice e recupera un insieme di candidati di pagine o passaggi che sembrano rilevanti. Getta una rete ampia.
- Fase due — reranking. Un secondo modello, più lento e più accurato, guarda solo quella shortlist e ri-valuta ogni candidato per quanto bene risponde effettivamente alla query, poi li riordina.
Solo la parte superiore di quella lista riordinata viene mostrata a te, o viene passata a un’AI per scrivere una risposta. Quindi la shortlist decide chi è in gara, e il rerank decide chi vince.
Perché farlo in due fasi?
Perché la lettura attenta è costosa. Il modello preciso che giudica “quanto bene questa pagina esatta risponde a questa domanda esatta?” è troppo lento per essere eseguito su ogni pagina di un indice da un miliardo di pagine. Quindi i sistemi recuperano ampiamente con qualcosa di economico, poi spendono il modello costoso solo sulla piccola shortlist. Veloce e approssimativo per restringere, lento e preciso per finire.
Perché è importante per te
Essere recuperati nella shortlist è necessario ma non sufficiente. La tua pagina può essere nell’indice, essere inclusa nell’insieme dei candidati, e comunque non fare il taglio finale se il reranker decide che altri risultati rispondono meglio alla domanda.
Il punto pratico è uno che hai già sentito, ora con una ragione più chiara: scrivi passaggi che rispondono a una domanda specifica in modo chiaro, da soli. Il reranker guarda il tuo passaggio accanto alla query e valuta quanto bene i due corrispondono. Una sezione che si legge come una risposta diretta e autonoma ottiene un punteggio migliore di una che ha senso solo dopo aver letto tre paragrafi sopra.
Vuoi i meccanismi reali — bi-encoder vs cross-encoder, come fanno Google e Bing, dove si inserisce nella ricerca AI, e perché non è la stessa cosa del Reciprocal Rank Fusion? Passa alla scheda Avanzate.
Evidence for this claim A cross-encoder can score query-document pairs for reranking after an initial retrieval stage. Scope: Sentence-BERT evaluation and related retrieve-then-rerank use; cross-encoders are one reranking approach, not a universal implementation. Confidence: high · Verified: Reimers and Gurevych: Sentence-BERTTL;DR — Il reranking è la seconda fase di una pipeline di recupero a due fasi (o multi-fase): un passaggio di recupero economico e ampio (corrispondenza di parole chiave BM25, similarità di embedding/vettori, o entrambi) estrae un insieme di candidati, poi un modello più lento e più preciso ri-valuta e riordina quella shortlist. Il meccanismo centrale è bi-encoder vs cross-encoder — un bi-encoder codifica query e documento separatamente in vettori e li confronta (veloce, precomputabile, meno preciso); un cross-encoder li codifica insieme e produce un punteggio di rilevanza per coppia (più lento, non precomputabile, più accurato). Non puoi eseguire un cross-encoder su un intero corpus, quindi recuperi ampiamente e ri-ordini la shortlist. Google non dice “reranking” pubblicamente, ma BERT e il ranking dei passaggi fanno il lavoro; Microsoft documenta un reranker esplicito derivato da Bing in Azure AI Search. Il reranking ≠ Reciprocal Rank Fusion (RRF). Implicazione SEO: i reranker valutano le coppie query-passaggio congiuntamente, quindi i passaggi autonomi e non ambigui vincono.
Il pattern recupera-poi-riordina
Il recupero a due stadi bilancia l’ampiezza dei candidati con uno scoring più costoso. Evidence for this claim A cross-encoder can score query-document pairs for reranking after an initial retrieval stage. Scope: Sentence-BERT evaluation and related retrieve-then-rerank use; cross-encoders are one reranking approach, not a universal implementation. Confidence: high · Verified: Reimers and Gurevych: Sentence-BERT La scelta del modello e i compromessi tra latenza e qualità sono specifici dell’implementazione. Evidence for this claim A rerank model can reorder an existing candidate list by relevance to a query. Scope: Cohere's Rerank product behavior; inputs, limits, and scoring semantics are vendor-specific. Confidence: high · Verified: Cohere: Rerank overview
A query enters fast first-stage retrieval, which produces a candidate shortlist. A slower query-candidate scoring model reranks only that shortlist into the final order. A document omitted by retrieval never reaches the reranker.
© Patrick Stox LLC · CC BY 4.0 ·
Ogni sistema di relevance su larga scala affronta lo stesso problema: non puoi permetterti di eseguire il tuo modello di relevance più accurato sull’intero corpus. Quindi la soluzione standard è dividere il lavoro in fasi. La documentazione di ricerca di Google Cloud lo afferma chiaramente: “In short, retrieval is finding relevant documents, while ranking is ordering those retrieved documents. Ranking all the available documents can be computationally expensive. Therefore, retrieval and ranking work sequentially.” (traduzione) «In breve, il retrieval consiste nel trovare documenti pertinenti, mentre il ranking consiste nell’ordinare quei documenti recuperati. Classificare tutti i documenti disponibili può essere computazionalmente costoso. Pertanto, retrieval e ranking lavorano in sequenza.» (Google Cloud, “About retrieval and ranking”)
Fase uno — retrieval — getta una rete ampia a basso costo. Usa il matching lessicale (BM25 su un indice invertito), la ricerca vettoriale basata su embedding, o un ibrido dei due, e restituisce un insieme di candidati. Fase due — reranking — prende quella shortlist e ri-valuta ogni candidato con un modello più costoso e più preciso, poi riordina. La versione in una riga su cui tutti convergono: recupera a basso costo e in modo ampio, ri-ordina con precisione su un piccolo insieme, poi servi o genera.
Bi-encoder vs cross-encoder: il meccanismo fondamentale
L’intero argomento ruota attorno a una distinzione architetturale — quando la query e il documento si incontrano.
- Bi-encoder (il retriever di prima fase). Codifica la query e ogni documento separatamente, ciascuno nel proprio vettore, e poi confronta i due vettori con qualcosa come la similarità coseno. Poiché i vettori dei documenti non dipendono dalla query, puoi calcolarli e indicizzarli in anticipo, il che rende il retrieval abbastanza veloce da essere eseguito sull’intero corpus. Il costo: query e documento non interagiscono mai realmente, quindi il modello deve, in effetti, comprimere ogni possibile significato di un documento in un singolo vettore — e le sfumature si perdono. I bi-encoder sono ciò su cui si basano gli embedding e la ricerca vettoriale.
- Cross-encoder (il reranker di seconda fase). Codifica la query e un documento candidato insieme, come un unico input congiunto attraverso un transformer, e restituisce un singolo punteggio di relevance per quella coppia. Poiché il modello vede entrambi contemporaneamente, può valutare direttamente come le parole specifiche della query si relazionano alle parole specifiche del documento — molto più accurato. Il costo: nulla può essere precalcolato. Ogni coppia query-documento deve essere elaborata dal modello al momento della query, quindi è di gran lunga troppo lento per essere applicato a un intero indice. È esattamente per questo che è riservato alla shortlist.
Google, notevolmente, descrive questo esatto meccanismo con le sue stesse parole. Nella documentazione sul retrieval/ranking di Google Cloud, uno dei segnali di retrieval elencati è cross-attention, definito come qualcosa che “allows a model to consider the relationship between a query and a document to assign a relevance score to the document.” (traduzione) «consente a un modello di considerare la relazione tra una query e un documento per assegnare un punteggio di relevance al documento.» Questa è l’idea del cross-encoder sotto un nome diverso.
Perché non usare semplicemente il modello accurato su tutto?
Latenza e costi lo rendono irrealizzabile su larga scala, e il divario è enorme, non marginale. L’articolo di Pinecone sul retrieval a due stadi fornisce un numero concreto: su un set di 40 milioni di record, eseguire un reranker cross-encoder stile BERT su tutto su una GPU V100 richiederebbe più di 50 ore, contro meno di 100 millisecondi per la ricerca vettoriale. (Pinecone, “Rerankers and Two-Stage Retrieval”) Questa è l’intera giustificazione per il design a due stadi — ottieni la maggior parte dell’accuratezza del cross-encoder pagando il suo costo solo su poche decine o poche centinaia di candidati.
Vectara inquadra lo stesso mito direttamente — la domanda del perché non classificare semplicemente tutti i documenti con il modello più preciso se è disponibile — e la risposta è la stessa: non puoi, quindi filtri prima in modo economico. (Vectara, “What is reranking and why does it matter?”)
Come lo fa Google
Google non ha mai pubblicato una dichiarazione ufficiale usando i termini “reranking,” “cross-encoder,” o “bi-encoder” riguardo a Google Search stesso — vale la pena dirlo chiaramente per non fare affermazioni eccessive. Ma la funzione è documentata con altri nomi.
La Guida ai sistemi di ranking di Google Search di Google stesso nomina due sistemi che svolgono il lavoro del reranking:
- BERT — “un sistema di intelligenza artificiale che Google usa per capire come le combinazioni di parole esprimono significati e intenzioni diverse.” BERT legge congiuntamente le parole di una query nel contesto; un reranker basato su BERT valuta la rilevanza query-documento come farebbe un cross-encoder.
- Passage ranking — “un sistema di intelligenza artificiale che usiamo per identificare singole sezioni o ‘passaggi’ di una pagina web per capire meglio quanto una pagina sia rilevante per una ricerca.” Questo è il reranking a livello di passaggio piuttosto che a livello di pagina (vedi passage ranking per l’approfondimento).
- RankBrain — il sistema precedente di Google che “ci aiuta a capire come le parole sono correlate ai concetti,” così può restituire contenuti rilevanti anche senza parole corrispondenti esatte.
Google Research ha anche pubblicato il meccanismo apertamente: il suo articolo Learning-to-Rank with BERT in TF-Ranking descrive la codifica di query e documenti con BERT e l’applicazione di un livello di learning-to-rank sopra, e lo inquadra esplicitamente come re-ranking dei passaggi — riportando le migliori prestazioni sul task di re-ranking dei passaggi MS MARCO al 30 marzo 2020. Questa è una pubblicazione di Google Research piuttosto che una guida di prodotto di Search Central, quindi trattala come ricerca tecnica di Google, non come una dichiarazione sulla pipeline di Search in produzione.
Un numero su cui vale la pena essere cauti: la descrizione “riduci ai primi 1 000 risultati, poi riordinali” che circola ampiamente nei contesti SEO risale alla mia interpretazione personale di ricerche pubbliche e brevetti — non a una dichiarazione attuale e testuale di Google sulla Ricerca web. Il prodotto di ricerca enterprise di Google Cloud documenta effettivamente una pipeline concreta (“the model retrieves documents in the order of thousands… The ranking model then orders the retrieved documents and serves the top 400 ranked results”), ma quello è il prodotto Vertex AI Search, non la Ricerca web di Google. Non dare per scontato che né il 1 000 né il 400 si applichino a Google Search stesso.
Come lo fa Bing/Microsoft
Microsoft è molto più esplicita, e la sua documentazione più chiara è la cosa più vicina a una descrizione ufficiale di un reranker in produzione che troverai. Il semantic ranker di Azure AI Search è documentato come “una funzionalità che migliora in modo misurabile la rilevanza della ricerca usando i modelli di comprensione del linguaggio di Microsoft per riordinare i risultati di ricerca” — e, cosa cruciale, “la tecnologia sottostante proviene da Bing e Microsoft Research.”
La meccanica si mappa chiaramente sul modello a due fasi:
- “aggiunge sempre un ranking secondario su un set di risultati iniziale classificato con BM25 o Reciprocal Rank Fusion (RRF).” La prima fase è BM25 o RRF; il ranker semantico è la seconda fase.
- Microsoft chiama questa fase ranking L2, che “usa il contesto o il significato semantico di una query per calcolare un nuovo punteggio di rilevanza sui risultati pre-classificati.”
- Riorganizza solo la shortlist, mai l’intero corpus: “Ciò che il ranker semantico non può fare è rieseguire la query sull’intero corpus… Il ranking semantico riordina il set di risultati esistente, composto dai primi 50 risultati classificati dall’algoritmo di ranking predefinito.” Anche se vengono restituiti più di 50 risultati, “solo i primi 50 risultati passano al ranking semantico.”
Il blog di Bing del maggio 2026 sul ruolo in evoluzione dell’indice non menziona direttamente il reranking, ma sottolinea che la qualità del recupero è ora giudicata dall’affidabilità del supporto alle risposte: “I sistemi di recupero devono quindi ottimizzare non solo per il recupero one-shot, ma per un comportamento coerente e ripetibile nell’uso iterativo.”
Reranking nella ricerca RAG e AI
È qui che il reranking tocca più direttamente AI Overviews, AI Mode, Copilot, ChatGPT Search e Perplexity. In una pipeline RAG, il reranking è una fase denominata tra il recupero e la generazione: il contenuto viene suddiviso in chunk, ogni chunk viene incorporato e archiviato, la query recupera i chunk vicini per similarità vettoriale, un reranker riassegna i punteggi a quei candidati e solo i migliori sopravvissuti vengono passati all’LLM come contesto. Il reranker è il gate tra “il tuo passaggio è stato recuperato” e “il tuo passaggio è stato effettivamente utilizzato”.
Questo gate può essere severo. Nei sistemi di ricerca AI, solo una frazione delle fonti recuperate supera tipicamente la soglia di rerank per entrare nella fase di generazione — quindi essere inclusi nel pool di candidati è il prezzo d’ingresso, non una garanzia di citazione. Come la ricerca di Ahrefs sull’ottimizzazione per la ricerca LLM inquadra il problema centrale: “Le aziende AI non rivelano come gli LLM selezionano le fonti, quindi è difficile sapere come influenzare i loro output.” Il reranking è una grande parte di quel passaggio di selezione nascosto.
Reranking vs. Reciprocal Rank Fusion (RRF)
Questi vengono confusi costantemente — anche in contenuti SEO altrimenti buoni — e non sono lo stesso meccanismo.
- Reranking riassegna i punteggi a un pool di candidati valutando congiuntamente ogni coppia query-documento con un singolo modello (il cross-encoder). Si chiede: quanto è rilevante questo documento per questa query, davvero?
- Reciprocal Rank Fusion (RRF) fonde più liste già classificate — ad esempio, i risultati di BM25 e i risultati della ricerca vettoriale, o i risultati di diverse sotto-query fan-out — premiando i documenti che appaiono in modo coerente tra le liste. L’explainer di Ahrefs sul Query Fan-Out lo descrive: le query fan-out vengono cercate negli indici “usando la reciprocal rank fusion (RRF) — un metodo che assegna punteggi e fonde più liste di risultati premiando quelli che appaiono in modo coerente tra di esse.”
Entrambi possono coesistere nella stessa pipeline — il ranker semantico di Azure riordina letteralmente sopra un set classificato con BM25 o RRF — ma RRF è un passaggio di fusione di liste (nessun modello legge il tuo contenuto), mentre il reranking è un passaggio di valutazione del contenuto (un modello legge la query e il tuo passaggio insieme). Se devi ricordare una sola differenza: RRF combina liste; il reranking rilegge il contenuto.
Una breve storia: BM25 → RankBrain → BERT → reranker LLM
Il reranking non è una novità — è il nome moderno di un modello che la ricerca usa da anni. Il filo conduttore, che illustro nel mio talk Ahrefs Evolve 2025 GEO? AEO? LLMO? What’s With All This AI Stuff?:
- BM25 / recuperazione lessicale — il classico punteggio di corrispondenza per parole chiave che ancora oggi esegue il primo restringimento.
- RankBrain (2016) — il primo sistema di ranking basato su machine learning di Google, che comprende le parole come concetti.
- BERT / DeepRank (2019) — comprensione linguistica contestuale a livello di passaggio; inizia l’era del reranking in stile cross-encoder.
- Reranker moderni basati su LLM (RankEmbed e cross-encoder dell’era RAG) — i reranker neurali ora si collocano tra il recupero e la generazione nella ricerca AI.
La forma coerente in tutti: prima un recupero ampio ed economico, poi un riordino preciso e costoso di una shortlist.
Cosa significa per contenuti e SEO
Poiché un cross-encoder valuta la query e il tuo passaggio congiuntamente, le implicazioni pratiche rafforzano le best practice che già conosci — ora con un meccanismo alla base:
- Scrivi passaggi autonomi. Un reranker valuta un passaggio in gran parte in base ai propri meriti rispetto alla query. Una sezione che ha senso solo nel contesto dei tre paragrafi precedenti ottiene un punteggio peggiore di una che si presenta come una risposta completa. Questo si collega direttamente a passage ranking e chunking.
- Rispondi alla domanda specifica, vicino all’inizio della sezione. Le risposte dirette ottengono punteggi migliori delle premesse. Metti prima la risposta, poi approfondisci.
- Minimizza l’ambiguità. Pronomi e frasi dipendenti dal contesto (“come menzionato sopra,” “questo approccio”) che si risolvono solo altrove nella pagina rendono più difficile valutare un passaggio in isolamento. Nomina la cosa.
- Il recupero è ancora il prerequisito. Il reranking vede solo ciò che il recupero gli passa. Una pagina che non può essere indicizzata o che non viene mai recuperata, non raggiunge mai il reranker. Prima risolvi la reperibilità; poi ottimizza i passaggi.
Niente di tutto questo è una manopola che invii a Google. È lo stesso consiglio “sii chiaro e sii trovato”, mirato alla fase specifica — il secondo sguardo — che decide quale contenuto recuperato viene effettivamente utilizzato.
Riepilogo AI
Una sintesi della versione Advanced:
- Il reranking è la seconda fase di una pipeline di recupero. La prima fase recupera un insieme di candidati in modo economico e ampio (BM25, ricerca vettoriale o ibrida); la seconda fase ri-valuta e riordina quella shortlist con un modello più lento e preciso prima che i risultati vengano serviti o passati a un LLM.
- Bi-encoder vs cross-encoder è il meccanismo centrale. Un bi-encoder codifica query e documento separatamente in vettori e li confronta — veloce, precomputabile, meno preciso; è il retriever. Un cross-encoder li codifica insieme e produce un punteggio di rilevanza per coppia — più lento, non precomputabile, più accurato; è il reranker.
- Perché due fasi: il modello accurato è troppo lento per essere eseguito su un intero corpus. Pinecone: un cross-encoder su 40M di record ≈ 50+ ore contro meno di 100ms per la ricerca vettoriale. Recupera in modo economico, riordina la shortlist.
- Google non dice pubblicamente “reranking”, ma BERT e passage ranking fanno il lavoro, e i documenti di Google Cloud elencano cross-attention (l’idea del cross-encoder). La cifra “top 1.000 poi riordina” deriva dal deck di Patrick che interpreta ricerche/brevetti — non una dichiarazione verbatim attuale di Google Search.
- Bing/Microsoft documenta un reranker esplicito: il semantic ranker di Azure AI Search (ranking L2) riordina un insieme classificato con BM25 o RRF, solo i primi ~50 risultati, usando tecnologia “from Bing and Microsoft Research.”
- Nella ricerca RAG/AI, il reranking è il gate tra “recuperato” e “effettivamente usato” — solo alcune fonti recuperate superano il gate nella generazione.
- Reranking ≠ RRF. RRF fonde più liste classificate; il reranking ri-valuta un singolo pool di candidati leggendo query + passaggio insieme. Spesso confusi; non sono la stessa cosa.
- Conclusione SEO: poiché i reranker valutano le coppie query-passaggio congiuntamente, i passaggi autonomi e non ambigui che rispondono direttamente a una domanda specifica ottengono punteggi migliori. Il recupero (indicizzabile + indicizzato) rimane il prerequisito.
Documentazione ufficiale
Documentazione di fonti primarie su recupero e riordinamento (retrieval e reranking) dei provider di ricerca e cloud.
- Informazioni su recupero e ranking (Google Cloud / Vertex AI Search) — la descrizione ufficiale più chiara di Google della suddivisione recupero→ranking, del segnale di cross-attention e della cifra di servizio dei primi 400 (per il prodotto enterprise, non per la Ricerca web).
- Una guida ai sistemi di ranking di Google Search — BERT, passage ranking e RankBrain con le parole di Google (i sistemi che svolgono il lavoro di reranking nella Ricerca).
- Learning-to-Rank con BERT in TF-Ranking (Google Research) — la ricerca di Google sul re-ranking dei passaggi con cross-encoder su MS MARCO.
Microsoft / Bing
- Panoramica del ranking semantico — Azure AI Search — la documentazione pubblica più dettagliata di Microsoft sul reranker: ranking L2 su un insieme BM25/RRF, solo i primi 50, tecnologia “da Bing e Microsoft Research.”
- La scienza dietro la ricerca semantica (Microsoft Research) — la ricerca alla base del ranker semantico (base BM25 + reranking con Transformer).
- Evoluzione del ruolo dell’indice (Bing Search Blog, maggio 2026) — affidabilità del recupero per i sistemi di risposta.
Riferimenti vendor / RAG
- Reranker e recupero a due stadi (Pinecone) — la spiegazione della perdita di informazioni del bi-encoder e il benchmark di latenza 50 ore vs 100 ms.
- Uso dei cross-encoder come reranker (Weaviate) — la cornice “veloce ma meno accurato” vs “accurato ma lento” e la pipeline multistadio.
- Cosa sono i reranker? (MongoDB) — definizione, ruolo nella ricerca e ottimizzazione RAG.
- Cos’è il reranking e perché è importante? (Vectara) — la domanda “perché non usare semplicemente il modello costoso su tutto?”.
Citazioni dalla fonte
Dichiarazioni pubbliche di Google e Microsoft. Ogni link è un deep link che salta al passaggio citato nella pagina di origine.
Google Cloud — la suddivisione recupero-poi-ranking
- “In short, retrieval is finding relevant documents, while ranking is ordering those retrieved documents. Ranking all the available documents can be computationally expensive. Therefore, retrieval and ranking work sequentially.” (traduzione) «In breve, il recupero consiste nel trovare documenti pertinenti, mentre il ranking consiste nell’ordinare quei documenti recuperati. Ordinare tutti i documenti disponibili può essere computazionalmente costoso. Pertanto, recupero e ranking lavorano in sequenza.» — Google Cloud, “Informazioni su recupero e ranking.” Vai alla citazione
Google Search Central — i sistemi che svolgono il lavoro di reranking
- “Bidirectional Encoder Representations from Transformers (BERT) is an AI system Google uses…” (traduzione) «Bidirectional Encoder Representations from Transformers (BERT) è un sistema di intelligenza artificiale che Google usa…» — Google Search Central, “Una guida ai sistemi di ranking di Google Search.” Vai alla citazione
- “Passage ranking is an AI system we use to identify individual sections or ‘passages’ of a web page…” (traduzione) «Il passage ranking è un sistema di intelligenza artificiale che usiamo per identificare singole sezioni o “passaggi” di una pagina web…» — Google Search Central, stessa guida. Vai alla citazione
Microsoft — un reranker esplicito derivato da Bing
- “In Azure AI Search, semantic ranker is a feature that measurably improves search relevance by using Microsoft’s language understanding models to rerank search results.” (traduzione) «In Azure AI Search, il ranker semantico è una funzionalità che migliora misurabilmente la pertinenza della ricerca utilizzando i modelli di comprensione del linguaggio di Microsoft per riordinare i risultati di ricerca.» — Microsoft Learn, “Semantic ranking overview.” Vai alla citazione
- “What semantic ranker can’t do is rerun the query over the entire corpus to find semantically relevant results. Semantic ranking reranks the existing result set, consisting of the top 50 results as scored by the default ranking algorithm.” (traduzione) «Ciò che il ranker semantico non può fare è rieseguire la query sull’intero corpus per trovare risultati semanticamente pertinenti. Il ranking semantico riordina il set di risultati esistente, composto dai primi 50 risultati come valutati dall’algoritmo di ranking predefinito.» — Microsoft Learn, stessa pagina.
Bing — recupero per sistemi di risposta
- “Retrieval systems must therefore optimize not just for one-shot retrieval, but for consistent, repeatable behavior across iterative use.” (traduzione) «I sistemi di recupero devono quindi ottimizzare non solo per il recupero one-shot, ma per un comportamento coerente e ripetibile nell’uso iterativo.» — Krishna Madhavan, Knut Risvik, Meenaz Merchant (Microsoft AI), Bing Search Blog, maggio 2026. Leggi la fonte
I modelli mentali
1. Recupera in modo ampio, riordina con precisione. La prima fase getta una rete ampia ed economica; la seconda legge attentamente la shortlist. Quando una risposta AI o un risultato di ricerca non include la tua pagina, chiediti quale fase l’ha esclusa: non sei mai stato recuperato nel set di candidati, oppure sei stato recuperato ma riordinato sotto la soglia? Sono problemi diversi con soluzioni diverse (trovabilità vs. chiarezza del passaggio).
2. Bi-encoder vs cross-encoder — separato vs congiunto. Un bi-encoder codifica query e documento separatamente e confronta i vettori — veloce, indicizzabile, con perdita. Un cross-encoder li codifica insieme e valuta la coppia — lento, esatto, non precomputabile. Il recupero usa il primo; il riordinamento usa il secondo. Questa singola distinzione “separato vs congiunto” spiega tutto il compromesso velocità/accuratezza.
3. Il modello costoso guadagna il suo posto solo su una shortlist. Non puoi eseguire un cross-encoder su un miliardo di pagine (50+ ore su 40 milioni di record). Il design a due fasi esiste proprio per pagare il costo del modello preciso su decine o centinaia di candidati, non sull’intero corpus. Quel vincolo è il motivo per cui il riordinamento è una fase separata.
4. Riordinamento ≠ RRF. Reciprocal Rank Fusion fonde più liste classificate (BM25 + vettoriale, o sotto-query fan-out) premiando l’accordo tra liste — nessun modello legge il tuo contenuto. Il riordinamento ri-valuta un singolo pool leggendo query + passaggio insieme. RRF combina liste; il riordinamento rilegge il contenuto.
5. Stessa funzione, nomi diversi. “Reranking” è il vocabolario del fornitore/ML. Google chiama le sue versioni BERT e passage ranking; Microsoft chiama la sua versione semantic ranker / L2 ranking. L’assenza della parola nella documentazione di Search Central non è l’assenza della funzione.
6. La regola decisionale sul contenuto. Non c’è una manopola del riordinatore da inviare. Chiediti invece: questo passaggio risponde a una domanda specifica in modo chiaro, da solo, senza dipendere dal resto della pagina? Se sì, ottiene un buon punteggio quando un cross-encoder lo legge accanto alla query. Se ha bisogno del contesto circostante per avere senso, non lo ottiene.
Riordinamento — cheat sheet
Cos’è in una riga La seconda fase del recupero: ri-valutare e riordinare una shortlist recuperata con un modello più lento e preciso prima di servire o generare.
Bi-encoder vs cross-encoder
| Bi-encoder | Cross-encoder | |
|---|---|---|
| Codifica query + doc… | Separatamente (due vettori) | Insieme (un input congiunto) |
| Output | Due vettori, confrontati (coseno) | Un punteggio di rilevanza per coppia |
| Precalcola il lato doc? | Sì — indicizzabile | No — eseguito al momento della query |
| Velocità | Veloce (scala all’intero corpus) | Lento (solo shortlist) |
| Precisione | Inferiore (query/doc non interagiscono mai) | Superiore (cattura l’interazione) |
| Ruolo nella pipeline | Fase 1 — recupero | Fase 2 — ri-ranking |
Chi fa cosa (per nome)
| Sistema | Proprietario | Ruolo |
|---|---|---|
| BM25 / indice invertito | (classico) | Recupero lessicale di prima fase |
| Ricerca vettoriale (embeddings) | (bi-encoder) | Recupero semantico di prima fase |
| BERT | Rilevanza in stile ri-ranking (parole nel contesto) | |
| Passage ranking | Ri-ranking a livello di passaggio | |
| Cross-attention | Google Cloud | Il nome di Google per il segnale cross-encoder |
| Semantic ranker / L2 ranking | Microsoft (derivato da Bing) | Ri-ranking esplicito sui top-50 di BM25/RRF |
Ri-ranking vs RRF
| Ri-ranking | Reciprocal Rank Fusion (RRF) | |
|---|---|---|
| Opera su | Un singolo pool di candidati | Più liste classificate |
| Meccanismo | Il modello legge query + doc insieme | Unisce le liste, premia l’accordo tra liste |
| Legge i tuoi contenuti? | Sì | No (solo posizioni) |
Fatti rapidi
- Il design a due fasi esiste perché i cross-encoder sono troppo lenti per un intero corpus: ~50+ ore (40M record) vs <100ms per la ricerca vettoriale (Pinecone).
- Google non usa mai pubblicamente “reranking”/“cross-encoder”/“bi-encoder” per la Ricerca web stessa — BERT e passage ranking sono gli equivalenti nominati.
- Il semantic ranker di Azure ri-ordina solo i top ~50 risultati recuperati, mai l’intero corpus.
- La cifra “top 1.000 poi riordina” deriva dalla lettura di Patrick di ricerche pubbliche / brevetti — non una dichiarazione verbatim di Google Search.
La mia pagina non viene mostrata — è un problema di recupero o di ri-ranking?
Un modo rapido per individuare quale fase sta fallendo prima di cambiare qualsiasi cosa. Il ri-ranking e il recupero sono problemi diversi; correggere quello sbagliato spreca sforzi.
Inizio: la pagina è indicizzata?
- No → È un problema di crawl/indicizzazione, a monte di entrambi. Correggi crawling e l’indicizzazione prima — nulla raggiunge il recupero o il ri-ranking finché la pagina non è nell’indice.
- Sì → continua.
La pagina viene classificata / recuperata per la query ampia (anche in basso)?
- No, non è da nessuna parte → Sembra un errore di recupero: il retriever di prima fase non ti sta portando nel set di candidati. Lavora sulla rilevanza tematica, sull’essere una corrispondenza genuina per il significato della query (embeddings / ricerca semantica), e su link interni e autorità così da essere un candidato.
- Sì, appari ma in basso / non citato → Sembra un errore di ri-ranking: sei nella shortlist ma hai un punteggio sotto la soglia. Continua.
La sezione pertinente si presenta come una risposta autonoma alla query specifica?
- No — dipende dal contesto circostante, usa pronomi ambigui, nasconde la risposta → Questa è la correzione a più alto impatto. Riscrivi il passaggio per rispondere alla domanda specifica direttamente, vicino all’inizio della sezione, senza dipendere dal resto della pagina (vedi passage ranking e chunking).
- Sì — è già una risposta pulita e diretta → Probabilmente stai perdendo su autorità / concorrenza, non chiarezza. Fonti concorrenti più forti e autorevoli vengono ri-classificate sopra di te; la leva qui è E-E-A-T e link, non ulteriori riscritture.
Regola pratica: da nessuna parte → recupero; presente ma non scelto → ri-ranking. Non riscrivere passaggi per correggere una pagina che non è mai stata recuperata, e non inseguire link per correggere un passaggio che si legge male in isolamento.
Anti-pattern del ri-ranking
Modi comuni in cui le persone fraintendono o usano male il concetto.
Trattare “recuperato” come “fatto.” Essere inclusi nel set di candidati è l’inizio, non la fine. Il ri-ranker deve ancora ti valuti sopra la soglia. Ottimizzare solo per il recupero (essere trovati) e ignorare la chiarezza dei passaggi (sopravvivere al ri-rank) lascia risultati sul tavolo.
Confondere il ri-ranking con la fusione a rango reciproco. RRF fonde più liste classificate tramite accordo tra liste; il ri-ranking ri-valuta un pool leggendo query + passaggio insieme. I contenuti che “vincono RRF” (appaiono in molte liste) e contenuti che “vincono il ri-ranking” (si leggono come la migliore risposta) non sono la stessa cosa. Molta scrittura SEO altrimenti buona confonde questi concetti — non farlo.
Presumere che il numero “top 1.000 → riordina” si applichi alla Ricerca Google web. Quella cifra deriva dall’interpretazione del mio stesso deck di ricerca pubblica e brevetti. Il pipeline documentato “migliaia recuperati, top 400 serviti” è il prodotto di ricerca enterprise di Google Cloud, non la Ricerca Google web. Cita il meccanismo, attenua i numeri specifici.
Fare a pezzi i contenuti in frammenti minuscoli “per il ri-ranker.” Il ri-ranking premia i passaggi che si leggono come risposte complete e autonome — non coriandoli. L’eccessiva frammentazione distrugge il contesto che rende un passaggio valutabile. Una struttura chiara H2/H3 con una risposta diretta per sezione si spezzetta bene da sola; non serve sminuzzare la pagina.
Credere che “se Google non dice ‘ri-ranking’, non sta accadendo.” Il vocabolario differisce dalla funzione. Il BERT e il ranking dei passaggi di Google, e il rank semantico di Microsoft, fanno esattamente questo lavoro. L’assenza della parola non è assenza del meccanismo.
Pensare che un cross-encoder “sostituisca” la ricerca vettoriale. Sono sequenziali, non in competizione. I cross-encoder sono troppo lenti per essere eseguiti su un intero corpus, quindi il recupero vettoriale bi-encoder è ancora richiesto come primo stadio. Servono entrambi.
Mettiti alla prova: Ri-ranking
Cinque domande rapide su come il ri-ranking riordina i risultati recuperati. Scegli una risposta per ciascuna, poi controlla.
Risorse che meritano il tuo tempo
I miei scritti e interventi correlati
- GEO? AEO? LLMO? Cosa sono tutte queste cose sull’IA? — il mio talk Ahrefs Evolve 2025 sulla discendenza BM25 → RankBrain → BERT/DeepRank → RankEmbed in cui si inserisce il ri-ranking. (Versione YouTube.)
- Come funziona la ricerca (SlideShare) — la mia spiegazione di crawling, rendering, indicizzazione e ranking, inclusa la fase di recupera-poi-riordina (“aggiustamenti post-recupero”). Vale la mia dichiarazione di esonero: questa è la mia comprensione di questi sistemi, non un resoconto garantito completo o perfettamente accurato, e i numeri esatti del set di candidati sono la mia lettura di ricerca pubblica e brevetti.
I miei interventi (ricerca IA più ampia)
- Cosa sappiamo davvero sull’ottimizzazione per la ricerca LLM — l’articolo di Ahrefs che usa la mia ricerca; inquadra quanto poco le aziende di IA rivelino su come vengono selezionate le fonti (il passaggio di cui il ri-ranking fa parte).
Dal settore
- Rerankers and Two-Stage Retrieval (Pinecone) — la spiegazione della perdita di informazioni del bi-encoder e il benchmark di latenza di 50 ore contro 100 ms.
- Using Cross-Encoders as reranker in multistage vector search (Weaviate) — la chiara contrapposizione “veloce ma meno accurato” vs “accurato ma lento”.
- What are Rerankers? (MongoDB) — definizione, ruolo nella ricerca e come i reranker si inseriscono nella RAG.
- What is reranking and why does it matter? (Vectara) — la sfatatura del mito “perché non usare semplicemente il modello costoso su tutto”.
- Semantic ranking overview (Microsoft Learn) — la documentazione più chiara sui reranker di produzione, esplicitamente basata sulla tecnologia Bing.
- AI Search Architecture Deep Dive (Mike King, iPullRank) — collega il reranking con cross-encoder alla pipeline inferita di Bing Copilot (tratta i dettagli architetturali come inferenza informata, non come dichiarazioni ufficiali Microsoft).
- What is Query Fan-Out? (Despina Gavoyannis, Ahrefs) — copre la Reciprocal Rank Fusion, il concetto adiacente ma distinto con cui il reranking viene spesso confuso.
- Query fan-out in AI search: What is it and how does it work? (Search Engine Land) — ulteriori informazioni su RRF e sintesi del fan-out, per la disambiguazione.
Cronologia modifiche
Aggiornato il 17 lug 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Dettagli delle modifiche
-
Le note dettagliate sulle modifiche sono attualmente disponibili in inglese.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.