---
term: 'RAG (Retrieval-Augmented Generation)'
seoTitle: 'RAG (Retrieval-Augmented Generation): pipeline, ACL e limiti'
headline: 'Che cos''è il RAG (Retrieval-Augmented Generation)?'
slug: rag
category: ai-modern-stack
shortDefinition: '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.'
relatedTerms:
  - vector-database-embeddings
  - api-key-security
  - cloud-code-serverless-functions
  - access-control-lists-acl
contrastsWith:
  - vector-database-embeddings
aboutTerms:
  - 'Retrieval-Augmented Generation'
  - 'Chunking'
  - 'Grounding'
faq:
  - question: 'Che cos''è il RAG in parole semplici?'
    answer: 'Una tecnica in cui l''applicazione cerca in una base di conoscenza i documenti pertinenti e li incolla nel prompt dell''LLM, così la risposta si ancora a dati reali, attuali o privati invece che alla memoria congelata del modello. È l''esame a libro aperto contro l''esame a libro chiuso di un LLM nudo.'
  - question: 'Perché usare il RAG?'
    answer: 'Colma tre lacune dell''LLM in un colpo solo, senza riaddestramento: l''allucinazione (ancorando le risposte a testo recuperato), la data di taglio dell''addestramento (recuperando i dati di oggi) e il fatto che il modello non ha mai visto i documenti privati di un''organizzazione. E poiché le fonti sono note, la risposta può citarle.'
  - question: 'Come funziona il RAG?'
    answer: 'In due fasi. Offline: caricare i documenti, suddividerli in chunk, trasformare ogni chunk in un vettore, salvarli in un indice. Online: trasformare in vettore la domanda dell''utente, recuperare i chunk più simili, aggiungerli al prompt e lasciare che il modello generi una risposta ancorata a quel contesto.'
  - question: 'Qual è la differenza tra RAG e fine-tuning?'
    answer: 'Cambiano cose diverse. Il RAG inietta conoscenza – fatti, freschezza, documenti privati – al momento della query. Il fine-tuning cambia il comportamento – stile, formato, ragionamento di dominio – fissato durante l''addestramento. Il fine-tuning insegna come rispondere; il RAG fornisce su che cosa rispondere; gli assistenti specializzati usano spesso entrambi.'
  - question: 'Le finestre di contesto lunghe rendono obsoleto il RAG?'
    answer: 'No. Anche con finestre da milioni di token, infilarci tutto costa molto di più per query ed è più lento, e gli studi rilevano un''accuratezza che degrada molto prima che la finestra si riempia: il "context rot". Freschezza e controllo degli accessi richiedono comunque il recupero. Lo standard del 2026 è ibrido: recuperare un sottoinsieme pertinente e poi ragionarci sopra con un modello a contesto lungo.'
  - question: 'Che cos''è il chunking e perché conta?'
    answer: 'È la suddivisione dei documenti in pezzi recuperabili – e la qualità del recupero ne dipende molto. Chunk troppo grandi diluiscono la pertinenza e consumano budget di prompt; troppo piccoli perdono il contesto. Una base comune è qualche centinaio di token con sovrapposizione, anche se una suddivisione sensibile alla struttura (per titolo, paragrafo o blocco di codice) batte di solito le dimensioni fisse.'
  - question: 'Il RAG elimina le allucinazioni?'
    answer: 'Le riduce, non le elimina. Il modello può ancora leggere male il contesto recuperato, mescolare passaggi obsoleti e recenti o rispondere con sicurezza partendo da recuperi sbagliati. E la maggior parte delle "allucinazioni del RAG" sono fallimenti di recupero travestiti: sono stati presi i chunk sbagliati, quindi la risposta ancorata si ancora alla materia sbagliata.'
  - question: 'Come si evita che il RAG faccia uscire documenti che un utente non dovrebbe vedere?'
    answer: 'Filtrando il recupero per permessi, non solo per similarità. La ricerca vettoriale ordina per significato e non sa nulla di chi può leggere che cosa: conviene salvare i metadati di controllo degli accessi con ogni chunk e restringere la query ai documenti che l''utente che pone la domanda ha il diritto di vedere – prima della selezione top-k, non dopo.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)'
    url: 'https://arxiv.org/abs/2005.11401'
  - name: 'Retrieval-Augmented Generation for LLMs: A Survey (Gao et al.)'
    url: 'https://arxiv.org/abs/2312.10997'
  - name: 'RAGAS — evaluation metrics'
    url: 'https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/'
  - name: 'Chunking strategies for RAG — Weaviate'
    url: 'https://weaviate.io/blog/chunking-strategies-for-rag'
cta:
  title: 'Il RAG è lavoro di backend ordinario'
  text: 'Archivia i documenti, indicizza i vettori accanto ai dati, filtra il recupero per ACL e chiama il modello da Cloud Code con la chiave lato server: Back4app ti dà ogni pezzo tranne il prompt.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-13'
translationKey: retrieval-augmented-generation-rag
---

**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](https://arxiv.org/abs/2005.11401), è 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

| Domanda | Risposta |
| --- | --- |
| La mossa | Recuperare i chunk pertinenti → aggiungerli al prompt → generare una risposta ancorata |
| Le tre lacune che colma | Allucinazione · data di taglio dell'addestramento · nessun accesso ai dati privati |
| vs. fine-tuning | Il RAG fornisce la *conoscenza*; il fine-tuning cambia il *comportamento* – spesso entrambi |
| L'errore dominante | Fallimento del recupero – chunk sbagliati in ingresso, risposta sbagliata e sicura in uscita |
| L'obbligo in produzione | Filtrare il recupero per [permessi](/glossary/it/liste-di-controllo-degli-accessi-acl/), non per la sola similarità |

## Le due fasi

```text
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:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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.
```

```mermaid
flowchart LR
  accTitle: Pipeline di ingestione e di query del RAG
  accDescr: Nella fase di ingestione i documenti vengono caricati, suddivisi in chunk, trasformati in vettori e salvati con metadati di controllo degli accessi in un indice vettoriale. Nella fase di query la domanda dell'utente viene trasformata in vettore, i chunk simili vengono recuperati e filtrati in base ai permessi dell'utente, il prompt viene arricchito con essi e il modello genera una risposta ancorata, con citazioni.
  subgraph Ingest["Ingestione – offline"]
    D["Documenti"] --> CH["Chunking"] --> EM["Embedding"] --> IDX[("Indice vettoriale<br/>+ metadati di ACL")]
  end
  subgraph Query["Query – online"]
    Q["Domanda"] --> QE["Embedding"] --> R["Recupero top-k"]
    IDX --> R
    R --> F["Filtro per ACL dell'utente"] --> AUG["Prompt arricchito"] --> G["Generazione di una<br/>risposta ancorata"]
  end
```

## 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

| | RAG | Fine-tuning |
| --- | --- | --- |
| Cambia | La *conoscenza* – ciò che il modello sa | Il *comportamento* – come risponde |
| Velocità di aggiornamento | Immediata – basta aggiungere un documento | Riaddestramento per cambiare |
| Freschezza | Sempre attuale | Congelata all'addestramento |
| Citazioni | Sì – le fonti sono note | No |
| Forma del costo | Recupero + token per query | Addestramento iniziale |
| Ideale per | Fatti, documenti privati, cambiamento | Stile, formato, ragionamento di dominio |

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](https://weaviate.io/blog/chunking-strategies-for-rag)). **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](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/): 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](/glossary/it/liste-di-controllo-degli-accessi-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

| Situazione | Scegliere |
| --- | --- |
| La conoscenza è pubblica, stabile, già nel modello | Il prompt nudo – nessuna pipeline |
| Il corpus sta nel prompt e cambia raramente | Incollarlo nel prompt (con il prompt caching) |
| Conoscenza voluminosa, privata o che cambia | Il RAG – il suo terreno |
| Il modello deve *comportarsi* in modo diverso | Il fine-tuning (eventualmente con il RAG) |
| Le risposte devono citare le fonti | Il RAG – le citazioni vengono gratis |
| Dati multiutente con permessi | Il RAG con recupero filtrato per ACL – obbligatorio |

## 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](/glossary/it/api/) per gli originali; i vettori dei chunk vivono accanto a essi in campi di tipo array, [indicizzati](/glossary/it/indice-del-database/) per la [ricerca per similarità](/glossary/it/database-vettoriale/); le [ACL](/glossary/it/liste-di-controllo-degli-accessi-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](/glossary/it/cloud-code-funzioni-serverless/) che chiama l'[API del modello con la chiave tenuta lato server](/glossary/it/sicurezza-delle-chiavi-api/), 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.