Volver al glosario
R
Definición

RAG Definición IT

Retrieval-Augmented Generation: arquitectura que combina búsqueda de información y generación por un LLM para producir respuestas ancladas en fuentes verificadas.

El RAG (Retrieval-Augmented Generation, o Generación Aumentada por Recuperación) es el patrón de arquitectura dominante para utilizar un LLM sobre datos de negocio. Consiste en recuperar los pasajes pertinentes de una base documental (búsqueda), luego en inyectarlos en el prompt del modelo (generación) para que produzca una respuesta anclada sobre estas fuentes, en lugar de sobre su entrenamiento solo.

El RAG se ha vuelto el enfoque estándar para reducir las alucinaciones, tratar datos recientes o propietarios (posteriores al knowledge cutoff) y proporcionar respuestas con fuentes y auditables. Según Gartner, más del 80 % de los proyectos GenAI de empresa desplegados en 2025 se apoyan en una arquitectura RAG, contra menos del 20 % en 2023.

Por qué existe el RAG

Sin RAG, un LLM responde únicamente a partir de sus parámetros internos — lo que plantea tres problemas:

  • Knowledge cutoff: .
  • Datos privados: los documentos internos de la empresa no están en su corpus.
  • Alucinaciones: .

El RAG resuelve estos tres problemas.

Cómo funciona un pipeline RAG

Un pipeline RAG tipo comprende cinco etapas:

  1. Indexación: los documentos fuente son cortados en chunks, embebidos (transformados en vectores) y almacenados en una vector database (Pinecone, Weaviate, Qdrant, pgvector, OpenSearch).
  2. Pregunta del usuario.
  3. Recuperación: la pregunta es embebida a su vez, luego comparada por similitud vectorial con los chunks indexados. Los top-k chunks más pertinentes son retornados.
  4. Aumento: los chunks recuperados son inyectados en el prompt del LLM con la pregunta.
  5. Generación: el LLM produce una respuesta apoyándose en estos chunks, idealmente citando las fuentes.

Variantes de RAG

  • Naive RAG: .
  • Advanced RAG: .
  • GraphRAG: .
  • Hybrid RAG: .
  • Agentic RAG: un agente IA decide cuándo y cómo recuperar.
  • Self-RAG: .

RAG vs. fine-tuning vs. contexto largo

  • RAG: recuperar dinámicamente el contexto pertinente en cada pregunta. Estándar de la industria.
  • Fine-tuning: adaptar los pesos del modelo a un dominio.
  • Contexto largo: empujar todo el corpus en la ventana de contexto (1M+ tokens con Gemini 2 o Claude).

Los tres enfoques son complementarios.

Los desafíos del RAG en producción

  • Calidad del *chunking: *.
  • Embeddings adaptados: .
  • Metadatos: .
  • Permisos y confidencialidad: .
  • Evaluación: .
  • Costo de inferencia: .
  • Actualización: .

RAG y contexto del SI

Para responder a preguntas internas («¿quién es propietario de esta aplicación?», «¿cuánto gastamos en Slack?»), el RAG debe nutrirse del patrimonio vivo del SI. Es precisamente lo que Kabeen expone — a la vez vía API REST, vía MCP y vía un endpoint RAG dedicado.

Herramientas RAG corrientes

  • Vector databases: Pinecone, Weaviate, Qdrant, Milvus, pgvector, Chroma.
  • Frameworks: LangChain, LlamaIndex, Haystack, DSPy.
  • Embeddings: OpenAI, Cohere, Voyage, BGE, Mistral Embed.
  • Plataformas administradas: Azure AI Search, AWS Kendra, Vertex AI Search.
  • Evaluación: Ragas, TruLens, DeepEval.

Preguntas frecuentes

¿Qué es el RAG?

+

El RAG (Retrieval-Augmented Generation, o Generación Aumentada por Recuperación) es una arquitectura que combina búsqueda de información y generación por un LLM. En lugar de responder a partir de sus solos parámetros, el LLM recibe en su prompt los pasajes pertinentes de una base documental interna — lo que ancla la respuesta sobre fuentes verificadas y reduce drásticamente las alucinaciones.

¿Por qué utilizar el RAG en lugar de un LLM bruto?

+

Tres razones: (1) un LLM solo ignora todo lo que pasó después de su entrenamiento (knowledge cutoff), (2) un LLM solo no conoce los datos internos de su empresa, (3) sin fuente que citar, un LLM inventa plausiblemente (alucinaciones). El RAG resuelve estos tres problemas: fuentes actualizadas, datos privados controlados, respuestas con fuentes y auditables.

¿Diferencia entre RAG y fine-tuning?

+

El RAG recupera dinámicamente el contexto pertinente en cada pregunta — flexible, fácil de actualizar, con fuentes. El fine-tuning adapta los pesos del modelo a un dominio — mejor para el tono, el formato o tareas muy específicas, pero costoso de entrenar y actualizar. Los dos son complementarios: la mayoría de los despliegues serios combinan RAG sobre los datos de negocio y fine-tuning ligero sobre el formato de respuesta.

¿Cuáles son las trampas del RAG en producción?

+

Siete puntos de vigilancia recurrentes: la calidad del chunking, la elección de embeddings adaptados al dominio, la riqueza de los metadatos para filtrar, el respeto a los permisos del usuario (a menudo olvidado), la implementación de un eval set propio, el costo de inferencia a gran escala, y la estrategia de re-indexación para gestionar las actualizaciones. Un RAG que funciona en demo y se rompe en producción falla casi siempre en uno de estos puntos.

¿Necesita ayuda para mapear su panorama TI?

Kabeen le ayuda a inventariar, analizar y optimizar su portafolio de aplicaciones.

Probar gratis