Nel dibattito sull’ottimizzazione dei sistemi RAG si affaccia un concetto che l’autore di Towards Data Science chiama «loop engineering», presentato come terza evoluzione dopo prompt e context engineering. L’articolo si concentra sul ciclo più piccolo e concreto possibile: un singolo turno di chiarimento che avviene durante il question parsing, prima ancora che il retrieval inizi.
Il problema: domande vaghe e retrieval rumoroso
La tesi di partenza è solida e nota a chiunque abbia messo in produzione un RAG: quando l’utente pone una domanda ambigua, il recupero ingenuo fallisce. L’esempio scelto è una polizza assicurativa: chiedere «qual è il premio?» senza indicare la sezione porta il sistema a restituire clausole di esclusione e testo di contorno anziché la tabella dei premi. Il punto non è la potenza del modello, ma la mancanza di informazione strutturata nella query.
La soluzione: un ciclo limitato a un turno
La proposta è un loop vincolato e a iterazione singola. Il parsing iniziale prova a riempire uno schema fisso di campi tipizzati (keyword, intent, section_hint, layout_hint, pages_hint); se un campo resta vuoto, il sistema formula una domanda mirata all’utente, ri-effettua il parsing con la risposta e prosegue. Il ciclo «non inventa mai nuovi campi»: arricchisce solo quelli già definiti nella pipeline. Tre casi pratici illustrano il guadagno: da 47 pagine a 1 quando si chiede in quale posizione compare il nome del cliente, e da un documento intero a circa 11 pagine quando l’utente risponde «verso la metà».
Non è agentic RAG (ed è un bene che l’autore lo dica)
La distinzione più utile dell’articolo è quella dal RAG agentico: qui la logica decisionale è scritta dall’ingegnere, non pianificata dal modello; il ciclo scatta solo su gap verificabili, aggiunge al massimo un round-trip e resta invisibile ai componenti a valle, che ricevono comunque un oggetto ParsedQuestion completo. Va detto che le cifre citate (da 47 a 1, da 32 a 11 pagine) sono esempi illustrativi dell’autore, non un benchmark misurato: vanno letti come dimostrazione del pattern, non come garanzia di prestazioni.
In sintesi
- Il «loop engineering» qui è concreto: un solo turno di chiarimento nel parsing, prima del retrieval.
- Il valore sta nel riempire uno schema tipizzato di hint, non nel dare più autonomia al modello.
- La differenza dall’agentic RAG (logica deterministica, gap verificabili, latenza limitata) è ciò che rende il pattern adottabile in produzione.
Fonte: Loop Engineering for RAG: Question Parsing, the Small Loop That Runs Before Retrieval
Hai qualcosa da aggiungere? Unisciti alla discussione.