---
term: 'RAG (Retrieval-Augmented Generation)'
seoTitle: 'RAG (Retrieval-Augmented Generation): Pipeline, ACLs y vs. Fine-Tuning'
headline: '¿Qué es RAG (Retrieval-Augmented Generation)?'
slug: rag
category: ai-modern-stack
shortDefinition: 'RAG es una técnica que recupera documentos al momento de la consulta y los agrega al prompt, para que el LLM responda desde datos, no desde 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: '¿Qué es RAG en términos simples?'
    answer: 'Una técnica en la que tu app busca documentos relevantes en una base de conocimiento y los pega en el prompt del LLM, para que la respuesta se apoye en datos reales, actuales o privados — y no en la memoria congelada del entrenamiento. Es el examen a libro abierto frente al examen a libro cerrado de un LLM puro.'
  - question: '¿Para qué sirve RAG?'
    answer: 'Corrige tres brechas del LLM a la vez, sin reentrenar nada: la alucinación (anclando cada respuesta en texto recuperado), el corte de entrenamiento (trayendo datos actuales) y el hecho de que el modelo nunca vio tus documentos privados. Y como las fuentes son conocidas, la respuesta puede citarlas.'
  - question: '¿Cómo funciona RAG?'
    answer: 'En dos fases. Offline: cargar los documentos, dividirlos en chunks, embeber cada chunk en un vector y almacenar todo en un índice. Online: embeber la pregunta del usuario, recuperar los chunks más similares, agregarlos al prompt y dejar que el modelo genere una respuesta fundamentada en ese contexto.'
  - question: '¿Cuál es la diferencia entre RAG y fine-tuning?'
    answer: 'Cambian cosas distintas. RAG inyecta conocimiento — hechos, actualidad, documentos privados — al momento de la consulta. El fine-tuning cambia comportamiento — estilo, formato, razonamiento de dominio — fijado durante el entrenamiento. El fine-tuning enseña cómo responder; RAG aporta sobre qué responder; los asistentes especializados suelen usar ambos.'
  - question: '¿Las ventanas de contexto largas vuelven obsoleto a RAG?'
    answer: 'No. Incluso con ventanas de millones de tokens, meter todo en el prompt cuesta mucho más por consulta y corre más lento, y los estudios muestran la precisión degradándose bastante antes de que la ventana se llene — el "context rot". La actualidad y el control de acceso siguen exigiendo recuperación. El estándar de 2026 es híbrido: recuperar un subconjunto relevante y razonar sobre él con un modelo de contexto largo.'
  - question: '¿Qué es el chunking y por qué importa?'
    answer: 'Es dividir documentos en piezas recuperables — y la calidad de la recuperación depende fuertemente de eso. Chunks demasiado grandes diluyen la relevancia y desperdician presupuesto de prompt; demasiado pequeños pierden el contexto. Una línea base común es unos cientos de tokens con solapamiento, aunque la división sensible a la estructura (por título, párrafo o bloque de código) suele superar a los tamaños fijos.'
  - question: '¿RAG elimina las alucinaciones?'
    answer: 'Las reduce; no las elimina. El modelo todavía puede leer mal el contexto recuperado, mezclar pasajes viejos con nuevos o responder con confianza a partir de recuperaciones malas. Y la mayoría de las "alucinaciones de RAG" son fallas de recuperación disfrazadas — se trajeron los chunks equivocados, así que la respuesta fundamentada se fundamenta en lo equivocado.'
  - question: '¿Cómo evitar que RAG filtre documentos que un usuario no debería ver?'
    answer: 'Filtra la recuperación por permisos, no solo por similitud. La búsqueda vectorial rankea por significado y no sabe nada sobre quién puede leer qué; almacena metadatos de control de acceso junto a cada chunk y restringe la consulta a los documentos que el usuario que pregunta puede ver — antes de la selección top-k, no después.'
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: 'RAG es trabajo normal de backend'
  text: 'Almacena documentos, indexa vectores junto a tus datos, filtra la recuperación por ACL y llama al modelo desde Cloud Code con la clave del lado del servidor — Back4app aporta cada pieza, salvo el prompt.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-03'
translationKey: retrieval-augmented-generation-rag
---

**RAG es una técnica que recupera documentos al momento de la consulta y los agrega al prompt, para que el LLM responda desde datos, no desde memoria.** Presentada por [Lewis et al. en 2020](https://arxiv.org/abs/2005.11401), es el examen a libro abierto frente al examen a libro cerrado de un modelo puro: en lugar de depender de lo que memorizó durante el entrenamiento, el modelo consulta el material que tú le entregas y responde a partir de él — fundamentado, actual, consciente de lo privado y, como las fuentes son conocidas, *citable*. Para quien desarrolla backend, la verdad tranquilizadora debajo del hype es que RAG no es un framework que debas adoptar; es un for-loop que ya sabes construir.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| La jugada | Recuperar los chunks relevantes → agregarlos al prompt → generar una respuesta fundamentada |
| Las tres brechas que corrige | Alucinación · corte de entrenamiento · ningún acceso a tus datos privados |
| vs. fine-tuning | RAG aporta *conocimiento*; el fine-tuning cambia *comportamiento* — a menudo ambos |
| El error dominante | Falla de recuperación — entran chunks equivocados, sale una respuesta errónea y confiada |
| La obligación en producción | Filtrar la recuperación por [permisos](/glossary/es/listas-de-control-de-acceso-acl/), no solo por similitud |

## Las dos fases

```text
INGESTA (offline, una vez por documento)
  cargar → dividir en chunks (~cientos de tokens, con solapamiento)
       → embeber cada chunk en un vector
       → almacenar vector + texto + metadatos de ACL en un índice

CONSULTA (online, por cada pregunta)
  embeber la pregunta → búsqueda por similitud de los top-k chunks (usualmente 5–10)
       → filtrar a lo que ESTE usuario puede leer
       → aumentar el prompt con los chunks
       → el LLM genera una respuesta fundamentada en ellos (+ citas)
```

La fase online completa, del lado del servidor, en una sola función:

**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: Pipelines de ingesta y consulta de RAG
  accDescr: En la fase de ingesta, los documentos se cargan, se dividen en chunks, se embeben en vectores y se almacenan con metadatos de control de acceso en un índice vectorial. En la fase de consulta, la pregunta del usuario se embebe, los chunks similares se recuperan y se filtran por los permisos del usuario, el prompt se aumenta con ellos y el modelo genera una respuesta fundamentada con citas.
  subgraph Ingest["Ingesta — offline"]
    D["Documentos"] --> CH["Chunk"] --> EM["Embedding"] --> IDX[("Índice vectorial<br/>+ metadatos de ACL")]
  end
  subgraph Query["Consulta — online"]
    Q["Pregunta"] --> QE["Embedding"] --> R["Recuperar top-k"]
    IDX --> R
    R --> F["Filtrar por la ACL del usuario"] --> AUG["Aumentar el prompt"] --> G["Generar respuesta<br/>fundamentada"]
  end
```

## Por qué RAG: las tres brechas

Un LLM puro tiene tres debilidades estructurales, y RAG ataca todas sin reentrenar. **Alucinación** — los modelos responden con confianza sepan o no la respuesta; anclar cada afirmación en texto recuperado (el famoso *grounding*) le da al modelo algo verdadero que decir. **El corte de entrenamiento** — el conocimiento del modelo se congela en la fecha del entrenamiento; la recuperación (*retrieval*) trae los datos de hoy. **Datos privados** — el modelo nunca vio tus documentos; la recuperación es la forma en que los lee al momento de la consulta. El bonus que los modelos a libro cerrado no pueden ofrecer: como los chunks recuperados son conocidos, la respuesta puede **citar sus fuentes** como notas al pie — la mayor ventaja de confianza que tiene RAG.

## RAG vs. fine-tuning

| | RAG | Fine-tuning |
| --- | --- | --- |
| Cambia | *Conocimiento* — lo que el modelo sabe | *Comportamiento* — cómo responde |
| Velocidad de actualización | Instantánea — agrega un documento | Reentrenar para cambiar |
| Actualidad | Siempre al día | Congelado en el entrenamiento |
| Citas | Sí — las fuentes son conocidas | No |
| Forma del costo | Recuperación + tokens por consulta | Entrenamiento por adelantado |
| Mejor para | Hechos, docs privados, cambio | Estilo, formato, razonamiento de dominio |

No son rivales: el fine-tuning le enseña al modelo *cómo* responder, RAG aporta *sobre qué* responder, y un asistente especializado de dominio usa con frecuencia ambos — una voz afinada por fine-tuning respondiendo desde una base de conocimiento recuperada.

## ¿RAG murió? La pregunta del contexto largo, respondida

El tratamiento honesto que las páginas genéricas evitan. Las ventanas de contexto ya llegan a millones de tokens, alimentando el argumento recurrente de "mete todo en el prompt". Tres hechos mantienen viva la recuperación. **Costo y latencia:** pagar por procesar un contexto gigante en *cada* consulta es dramáticamente más caro y más lento que traer el trozo relevante — órdenes de magnitud, a escala. **Context rot:** estudios a lo largo de 2025 encontraron la precisión de los modelos degradándose bastante antes de que la ventana se llene — los hechos relevantes enterrados en un contexto enorme pasan desapercibidos, así que una ventana más grande no es una respuesta confiablemente mejor. **Actualidad y control de acceso:** un mega-prompt estático queda obsoleto en el instante en que los datos cambian y es ciego a quién puede leer qué. El consenso de 2026 no es "RAG o contexto largo", sino *ambos* — recuperar un subconjunto generoso, relevante y filtrado por permisos, y luego razonar sobre él con un modelo de contexto largo. El contexto largo puro solo sirve para corpus pequeños, estables y no sensibles.

## La recuperación es donde RAG falla

El encuadre que reorganiza cómo depuras un sistema RAG: **basura recuperada es basura generada con confianza.** La mayoría de las fallas que se le atribuyen al modelo son fallas de recuperación disfrazadas de generación — se trajeron los chunks equivocados, así que una respuesta perfectamente fiel se fundamenta en el material equivocado. Eso convierte a dos variables en las que de verdad mueven la calidad. **Chunking:** piezas demasiado grandes diluyen la relevancia y queman presupuesto de prompt; demasiado pequeñas pierden el contexto que les daba sentido — la división sensible a la estructura (por título, párrafo, bloque de código) suele superar a los tamaños fijos ([las estrategias importan](https://weaviate.io/blog/chunking-strategies-for-rag)). **Recuperación híbrida:** combina búsqueda por palabras clave (términos exactos, nombres, IDs) con búsqueda vectorial (significado) y luego *re-rankea* los candidatos combinados con un modelo de relevancia más fuerte antes del prompt — recall de ambos lados, precisión del re-ranker. Y mide las dos mitades por separado, en el vocabulario de [RAGAS](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/): métricas de recuperación (¿trajimos los chunks correctos?) versus fidelidad (¿cada afirmación está respaldada por lo que trajimos?) — porque fallan de forma independiente y se corrigen de formas distintas.

## La brecha de seguridad que nadie menciona

La similitud vectorial rankea por significado y no sabe *nada* sobre permisos — lo que convierte a un RAG ingenuo en una máquina de fugas de datos. Embebe los documentos de una empresa en un único índice sin metadatos de acceso y la pregunta de cualquier usuario puede recuperar cualquier documento, porque el reporte financiero y la duda del pasante son solo puntos vecinos en el espacio vectorial. Filtrar después de la recuperación tampoco es la solución: descartar los chunks prohibidos después de la selección top-k tanto filtra su existencia como rompe el contrato del top-k (pediste seis y recibiste dos). El patrón correcto: **almacenar metadatos de [ACL](/glossary/es/listas-de-control-de-acceso-acl/) con cada chunk y restringir la recuperación al conjunto permitido del usuario que pregunta *antes* del ranking por similitud** — recuperación filtrada por permisos, no visualización filtrada por permisos. El parámetro `aclUser` de las pestañas de código es exactamente eso, y es la diferencia entre una demo y un sistema que puedes llevar a producción.

## Casos de uso comunes

- **Chat de soporte y conocimiento** — responder desde los docs reales de la empresa, con citas, actualizado hasta la última ingesta.
- **Búsqueda en corpus privados** — legal, médico, wikis internas: recuperación por significado que la caja de palabras clave nunca te dio.
- **Asistentes con alcance por cliente** — los datos de cada usuario, filtrados por ACL para que la recuperación nunca cruce la frontera de un tenant.
- **Analítica fundamentada** — preguntas respondidas desde registros vivos, no desde la suposición desactualizada de un modelo.
- **Documentación y onboarding** — un modelo que cita el manual en lugar de improvisarlo.

## ¿Realmente necesitas RAG? Matriz de decisión

| Situación | Elige |
| --- | --- |
| El conocimiento es público, estable y ya está en el modelo | Prompt puro — sin pipeline |
| El corpus cabe en el prompt y rara vez cambia | Pégalo en el prompt (con prompt caching) |
| Conocimiento grande, privado o cambiante | RAG — su casa |
| El modelo necesita *comportarse* distinto | Fine-tuning (quizá junto a RAG) |
| Las respuestas deben citar fuentes | RAG — las citas vienen gratis |
| Datos multiusuario con permisos | RAG con recuperación filtrada por ACL — obligatorio |

## Limitaciones y trade-offs

- **RAG reduce la alucinación; no la elimina.** La fidelidad debe medirse, no presumirse — el modelo todavía puede leer mal un contexto bueno.
- **La calidad vive en la recuperación.** La mayor parte del esfuerzo de ingeniería — chunking, búsqueda híbrida, re-ranking — está antes del modelo, donde están las ganancias.
- **Los embeddings tienen versión.** Cambia el modelo de embedding y cada vector almacenado debe regenerarse; re-embeber un corpus grande es una migración de verdad.
- **Agrega partes móviles.** Pipelines de ingesta, un índice que mantener, tokens y latencia extra por consulta — costo real que un corpus pequeño y estable puede no justificar.
- **Los permisos no vienen gratis.** La recuperación filtrada por ACL es el trabajo de seguridad estructural — la parte que las demos se saltan y los incidentes redescubren.

## RAG en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La afirmación de que "RAG es un for-loop" aquí es literal: los documentos son objetos comunes, con [almacenamiento de archivos](/glossary/es/api/) para los originales; los vectores de los chunks viven como campos de array a su lado, [indexados](/glossary/es/indice-de-base-de-datos/) para la [búsqueda por similitud](/glossary/es/base-de-datos-vectorial/); las [ACLs](/glossary/es/listas-de-control-de-acceso-acl/) que ya gobiernan cada consulta se convierten en el filtro de permisos de la recuperación *gratis* — la misma regla que impide que un usuario lea los registros de otro impide que el retriever los traiga; y la orquestación — embeber, recuperar, aumentar el prompt, generar — es una [función de Cloud Code](/glossary/es/cloud-code-funciones-serverless/) llamando a la [API del modelo con la clave guardada en el servidor](/glossary/es/seguridad-de-claves-de-api/), exactamente como muestran las pestañas de código. Sin framework, sin un servicio vectorial aparte que asegurar, sin clave de LLM en el dispositivo — RAG deja de ser un proyecto de IA y se vuelve ingeniería de backend que ya sabes hacer.