Introduzione alla nuova funzionalità RAG di Amazon Bedrock
Il 9 novembre 2026, Amazon Web Services ha comunicato che il servizio Amazon Bedrock Managed Knowledge Base ora supporta la generazione aumentata da recupero (RAG) in un’unica chiamata, oltre alle tradizionali richieste di recupero solo. Questa evoluzione è resa possibile tramite il nuovo endpoint AgenticRetrieveStream, che introduce una gamma estesa di impostazioni per maxAgentIteration da 0 a 5.
Grazie a queste impostazioni, le applicazioni possono scegliere tra:
- Recupero di fonti senza generare risposta (valore 0);
- Una singola ricerca seguita da generazione di risposta (valore 1);
- Il comportamento agente tradizionale, con più cicli di pianificazione (valori 2‑5).
Questa flessibilità permette di adattare il flusso di lavoro alle esigenze di latenza, costi e precisione, mantenendo la compatibilità con più basi di conoscenza.
Come funziona il RAG in un’unica chiamata
Il modello di base RAG prevede due fasi: recupero dei documenti pertinenti e generazione della risposta. Con la nuova API, entrambe le fasi avvengono all’interno della stessa chiamata di streaming utilizzata per le ricerche complesse. Quando maxAgentIteration è impostato a 1, il servizio effettua una singola chiamata al modello di fondazione per generare la risposta, riducendo potenzialmente la latenza rispetto al flusso agente tradizionale, che richiede più chiamate.
Nel caso di maxAgentIteration = 0, il servizio restituisce solo i passaggi recuperati senza alcuna generazione di testo. Questo corrisponde a una chiamata Retrieve tradizionale, ma con un formato di risposta differente: i passaggi compaiono nell’evento result del flusso, senza campi score o location.
Per le impostazioni da 2 a 5, il comportamento rimane invariato rispetto alla versione agente precedente: il sistema può eseguire più cicli di pianificazione, ognuno dei quali comprende una riformulazione della query e un nuovo recupero, fino a un massimo di maxAgentIteration - 1 cicli di pianificazione.
Dettagli sull’iterazione e sui limiti
Un’iterazione corrisponde a un singolo richiamo al modello di fondazione. Quando la generazione è attiva, il limite n riserva l’ultimo richiamo per la generazione della risposta e consente fino a n‑1 cicli di pianificazione. La fase di recupero esplorativo iniziale avviene prima della pianificazione e non è conteggiata nel limite.
Se si tenta di attivare la generazione con maxAgentIteration = 0, il servizio restituisce un errore 4xx, poiché una risposta richiede almeno una chiamata al modello.
Con maxAgentIteration = 1, il flusso trasmette sia il recupero che la risposta sintetizzata, ma non genera eventi di pianificazione aggiuntivi.
Parametri obbligatori e opzionali dell’API
La documentazione di AgenticRetrieveStream elenca i seguenti parametri come obbligatori:
messagesretrieversagenticRetrieveConfiguration
Il parametro generateResponse è facoltativo; i segmenti di risposta vengono inviati solo se è abilitato.
Il risultato finale può includere:
- Elementi recuperati;
- Risposta sintetizzata;
- Citations che collegano i passaggi della risposta ai risultati di origine.
Modalità recupero solo vs. recupero agente
La modalità recupero solo è essenzialmente equivalente a una chiamata diretta a Retrieve, ma senza la necessità di integrare una API separata. Basta modificare maxAgentIteration a 0 per ottenere lo stesso comportamento.
Le query complesse, invece, continuano a sfruttare il processo agente descritto nella guida utente di Amazon Bedrock, che prevede:
- Decomposizione della query in sotto‑query;
- Verifica della sufficienza dei risultati recuperati;
- Ricerca aggiuntiva se necessario;
- Possibilità di estendere la ricerca a un documento intero.
Questa modalità è compatibile solo con le basi di conoscenza Bedrock completamente gestite e supporta fino a cinque motori di recupero per singola richiesta.
Esempi pratici e casi d’uso illustrati da AWS
AWS ha mostrato diversi scenari usando un assistente interno dedicato alle regole di una banca fittizia. Nessun cliente reale è stato coinvolto.
Esempi di configurazione:
- Domanda su documentazione per un imprenditore individuale:
maxAgentIteration=1. Il sistema recupera le informazioni pertinenti e genera una risposta sintetica. - Confronto tra requisiti per imprenditori individuali e LLC, includendo regole per proprietari non residenti:
maxAgentIteration=4, consentendo fino a tre cicli di pianificazione per verificare più fonti. - Revisione del testo delle regole:
maxAgentIteration=0. Vengono restituiti solo i passaggi di origine, senza alcun riepilogo.
In tutti i casi, l’applicazione deve scegliere esplicitamente il valore di maxAgentIteration; il servizio non effettua automaticamente il passaggio tra le modalità.
Raccomandazioni per l’adozione
AWS suggerisce di confrontare il nuovo RAG in un’unica chiamata con la configurazione agente esistente, utilizzando la stessa base di conoscenza e un set di domande rappresentative con risposte attese. L’analisi dovrebbe includere:
- Misurazione della latenza e del costo per richiesta;
- Verifica dell’accuratezza delle risposte e del loro supporto tramite citazioni;
- Test con domande che richiedono più documenti e con quelle impossibili da rispondere.
Questi dati aiutano a determinare la soglia di iterazioni più bassa che soddisfi i requisiti di qualità, ottimizzando al contempo l’uso del modello.
Implicazioni per le imprese
La principale decisione per le organizzazioni è valutare se la riduzione dell’utilizzo del modello (grazie a maxAgentIteration più basso) comprometta la completezza e la correttezza delle risposte. Una limitazione più alta garantisce una raccolta più approfondita di prove, ma può aumentare latenza e costi.
La nuova configurazione rende la “profondità di recupero” un parametro di infrastruttura esplicito, consentendo alle aziende di bilanciare velocità e precisione in base alle esigenze specifiche dei loro processi.
Conclusioni
Con l’introduzione del RAG in un’unica chiamata e della modalità recupero solo, Amazon Bedrock offre una flessibilità senza precedenti per le applicazioni basate su conoscenza. Le imprese possono ora ottimizzare le proprie pipeline di risposta, riducendo potenzialmente latenza e costi, senza sacrificare la capacità di fornire risposte ben supportate dai propri documenti.
