La maggior parte delle pipeline RAG usa un default preciso: recupera i top-k candidati e li passa tutti in un unico prompt al modello di generazione. Funziona, ma su molte domande è uno spreco. Un articolo su Towards Data Science, firmato Kezhan Shi, cataloga il secondo regime — sequential, top-1 first — e spiega quando ciascuno conviene.
L’esempio è concreto. Alla domanda “qual è la data di efficacia di questa policy?”, il retrieval restituisce cinque line-window dove compare la parola “effective”. La prima contiene già la risposta; le altre quattro sono firme, note a piè di pagina e paragrafi su date storiche. In modalità batch il modello legge tutti e cinque i chunk per estrarre la stessa data che il primo conteneva già. Su un corpus di 50.000 policy, questo è denaro reale ogni mese.
Il regime sequenziale
L’idea è trattare i k candidati come lista ordinata e chiedere al brick di generazione di validare la sufficienza a ogni passo. Il contratto tipizzato espone due booleani, answer_found e complete_answer_found: found + complete ferma il loop, found + incomplete passa al candidato successivo, not found continua o si arrende a k. Due booleani non “driftano” da un modello all’altro come farebbe una soglia su un valore di confidence.
Il loop ha tre uscite: sufficienza, esaurimento dei k candidati e budget di token o tempo imposto dal dispatcher, per evitare che un caso limite bruci token all’infinito.
Batch resta il default giusto per alcune domande
Il regime batch vince su tre tipi di domanda: le listing (“elenca tutte le esclusioni”), dove la risposta è ogni candidato che matcha; le comparison, che richiedono più candidati nella stessa call per confrontarli; e i casi in cui gli score di rilevanza dei top-k sono entro il 5% l’uno dall’altro. La scelta, sottolinea l’autore, va fatta per domanda e non per pipeline, letta dal question parser — non decisa dall’LLM, così l’audit trail resta intatto.
Sul back-of-envelope proposto (100 domande al giorno, k=5, chunk da 600 token, 80% risolvibili col top-1), il sequential porta il costo di input della generazione da circa 330k a circa 115k token al giorno, ovvero circa il 65% di risparmio.
In sintesi
- Sequential (top-1 first) taglia i token sulle domande fattuali, la maggioranza del traffico enterprise.
- Due booleani di sufficienza guidano il loop in modo deterministico, con tre uscite: sufficienza, esaurimento, budget.
- Batch resta il default per listing, comparison e retrieval con score ravvicinati; la scelta la fa il parser, per domanda.
Fonte: Loop Engineering for RAG Generation: Iterate top-k One at a Time — towardsdatascience.com
Hai qualcosa da aggiungere? Unisciti alla discussione.