Perché serve RAG

Un foundation model conosce solo ciò che era presente nei dati di addestramento: non ha visibilità sui documenti interni, sui listini aggiornati o sulle policy della tua organizzazione. Interrogarlo su informazioni che non possiede porta a due esiti indesiderati: risposte generiche o hallucination. Le strade per fornirgli i propri dati sono essenzialmente due. Il fine-tuning ri-addestra il modello: efficace per stile e formato, ma costoso e da rifare a ogni aggiornamento dei dati. Il RAG (retrieval-augmented generation) segue una logica diversa: non tocca i pesi del modello, ma al momento della domanda recupera i documenti pertinenti e li inietta nel prompt come contesto aggiuntivo.

Il RAG è la scelta di default quando i dati cambiano spesso, servono citazioni verificabili e non si vuole sostenere il costo e la complessità di un training. La risposta risulta così ancorata (grounded) ai propri dati anziché alla sola conoscenza generica del modello.

Il cuore del RAG è saper individuare, tra migliaia di documenti, quelli davvero rilevanti per la domanda. Qui entrano gli embeddings: un embedding model trasforma un testo in un vettore numerico che ne cattura il significato. Testi dal significato simile producono vettori vicini nello spazio vettoriale, anche quando usano parole diverse.

Questa è la base della semantic search (ricerca semantica): a differenza della ricerca per keyword, che cerca corrispondenze letterali, la semantic search recupera per similarità di significato. Trova quindi un documento su “auto elettriche” anche se l’utente ha scritto “veicoli a batteria”. In pratica i documenti vengono spezzati in blocchi (chunking), ogni blocco convertito in embedding e archiviato. All’arrivo della domanda si calcola l’embedding della query e si recuperano i chunk con i vettori più vicini: diventano il contesto passato al foundation model, che genera la risposta.

Vector database e Amazon Bedrock Knowledge Bases

Un vector database è ottimizzato per memorizzare e cercare vettori ad alta dimensionalità con bassa latenza — un compito per cui un database relazionale tradizionale non è pensato. Su AWS questo ruolo può essere svolto, tra gli altri, da Amazon OpenSearch Service e da Amazon Aurora PostgreSQL con l’estensione pgvector.

Gestire manualmente l’intera pipeline — ingestione, chunking, generazione degli embeddings, indicizzazione, retrieval — è oneroso. Amazon Bedrock Knowledge Bases è il servizio gestito che orchestra questo flusso: si collega a una sorgente dati (tipicamente un bucket Amazon S3), automatizza chunking ed embeddings, popola il vector store e, in fase di query, recupera i passaggi rilevanti e li fornisce al modello per una risposta grounded, spesso con citazioni alle fonti. È il modo AWS-native di implementare RAG senza costruire l’infrastruttura da zero, e può essere collegato anche agli agent di Amazon Bedrock. Per l’esame è sufficiente ricordare l’equazione: Bedrock Knowledge Bases = RAG gestito su AWS.

Trappole tipiche d’esame

  • Dati privati o aggiornati di frequente senza ri-addestrare → RAG, non fine-tuning: il RAG aggiunge conoscenza a runtime; aggiorni la sorgente dati e le risposte cambiano, senza toccare il modello.
  • Ridurre le hallucination con fonti verificabili → RAG con citazioni: ancorare le risposte a documenti recuperati e mostrarne le fonti è il pattern giusto; il fine-tuning da solo non fornisce citazioni.
  • Cambiare stile, tono o formato dell’output → fine-tuning, non RAG: il RAG fornisce contesto e conoscenza, non modifica il comportamento del modello. Se la domanda parla di “adattare il modo di rispondere”, la risposta è fine-tuning.
  • Query con sinonimi o parafrasi che la ricerca per keyword non intercetta → embeddings + semantic search: la ricerca semantica recupera per significato, non per corrispondenza letterale delle parole.
  • Dove archiviare gli embeddings per il retrieval → vector database: non un database relazionale generico; su AWS pensa a OpenSearch Service o Aurora/pgvector.
  • Implementare RAG su AWS senza gestire l’infrastruttura → Amazon Bedrock Knowledge Bases: è la scelta gestita end-to-end; costruire a mano chunking, embeddings e indicizzazione è l’opzione da scartare in uno scenario foundational.