Agentic RAG sostituisce un singolo retrieval con un loop: il modello recupera, legge, decide che gli serve altro, recupera di nuovo, e ripete finché non è soddisfatto. Ogni hop è un round trip completo al modello più una ricerca, e gli hop sono sequenziali perché ognuno dipende dal precedente. Per la maggior parte delle domande, questo compra una risposta marginalmente migliore a diverse volte la latenza, quando una query ben costruita avrebbe restituito lo stesso contesto in un solo passaggio. Il retrieval multi-hop è uno strumento vero per una classe ristretta di domande, e un default che triplica silenziosamente il tempo di risposta ovunque altrove.

Il modo utile di vederla: il retrieval agentico scambia latenza per la capacità di scomporre una domanda a runtime. Quel baratto vale la pena solo quando la domanda ha davvero bisogno di essere scomposta. La maggior parte non ne ha bisogno, e pagare la tassa del loop su domande a cui basta una singola query è il modo più comune in cui i sistemi RAG diventano lenti senza guadagnarci nulla.

Da dove viene la latenza

Il RAG a singolo passaggio è un embedding, una ricerca vettoriale, una chiamata al modello. Agentic RAG è un loop, e il loop è seriale per costruzione: il modello non può emettere la seconda query finché non ha letto i risultati della prima. Quindi il costo in tempo reale non è un retrieval più una generazione, è la somma della ricerca di ogni hop, della chiamata al modello di ogni hop per decidere cosa fare dopo, e della generazione finale. Tre hop sono grosso modo il triplo dei round trip, e siccome ogni chiamata al modello rilegge anche il contesto accumulato, il costo per hop tende a crescere invece di restare piatto.

Niente di tutto questo è lavoro nascosto che l'utente ha chiesto. Dal suo punto di vista è una domanda sola che ora richiede otto secondi invece di due. Se quegli otto secondi non hanno comprato una risposta materialmente migliore, hai speso il tuo budget di latenza per niente.

Una buona query batte un loop intelligente, di solito

Una quantità sorprendente di agentic RAG esiste per compensare una prima query debole. Se il retrieval iniziale tira fuori i chunk sbagliati, il compito del loop diventa "accorgersi che il contesto è scarso e andare a prenderne uno migliore", che è un costoso recupero da errore. Sistema la query e il loop spesso non ha più nulla da fare.

Prima di ricorrere al multi-hop, spendi lo sforzo sul singolo passaggio:

  • Riscrivi la query. Una chiamata al modello economica per trasformare una domanda utente disordinata in una query di ricerca pulita migliora il retrieval più di un secondo hop, a una frazione della latenza.
  • Recupera di più, poi riordina. Tira fuori un insieme di candidati più ampio in una ricerca sola e riordinalo, invece di fare diverse ricerche strette in sequenza.
  • Sistema i chunk. La maggior parte dei retrieval scarsi è un problema di chunking. Chunk migliori fanno atterrare la prima query, e il loop diventa superfluo.

Questi sono tutti miglioramenti a singolo passaggio. Alzano la qualità della risposta senza aggiungere un round trip seriale, che è l'opposto di ciò che fa il loop.

Quando il retrieval agentico vince davvero

Il loop si guadagna la sua latenza per domande che genuinamente non possono avere risposta con una sola query, perché la seconda query dipende dalla risposta della prima. Il caso più chiaro è il ragionamento multi-hop su fatti da concatenare: "quali dei nostri fornitori nella regione colpita dalla nuova normativa hanno il rinnovo in scadenza questo trimestre" è in realtà tre ricerche dove ognuna restringe la successiva, e nessun singolo retrieval contiene la risposta unita.

Il pattern da cercare è una dipendenza genuina tra i retrieval: non puoi scrivere la seconda query finché non conosci il risultato della prima. Quando quella dipendenza è reale, il loop sta facendo lavoro necessario e la latenza è il prezzo di una risposta che altrimenti non avresti ottenuto. Quando è assente, e di solito lo è, il loop è macchinario elaborato per una domanda a cui una singola query avrebbe già risposto.

Decidi per domanda, non per sistema

Il fallimento è rendere il retrieval agentico il default per ogni richiesta. Un design migliore instrada: le domande economiche prendono il singolo passaggio, e solo le domande che mostrano un segnale di scomposizione, entità multiple, una condizione concatenata, un "confronta tra" esplicito, salgono al loop. Un piccolo classificatore o anche un'euristica davanti al retrieval può prendere quella decisione. L'obiettivo è pagare la tassa multi-hop esattamente sulle domande che la ripagano, e mai su quelle che non lo fanno.

Il punto chiave

Agentic RAG non è sbagliato, è sovra-applicato. Trasforma il retrieval in un loop seriale di round trip al modello, e per la grande maggioranza delle domande a cui una buona query basta, quel loop è pura latenza. Spendi il tuo sforzo prima sul singolo passaggio: riscrivi la query, recupera più ampio e riordina, e sistema i chunk. Riserva il multi-hop alle domande con una dipendenza reale tra i retrieval, e instrada verso di esso per domanda invece di mettere l'intero sistema in default su quello. Il sistema RAG più veloce è quello che fa il loop solo quando la domanda lo richiede davvero.

Leggi questo dopo

Per l'infrastruttura dietro il retrieval a bassa latenza su scala, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.