The Pulse

AWS aggiunge a Bedrock il recupero single-shot e quello dei soli passaggi

Amazon Bedrock Managed Knowledge Base supporta ora la generazione di risposte single-shot e il recupero senza generazione di una risposta tramite AgenticRetrieveStream. AWS afferma che gli sviluppatori possono scegliere tra queste modalità

AI.info Team · Scritto con l’IA · verificato · 2026-11-09

Una API, tre modalità di recupero

AWS afferma che Amazon Bedrock Managed Knowledge Base supporta ora la Retrieval Augmented Generation (RAG) single-shot e le richieste di solo recupero tramite AgenticRetrieveStream. Le nuove opzioni consentono a un’applicazione di recuperare passaggi e generare una risposta a partire da essi oppure restituire il testo delle fonti senza generarne una. Il servizio mantiene anche il recupero agentico, che pianifica ed esegue più ricerche prima di produrre una risposta. AWS presenta la modifica come un modo per scegliere quanto lavoro di recupero applicare a ciascuna richiesta attraverso la stessa API.

Il parametro chiave è maxAgentIteration, il cui intervallo di valori supportati è ora 0–5. AWS afferma che il valore 0 restituisce i passaggi senza effettuare una chiamata a un modello di base, mentre 1 esegue un recupero e genera una risposta. I valori da 2 a 5 mantengono il recupero agentico, consentendo fino a n meno 1 cicli di pianificazione prima della generazione della risposta. L’azienda afferma che ogni ciclo di pianificazione comprende una riscrittura della query e un recupero, mentre l’ultima iterazione è riservata alla generazione della risposta. Secondo AWS, un recupero speculativo eseguito prima della prima fase di pianificazione non viene conteggiato ai fini di maxAgentIteration.

Scegliere quanto recuperare

Con maxAgentIteration=0, la richiesta deve impostare generateResponse su false; AWS afferma che impostarlo su true restituisce un errore 4xx. Secondo l’azienda, maxAgentIteration=0 equivale a chiamare direttamente l’API Retrieve, anche se il formato della risposta è diverso. Con maxAgentIteration=1 e la generazione della risposta attivata, AWS afferma che il servizio esegue un solo recupero e genera una risposta basata sulle informazioni recuperate, senza pianificazione né riscrittura della query. AWS afferma che la RAG single-shot usa una chiamata a un modello di base per generare la risposta, il che può ridurre la latenza e l’utilizzo del modello rispetto al recupero agentico.

Il post afferma che tutte e tre le modalità supportano più basi di conoscenza, anche con i valori 0 e 1. Per le domande più complesse, il recupero agentico può suddividere una richiesta in sottoquery, cercare tra le basi di conoscenza, valutare gli elementi raccolti e affinare le ricerche se mancano informazioni. AWS afferma che la generazione della risposta può combinare le informazioni recuperate in una risposta con citazioni, mentre gli eventi di tracciamento rendono visibili le fasi di pianificazione e recupero.

Gli esempi usano un assistente bancario fittizio

Per una domanda diretta sui documenti necessari per il conto corrente aziendale di un imprenditore individuale, l’esempio imposta maxAgentIteration=1 e generateResponse=true. Per un confronto tra strutture aziendali e verifiche sulla proprietà, l’esempio imposta maxAgentIteration=4, consentendo fino a tre cicli di pianificazione prima di una risposta. AWS avverte che il limite di iterazioni appropriato dovrebbe essere valutato sulla base di domande rappresentative, anziché presumere che un valore più alto migliori sempre i risultati.

Per i dipendenti che devono esaminare il testo delle policy anziché ricevere un riepilogo generato, l’esempio imposta maxAgentIteration=0 e generateResponse=false per restituire i passaggi senza chiamate al modello linguistico. È l’applicazione, non il parametro, a scegliere quale modalità di recupero usare per una richiesta. AWS raccomanda di testare le modalità con domande rappresentative e risposte attese, confrontando latenza, costo delle richieste, correttezza e verificando se i passaggi recuperati supportano le risposte. Il post afferma che le richieste esistenti che usano valori da 2 a 5 mantengono il comportamento attuale, consentendo agli sviluppatori di introdurre le nuove modalità in modo selettivo.