Entendiendo RAG para la Recuperación Aumentada en IA

Qué es un RAG (Retrieval-Augmented Generation)

Tiempo estimado de lectura: 10 min

• RAG combina recuperación y generación para respuestas precisas.
• Permite referencia y trazabilidad de información interna.
• Constituye una solución a las limitaciones de LLMs en producción.
• Incluye múltiples componentes técnicos en su arquitectura.
• Es clave para la automatización de workflows con IA.

Tabla de contenidos

• ¿Qué es un RAG (Retrieval-Augmented Generation)?
• ¿Por qué existe RAG?
• Componentes de una arquitectura RAG
• RAG vs fine-tuning
• Tipos de RAG
• Errores típicos al implementar RAG
• Ejemplo mental de flujo RAG
• Cómo se implementa un RAG en 2025
• RAG y automatización
• Fuentes y lecturas recomendadas
• Cierre

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

RAG significa Retrieval-Augmented Generation (en español, “generación aumentada con recuperación”). Es una arquitectura en la que, antes de que el LLM responda, el sistema:

1. Recupera (retrieve) fragmentos relevantes desde una base de conocimiento.
2. Aumenta (augment) el prompt con ese contexto recuperado.
3. Genera (generate) una respuesta usando el LLM, apoyándose en ese contexto.

La idea clave: el modelo no tiene que “recordar” tus documentos; los consulta en tiempo de ejecución y responde con la evidencia que tú le das.

Este patrón se popularizó formalmente con el paper de Facebook AI “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (Lewis et al., 2020).

¿Por qué existe RAG?

Un LLM puro (sin recuperación) tiene tres limitaciones prácticas:

• Conocimiento cerrado y desactualizado: el modelo se entrenó con un corte temporal. No sabe tus cambios de ayer.
• No conoce tu dominio interno: procedimientos, políticas, contratos, tickets, incidentes, arquitectura, etc.
• Riesgo de alucinación: si no tiene datos, puede “rellenar” con texto plausible.

RAG no “elimina” la alucinación por arte de magia, pero reduce drásticamente el incentivo del modelo a inventar: le das contexto específico y le exiges citarlo/usar solo ese material.

Componentes de una arquitectura RAG

Un RAG en producción no es “meto un vector store y listo”. Tiene piezas con decisiones técnicas importantes.

 

1) Ingesta y normalización de fuentes

Primero conviertes tus fuentes a texto procesable:

• Confluence/Notion
• Google Drive
• Git repos (README, ADRs, docs)
• PDFs (manuales, contratos)
• Bases de datos (FAQs, productos)
• Tickets (Jira, Zendesk)

Problema real: cada fuente tiene ruido (cabeceras, menús, duplicados, tablas rotas). La calidad del RAG se decide aquí.

 

2) Chunking (fragmentación)

No puedes indexar documentos gigantes “tal cual”. Los divides en chunks (fragmentos) con:

• Tamaño (p. ej., 400–1.000 tokens)
• Solape (overlap) para no cortar ideas a la mitad
• Heurísticas por estructura (títulos, secciones, listas)

Chunking malo = recuperas contexto incompleto o irrelevante.

Referencia útil: documentación de OpenAI sobre RAG / retrieval: https://platform.openai.com/docs.

 

3) Embeddings (representación vectorial)

A cada chunk le calculas un embedding y lo guardas en un índice vectorial.

• Embeddings capturan similitud semántica.
• No son mágicos: fallan con nombres internos, acrónimos, IDs, tablas, y ambigüedad.

 

4) Vector store / motor de búsqueda

Almacena embeddings y permite consultas por similitud:

• pgvector (Postgres)
• Pinecone
• Weaviate
• Milvus
• Elasticsearch/OpenSearch (kNN)

La elección depende más de tus restricciones (compliance, coste, latencia) que del hype.

 

5) Recuperación (Retrieval)

Dado un input del usuario, generas embedding de la consulta y recuperas top-k chunks similares.

Aquí ya aparecen decisiones serias:

• top-k demasiado bajo: falta contexto
• top-k demasiado alto: ruido, el modelo se dispersa
• filtros por metadatos (equipo, producto, región, fecha, permisos)

 

6) Re-ranking (opcional pero muy recomendable)

Después de recuperar, un modelo “reranker” reordena los resultados por relevancia real (no solo similitud vectorial). Suele mejorar mucho la precisión.

 

7) Prompting + generación

Construyes un prompt con:

• Instrucciones (política de respuesta, tono, límites)
• Contexto recuperado (con citas/IDs)
• Pregunta del usuario

Y pides al LLM que responda sólo con ese contexto o que marque incertidumbre si falta evidencia.

 

8) Observabilidad y evaluación

Si no mides, no mejoras:

• ratio de respuestas con cita
• recall: ¿recuperaste el chunk correcto?
• precision: ¿lo usaste bien?
• latencia y coste por consulta
• logs de queries difíciles y “no answer”

RAG vs fine-tuning: cuándo usar cada uno

Una confusión recurrente: “¿RAG o fine-tuning?”. No son excluyentes, pero sirven para cosas distintas.

 

Usa RAG cuando:

• La información cambia (docs vivas, tickets, catálogo).
• Necesitas citas o trazabilidad.
• Hay mucha información y no quieres reentrenar.
• Debes respetar permisos por documento.

 

Usa fine-tuning cuando:

• Quieres adaptar estilo o formato de salida.
• Quieres enseñar un comportamiento repetible.
• Tu conocimiento es estable y pequeño.

En la práctica madura: RAG para conocimiento + fine-tuning o prompt engineering para comportamiento.

Tipos de RAG

Un RAG no tiene por qué ser únicamente embeddings + vector DB.

 

1) Vector RAG clásico

El más común: embeddings y similitud coseno.

 

2) Hybrid search (vector + keyword/BM25)

Mejor para:

• códigos de error
• nombres de tablas/fields
• IDs
• términos exactos

El híbrido suele ganar en sistemas corporativos donde hay jerga y tokens raros.

 

3) Graph RAG / Knowledge Graph augmentation

Cuando el conocimiento es relacional. Puede ser útil para preguntas como “¿qué servicios dependen de X?”.

Errores típicos al implementar RAG

1) Pensar que el vector store “entiende” tu negocio

Si tus documentos están sucios o mal fragmentados, recuperarás basura con alta confianza.

2) No controlar permisos (security leak)

RAG sin autorización por documento = riesgo real. Necesitas filtrado por metadatos y enforcement en el retrieval.

3) No tener estrategia de “no answer”

Si el contexto no contiene la respuesta, el sistema debe decirlo. Forzar siempre una respuesta es diseñar alucinación.

4) No evaluar con dataset real

Sin un set de preguntas reales, no sabes si funciona. “Parece que responde bien” no es una métrica.

5) Prompts gigantes y contextos interminables

Meter 30 chunks “por si acaso” sube coste, baja precisión y empeora la respuesta. RAG es selección, no acumulación.

Ejemplo mental de flujo RAG

Pregunta del usuario:

“¿Cuál es el procedimiento para rotar credenciales en el servicio X?”

Pipeline:

1. Query embedding
2. Recupero top-8 chunks de “Runbook credenciales”, “On-call”, “Security policy”
3. Re-ranking y me quedo con 3 chunks
4. Prompt: “Responde solo con el procedimiento descrito en las fuentes. Si hay pasos ambiguos, indícalo.”
5. Incluyo chunks con IDs y URLs internas

Respuesta:

• Pasos enumerados
• Referencias a “Runbook v3”, “Policy 2024-10”
• Nota: “No se especifica el tiempo de propagación; consulta a SRE”

Eso es un RAG bien diseñado: evidencia + límites.

Cómo se implementa un RAG en 2025

Un enfoque mínimo viable, pero serio:

 

Paso 1: define el caso de uso y el contrato de salida

• ¿Soporte interno? ¿Asistente de ventas? ¿Copiloto para devs?
• ¿Necesitas citas? ¿Formato estructurado?
• ¿Qué significa “correcto”?

 

Paso 2: elige 1–2 fuentes de alta calidad

Empieza con lo que tenga mejor señal: runbooks, FAQs internas, docs de producto bien mantenidas.

 

Paso 3: chunking + metadatos desde el día 1

Guarda metadatos útiles:

• source
• fecha
• equipo
• permisos/rol
• URL

 

Paso 4: retrieval híbrido si tienes jerga técnica

Especialmente si hay nombres de endpoints, códigos, comandos, identificadores.

 

Paso 5: exige trazabilidad en el prompt

Pide que:

• cite IDs de chunks
• marque “no encontrado” si no está en el contexto

 

Paso 6: evaluación continua

Crea un set pequeño (30–100 preguntas) y mide antes de iterar.

RAG y automatización

El salto interesante no es “responder preguntas”, sino usar RAG como capa de conocimiento para workflows:

• Clasificar un ticket y proponer respuesta con base en tu KB
• Enriquecer incidencias con pasos de runbook y checklist
• Generar borradores de PRDs o ADRs con referencias internas
• Validar que una respuesta cumple política (guardrails)

Aquí es donde muchos equipos entran con Dominicode Labs: sistemas de automatización e IA aplicada con foco en valor operativo, no demos.

Fuentes y lecturas recomendadas

• Paper original de RAG: https://arxiv.org/abs/2005.11401
• Documentación/guías de retrieval: https://platform.openai.com/docs

Cierre: qué es un RAG en una frase

Un RAG es una arquitectura que hace que un LLM responda usando información recuperada en tiempo real desde tus fuentes, para ganar precisión, trazabilidad y control sin reentrenar el modelo.

Cuando se diseña con chunking decente, búsqueda híbrida, control de permisos, re-ranking y evaluación, deja de ser “una demo de embeddings” y se convierte en infraestructura de producto.