La tua pipeline RAG supera un test di carico standard con successo. La latenza p95 sembra ottimale. I tassi di errore sono vicini allo zero. Eppure, gli utenti segnalano risposte che evitano la domanda, citano documenti inesistenti o tirano fuori paragrafi irrilevanti da un white paper caricato sei mesi fa. La dashboard dice che tutto va bene. L'esperienza d'uso dice che è tutto rotto.
Questa discrepanza esiste perché i test di performance convenzionali sono stati progettati per sistemi request-response, non per sistemi che "pensano". Quando invii mille richieste parallele a un endpoint REST, scopri se i tuoi server rimangono in piedi. Non scopri nulla sul fatto che il tuo livello di retrieval recuperi i chunk corretti, che il tuo prompt template preservi il contesto o che il modello inventi fonti quando il vector store è vuoto. Il load testing standard misura la velocità. Le applicazioni RAG richiedono che tu misuri la comprensione.
Oltre lo Status Code 200
Un tipico test di carico API controlla tre cose: disponibilità, latenza e throughput. Verifica se il server ha risposto, quanto tempo ci è voluto e quanti utenti concorrenti è riuscito a gestire. Per un'applicazione RAG, questi numeri sono prerequisiti, non conclusioni. Una risposta errata veloce è comunque una risposta errata, e le risposte errate su larga scala costano più di quelle lente.
Il RAG aggiunge due fasi distinte a ogni richiesta. Primo, il sistema trasforma la domanda dell'utente in un embedding, interroga un vector store e recupera un set di chunk di contesto. Secondo, inserisce quei chunk in un prompt, invia tutto a un modello linguistico e restituisce in streaming una completion. I test tradizionali spesso accorpano queste fasi in un'unica metrica di "tempo di risposta". Trattano il motore di retrieval e il generatore come un'unica black box.
Devi aprire quella scatola. Se il tuo database vettoriale rallenta sotto carico, la latenza di retrieval aumenta. L'LLM potrebbe comunque rispondere velocemente, ma lo farà basandosi su un contesto spazzatura recuperato in fretta. In alternativa, la ricerca vettoriale rimane rapida mentre la coda dell'LLM si accumula, aumentando il time-to-first-token finché gli utenti non rimangono a fissare un cursore lampeggiante. Un singolo timer end-to-end nasconde entrambi i fallimenti.
Testa il Retrieval, non solo il Database
La maggior parte dei team esegue un rapido benchmark della ricerca vettoriale e considera testato il livello di retrieval. Quel benchmark di solito misura quanto velocemente il database restituisce i nearest neighbors per una query selezionata manualmente. Raramente misura se quei vicini contengano effettivamente la risposta.
La qualità del retrieval cambia con il carico in modi sottili. Sotto pressione concorrente, gli indici approximate nearest neighbor possono comportarsi diversamente rispetto a quando sono isolati. Le strategie di chunking che sembravano perfette in un notebook iniziano a far trasbordare il contesto oltre i confini quando diecimila documenti competono per lo stesso spazio di embedding. Una query che restituisce il paragrafo ideale in un ambiente tranquillo potrebbe far emergere una slide di marketing fuorviante quando l'indice si sta ricostruendo o quando il filtraggio dei metadati viene rimosso sotto la pressione delle richieste.
Per testare questo aspetto correttamente, hai bisogno di un dataset ground-truth. Seleziona domande per le quali sai già quali documenti sorgente dovrebbero apparire. Esegui quelle domande a vari livelli di concorrenza e controlla se i chunk attesi finiscono tra i risultati top-k. Monitora l'hit rate, non solo la durata della query. Se i tuoi primi cinque chunk mancano completamente la fonte critica, la tua pipeline di retrieval è fallita prima ancora che l'LLM si svegliasse.
Dovresti anche sottoporre a stress-test i casi limite. Invia query che non hanno risposta nel corpus. Invia domande ambigue che potrebbero riferirsi a più domini. Invia domande lunghe che superano il limite di token del tuo modello di embedding e vengono troncate silenziosamente. Osserva cosa restituisce il livello di retrieval. In ogni caso, la modalità di fallimento conta più dei millisecondi trascorsi.
Quando il modello va in crisi silenziosamente
Una volta che i chunk raggiungono l'LLM, il load testing standard continua a mentire