Il reranker bugiardo

Capitolo 3 — Il reranker bugiardo

Nel gergo tecnico del RAG c'è una figura chiave, poco glamour e poco raccontata: il reranker. Immagina la ricerca aziendale come un ingresso di discoteca. Il vector database è il portiere: guarda rapidamente la folla e fa entrare trenta candidati che, a occhio, assomigliano a quello che cerchi. Il reranker è il buttafuori interno: prende quei trenta, li guarda con calma, ne seleziona cinque — quelli che l'LLM leggerà davvero per costruire la risposta — e rimanda indietro gli altri venticinque. È una funzione piccola ma enorme: sbaglia lui, sbagliano tutti. Se il buttafuori non sa leggere le facce, il locale si riempie delle persone sbagliate e nessuno capirà mai perché la serata è andata male.

Nel 2025 sono comparsi sul mercato diversi servizi cloud che offrivano reranker come API. Mandi una domanda e una lista di documenti, ti restituiscono punteggi. Comodo, scalabile, niente GPU da comprare, niente modelli da scaricare. Un famoso provider europeo di modelli — senza fare nomi, ma sapete quali nomi stiamo evitando — esponeva un modello promettente della famiglia Qwen, da quattro miliardi di parametri, etichettato "Reranker". Il prezzo era ragionevole, la latenza accettabile. Chiunque, in quel momento storico, lo avrebbe scelto. Molti lo hanno scelto.

Salvo che i punteggi erano sbagliati. Non "leggermente" sbagliati, come può capitare a qualsiasi modello: sbagliati strutturalmente. Documenti palesemente rilevanti prendevano 0.2, documenti fuori tema prendevano 0.8. I primi sospetti, come sempre in questi casi, sono stati rivolti ai soliti colpevoli: il modello di embedding, il chunking, la formulazione della query, il preprocessing dei documenti. Settimane di indagini su piste sbagliate. Solo confrontando sistematicamente le risposte del reranker cloud con quelle di un reranker locale di riferimento — lo stesso input, gli stessi documenti, punteggi messi fianco a fianco su un foglio Excel — è emersa la verità scomoda: il modello esposto via API era rotto. Forse un errore di deploy, forse una versione sbagliata caricata per sbaglio, forse un bug nella serializzazione dei punteggi. Il provider non lo ha mai ammesso formalmente. Il problema, però, è semplicemente sparito un giorno, dopo un aggiornamento silenzioso e nessun cambio note.

Il punto di questa storia non è "i servizi cloud sbagliano" — tutti sbagliano, anche i modelli locali sbagliano. Il punto è più sottile: in un RAG serio, il reranker è un pezzo a cui devi poter guardare dentro. Se è una scatola nera a pagamento, e se i suoi output sono numeri che sembrano plausibili anche quando sono casuali — e i punteggi di un reranker sembrano sempre plausibili, perché sono numeri tra zero e uno con qualche decimale —, non hai nessun modo di capire cosa non va nel tuo sistema. E siccome il reranker è "verso la fine" della pipeline, il suo errore inquina ogni valutazione a monte: sembra lenta la ricerca, sbagliata la query, poveri gli embedding. In realtà è il buttafuori che non sa leggere le facce, e tu stai mettendo in discussione i vetri della porta.

La scelta controcorrente di alcuni team, in questi mesi — invece di andare verso più cloud, tornare indietro — è stata riportare il reranker in casa. Un modello open source della famiglia BGE, non gigantesco, fatto girare su GPU locale (anche su Apple Silicon, con qualche cautela sui driver). Più lavoro di gestione, è vero. Ma la possibilità di fare esperimenti controllati, di capire quando sbaglia, di confrontare versioni, di tenere uno storico. E — non ultimo — di non versare all'API una frazione di centesimo per ogni singola ricerca utente. Frazione che, moltiplicata per decine di migliaia di query al mese, smette rapidamente di essere una frazione e diventa una voce di bilancio.

Quando un componente è così critico che il suo malfunzionamento corrompe ogni tua capacità di misurare tutto il resto, allora delegarlo a una scatola nera non è efficienza. È un atto di fede. E gli atti di fede, in produzione, si pagano a interesse composto.