Qué es RAG (Generación Aumentada por Recuperación)

Nota: Este documento es una traducción automática del original en inglés.

Qué es RAG (Generación Aumentada por Recuperación)

Imagina a un estudiante haciendo un examen a libro abierto. En lugar de responder cada pregunta solo de memoria, el estudiante hojea un libro de texto, encuentra las páginas más relevantes, las lee y luego escribe una respuesta que combina conocimiento recordado con datos recién consultados. La Generación Aumentada por Recuperación (RAG) funciona del mismo modo para un modelo de lenguaje grande. El modelo no depende únicamente de lo que memorizó durante el entrenamiento: primero busca en una base de conocimiento externa, recupera los documentos más relevantes y los usa como contexto adicional al generar su respuesta.

Esta técnica importa porque incluso los LLMs más potentes tienen una fecha de corte de conocimiento, pueden "alucinar" (producir afirmaciones plausibles pero incorrectas) y pueden carecer de conocimiento especializado de un dominio. RAG aborda las tres debilidades a la vez al dar al modelo acceso a fuentes actualizadas, específicas del dominio y verificables cada vez que responde una pregunta.

En resumen: RAG es un patrón de arquitectura que combina un sistema de recuperación con un LLM. No es un tipo de modelo separado: es una forma de trabajar con conocimiento y contexto externos.

Cómo funciona

Un pipeline de RAG sigue una secuencia clara de cinco pasos. Entender cada paso ayuda a evaluar si un proyecto que afirma usar RAG tiene una capa de recuperación genuinamente funcional o simplemente envuelve una llamada estándar a un LLM.

Paso 1 — Consulta del usuario

El proceso comienza cuando un usuario envía una pregunta, comando o prompt. Esta consulta es el punto de partida de todo lo que sigue. Por ejemplo, un usuario podría preguntar: "¿Cuáles fueron las principales propuestas de gobernanza en Ethereum el último mes?". El sistema no intenta responder solo desde la memoria del LLM, sino que trata la consulta como una instrucción de búsqueda.

Paso 2 — Embedding de la consulta

La consulta de texto en bruto se convierte en una representación numérica llamada embedding —un vector de números que captura el significado semántico de la consulta. Este paso usa un modelo de embedding especializado (como text-embedding-ada-002 de OpenAI o una alternativa de código abierto como E5 o BGE). El vector resultante permite al sistema realizar una búsqueda semántica —encontrar documentos por significado en lugar de por coincidencia exacta de palabras clave.

Paso 3 — Recuperación desde la base de conocimiento

El embedding de la consulta se compara con una base de datos vectorial (también llamada almacén de vectores) que contiene embeddings precalculados de documentos, pasajes o fragmentos de datos. La base de datos devuelve los top-k elementos semánticamente más similares. Las bases de datos vectoriales comunes incluyen Pinecone, Weaviate, Qdrant, Milvus y Chroma.

La calidad de la recuperación depende de varios factores:

Estrategia de fragmentación (chunking) — cómo se dividieron los documentos originales en piezas más pequeñas. Los fragmentos demasiado grandes diluyen la relevancia; los demasiado pequeños pierden contexto. Encontrar el tamaño de fragmento adecuado es una de las decisiones de ingeniería más impactantes en un pipeline de RAG.
Modelo de embedding — con qué precisión se captura el significado en los vectores. Un modelo de embedding débil conduce a una recuperación débil sin importar la base de datos.
Ranking de relevancia — si la búsqueda devuelve resultados verdaderamente relevantes o solo superficialmente similares. Algunos sistemas añaden un paso de re-ranking que usa un cross-encoder para volver a puntuar los resultados iniciales.

Paso 4 — Inyección de contexto

Los documentos recuperados se combinan con la consulta original del usuario en un único prompt (a veces llamado "prompt aumentado") que se envía al LLM. El prompt suele instruir al modelo a responder la pregunta usando el contexto proporcionado y a indicar cuándo el contexto no contiene información suficiente.

Paso 5 — Generación y salida del LLM

El LLM lee el prompt aumentado y genera una respuesta fundamentada tanto en su conocimiento preentrenado como en la evidencia recuperada. Un sistema RAG bien diseñado también puede incluir una capa de citación que enlaza partes de la respuesta con documentos fuente específicos, dando al usuario una forma de verificar las afirmaciones.

Etapa	Entrada	Salida	Componente clave
Consulta	Texto del usuario	Consulta en bruto	Interfaz de usuario
Embedding	Consulta en bruto	Vector de consulta	Modelo de embedding
Recuperación	Vector de consulta	Documentos relevantes	Base de datos vectorial
Inyección de contexto	Consulta + documentos	Prompt aumentado	Plantilla de prompt
Generación	Prompt aumentado	Respuesta final	LLM

Por qué importa RAG

RAG aborda tres limitaciones bien conocidas de los LLM autónomos:

Alucinaciones. Los LLM pueden producir respuestas seguras pero incorrectas. RAG reduce esto al fundamentar las respuestas en documentos reales. Cuando el modelo puede referenciar un pasaje específico, el riesgo de fabricación cae significativamente.
Conocimiento desactualizado. Un modelo preentrenado tiene una fecha de corte de conocimiento. RAG permite el acceso a datos frescos y actualizados continuamente: una base de datos externa puede refrescarse a diario o incluso en tiempo real.
Especificidad de dominio. Hacer fine-tuning de un LLM para un dominio estrecho es caro y consume tiempo. RAG permite que un modelo de propósito general trabaje con bases de conocimiento especializadas sin reentrenamiento, lo que hace más rápido y barato desplegar aplicaciones específicas de un dominio.

RAG vs fine-tuning

Tanto RAG como el fine-tuning buscan mejorar el rendimiento de un LLM en tareas específicas, pero funcionan de maneras fundamentalmente diferentes.

Aspecto	RAG	Fine-tuning
Cuándo se añade el conocimiento	En tiempo de inferencia (cada consulta)	En tiempo de entrenamiento (una vez, luego estático)
Coste de actualización	Bajo — actualizar la base de conocimiento	Alto — reentrenar o volver a hacer fine-tuning del modelo
Frescura del conocimiento	Puede ser casi en tiempo real	Congelado en el corte de entrenamiento
Requiere infraestructura de entrenamiento	No	Sí (GPUs, datasets, pipeline de entrenamiento)
Más adecuado para	Recuperación de hechos, preguntas y respuestas sobre documentación	Estilo, tono, formato, optimización de tareas estrechas
Auditabilidad	Alta — las fuentes recuperadas pueden registrarse	Baja — el conocimiento está embebido en los pesos

En la práctica, muchos sistemas de producción combinan ambos: un modelo con fine-tuning aporta el tono y comportamiento de tarea adecuados, mientras que RAG suministra fundamentación factual actualizada.

Patrones avanzados de RAG

El pipeline básico de cinco pasos descrito arriba a veces se llama RAG ingenuo (naive RAG). A medida que la técnica ha madurado, los ingenieros han desarrollado variantes más sofisticadas:

RAG multipaso (iterativo). En lugar de recuperar una sola vez, el sistema recupera, genera una respuesta intermedia, identifica lagunas de conocimiento, vuelve a recuperar con una consulta refinada y repite hasta que la respuesta sea suficientemente completa. Este enfoque maneja preguntas complejas que no pueden responderse con un único pase de recuperación.
RAG agéntico. El paso de recuperación se envuelve dentro de un marco de agente de IA. El agente decide cuándo recuperar, qué base de conocimiento consultar, si reformular la consulta y cuándo tiene suficiente contexto para generar una respuesta final. Este patrón difumina la línea entre RAG y los agentes autónomos.
Búsqueda híbrida. Combina la búsqueda semántica basada en vectores con la búsqueda tradicional por palabras clave (BM25) en el mismo paso de recuperación. La búsqueda híbrida captura tanto coincidencias basadas en significado como basadas en términos, mejorando el recall para consultas que contienen términos técnicos específicos o nombres propios.
Graph RAG. En lugar de fragmentos planos de documentos, la base de conocimiento se estructura como un grafo de conocimiento —entidades y relaciones. La recuperación sigue las aristas del grafo en lugar de (o además de) la similitud vectorial, permitiendo razonamiento multisalto sobre datos estructurados. Estos patrones importan para la evaluación: un proyecto que describe un pipeline de graph-RAG con recuperación iterativa hace una afirmación más específica (y más difícil de falsificar) que uno que simplemente dice "usamos RAG".

Ejemplos reales de RAG

RAG no es un concepto teórico: impulsa algunos de los productos de IA más usados hoy.

Bing Chat (Microsoft Copilot). Cuando le haces una pregunta a Bing Chat, busca en la web, recupera páginas relevantes y las usa como contexto para la respuesta del LLM. Las citas en línea que ves en la respuesta son resultado directo del paso de recuperación.
Perplexity. Perplexity se construye en torno a una arquitectura RAG: cada consulta de usuario dispara una búsqueda web, los resultados se pasan a un LLM y la respuesta incluye referencias numeradas a las fuentes. El usuario puede hacer clic para verificar cada afirmación.
Asistentes de conocimiento empresarial. Las empresas usan sistemas RAG internos para que los empleados consulten políticas de RR. HH., documentación de ingeniería o contratos legales en lenguaje natural. La capa de recuperación busca en el almacén de documentos interno de la empresa en lugar de la web abierta. Estos ejemplos demuestran que RAG es tecnología consolidada. Cuando un proyecto de cripto-IA dice "usamos RAG", la pregunta no es si RAG es tecnología real, sino si la implementación específica del proyecto es sólida: qué datos se recuperan, cómo se indexan y si se ha medido la calidad de la recuperación.

Por qué RAG aparece en los proyectos de cripto-IA

Muchos proyectos de cripto-IA usan RAG o afirman usarlo en sus arquitecturas. Los casos de uso comunes incluyen:

Asistentes de documentación — recuperar documentación de protocolos, whitepapers o propuestas de gobernanza para responder preguntas de usuarios sobre las reglas o parámetros de un protocolo.
Herramientas de inteligencia cripto — extraer datos de mercado en tiempo real, eventos on-chain o artículos de noticias para generar resúmenes de análisis o alertas.
Bases de conocimiento para agentes — construir repositorios estructurados que los agentes de IA pueden consultar antes de actuar, asegurando que las decisiones se basen en los datos más recientes.
Fundamentación con datos on-chain — conectar la capa de recuperación a indexadores de blockchain para que el LLM pueda responder preguntas sobre saldos de carteras, historiales de transacciones o estados de contratos inteligentes con información actual en lugar de instantáneas del momento del entrenamiento.

Los valores típicos de AI component en las fichas de proyecto de DecAIHub que involucran patrones de RAG incluyen: "3D AI agents (RAG/memory/LLM catalog)", "AI summaries + crypto intelligence terminal" y "AgentData (real-time data streams for AI agents)".

RAG no es un modelo

Un error común es tratar RAG como un tipo de modelo de IA. No lo es. RAG es un patrón de arquitectura —una forma de combinar un sistema de recuperación con un LLM. El modelo dentro de un pipeline de RAG puede ser GPT, DeepSeek, Mistral o cualquier otro LLM. El componente de recuperación puede ser una base de datos vectorial, una API de búsqueda o un grafo de conocimiento estructurado.

Decir "usamos RAG" te dice cómo está organizado el sistema. No te dice qué modelo se usa, si es propietario o cuán buena es la calidad de la recuperación. Dos proyectos pueden afirmar usar RAG mientras tienen niveles de sofisticación enormemente diferentes: uno con una base de conocimiento cuidadosamente curada y embeddings personalizados, otro con un prototipo ensamblado a las prisas que rara vez devuelve documentos relevantes.

Qué no demuestra RAG

Usar RAG no demuestra que el LLM subyacente sea propietario o tenga fine-tuning. El proyecto puede estar llamando a una API de terceros.
Construir un pipeline de RAG no demuestra que la calidad de la recuperación sea alta. La calidad depende de la base de conocimiento, la estrategia de fragmentación, el modelo de embedding y la relevancia de la búsqueda.
Tener una arquitectura RAG no demuestra que las respuestas sean precisas. Una recuperación pobre puede alimentar contexto irrelevante, y el LLM aún puede alucinar.
Mencionar RAG en una landing page no demuestra que el sistema realmente realice recuperación. Sin evidencia Tier-1 —código, diagramas de arquitectura, logs de demos— la afirmación queda sin verificar. Al evaluar un proyecto de cripto-IA que afirma usar RAG, busca detalles concretos: qué base de conocimiento se busca, qué modelo de embedding se usa, cómo se mide la relevancia y si se publican métricas de calidad.

Dónde aparece en las fichas de proyecto de DecAIHub

RAG suele referenciarse en el campo AI component, ya sea directamente o mediante descripciones que implican un pipeline de recuperación más generación. El flag AI_1 comprueba si el AI component se describe con suficiente especificidad. Escribir simplemente "RAG" no es suficiente; la ficha debe explicar qué se recupera, desde dónde y con qué propósito.

No confundir con

LLM — el motor de generación dentro de un pipeline de RAG. RAG añade recuperación por encima.
Entrenamiento — RAG es un patrón de tiempo de inferencia. No reentrena el modelo; aumenta el prompt con contexto recuperado.
Agente de IA — un agente puede usar RAG como una de sus herramientas, pero RAG por sí solo no convierte a un sistema en agente.
Fine-tuning — el fine-tuning ajusta los pesos del modelo durante una fase de entrenamiento. RAG inyecta conocimiento externo en tiempo de inferencia sin modificar el modelo.
Capa de recuperación / conocimiento — el componente de recuperación es una mitad de RAG. RAG añade el paso de generación por encima de la recuperación pura.

Preguntas frecuentes

¿Cuál es la diferencia entre RAG y fine-tuning?

El fine-tuning altera permanentemente los pesos del modelo entrenándolo sobre un dataset especializado. El nuevo conocimiento pasa a formar parte del modelo mismo. RAG deja el modelo intacto y, en su lugar, suministra documentos relevantes en el momento de la consulta. El fine-tuning es mejor para enseñar a un modelo un nuevo estilo o formato de tarea; RAG es mejor para mantener las respuestas fundamentadas en hechos frescos y verificables. Muchos sistemas de producción usan ambos: el modelo con fine-tuning maneja el tono y el formato mientras que RAG aporta la fundamentación factual actualizada.

¿RAG hace que los LLM sean más precisos?

RAG puede reducir significativamente las alucinaciones al fundamentar la salida del modelo en evidencia recuperada. Sin embargo, la precisión depende de la calidad de la recuperación. Si el sistema de recuperación devuelve documentos irrelevantes o desactualizados, el LLM puede producir respuestas que están seguras pero equivocadas, ahora respaldadas por la evidencia equivocada. RAG eleva el techo de la precisión pero no la garantiza. Medir la precisión y el recall de la recuperación es esencial para cualquier despliegue serio de RAG.

¿Qué es una base de datos vectorial?

Una base de datos vectorial es un almacén de datos especializado diseñado para contener y buscar vectores numéricos de alta dimensión (embeddings). Cuando se envía un embedding de consulta, la base de datos realiza una búsqueda de similitud —normalmente usando algoritmos como HNSW o IVF— para encontrar los vectores coincidentes más cercanos. Esto habilita la búsqueda semántica: encontrar documentos por significado en lugar de por coincidencia exacta de palabras clave. Las bases de datos vectoriales populares incluyen Pinecone, Weaviate, Qdrant, Milvus y Chroma.

¿Cómo se usa RAG en los proyectos de cripto-IA?

Los proyectos de cripto-IA usan RAG para conectar LLMs con datos específicos de blockchain: documentación de protocolos, propuestas de gobernanza, historiales de transacciones on-chain, feeds de precios en tiempo real y código fuente de contratos inteligentes. La capa de recuperación busca en estas fuentes especializadas para que el LLM pueda responder preguntas específicas del dominio con datos actuales en lugar de depender de conocimiento de entrenamiento desactualizado. La calidad de tales sistemas varía ampliamente, desde bases de conocimiento bien indexadas y curadas hasta configuraciones mínimas que recuperan poco contexto útil.

¿Puede RAG funcionar con datos on-chain?

Sí. La capa de recuperación en un pipeline de RAG puede conectarse a indexadores de blockchain, subgraphs o APIs de analítica on-chain. Cuando un usuario pregunta sobre el saldo de una cartera, un historial de transacciones o el estado de un contrato inteligente, el sistema de recuperación obtiene los datos on-chain relevantes y el LLM genera una explicación legible por humanos. Los principales retos son la latencia (las consultas de blockchain pueden ser lentas), el formateo de datos (los datos on-chain en bruto deben analizarse y fragmentarse para el embedding) y la frescura (el índice debe actualizarse con suficiente frecuencia para reflejar el estado actual de la cadena).

Véase también

Referencias externas

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview