Amazon Bedrock porta l'agentic retrieval nelle knowledge base

Su domande a più parti, la Managed Knowledge Base di Amazon Bedrock separa gli intenti, lancia ricerche mirate e recupera fonti più varie rispetto alla sola similarity search. Il percorso è visibile nelle tracce di esecuzione, che mostrano scelte e ordine dei passaggi¹.

Il caso d’uso è concreto: confronto tra due prodotti su tre dimensioni con LangChain. La similarity search usa un unico vettore di query. Quel vettore comprime intenti diversi. I punteggi di rilevanza restano alti, ma i chunk coprono solo una fetta della richiesta. Il risultato suona credibile, però lascia fuori parti del problema¹.

Nel post, gli autori eseguono la stessa domanda in due modi: retrieval standard e retrieval agentico su Amazon Bedrock Managed Knowledge Base, sempre con LangChain. Non guardano solo l’output finale. Aprono le tracce, leggono il piano generato dal modello e seguono gli step che portano alle fonti. Così misurano come cambia la copertura dei sotto-temi lungo il percorso¹.

Qui sta il limite strutturale della similarity search: un singolo embedding deve rappresentare intenti multipli. Con query lineari funziona. Con richieste composte, restituisce una media degli intenti, non una copertura completa. Da qui risposte ordinate ma incomplete quando l’utente compatta molti aspetti in un unico prompt¹.

Il retrieval agentico affronta la richiesta per parti. Non riscrive la domanda. Scompone l’obiettivo, decide cosa cercare e in quale sequenza, poi collega le evidenze prima della generazione. Le tracce rendono espliciti questi passaggi: query formulate, risorse consultate, criteri di aggregazione. L’effetto, nel confronto pubblicato, è maggiore varietà dei documenti pertinenti e minori “zone d’ombra” nella risposta¹.

Gli autori toccano anche il tema dei costi operativi. Mettono a confronto il percorso più economico e quello più costoso e indicano quando conviene ciascuno. La valutazione non isola il prezzo: intreccia qualità della risposta ed efficienza del recupero, con esempi che mostrano come la copertura vari al variare della strategia di ricerca e dell’impatto computazionale¹.

Indicazioni pratiche:

• Domande multi-intento: preferisci il retrieval agentico. Aumenta la copertura delle parti rilevanti e rende ispezionabili le scelte fatte lungo la ricerca¹.
• Domande semplici: resta sul retrieval standard. È più leggero e spesso sufficiente¹.
• In entrambi i casi: apri le tracce. Verifica come il sistema ha interpretato la richiesta, quali fonti ha recuperato e dove si concentrano i risultati. Se noti sbilanciamenti, passa a una strategia che separi gli intenti e controlla nelle tracce che ogni sotto-tema abbia avuto una ricerca dedicata¹.

Questa visibilità operativa non è un dettaglio per chi mantiene sistemi RAG: consente di diagnosticare lacune di copertura, correlare qualità e costo per scenario, e decidere quando vale la pena investire in un percorso di ricerca più articolato¹.