RAG - retrieval-augmented generation

RAG une búsqueda y generación: el modelo solo responde después de traer los pasajes relevantes de una base externa, de modo que la respuesta está anclada en material que existe y puede citarse.

LangChainLlamaIndexHaystackPinecone

Qué es

RAG (Retrieval-Augmented Generation) es un patrón de arquitectura en el que el modelo de lenguaje recibe, junto con el prompt del usuario, un conjunto de documentos provenientes de una búsqueda. El retrieval ocurre antes de la generación, y lo que el LLM lee es esa mezcla: la pregunta más el contexto recuperado. La respuesta sale del modelo, pero anclada en lo que trajo el retrieval.

La idea central es simple: un LLM puro responde con base en lo que aprendió en el entrenamiento, así que se equivoca con hechos recientes, mezcla dominios e inventa referencias. Con RAG, el sistema primero trae la parte relevante de una base actual (una wiki, un índice de manuales, una colección de PDFs) y se la entrega al modelo como evidencia. El texto final pasa a tener fuente.

En una definición corta: el retrieval decide con qué conversa el modelo, y la generación decide cómo responde.

Cómo funciona

El flujo tiene cinco etapas, todas determinísticas y auditables:

1. el usuario envía una pregunta; el sistema escribe una versión limpia de ella (a veces expandida por un LLM de query expansion).
2. la pregunta se convierte en un vector (embedding) y el sistema busca los k fragmentos más cercanos en el índice vectorial.
3. la búsqueda léxica (palabras exactas) corre en paralelo y entra en una fusión con la vectorial, formando el ranking híbrido.
4. un reranker reordena los candidatos por relevancia percibida, descartando los que no aportan.
5. los mejores fragmentos pasan a ser contexto en el prompt del LLM, junto con la pregunta; el modelo responde citando las fuentes.

En la práctica

El ejemplo de abajo muestra el pipeline mínimo en TypeScript: recibe una pregunta, recupera los k chunks, arma el prompt y llama al LLM. No es de producción, pero es el esqueleto que aparece en todo proyecto.

rag/pipeline.tstypescript

type Chunk = { id: string; text: string; source: string };

async function retrieve(query: string, k = 5): Promise<Chunk[]> {
  // 1. embedding de la pregunta
  const qVec = await embedder.embed(query);

  // 2. búsqueda densa
  const dense = await vectorStore.search(qVec, { topK: k * 2 });

  // 3. búsqueda léxica (BM25) + fusión
  const lexical = await bm25.search(query, { topK: k * 2 });
  const fused = rrf([dense, lexical]);

  // 4. rerank
  const reranked = await reranker.rerank(query, fused, { topK: k });

  return reranked;
}

async function answer(query: string) {
  const chunks = await retrieve(query);
  const context = chunks.map((c) => `[${c.source}] ${c.text}`).join("\n\n");
  const prompt = `Contexto:\n${context}\n\nPregunta: ${query}\nResponde citando las fuentes.`;
  return await llm.generate(prompt);
}

Variaciones comunes

Tres variaciones aparecen en casi toda arquitectura seria. La primera es el RAG agéntico, en el que el agente decide si llama al retrieval, cuántas veces y con qué filtros, en lugar de que el retrieval corra siempre. La segunda es el RAG multi-hop, en el que la respuesta de una ronda se convierte en la consulta de la siguiente, armándose a partir de varias búsquedas encadenadas. La tercera es GraphRAG, en el que el índice es un grafo de entidades y la búsqueda sigue aristas.

Todas comparten el mismo principio: la generación queda restringida a lo que el retrieval logra encontrar, así que la calidad de la respuesta depende de la calidad del índice. Cambiar el LLM sin revisar el retrieval rara vez cambia el resultado.

Puntos fuertes

anclaje en fuente: cada respuesta tiene una referencia verificable, así que la alucinación factual baja y la auditoría es posible
conocimiento actualizable: cambiar la base es reindexar; el modelo no necesita reentrenamiento ni fine-tuning
control de alcance: se puede limitar la búsqueda a un dominio (manuales de la empresa, jurisprudencia, contratos) y bloquear el resto
costo menor que el fine-tuning: indexar y buscar cuesta órdenes de magnitud menos que entrenar o adaptar pesos

Limitaciones

calidad heredada del retrieval: un retrieval malo se vuelve contexto malo, y un contexto malo se vuelve una respuesta mala, incluso con un LLM excelente
limitada: demasiados chunks obligan a recortar, y lo que sale muchas veces es justamente lo relevante
costo de mantenimiento: un índice desactualizado, embeddings sin revisión y un chunking mal elegido se degradan en silencio
el razonamiento multidocumento sigue siendo difícil: el modelo lee chunks, no conecta hechos entre ellos; GraphRAG ataca parte de esto

Ventana de contextocontext windowCantidad máxima de tokens que el modelo puede leer de una sola vez: el prompt, todo el historial concatenado y la salida que va a generar. Es la memoria de corto plazo del LLM. Las ventanas enormes parecen resolver el RAG, pero amplifican costo, latencia y el riesgo de que el modelo se pierda en medio del texto, así que un buen contexto es un contexto pequeño y bien elegido.ver en el glosario →

conexiones en el mapa

Retrievalalimenta el contextoRAG - retrieval-augmented generation
RAG - retrieval-augmented generationinyecta contextoLLM - large language model
Evals - calidad medida en producciónmide la recuperaciónRAG - retrieval-augmented generation

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

Estudia antes

pon a prueba lo que entendiste

Cargando preguntas…