Lo studio EAR mostra che si possono eliminare fino al 40,2% delle parole recuperate con variazioni di accuratezza contenute
Nella retrieval-augmented generation (RAG), l’architettura in cui un modello linguistico recupera prima una serie di documenti e poi costruisce la risposta, la corsa non è al modello più grande, ma al contesto più magro. A mostrarlo è lo studio EAR presentato all’ASYU 2026, sottomesso su arXiv nei giorni scorsi: si può eliminare fino al 40,2% delle parole recuperate e perdere solo 3,9 punti di accuratezza nel caso peggiore, guadagnandone 5,2 nel migliore.
Meno parole, stessa risposta
Il dato arriva da un esperimento su un sottoinsieme in stile MMLU, un tipo di valutazione usata per misurare le conoscenze generali dei modelli linguistici, con 153 domande selezionate da un’euristica automatica e testi di libri di testo pubblici decontaminati. Con top-k = 3, cioè tre frammenti recuperati per ogni domanda, le variazioni di accuratezza osservate sono +5,2, +1,3 e -3,9 punti.
Il confronto è con i chunk, i blocchi in cui i documenti vengono normalmente divisi prima del recupero. Il metodo EAR riduce le parole recuperate del 37,5-40,2% rispetto ai chunk. In due configurazioni su tre il risultato migliora; nel caso peggiore si perdono meno di quattro punti. Detto in modo semplice: si porta al modello una quantità molto minore di testo e la qualità della risposta resta sostanzialmente invariata, a volte migliora.
Ma perché ridurre i token recuperati è così importante? La risposta sta nel costo nascosto del contesto.
Il paradosso del chunking perfetto
Se il risparmio di token si traduce in latenza, il vero collo di bottiglia non è come tagli i documenti, ma quante parole decidi di passare al modello. Il blog ufficiale per sviluppatori NVIDIA descrive il chunking, cioè la divisione dei documenti in blocchi, come una scelta di progettazione fondamentale per l’efficacia dell’intero sistema RAG. Eppure una valutazione sistematica dei metodi di chunking concorrenti ha concluso che i metodi più costosi e sofisticati non offrono miglioramenti significativi rispetto ai baseline più semplici.
Il punto non è trovare il taglio perfetto del testo. È che ogni parola in più nel contesto recuperato allunga la sequenza di input e pesa sul tempo di risposta. La domanda diventa: chi ne beneficia davvero quando il contesto recuperato si riduce?
Il vantaggio silenzioso di chi pubblica
La pipeline RAG non è un dettaglio tecnico: l’overhead del contesto recuperato allunga la sequenza di input e pesa direttamente sul tempo al primo token (TTFT). Secondo la guida NVIDIA per il dimensionamento della RAG aziendale, il contesto recuperato — guidato da dimensione dei chunk e Top-K — è legato direttamente alla lunghezza della sequenza di input e alla latenza del TTFT.
In pratica, meno token recuperati significano meno tempo prima che il modello inizi a rispondere e costi di inferenza ridotti. Per chi pubblica contenuti che finiscono nei sistemi RAG, questo è un vantaggio competitivo misurabile in millisecondi. Il prossimo passo non è rincorrere nuovi modelli, ma ripensare come i propri contenuti vengono selezionati e segmentati dalla macchina.
La prossima ottimizzazione non è un nuovo modello o un nuovo chunker, ma scegliere quali parole non finiscono nel prompt. Per chi pubblica online, essere una fonte che si fa selezionare in modo essenziale diventa un vantaggio competitivo misurabile in millisecondi.
