RAG

Resumen

RAG, o retrieval-augmented generation, es un patrón donde una aplicación busca información relevante en una base documental y la entrega como contexto a un modelo generativo antes de pedirle una respuesta. El modelo no responde solo desde sus pesos entrenados: responde condicionado por fragmentos recuperados en tiempo de consulta.

Importa porque muchas aplicaciones necesitan respuestas sobre información privada, reciente o cambiante: políticas internas, tickets, contratos, documentación técnica o catálogos. RAG permite conectar un LLM con esa fuente sin entrenar el modelo cada vez que cambia el conocimiento.

Alcance y supuestos

Este paquete cubre RAG como patrón de arquitectura de aplicación: ingesta, indexación, recuperación, armado de contexto, generación y límites de grounding. Habla de embeddings y búsqueda vectorial solo al nivel necesario para entender el flujo.

No cubre implementación interna de bases vectoriales, fine-tuning, entrenamiento de embeddings, evaluación avanzada de LLMs, agentes multi-step ni seguridad completa de sistemas RAG. Asume que entiendes el flujo básico de una aplicación web y que sabes que un LLM recibe un prompt y produce texto.

Modelo mental

Piensa en un abogado que responde una pregunta revisando un archivador antes de hablar. Si responde de memoria, puede sonar convincente pero olvidar una cláusula reciente. Si primero busca los documentos relevantes, marca los párrafos importantes y recién ahí redacta, su respuesta queda anclada en evidencia concreta.

RAG hace algo parecido. La aplicación no le pide al modelo "inventá desde lo que sabes". Primero recupera fragmentos candidatos desde una colección, luego arma un paquete de contexto con esos fragmentos y finalmente le pide al modelo que responda usando ese material.

La calidad depende de toda la cadena. Si el archivador está desactualizado, si la búsqueda trae documentos irrelevantes o si el prompt permite responder sin evidencia, el resultado puede fallar aunque el modelo sea bueno. RAG no elimina alucinaciones por magia; crea una ruta para reducirlas y auditarlas.

Uso práctico

Usa RAG cuando la respuesta debe depender de conocimiento externo al modelo o de datos que cambian fuera del ciclo de entrenamiento:

• ✅ Un asistente para documentación interna puede recuperar páginas vigentes antes de responder.
• ✅ Un soporte de clientes puede citar políticas, estados de pedido o artículos de ayuda relevantes.
• ❌ RAG no reemplaza permisos: no debes recuperar documentos que el usuario no tiene derecho a ver.
• ❌ RAG no arregla una base documental desordenada; basura recuperada produce respuestas malas.

Ejemplo trabajado: responder con una política recuperada

Supón que un ecommerce quiere responder preguntas sobre devoluciones. La aplicación mantiene documentos cortos con políticas internas. En producción probablemente usarías embeddings, filtros por permisos y re-ranking; este ejemplo usa una búsqueda simple para mostrar el contrato del pipeline.

type DocumentChunk = {
  id: string;
  text: string;
};

const chunks: DocumentChunk[] = [
  {
    id: "returns-30-days",
    text: "Los clientes pueden devolver productos físicos hasta 30 días después de la entrega.",
  },
  {
    id: "digital-products",
    text: "Los productos digitales no tienen devolución una vez descargados.",
  },
];

function retrieve(question: string) {
  const terms = question.toLowerCase().split(/\W+/);

  return chunks.filter((chunk) => {
    const text = chunk.text.toLowerCase();
    return terms.some((term) => term.length > 3 && text.includes(term));
  });
}

retrieve representa la etapa de recuperación: recibe la pregunta y devuelve fragmentos candidatos. No genera respuesta; solo selecciona evidencia posible.

function buildPrompt(question: string, context: DocumentChunk[]) {
  const evidence = context
    .map((chunk) => `Fuente ${chunk.id}: ${chunk.text}`)
    .join("\n");

  return `Responde solo con la evidencia entregada.\n${evidence}\nPregunta: ${question}`;
}

const question = "¿Puedo devolver un producto físico después de 20 días?";
const context = retrieve(question);
const prompt = buildPrompt(question, context);

console.log(prompt);

La salida esperada contiene la pregunta más la fuente recuperada:

Responde solo con la evidencia entregada.
Fuente returns-30-days: Los clientes pueden devolver productos físicos hasta 30 días después de la entrega.
Pregunta: ¿Puedo devolver un producto físico después de 20 días?

El LLM recién entra después de esta preparación. Su tarea no es recordar la política desde entrenamiento, sino redactar una respuesta apoyada en el contexto: "Sí, puedes devolverlo porque está dentro de los 30 días". Si la recuperación no trae ninguna fuente relevante, una aplicación bien diseñada debería decir que no tiene evidencia suficiente en vez de responder con confianza.

Un pipeline RAG mínimo tiene cinco decisiones:

1. ¿Qué documentos entran al corpus y cómo se actualizan?
2. ¿Cómo se dividen en fragmentos útiles sin perder contexto?
3. ¿Cómo se recuperan y ordenan los fragmentos relevantes para la pregunta?
4. ¿Cómo se arma el prompt para exigir uso de evidencia y citas?
5. ¿Qué hace el sistema cuando no hay evidencia suficiente?

Si esas decisiones están claras, RAG puede mejorar grounding y mantenibilidad. Si se omiten, solo agregas una búsqueda delante del modelo sin garantizar que la respuesta quede conectada a fuentes reales.

Evidencia

• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks introduce RAG como modelos que combinan memoria paramétrica preentrenada con memoria no paramétrica recuperada.
• AWS, What is RAG? describe RAG como una técnica para optimizar salidas de LLM referenciando bases de conocimiento externas a los datos de entrenamiento.
• Google Cloud, What is Retrieval-Augmented Generation? presenta RAG como la combinación de LLMs con bases de conocimiento externas para mejorar respuestas.