Embedding, struttura dei dati, parametri di retrieval e LLM: come funziona una RAG oggi

 

Una RAG efficace dipende più da embedding, struttura dei dati e parametri di retrieval che dal modello linguistico.

Quando si lavora con grandi volumi di testi complessi, come norme, regolamenti o manuali tecnici, la ricerca per parola chiave non regge. Trova termini, non significati. La RAG, Retrieval-Augmented Generation, nasce per questo: affianca un modello linguistico a un sistema di recupero semantico, così che le risposte siano basate su contenuti reali e pertinenti.

Il punto centrale è spesso frainteso. Una RAG non è “un LLM con più memoria”. È un’architettura. E come tutte le architetture, funziona solo se ogni componente fa bene il suo lavoro. In particolare, tre elementi determinano quasi tutto il risultato: embedding, struttura dei dati e parametri di retrieval.

Il resto viene dopo.

Il meccanismo parte dall’embedding. Un embedding è una trasformazione: prende un testo e lo converte in un vettore numerico. Non produce frasi, non interpreta intenzioni, non decide cosa rispondere. Serve solo a posizionare contenuti diversi nello stesso spazio matematico, in modo che testi “simili nel significato” risultino vicini.

Questo passaggio avviene in due momenti precisi: quando i documenti entrano nel sistema e quando l’utente fa una domanda. Se in uno dei due casi l’embedding è debole, incoerente o inadatto al dominio, la RAG non può funzionare. Il modello generativo riceverà contesto sbagliato e farà il suo lavoro su basi fragili.

Da qui una conseguenza diretta: il problema principale non è il modello linguistico, ma ciò che gli viene passato come contesto.

Prima ancora dell’embedding, però, c’è un livello spesso sottovalutato: la struttura dei documenti. Prendere un PDF, spezzarlo in blocchi di lunghezza fissa e vettorizzarlo è una scorciatoia comune. Funziona su testi narrativi o informativi generici. Funziona molto meno su testi normativi o tecnici, dove il significato dipende dalla posizione e dalle relazioni interne.

Una legge non è solo testo. È gerarchia: titolo, articolo, comma, rimando. Se un chunk taglia un articolo a metà o separa un comma dal suo riferimento, il vettore risultante rappresenta qualcosa di semanticamente incompleto. Il database vettoriale farà comunque il suo lavoro, ma recupererà pezzi che “assomigliano” alla domanda senza contenere davvero la risposta.

Per questo, prima della RAG vera e propria, serve una normalizzazione. Il flusso corretto non è “PDF → chunk → embedding”, ma “PDF → parsing → ricostruzione logica → testo coerente → embedding”. Anche una struttura semplice, come un JSON che preserva articoli e commi, cambia radicalmente il comportamento del sistema. Riduce ambiguità, migliora il recupero e rende sostenibile lavorare su migliaia di pagine.

A questo punto entrano in gioco i parametri di retrieval. Qui è facile cadere nell’idea che basti “trovare i valori giusti”. In realtà, questi parametri funzionano solo se ciò che c’è sotto è già solido.

La dimensione del chunk definisce quanta informazione viene compressa in un singolo vettore. Chunk troppo piccoli perdono contesto. Chunk troppo grandi mescolano concetti diversi. Nei testi normativi, un intervallo medio, allineato a unità logiche come articoli o commi, è una scelta tecnica, non estetica. Se la scelta è sbagliata, non si corregge con il prompt: bisogna rigenerare i vettori.

L’overlap serve a mantenere continuità. Una sovrapposizione moderata evita che un concetto a cavallo tra due chunk venga perso. Non aggiunge conoscenza, riduce solo le fratture artificiali introdotte dal chunking.

Il top-k stabilisce quanti risultati il database restituisce. È un filtro grezzo. Seleziona i contenuti più vicini nello spazio vettoriale, ma non li ordina in modo fine. Qui molti sistemi si fermano, passando direttamente questi chunk al modello linguistico.

Il limite è evidente: similarità non significa pertinenza.

Per questo il re-ranking è il passaggio che fa la differenza. Un secondo modello, spesso più leggero, prende i risultati del top-k e li riordina valutando la domanda e i testi insieme. Non genera risposte, non usa prompt complessi. Serve solo a decidere quali contenuti sono davvero i migliori da fornire al modello generativo.

Embedding e re-ranking svolgono ruoli diversi. Il primo costruisce la mappa globale del significato. Il secondo affina localmente la scelta. Confonderli porta a sistemi instabili o sovra-ingegnerizzati.

Messa così, una RAG efficace appare meno “magica” e più ingegneristica. Il modello linguistico resta importante, ma entra in gioco alla fine, quando il contesto è già stato selezionato, pulito e ordinato.

L’implicazione è chiara per chi costruisce o valuta questi sistemi. Migliorare le risposte non significa cambiare modello ogni mese. Significa capire il dominio, rispettarne la struttura, progettare l’ingestione e trattare il retrieval come un problema a sé, non come un dettaglio.

In questo senso, una RAG assomiglia più a un sistema informativo che a un chatbot evoluto. E come tutti i sistemi informativi, riflette le decisioni prese a monte. La domanda aperta non è quanto potente sia il modello, ma quanta attenzione siamo disposti a dedicare a ciò che gli facciamo leggere prima che inizi a parlare.