AWS ha introdotto un nuovo pattern per ridurre i costi di retrieval dell’IA su Amazon Bedrock. Se sviluppi applicazioni di retrieval-augmented generation (RAG), questa configurazione può ridurre la spesa per i token, ma gli utenti potrebbero dover attendere più a lungo per le risposte.
In un post pubblicato il 2026-08-21 sull’AWS Machine Learning Blog, AWS ha mostrato come inserire un modello piccolo tra il retrieval e la risposta finale. Invece di inviare lunghi blocchi di testo a un modello grande, un modello veloce estrae prima solo le esatte frasi rilevanti.
Come funziona la configurazione
Il design di riferimento viene eseguito all’interno di una funzione AWS Lambda utilizzando l’Amazon Bedrock Converse API. È necessario un account AWS, permessi IAM e l’accesso ai modelli.
La pipeline suddivide il lavoro tra due modelli:
– Claude Haiku funge da compressore, selezionando porzioni di testo testuali che corrispondono alla domanda dell’utente.
– Claude Sonnet legge solo il testo ridotto e scrive la risposta finale.
AWS ha testato tre approcci su oltre 500.000 documenti provenienti da nove tipi di fonti aziendali e 500 domande distribuite su 10 categorie: RAG di base, solo compressione e rerank più compressione.
Cosa mostrano i numeri
Secondo AWS, ridurre il contesto genera risparmi significativi:
– Volume di token: scende al 12% con la compressione (8.6x token in meno) e al 10% con rerank più compressione (10.1x token in meno), rispetto al 100% del RAG di base.
– Costo totale: scende al 67% (un risparmio del 33%) e al 64% (un risparmio del 36%).
– Punteggio di qualità: rimane vicino alla baseline (97.5% e 97.6% rispetto al 100%), sulla base di un giudice LLM che valuta correttezza, completezza, accuratezza delle citazioni e concisione.
– Tasso di allucinazione: scende dal 51% della baseline al 44% con la compressione e al 38% con il reranking, con la fedeltà tracciata separatamente.
– Latenza: aumenta del +19% per la compressione e del +12% per rerank più compressione. La velocità ne risente.
Le affermazioni da verificare di persona
Questi numeri derivano interamente da test interni di AWS su un singolo corpus valutato da un giudice LLM. Nessuno al di fuori di AWS li ha verificati in modo indipendente e non costituiscono una garanzia di prestazioni per altri carichi di lavoro, fasce di prezzo o modelli. L’aggiunta di un’ulteriore chiamata a un modello crea un nuovo punto di errore. Il compressore potrebbe scartare accidentalmente fatti essenziali, indebolire le citazioni o bloccarsi su frammenti malformati e prompt injection.
Come testare questo pattern
Non modificare ancora la tua pipeline di produzione. Fai prima dei test sui tuoi dati.
Imposta un set fisso di query di test con il tuo retriever, le impostazioni top-k, il chunking e gli ID dei modelli. Esegui le query attraverso tutti e tre i percorsi: RAG di base, compressione e rerank più compressione. Registra i token di input, i token di output, i costi di Lambda, i costi dei modelli e la latenza sia p50 che p95. Soprattutto, esamina direttamente le porzioni compresse. Controlla cosa viene eliminato. Se la latenza di coda subisce picchi o mancano prove fondamentali, mantenere il percorso RAG di base resta la scelta più sicura.