Che cos'è il RAG (Retrieval-Augmented Generation)?

Il RAG è una tecnica che recupera documenti al momento della query e li aggiunge al prompt, perché un LLM risponda a partire dai dati e non dalla memoria. Introdotto da Lewis et al. nel 2020, è l’esame a libro aperto contro quello a libro chiuso di un modello nudo: invece di affidarsi a ciò che ha memorizzato durante l’addestramento, il modello consulta il materiale che gli viene fornito e risponde a partire da quello – ancorato, attuale, capace di sfruttare dati privati e, poiché le fonti sono note, citabile. Per chi sviluppa backend la verità rassicurante sotto l’hype è che il RAG non è un framework da adottare: è un ciclo for che si sa già scrivere.

Punti chiave

Le due fasi

INGESTIONE (offline, una volta per documento)
  caricare → suddividere in chunk (~qualche centinaio di token, con sovrapposizione)
           → trasformare ogni chunk in un vettore
           → salvare vettore + testo + metadati di ACL in un indice

QUERY (online, a ogni domanda)
  embedding della domanda → ricerca per similarità dei top-k chunk (di solito 5–10)
           → filtrare in base a ciò che QUESTO utente può leggere
           → aggiungere i chunk al prompt
           → l'LLM genera una risposta ancorata a essi (+ citazioni)

Tutta la fase online, lato server, in una sola funzione:

// JavaScript — Cloud Code (cloud/main.js): RAG is a for-loop, not a framework
Parse.Cloud.define('askDocs', async (req) => {
  // 1 · embed the question (LLM API key stays server-side)
  const qVec = await embed(req.params.question);

  // 2 · retrieve — similarity search, ACL-FILTERED to this user's docs
  const chunks = await vectorSearch('DocChunk', qVec, {
    limit: 6,
    aclUser: req.user, // never retrieve what the asker can't read
  });

  // 3 · augment + generate
  const context = chunks.map((c) => c.get('text')).join('\n---\n');
  return await complete(`Answer using ONLY this context:\n${context}\n\nQ: ${req.params.question}`);
  // Answer cites the retrieved chunks — grounded, and permission-safe.
});

// Flutter / Dart — Back4app Flutter SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
final answer = await ParseCloudFunction('askDocs')
    .execute(parameters: {'question': 'What is our refund window?'});
print(answer.result); // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

// iOS / Swift — Back4app Swift SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
let answer: String = try await Cloud.run(
    name: "askDocs",
    parameters: ["question": "What is our refund window?"])
print(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

// Android / Kotlin — Back4app Android SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
val params = mapOf("question" to "What is our refund window?")
val answer = ParseCloud.callFunction<String>("askDocs", params)
println(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

Perché il RAG: le tre lacune

Un LLM nudo ha tre debolezze strutturali, e il RAG le affronta tutte senza riaddestramento. L’allucinazione – i modelli rispondono con sicurezza, che sappiano o no; ancorare ogni affermazione a testo recuperato dà al modello qualcosa di vero da dire. La data di taglio dell’addestramento – la conoscenza di un modello si congela al momento dell’addestramento; il recupero va a prendere i dati di oggi. I dati privati – il modello non ha mai visto quei documenti; il recupero è il modo in cui li legge al momento della query. Il bonus che i modelli a libro chiuso non possono offrire: poiché i chunk recuperati sono noti, la risposta può citare le proprie fonti come note a piè di pagina – il più grande vantaggio di fiducia del RAG.

RAG vs. fine-tuning

Non sono rivali: il fine-tuning insegna al modello come rispondere, il RAG fornisce su che cosa rispondere, e un assistente specializzato di dominio usa spesso entrambi – una voce affinata dal fine-tuning che risponde a partire da una base di conoscenza recuperata.

Il RAG è morto? La questione del contesto lungo, risolta

Il trattamento onesto che le pagine generiche evitano. Le finestre di contesto raggiungono ormai milioni di token, e questo alimenta l’argomento ricorrente del “basta infilare tutto nel prompt”. Tre fatti tengono in vita il recupero. Costo e latenza: pagare l’elaborazione di un contesto gigantesco a ogni query è radicalmente più costoso e più lento che andare a prendere la fetta pertinente – ordini di grandezza, su scala. Context rot: gli studi condotti fino al 2025 hanno rilevato un’accuratezza dei modelli che degrada molto prima che la finestra si riempia; i fatti pertinenti sepolti in un contesto enorme vengono mancati, quindi una finestra più grande non è in modo affidabile una risposta migliore. Freschezza e controllo degli accessi: un mega-prompt statico è obsoleto nell’istante in cui i dati cambiano, e cieco rispetto a chi può leggere che cosa. Il consenso del 2026 non è “RAG o contesto lungo” ma entrambi: recuperare un sottoinsieme generoso, pertinente e filtrato per permessi, poi ragionarci sopra con un modello a contesto lungo. Il contesto lungo puro va bene solo per corpus piccoli, stabili e non sensibili.

È nel recupero che il RAG fallisce

L’inquadramento che riorganizza il debug di un sistema RAG: spazzatura recuperata è spazzatura generata con sicurezza. La maggior parte dei fallimenti addossati al modello sono fallimenti di recupero travestiti da generazione – sono stati presi i chunk sbagliati, quindi una risposta perfettamente fedele si ancora alla materia sbagliata. Questo rende due variabili le sole che muovono davvero la qualità. Il chunking: pezzi troppo grandi diluiscono la pertinenza e bruciano budget di prompt; troppo piccoli perdono il contesto che li rendeva significativi – una suddivisione sensibile alla struttura (per titolo, paragrafo, blocco di codice) batte di solito le dimensioni fisse (le strategie contano). Il recupero ibrido: combinare la ricerca per parole chiave (termini esatti, nomi, identificatori) con la ricerca vettoriale (il significato), poi riordinare i candidati fusi con un modello di pertinenza più forte prima di costruire il prompt – richiamo da entrambi i lati, precisione dal reranking. E conviene misurare le due metà separatamente, nel vocabolario di RAGAS: le metriche di recupero (sono stati presi i chunk giusti?) contro la fedeltà (ogni affermazione è sostenuta da ciò che è stato preso?) – perché falliscono in modo indipendente e si correggono in modo diverso.

La falla di sicurezza che nessuno menziona

La similarità vettoriale ordina per significato e non sa nulla dei permessi, il che rende un RAG ingenuo una macchina per fughe di dati. Basta trasformare in vettori i documenti di un’azienda in un unico indice senza metadati di accesso e la domanda di qualunque utente può recuperare qualunque documento, perché il bilancio e la domanda dello stagista sono soltanto punti vicini nello spazio vettoriale. Nemmeno il filtro dopo il recupero è la soluzione: scartare i chunk proibiti dopo la selezione top-k rivela la loro esistenza e rompe il contratto del top-k (ne sono stati chiesti sei e ne arrivano due). Lo schema corretto: salvare i metadati di ACL con ogni chunk e restringere il recupero all’insieme consentito all’utente che pone la domanda prima dell’ordinamento per similarità – recupero filtrato per permessi, non visualizzazione filtrata per permessi. Il parametro aclUser delle schede di codice è esattamente questo, ed è la differenza fra una demo e un sistema da mettere in produzione.

Casi d’uso tipici

• Chat di supporto e di conoscenza – rispondere dalla documentazione reale di un’azienda, con citazioni, aggiornata all’ultima ingestione.
• Ricerca su corpus privati – legale, medico, wiki interni: il recupero per significato che la casella di ricerca per parole chiave non ha mai dato.
• Assistenti delimitati per cliente – i dati propri di ogni utente, filtrati per ACL perché il recupero non attraversi mai un confine di tenant.
• Analisi ancorata – risposte tratte da record vivi invece che dalla congettura obsoleta di un modello.
• Documentazione e onboarding – un modello che cita il manuale invece di improvvisarlo.

Serve davvero il RAG? Matrice decisionale

Limiti e trade-off

• Il RAG riduce l’allucinazione, non la elimina. La fedeltà va misurata, non presunta – il modello può ancora leggere male un buon contesto.
• La qualità vive nel recupero. La maggior parte dello sforzo di ingegneria – chunking, ricerca ibrida, reranking – sta a monte del modello, dove sono i guadagni.
• Gli embedding hanno una versione. Cambiare modello di embedding obbliga a rigenerare ogni vettore salvato; ricalcolare gli embedding di un corpus grande è una migrazione vera.
• Aggiunge parti in movimento. Pipeline di ingestione, un indice da mantenere, token e latenza aggiuntivi per query – un costo reale che un corpus piccolo e stabile può non giustificare.
• I permessi non arrivano gratis. Il recupero filtrato per ACL è il lavoro di sicurezza portante, ed è la parte che le demo saltano e che gli incidenti riscoprono.

Il RAG su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’affermazione “il RAG è un ciclo for” qui è letterale: i documenti sono oggetti ordinari, con l’archiviazione di file per gli originali; i vettori dei chunk vivono accanto a essi in campi di tipo array, indicizzati per la ricerca per similarità; le ACL che governano già ogni query diventano gratuitamente il filtro dei permessi sul recupero – la stessa regola che impedisce a un utente di leggere i record di un altro impedisce al retriever di andarli a prendere; e l’orchestrazione – embedding, recupero, arricchimento, generazione – è una funzione Cloud Code che chiama l’API del modello con la chiave tenuta lato server, esattamente come mostrano le schede di codice. Nessun framework, nessun servizio vettoriale separato da mettere in sicurezza, nessuna chiave di LLM sul dispositivo: il RAG smette di essere un progetto di IA e diventa ingegneria di backend già nota.