Interrogare, recuperare e generare

La pipeline di query è la parte online di RAG: il codice che viene eseguito in tempo reale quando un utente pone una domanda. Collega tutti i componenti creati durante l'indicizzazione: il modello di embedding, il vector store, il template del prompt e l'LLM. Una pipeline di query ben implementata si completa in meno di 500 ms per la maggior parte dei carichi di lavoro e produce risposte basate sulle fonti e corredate da citazioni. In questa lezione creeremo ogni passaggio da zero.

Il primo passaggio consiste nel convertire la domanda in linguaggio naturale dell'utente in un embedding vettoriale utilizzando lo stesso modello usato durante l'indicizzazione. Questo embedding codifica il significato semantico della domanda e verrà confrontato con gli embedding dei chunk dei documenti nel vector store. Mantenga rapido questo passaggio: utilizzi un modello leggero come text-embedding-3-small e memorizzi nella cache gli embedding per le query identiche ripetute.

Invii il vettore della query al vector store per trovare i K chunk semanticamente più simili. Le corrispondenze restituite sono ordinate in base al punteggio di similarità coseno (in genere da 0,0 a 1,0; più alto è meglio). Il valore ideale di K bilancia la ricchezza del contesto con il costo della context window: K=5 è un punto di partenza comune. Può anche applicare qui i filtri sui metadati per limitare il recupero a un reparto, un tipo di documento o un intervallo di date specifico.

Non tutti i chunk recuperati sono realmente pertinenti: alcuni possono avere punteggi di similarità bassi, ma classificarsi comunque tra i Top-K perché la query non rientra nella copertura dell'indice. Applichi una soglia minima del punteggio per eliminare le corrispondenze con bassa confidenza. Se tutti i chunk recuperati sono al di sotto della soglia, restituisca una risposta del tipo "nessuna informazione trovata" invece di inviare contesto irrilevante all'LLM, che produrrebbe una risposta peggiore di un rifiuto formulato correttamente.

Assembli i chunk recuperati in un blocco di contesto strutturato che l'LLM possa leggere. Indichi la fonte di ogni chunk, così il modello potrà citarla accuratamente. Inserisca un separatore tra i chunk per maggiore chiarezza. Mantenga il contesto complessivo entro il proprio budget di token: conti i token con tiktoken e tronchi o elimini i chunk con punteggio più basso se supera il limite. Il blocco di contesto viene inserito nel prompt tra l'istruzione di sistema e la domanda dell'utente.

Combini il blocco di contesto, l'istruzione di sistema e la domanda dell'utente nel prompt finale. Il messaggio di sistema indica al modello di utilizzare solo il contesto fornito e di citare le fonti. Il messaggio dell'utente contiene il contesto formattato seguito dalla domanda. Questa netta separazione impedisce al modello di confondere il contenuto del contesto con la domanda e rende inequivocabile il confine tra i dati recuperati e l'input dell'utente.

Invii il prompt assemblato all'LLM utilizzando la Chat Completions API. Utilizzi una temperatura bassa (da 0,0 a 0,3) per le domande e risposte fattuali, così da ottenere risposte coerenti e basate sulle fonti. Temperature più alte producono risposte più creative, ma aumentano il rischio che il modello aggiunga informazioni non presenti nel contesto. Analizzi la risposta e restituisca sia il testo della risposta sia le fonti recuperate, in modo che l'applicazione possa mostrare le citazioni all'utente.

La pipeline di query completa esegue questi passaggi in sequenza. Ogni passaggio è una funzione pura che può essere testata in modo indipendente, e i dati passano ordinatamente da un passaggio a quello successivo. L'aggiunta di log a ogni passaggio rende la pipeline osservabile: è possibile vedere esattamente quali chunk sono stati recuperati, quale punteggio avevano, come è stato assemblato il contesto e quanti token sono stati utilizzati. Questa visibilità è essenziale per il debugging e per migliorare la qualità del recupero.

La pipeline di query presenta due passaggi vincolati dall'I/O: la chiamata per l'embedding e la chiamata all'LLM. Li esegua senza attese non necessarie: la chiamata per l'embedding è rapida (<100 ms), mentre quella all'LLM è lenta (500 ms-3 s). Per ridurre la latenza percepita, trasmetta in streaming la risposta dell'LLM, in modo che i token compaiano man mano che vengono generati anziché attendere la risposta completa. Memorizzi nella cache l'embedding delle query identiche ripetute per evitare chiamate API ridondanti.

Le pipeline RAG in produzione richiedono un logging strutturato per poter diagnosticare i casi in cui il recupero non funziona o l'LLM fornisce una risposta errata. Registri per ogni richiesta la query, gli ID e i punteggi dei chunk recuperati, il numero di token del contesto, la risposta e la latenza. Memorizzi questi log in un database o in una piattaforma di osservabilità. Quando gli utenti segnalano risposte errate, può riprodurre la query esatta e verificare quali chunk sono stati recuperati e perché non erano sufficienti.

Se l'applicazione riceve molte query ripetute o quasi identiche, come nel caso dei bot FAQ in cui gli utenti pongono spesso le stesse domande, la memorizzazione nella cache degli embedding delle query è un'ottimizzazione semplice e molto efficace. Calcoli l'hash della stringa della query, verifichi nella cache Redis la presenza dell'embedding corrispondente e chiami l'API per gli embedding solo in caso di cache miss. In produzione, nei bot FAQ e nei chatbot di supporto sono comuni tassi di cache hit degli embedding del 30-60%; ciò elimina una parte consistente dei costi delle API e riduce la latenza di 50-100 ms per ogni query servita dalla cache.

In questa lezione ha imparato a utilizzare: la pipeline di query in sei passaggi (incorporare la query, recuperare i chunk, filtrare in base al punteggio, formattare il contesto, creare il prompt e generare la risposta), il filtro basato sulla soglia del punteggio per gestire le query al di fuori della copertura dell'indice e i miglioramenti per la produzione, tra cui le risposte in streaming, il logging strutturato e l'ottimizzazione della latenza. Nel prossimo capitolo impareremo a valutare se il sistema RAG completo funziona effettivamente in modo corretto.