Una finestra di contesto ampia è un limite di capacità, non una strategia di retrieval. Il fatto che un modello accetti diverse centinaia di migliaia di token non significa che li legga con attenzione uniforme, e di certo non significa che tu debba pagare per inviarli tutti. Ogni benchmark sul contesto lungo che si è preso la briga di misurare posizione e lunghezza dice la stessa cosa: l'accuratezza cala man mano che l'input cresce, e le prove sepolte al centro di un prompt sono quelle usate meno.

Il cambio di prospettiva da interiorizzare è questo: la finestra di contesto è un budget da spendere, non un database da interrogare. I team che la trattano come uno storage costruiscono sistemi più lenti, più costosi e meno accurati della pipeline di retrieval che hanno saltato.

I due modi di fallire sono diversi

Vengono spesso confusi tra loro, ma le soluzioni sono diverse.

  • Degrado posizionale. L'effetto lost-in-the-middle descritto da Liu et al. (2023): l'accuratezza è più alta quando il passaggio rilevante si trova proprio all'inizio o proprio alla fine dell'input, e cala al centro, producendo una curva a U. Sposta lo stesso fatto dal bordo al centro e la qualità della risposta peggiora anche se nient'altro è cambiato.
  • Degrado da lunghezza. L'accuratezza diminuisce man mano che l'input cresce, anche quando le prove restano fisse e ben posizionate. Lavori successivi come RULER (Hsieh et al., 2024) hanno testato modelli a contesto lungo su compiti multi-needle e di ragionamento sul contesto, scoprendo che la lunghezza di contesto effettiva è sistematicamente inferiore al numero dichiarato.

Il degrado posizionale a volte lo puoi aggirare riordinando i contenuti. Il degrado da lunghezza no, perché il problema è la dimensione del pagliaio stesso. Risolverlo significa mettercene meno dentro.

Perché il numero del benchmark inganna

Il test needle-in-a-haystack ha guadagnato popolarità perché è facile da eseguire e facile da superare. Nascondi una frase fuori posto a varie profondità in un documento lungo, chiedi al modello di ripeterla, disegna una griglia verde. Un modello può ottenere un punteggio quasi perfetto su questo test e comunque fallire ciò di cui hai davvero bisogno, perché le domande reali non sono ricerche lessicali.

I tuoi utenti chiedono cose che richiedono di trovare quattro fatti correlati sparsi in un corpus, notare che due di essi sono in contraddizione, e ragionare sul resto. È questo il compito che RULER misura, ed è il punto in cui la finestra dichiarata e quella effettivamente utilizzabile divergono. Considera il recall a singolo needle come uno smoke test, non come prova che la finestra funzioni.

Il lato costi non lascia margini di dubbio

Il degrado del retrieval si può discutere. La bolletta no. I token di input vengono fatturati per chiamata, quindi un design che stipa 200.000 token di contesto in ogni richiesta paga tutti e 200.000 ogni volta, che la risposta ne richiedesse dodici o nessuno.

# Stuff-the-window: whole handbook, every turn
200,000 input tokens x 50,000 calls/month = 10,000,000,000 tokens

# Retrieve-then-answer: system prompt + 6 chunks
  3,000 input tokens x 50,000 calls/month =    150,000,000 tokens

Questo è un fattore sessantasei sulla riga dell'input, prima ancora di contare la latenza. Il time to first token scala con quanto il modello deve leggere, quindi il prompt stipato è anche quello più lento. Stai pagando di più per una risposta peggiore, consegnata più tardi. Non c'è un solo asse su cui questo vinca.

Il prompt caching complica l'aritmetica in un caso specifico: un prefisso davvero stabile che si ripete tra le chiamate può essere letto con uno sconto notevole. È reale, e vale la pena usarlo. Ma salva il costo di un preambolo statico, non il recall di un pagliaio gonfiato. Un prompt sbagliato in cache resta un prompt sbagliato, solo più economico.

Cosa fare invece

La disciplina non è affascinante, ma funziona.

  • Recupera, poi rispondi. Metti un passaggio di retrieval davanti al modello e passa una manciata dei chunk migliori. Una Bedrock Knowledge Base fa questo senza che tu debba gestire un indice tuo. Sei chunk buoni battono seicento mediocri, sempre.
  • Ordina, e fallo sul serio. Se passi dieci chunk, l'ordine conta perché la posizione conta. Metti la prova più forte in cima e la seconda più forte in fondo, dove l'attenzione è migliore. Riempi il centro con il materiale marginale, non con il fatto portante.
  • Metti un tetto a ciò che ogni singolo passaggio può vedere. Un tetto rigido di token per chiamata costringe il livello di retrieval a essere selettivo. Senza un tetto, il contesto cresce finché qualcosa si rompe, di solito nel momento peggiore.
  • Metti in cache il prefisso stabile, non il corpo variabile. Il system prompt e gli schemi dei tool sono identici a ogni chiamata e appartengono alla cache. Le prove recuperate cambiano a ogni domanda e non ci appartengono.
  • Misura il recall sulle tue domande. Esegui le tue query reali sul tuo corpus reale e valuta le risposte. Le dichiarazioni dei fornitori sulla lunghezza del contesto sono un numero di marketing; la tua eval è l'unica che descrive davvero il tuo sistema.

Quando la finestra grande è la risposta giusta

Ci sono casi in cui riempire la finestra è corretto, e rifiutarsi per principio è a sua volta un errore. Riassumere un singolo documento dall'inizio alla fine richiede l'intero documento; non c'è nulla da recuperare perché tutto è rilevante. Un ragionamento che richiede di tenere sott'occhio un intero codebase o contratto in una volta sola ha davvero bisogno di quell'ampiezza. Un'analisi una tantum in cui costruire una pipeline di retrieval costa più dei token è un buon posto per essere pigri di proposito.

Il test è se riesci a nominare il sottoinsieme che conta. Se ci riesci, recuperalo. Se davvero non ci riesci, perché il compito riguarda l'intero corpus e non una sua parte, allora la finestra sta facendo un lavoro reale e dovresti usarla.

Il punto

Le finestre di contesto più grandi sono un traguardo ingegneristico reale, e continuano a crescere. Sono anche il modo più costoso per evitare di scrivere un passaggio di retrieval. Il recall peggiora con la lunghezza e con la posizione, la bolletta scala con ogni token inviato, e la latenza segue la dimensione del prompt. Decidi cosa il modello deve vedere, invia quello, e smettila di scambiare la capacità per competenza.

Leggi questo dopo

Per il lato infrastruttura del far girare il retrieval su larga scala, le note di campo su cloud e piattaforma vivono su ercan.cloud, e l'hub è su ercanermis.com.