RAG

RAG: dare ai modelli il contesto giusto, nella quantità giusta

Un LLM senza contesto inventa, un LLM annegato nel contesto si perde. Il Retrieval-Augmented Generation serve a dare al modello esattamente le informazioni che gli servono, al momento giusto, e la qualità del recupero e dei dati pesa quanto il modello. Questa categoria affronta il RAG come un problema di ingegneria dell'informazione.

Si parte dal recupero come problema di dati. Vector database come Weaviate e Qdrant, multi-vector e ColBERT, GraphRAG, ed embeddings costruiti su un vocabolario di dominio, italiano incluso: quando il RAG non trova i documenti giusti, quasi sempre bisogna guardare agli embedding e al modo in cui i dati sono stati indicizzati.

Poi i costi e la scala: la quantization per ridurre drasticamente la VRAM a parità di recall, approcci come LazyGraphRAG per abbattere il costo di indicizzazione, il semantic caching per non ripagare ogni query semanticamente identica. Un RAG che funziona ma costa troppo non arriva mai in produzione.

E la sicurezza: un RAG aziendale indicizza documenti interni, e un documento avvelenato può diventare un vettore di prompt injection. Un'implementazione seria comprende il red team sul sistema RAG e le difese applicative che ne seguono.

Se vuoi costruire un sistema RAG sui tuoi dati, vedi l'integrazione di sistemi e AI o scrivimi.

Se il recupero è scadente, nessun LLM ti salverà: nel RAG contano prima di tutto i dati.