Agentic RAG: quando il retrieval diventa un loop search-read-decide

La prima applicazione LLM che molti costruiscono è una RAG: chunk, embed, retrieve, answer. Sulla carta è pulita, ma nei casi reali diventa presto problematica: la similarity search trova formulazioni simili ma non necessariamente chunk utili, l’evidenza giusta ranka troppo in basso, o il contesto importante viene spezzato tra i confini dei chunk. Con contesto insufficiente, l’LLM ha poco margine per recuperare.

L’idea dell’agentic RAG è rendere il retrieval iterativo: il modello cerca, legge, decide se ha evidenza sufficiente e cerca di nuovo quando serve. Questo tutorial costruisce un workflow minimale con l’OpenAI Agents SDK su una collezione di sei documenti di policy aziendali, dove volutamente la risposta a una domanda può non risiedere in un solo documento.

Tre tool e un loop

L’agente ha accesso a soli tre tool curati: list_docs per una panoramica dei documenti disponibili, search_docs per una ricerca keyword su chunk a livello di paragrafo (per overlap di token) e read_doc per aprire un documento per nome file. Su una domanda concreta (prenotare un hotel di conferenza sopra il cap, con relativa approvazione), la traccia mostra il comportamento atteso: l’agente prima chiama search_docs, poi list_docs, quindi apre i file rilevanti con read_doc e solo allora produce la risposta, citando i file usati per ciascuna affermazione. Un punto interessante: forse in questo schema non servono nemmeno gli embedding.

Cinque domande prima di andare in produzione

La parte più utile per chi lavora con data stack e LLM è la lista di considerazioni pratiche. Quanta libertà dare all’agente (tool curati contro accesso a shell e filesystem)? Cercare solo testo grezzo o derivare un knowledge layer (metadata, summary, link cross-documento, fino a un knowledge graph)? Servono ancora gli embedding? L’autore chiarisce che nell’agentic RAG il retrieval diventa un’azione che può essere alimentata da un retriever keyword, embedding o ibrido: gli embedding restano una delle opzioni. Un solo agente o multi-agente (planner-retriever-writer)? E soprattutto: serve sempre l’agentic RAG? La risposta è no: aggiunge flessibilità ma anche costi e comportamento meno prevedibile.

• L’agentic RAG trasforma il retrieval in un’azione iterativa: cercare, leggere, decidere, ripetere.
• Iniziare con tool curati facilita controllo, test e audit; l’accesso a shell/filesystem va aggiunto solo se la complessità lo giustifica.
• Non è sempre la scelta giusta: partire semplici e introdurre il loop agentico solo quando la domanda richiede davvero retrieval iterativo.

Fonte: Agentic RAG: Let the Agent Search — https://towardsdatascience.com/agentic-rag-let-the-agent-search/