AWS ha introdotto l’agentic retrieval per le Amazon Bedrock Managed Knowledge Bases, disponibile tramite la nuova API AgenticRetrieveStream. L’idea nasce da un limite noto: il retrieval classico a colpo singolo si rompe sulle domande multi-parte. Una domanda con più intenti non ha un singolo punto nello spazio degli embedding che la rappresenti bene, quindi i top-k chunk tornano come media di sotto-intenti in competizione.
L’esempio del post è chiaro: “Confronta come Amazon parlava di hiring, investimenti a lungo termine e customer obsession nel 2020 rispetto al 2023”. Con una sola query vettoriale servita su tre intenti e due periodi, si ottiene o uno sparpagliamento di chunk poco correlati o un cluster dominato dal segnale più forte. Nessuno dei due è ciò che farebbe un analista umano, che invece decompone la domanda, cerca pezzo per pezzo, nota le lacune e itera.
Agentic retrieval automatizza proprio questo. Invece di una similarity search, esegue un loop di planning guidato da un foundation model: decompone la domanda, fa retrieval su ogni parte, valuta se ha evidenza sufficiente e itera, generando di default una risposta grounded nella stessa chiamata (con generateResponse=False torna solo i chunk). Ogni passo è visibile come stream ordinato di trace event — SpeculativeRetrieval, Planning, Retrieval o FullDocumentExpansion, e Result finale con i chunk deduplicati.
Due parametri fanno la maggior parte del tuning: maxAgentIteration (3 per una singola KB, 4–5 per query multi-KB o comparative) e la configurazione del foundation model. Il routing multi-KB è ciò che le altre API non fanno: si registrano fino a cinque retriever, ognuno con una descrizione in linguaggio naturale che il planner usa per instradare i sotto-quesiti — descrizioni vaghe portano a routing vago.
Sul fronte costi, il modello managed costa 4 dollari ogni 1.000 chiamate di agentic retrieval più 1 dollaro ogni 1.000 chiamate Retrieve sottostanti; con un modello Bedrock a scelta si paga il pass-through standard più lo stesso dollaro ogni 1.000 Retrieve. AWS consiglia di pianificare i costi per iterazioni, non per token, perché sono le iterazioni a guidare costo e latency. Sui benchmark, valutato su MuSiQue (domande multi-hop), l’agentic retrieval mostra un miglioramento assoluto di recall del 20% rispetto al single-shot, con i guadagni maggiori sulle domande più difficili: +22,8 sulle 2-hop, +31,9 sulle 3-hop, +37,3 sulle 4-hop. E fa circa i passi che la domanda richiede, restando entro circa uno dall’ideale tracciato da un annotatore umano.
Il consiglio pratico di AWS: usare Retrieve per lookup diretti e ben delimitati, e AgenticRetrieveStream quando le domande sono multi-parte, comparative, esplorative o attraversano più knowledge base. E trattare i risultati come evidence, sintetizzando con un modello che si controlla.
In sintesi
- Il single-shot retrieval fallisce sulle domande multi-intento; l’agentic retrieval decompone, itera e valuta la sufficienza.
- Su MuSiQue, +20% di recall assoluto, con i guadagni più grandi sulle domande a più hop.
- Costo per chiamata (4$/1.000 col modello managed) e latency crescono con le iterazioni: da usare quando serve davvero.
Fonte: Agentic retrieval for Amazon Bedrock Managed Knowledge Base — https://aws.amazon.com/blogs/machine-learning/agentic-retrieval-for-amazon-bedrock-managed-knowledge-base/
Hai qualcosa da aggiungere? Unisciti alla discussione.