¿Qué es RAG (Retrieval-Augmented Generation)?

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

Las dos fases

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 — 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.

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

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). 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: 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 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

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 para los originales; los vectores de los chunks viven como campos de array a su lado, indexados para la búsqueda por similitud; las ACLs 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 llamando a la API del modelo con la clave guardada en el servidor, 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.