Lo studio introduce un nuovo diagnostico chiamato answer-in-context per misurare la presenza effettiva della risposta nei documenti
La scorsa settimana è uscito uno studio che mette in discussione una convinzione molto diffusa tra chi costruisce sistemi di retrieval-augmented generation, i cosiddetti RAG: quella per cui, per migliorare le risposte di un’intelligenza artificiale, basta aumentare il numero di documenti recuperati e infilati nel contesto. I numeri dicono altro.
Il paradosso della copertura
Il dato più controintuitivo arriva da un test su 2WikiMultiHopQA, un benchmark multilingua che misura la capacità di ragionare su più fonti. I ricercatori hanno modificato il modo in cui i documenti vengono impacchettati prima di essere passati al modello che genera la risposta — un’operazione che tecnicamente si chiama packing — e hanno ottenuto un aumento della copertura documentale. Tradotto dal gergo: il sistema recuperava più documenti potenzialmente utili. Ma l’accuratezza della risposta finale non è migliorata. Zero.
Perché? Perché la copertura, da sola, è un indicatore che inganna. Aumentare il numero di documenti rilevanti nel mucchio non garantisce che la risposta giusta sia effettivamente contenuta in quei testi. Ed è proprio lì, in quel dettaglio, che si annida il vero collo di bottiglia.
Cosa conta davvero: la risposta nel contesto
Il paper, pubblicato il primo luglio 2026, introduce un diagnostico nuovo: si chiama answer-in-context e misura se la risposta corretta è materialmente presente nei documenti che il sistema passa al generatore. Non basta che un documento sia attinente al tema della domanda. Deve contenere l’informazione puntuale che serve per rispondere.
Quanto è più utile questa metrica rispetto al recall tradizionale? I test su HotpotQA — un dataset di 113mila coppie domanda-risposta basate su Wikipedia, creato già nel 2018 e pensato per costringere i modelli a cercare e ragionare su più documenti — dicono che l’answer-in-context predice l’F1 della risposta con correlazioni tra 0,39 e 0,55. Il recall classico si ferma intorno a 0,31. C’è una differenza di oltre il 60% nella capacità predittiva.
Ancora più netta è la separazione che questo diagnostico introduce nella qualità delle risposte: su HotpotQA, i casi in cui la risposta è effettivamente nel contesto producono un punteggio di 0,60; quando invece la risposta è assente, il punteggio crolla a 0,12. Un fattore cinque. Semplificando: se la risposta non è lì dentro, il generatore può fare poco.
E qui entra in gioco il metodo di packing proposto dai ricercatori, che si chiama AdaGReS ed è un framework submodulare per la selezione del contesto con budget di token. Tradotto: invece di prendere i documenti uno a uno in base alla rilevanza con la domanda e impilarli finché il budget lo consente, AdaGReS ottimizza l’insieme dei documenti nel suo complesso. Tiene conto non solo di quanto ogni frammento è rilevante, ma anche di quanto è ridondante rispetto agli altri già selezionati. L’obiettivo è massimizzare la diversità informativa senza sprecare token preziosi.
Grande o piccolo: il lettore fa la differenza
I test con un budget di 160 token e un modello di lettura — il reader, cioè il componente che legge il contesto e genera la risposta — da 3 miliardi di parametri mostrano che AdaGReS batte le euristiche tradizionali. Su HotpotQA il guadagno arriva fino a +5,1 punti di F1 rispetto a un’euristica focalizzata, a MMR e al packing naive, a parità o con costo inferiore di token. Il dato è consistente su tre diverse inizializzazioni casuali.
Ma quando si scala il modello di lettura, la musica cambia. I ricercatori hanno costruito una scala controllata — 3B, 7B, 14B di parametri, mantenendo fissa la quantizzazione — e hanno osservato un fenomeno che dovrebbe far riflettere chi progetta sistemi RAG in produzione. Il vantaggio del packer submodulare rispetto all’euristica semplice si assottiglia già con un reader da 7 miliardi di parametri fin quasi a scomparire. Con un reader da 14 miliardi, secondo il paper di Bala, il vantaggio si inverte in modo significativo: l’euristica semplice fa meglio.
La spiegazione è intuitiva. Un modello piccolo ha bisogno di un contesto pulito, sfrondato dal rumore e dalla ridondanza, perché fatica a distinguere ciò che è utile da ciò che è accessorio. Un modello grande, invece, ha già una capacità interna di giudizio sufficiente per pesare l’importanza relativa dei documenti, e trarre vantaggio da una copertura più ampia, anche se meno sofisticata nella selezione. Il packing ottimizzato, che per un reader piccolo è una stampella preziosa, per un reader grande diventa un vincolo.
Per chi costruisce sistemi RAG, la lezione è piuttosto chiara. La scelta del retriever e della strategia di packing non si può fare in astratto: va calibrata sulla potenza del generatore. Con modelli di lettura molto grandi, conviene restare su euristiche semplici e spendere il budget computazionale altrove. Per dirla senza giri di parole: a volte la sofisticazione paga, a volte è solo complessità superflua.
Quel che conta, in ogni caso, non è la quantità di documenti recuperati, ma che la risposta giusta sia effettivamente lì, nero su bianco, in mezzo a quei token. Tutto il resto — recall, copertura, numero di chunk — sono metriche proxy che rischiano di indicare una direzione sbagliata.
