Come abbiamo reso RAG il 50% più veloce

RAG migliora l'accuratezza degli agenti IA basando le risposte degli LLM su ampie knowledge base. Anziché inviare l'intera knowledge base all'LLM, RAG incorpora la query, recupera le informazioni più pertinenti e le passa al modello come contesto. Nel nostro sistema, aggiungiamo prima una fase di riscrittura della query, che sintetizza la cronologia del dialogo in una query precisa e autonoma prima del recupero.

Per knowledge base molto piccole, può essere più semplice inserire tutto direttamente nel prompt. Ma quando la knowledge base diventa più ampia, RAG diventa essenziale per mantenere accurate le risposte senza sovraccaricare il modello.

Molti sistemi trattano RAG come uno strumento esterno, ma noi lo abbiamo integrato direttamente nella pipeline delle richieste, così viene eseguito per ogni query. Questo garantisce un'accuratezza costante, ma comporta anche un rischio di latenza.

Perché la riscrittura delle query ci rallentava

La maggior parte delle richieste degli utenti fa riferimento a turni precedenti, quindi il sistema deve sintetizzare la cronologia del dialogo in una query precisa e autonoma.

Per esempio:

• Se l'utente chiede: “Possiamo personalizzare quei limiti in base ai nostri picchi di traffico?”
• Il sistema la riscrive così: “I limiti di frequenza delle API del piano Enterprise possono essere personalizzati per specifici pattern di traffico?”

La riscrittura trasforma riferimenti vaghi come “quei limiti” in query autonome che i sistemi di recupero possono utilizzare, migliorando il contesto e l'accuratezza della risposta finale. Tuttavia, fare affidamento su un unico LLM fornito esternamente creava una forte dipendenza dalla sua velocità e disponibilità. Questa fase da sola rappresentava oltre l'80% della latenza di RAG.

Come abbiamo risolto con il model racing

Abbiamo riprogettato la riscrittura delle query per eseguirla come una gara:

• Più modelli in parallelo. Ogni query viene inviata contemporaneamente a più modelli, inclusi i nostri modelli Qwen 3-4B e 3-30B-A3B forniti internamente. Vince la prima risposta valida.
• Fallback che mantengono fluide le conversazioni. Se nessun modello risponde entro un secondo, usiamo il messaggio originale dell'utente. Potrebbe essere meno preciso, ma evita blocchi e garantisce continuità.

L'impatto sulle prestazioni

Questa nuova architettura ha dimezzato la latenza mediana di RAG, da 326 ms a 155 ms. A differenza di molti sistemi che attivano RAG in modo selettivo come strumento esterno, noi lo eseguiamo per ogni query. Con una latenza mediana ridotta a 155 ms, il sovraccarico è trascurabile.

Latenza prima e dopo:

• Mediana: 326 ms → 155 ms
• p75: 436 ms → 250 ms
• p95: 629 ms → 426 ms

L'architettura ha նաև reso il sistema più resiliente alla variabilità dei modelli. Mentre i modelli forniti esternamente possono rallentare nelle ore di picco della domanda, i nostri modelli interni rimangono relativamente costanti. Far competere i modelli attenua questa variabilità, trasformando prestazioni individuali imprevedibili in un comportamento del sistema più stabile.

Per esempio, quando uno dei nostri fornitori di LLM ha avuto un'interruzione del servizio il mese scorso, le conversazioni sono proseguite senza problemi sui nostri modelli forniti internamente. Dato che utilizziamo già questa infrastruttura per altri servizi, il costo di calcolo aggiuntivo è trascurabile.

Perché è importante

La riscrittura delle query RAG in meno di 200 ms elimina un importante collo di bottiglia per gli agenti conversazionali. Il risultato è un sistema che mantiene sia il contesto sia l'operatività in tempo reale, anche con ampie knowledge base aziendali. Con il sovraccarico del recupero ridotto a livelli quasi trascurabili, gli agenti conversazionali possono scalare senza compromettere le prestazioni.