Primeros pasos con RAG: una guía para principiantes sobre la generación aumentada por recuperación

La Generación Aumentada por Recuperación (RAG) es la forma más práctica de hacer que un modelo de lenguaje extenso (LLM) sea útil con tus datos. En lugar de realizar un ajuste fino (fine-tuning) de un modelo o introducir todo en el prompt, RAG recupera los documentos más relevantes en el momento de la consulta y se los entrega al modelo como contexto. El resultado: respuestas precisas y fundamentadas que citan tus fuentes, no ficciones alucinadas.

Esta guía te acompaña a través de cada capa de un sistema RAG, desde la ingesta de documentos hasta el despliegue en producción, para que puedas construir uno que realmente funcione. Ya sea que estés creando un asistente de conocimiento interno, un bot de soporte para clientes o una herramienta de investigación, se aplican los mismos principios.

¿Qué es RAG (y qué no es)?

RAG es un patrón de arquitectura que combina la recuperación de información con la generación de texto. Cuando un usuario hace una pregunta, el sistema busca pasajes relevantes en una base de conocimientos y luego entrega esos pasajes a un LLM junto con la pregunta. El modelo genera una respuesta basada en el contexto recuperado.

Piénsalo de esta manera: el LLM es el cerebro, pero RAG le da la capacidad de abrir un archivador y leer la carpeta correcta antes de responder. Sin RAG, el modelo solo puede confiar en lo que memorizó durante su entrenamiento, lo cual puede estar desactualizado, incompleto o carecer por completo de tus datos patentados.

RAG no es:

• Un producto que instalas. Es un patrón de diseño que implementas sobre componentes existentes (modelos de embedding, bases de datos vectoriales, LLMs). Existen frameworks que aceleran el proceso, pero aún necesitas entender las piezas.
• Ajuste fino (Fine-tuning). El ajuste fino cambia los pesos del modelo de forma permanente; RAG deja el modelo intacto y cambia el contexto que este ve en el momento de la inferencia. El ajuste fino enseña al modelo nuevos comportamientos o estilos, mientras que RAG le da acceso a nueva información. Para una comparación más profunda, consulta nuestra publicación sobre RAG vs fine-tuning.
• Una solución mágica para datos de mala calidad. Si tus documentos fuente están desactualizados, son contradictorios o están mal escritos, tus respuestas de RAG también lo estarán. El techo de calidad de un sistema RAG es la calidad de su base de conocimientos.
• Simplemente "búsqueda más GPT". Un sistema RAG de producción implica una fragmentación cuidadosa, re-clasificación (re-ranking), seguimiento de citas, evaluación y control de acceso; mucho más que una simple búsqueda de similitud acoplada a una interfaz de chat.

Por qué RAG es importante ahora

Dos avances convirtieron a RAG en el patrón dominante para la IA empresarial:

1. Las ventanas de contexto crecieron, pero los costos y la latencia crecieron con ellas. Podrías volcar 200,000 tokens de documentación en cada prompt, pero eso cuesta dinero y ralentiza las respuestas. RAG recupera solo los 5-10 pasajes más relevantes, manteniendo el contexto acotado y los costos bajos.
2. Los modelos de embedding mejoraron drásticamente. Modelos como text-embedding-3-large y Voyage-3 entienden el significado lo suficientemente bien como para que la recuperación realmente funcione: obtienes los pasajes correctos, no solo los que contienen palabras clave similares.

Recorrido por la arquitectura

Un pipeline de RAG completo tiene seis etapas. Comprender cada una te ayuda a tomar mejores decisiones de diseño y evitar los errores que descarrilan la mayoría de las primeras implementaciones.

Etapa 1: Ingesta de documentos

Los datos brutos entran en el pipeline. Estos pueden ser PDFs, documentos de Word, páginas web, wikis de Confluence, bases de datos de Notion, transcripciones de Slack, archivos de Google Drive o respuestas de API. Una capa de ingesta normaliza todo en texto limpio (o markdown estructurado) mientras preserva los metadatos: título del documento, autor, fecha, encabezados de sección, números de página y cualquier atributo personalizado relevante para tu dominio.

Herramientas comunes: Unstructured.io, cargadores de documentos de LlamaIndex, Apache Tika, parsers personalizados para formatos propietarios.

Decisiones clave:

• Programación: ¿Ingestas por la noche, mediante un disparador de webhook o en tiempo real? El requisito de frescura depende de qué tan rápido cambien tus datos de origen.
• Deduplicación: Si el mismo contenido existe en múltiples sistemas (un documento de política en Confluence y en SharePoint), decide qué fuente de verdad prevalece.
• Extracción de metadatos: Captura todo aquello por lo que podrías querer filtrar más adelante: departamento, tipo de documento, rango de fechas, línea de productos. Añadir metadatos después significa volver a procesar todos tus documentos.

Consejo: Preserva la estructura del documento. Una jerarquía de encabezados te permite crear fragmentos más inteligentes más adelante y mejora la precisión de las citas. Eliminar todo el formato para convertirlo en texto plano descarta valiosas señales estructurales.

Etapa 2: Fragmentación (Chunking)

No puedes convertir un PDF completo de 80 páginas en un solo vector; esto diluiría la señal y, de todos modos, la mayoría de los modelos de embedding tienen límites en su ventana de contexto. El chunking divide los documentos en pasajes más pequeños que tienen significado por sí mismos.

Este es el paso que la mayoría de los equipos subestiman, y a menudo es la palanca individual más grande para mejorar la calidad de RAG.

Estrategias de fragmentación

En la práctica, el chunking consciente del documento ofrece los mejores resultados para contenido estructurado, mientras que el chunking recursivo con fragmentos de 512 tokens y un solapamiento de 64 tokens es un estándar sólido para texto no estructurado.

Error común: Los fragmentos demasiado pequeños pierden el contexto; los fragmentos demasiado grandes diluyen la relevancia. Comienza con 512 tokens para contenido general, 256 para documentación técnica densa, y experimenta a partir de ahí. Incluye siempre un solapamiento (10-15 % del tamaño del fragmento) para que las ideas divididas en un límite sigan siendo capturadas.

Técnica avanzada: fragmentación padre-hijo. Genera embeddings de fragmentos pequeños para una recuperación precisa, pero cuando un fragmento coincide, recupera la sección "padre" más grande para el contexto de generación. Esto te da lo mejor de ambos mundos: coincidencia precisa con un contexto enriquecido.

Etapa 3: Embedding (Incrustación)

Cada fragmento se convierte en un vector denso (una lista de números) que captura su significado semántico. Significados similares producen vectores similares, que es lo que hace que la recuperación funcione. Cuando un usuario pregunta "¿Cuál es nuestra política de reembolso?", el embedding de esa pregunta estará cerca del embedding del fragmento que describe tu política de reembolso, incluso si el fragmento nunca usa la palabra "reembolso" sino que dice "procedimiento de devolución y reintegro".

Modelos de embedding a considerar

Para la mayoría de las aplicaciones empresariales, text-embedding-3-large ofrece el mejor equilibrio entre calidad y soporte del ecosistema. Si trabajas con contenido multilingüe (como solemos hacer para clientes europeos), vale la pena evaluar Cohere Embed v4 o BGE-M3. Para bases de código y documentación técnica, Voyage-3 supera consistentemente a las alternativas.

Importante: Una vez que eliges un modelo de embedding, te comprometes con él. Cambiar de modelo más tarde significa volver a generar los embeddings de todo tu corpus porque los vectores de diferentes modelos no son compatibles. Elige con cuidado y realiza pruebas con tus datos reales antes de decidirte.

Etapa 4: Base de datos vectorial

Los embeddings necesitan vivir en algún lugar donde puedan ser buscados eficientemente. Una base de datos vectorial almacena tus vectores junto con sus metadatos y realiza una búsqueda rápida de vecinos más cercanos aproximados (ANN) para encontrar los vectores más similares a una consulta.

Opciones de bases de datos vectoriales

Nuestra recomendación: Comienza con pgvector si ya utilizas PostgreSQL; mantiene tu stack simple y maneja cómodamente la mayoría de las cargas de trabajo hasta 5 millones de vectores. Obtienes el beneficio de las transacciones ACID, herramientas familiares y ninguna infraestructura nueva que gestionar. Cambia a una base de datos vectorial dedicada como Qdrant o Pinecone cuando necesites una latencia inferior a 10 ms a escala, filtrado avanzado o cuando trabajes con decenas de millones de vectores.

Para una mirada detallada sobre cómo escalar la búsqueda vectorial en producción, consulta nuestra guía sobre escalar RAG a producción.

Etapa 5: Recuperación

Cuando un usuario hace una pregunta, el sistema genera el embedding de la consulta con el mismo modelo utilizado para los documentos, busca en la base de datos vectorial los K fragmentos más similares y (opcionalmente) re-clasifica los resultados antes de pasarlos al LLM.

Búsqueda híbrida: Semántica + BM25

La búsqueda vectorial pura es potente, pero puede pasar por alto coincidencias exactas de palabras clave, un problema cuando los usuarios buscan códigos de productos, números de cláusulas legales, mensajes de error o términos técnicos específicos. La búsqueda híbrida combina dos enfoques complementarios:

• Búsqueda semántica (similitud vectorial): encuentra pasajes conceptualmente relacionados incluso cuando la redacción difiere. Ideal para preguntas en lenguaje natural.
• BM25 / búsqueda por palabras clave: encuentra coincidencias exactas de términos con una puntuación al estilo TF-IDF. Ideal para identificadores precisos, códigos y jerga específica del dominio.

Los resultados de ambos métodos se fusionan utilizando Reciprocal Rank Fusion (RRF) o un re-clasificador entrenado. En nuestra experiencia, la búsqueda híbrida mejora la relevancia de las respuestas entre un 15 y 30 % respecto a la búsqueda semántica pura, especialmente para corpus específicos de un dominio con vocabulario especializado. La mejora es aún mayor cuando los usuarios mezclan lenguaje natural con códigos o identificadores específicos en sus consultas.

Cómo implementarlo: pgvector admite la búsqueda semántica de forma nativa. Para BM25, utiliza la búsqueda de texto completo de PostgreSQL (tsvector/tsquery) junto con pgvector en la misma base de datos. Qdrant, Weaviate y Pinecone ofrecen búsqueda híbrida integrada.

Re-Ranking (Re-clasificación)

Un re-ranker toma los 20-50 mejores candidatos de la recuperación inicial y los puntúa con más cuidado utilizando un modelo de codificador cruzado (cross-encoder) que analiza tanto la consulta como el documento juntos. La recuperación inicial es rápida pero aproximada (compara vectores de forma independiente); el re-ranking es más lento pero mucho más preciso (compara pares consulta-documento de forma conjunta).

Este enfoque de dos etapas te brinda la velocidad de la búsqueda vectorial con la precisión de un codificador cruzado. Cohere Rerank v3, los modelos de codificador cruzado de Hugging Face y los modelos basados en ColBERT son las opciones más populares.

Impacto práctico: En nuestras pruebas, añadir un re-ranker mejora consistentemente la calidad de las respuestas en un 10-20 %, medido por la exhaustividad (recall) de la recuperación en K=5. El costo de latencia suele ser de 50-100 ms, lo cual vale totalmente la pena.

Etapa 6: Generación

Los pasajes recuperados (y re-clasificados) se inyectan en el prompt del LLM como contexto, junto con la pregunta del usuario e instrucciones del sistema. El modelo genera una respuesta fundamentada en el contexto proporcionado.

Los buenos prompts instruyen al modelo para:

• Responder únicamente a partir del contexto proporcionado; no utilizar conocimientos previos.
• Decir "No lo sé" o "Los documentos disponibles no cubren esto" cuando el contexto no contenga la respuesta. Esto es fundamental para la confianza.
• Citar documentos o pasajes específicos, idealmente con nombres de documentos y números de página para que los usuarios puedan verificar.
• Mantener un tono, formato y nivel de detalle consistentes y apropiados para tu audiencia.
• Manejar preguntas de varias partes abordando cada una de forma sistemática.

Consejo de ingeniería de prompts: Incluye una breve descripción de los tipos de documentos en tu prompt de sistema. Decirle al modelo "Estás respondiendo basándote en nuestra documentación interna de ingeniería y guías de API" le ayuda a establecer expectativas y un tono adecuados.

Errores comunes

Incluso los sistemas RAG bien diseñados pueden fallar de formas sutiles. Estos son los errores que vemos con más frecuencia, junto con cómo evitarlos:

1. Basura entra, basura sale. Si tus documentos fuente están desordenados, desactualizados o son contradictorios, ninguna cantidad de recuperación inteligente te salvará. Invierte en la calidad de los datos antes de invertir en infraestructura. Realiza una auditoría de contenido: elimina documentos obsoletos, fusiona duplicados y llena los vacíos.

2. Desajustes en la fragmentación. Los fragmentos demasiado pequeños eliminan el contexto y producen respuestas que parecen aleatorias. Los fragmentos demasiado grandes diluyen la relevancia, por lo que el modelo se aferra a la sección equivocada. Prueba múltiples tamaños con consultas reales y mide la exhaustividad de la recuperación.

3. Desajuste entre embedding y consulta. Si tus documentos son técnicos pero tus usuarios hacen preguntas informales (o viceversa), la brecha semántica perjudica la recuperación. Considera la reescritura de consultas (usar un LLM para reformular la pregunta del usuario en un lenguaje similar al del documento) o HyDE (Hypothetical Document Embedding), donde el modelo genera primero una respuesta hipotética y tú generas el embedding de esa respuesta en su lugar.

4. Ignorar los filtros de metadatos. Un usuario que pregunta por los "ingresos del tercer trimestre de 2024" no debería recuperar fragmentos de 2022. Utiliza metadatos (fechas, tipos de documentos, departamentos, líneas de productos) para pre-filtrar antes de la búsqueda vectorial. Esto es tanto una cuestión de relevancia como de seguridad.

5. Falta de un marco de evaluación. No puedes mejorar lo que no mides. Construye un conjunto de pruebas de pares pregunta-respuesta desde el primer día y realiza un seguimiento de la exhaustividad de la recuperación (¿aparecieron los fragmentos correctos en los mejores K?), la corrección de la respuesta (¿es la respuesta factualmente correcta?) y la fidelidad (¿la respuesta contradice o va más allá de las fuentes?).

6. Confiar demasiado en la recuperación top-1. La mejor respuesta no siempre está en el fragmento más similar. Recupera 5-10 fragmentos y deja que el LLM sintetice la información entre ellos. Algunas preguntas requieren combinar información de múltiples documentos.

7. Omitir el re-ranking. La recuperación inicial ANN es rápida pero aproximada. Un re-ranker mejora consistentemente la calidad de las respuestas por un pequeño costo de latencia. Si solo implementas una técnica "avanzada", que sea el re-ranking.

8. Descuidar el control de acceso. En entornos empresariales, diferentes usuarios deben ver diferentes documentos. Si tu sistema RAG no aplica permisos a nivel de documento, tienes una filtración de datos latente. Implementa seguridad a nivel de fila en los metadatos de tu almacenamiento vectorial.

Lista de verificación para producción

Antes de lanzar el sistema, asegúrate de haber cubierto estos aspectos esenciales:

• Pipeline de datos: ingesta automatizada que mantiene fresca tu base de conocimientos (sincronización diaria, disparada por webhook o en tiempo real).
• Fragmentación probada: has evaluado al menos dos estrategias de chunking con consultas de usuarios reales y medido la calidad de la recuperación.
• Modelo de embedding evaluado: has realizado pruebas con tus datos reales, no solo confiado en las puntuaciones de las tablas de clasificación.
• Búsqueda híbrida habilitada: tanto la recuperación semántica como la de palabras clave contribuyen a los resultados.
• Re-ranking implementado: un codificador cruzado o Cohere Rerank se sitúa entre la recuperación y la generación.
• Conjunto de datos de evaluación: al menos 50 pares de pregunta-respuesta con respuestas de referencia para pruebas de regresión continuas.
• Seguimiento de citas: cada respuesta generada enlaza de vuelta a los fragmentos de origen para que los usuarios puedan verificar las afirmaciones.
• Salvaguardas (Guardrails): el sistema se niega a responder cuando la confianza es baja en lugar de alucinar una ficción que suene plausible.
• Monitoreo y observabilidad: realizas un seguimiento de la latencia de recuperación, el uso de tokens del LLM, las señales de satisfacción del usuario, las puntuaciones de calidad de las respuestas y las tasas de error.
• Control de acceso: los usuarios solo recuperan documentos que están autorizados a ver (seguridad a nivel de fila en los metadatos).
• Controles de costos: presupuestos de tokens, almacenamiento en caché de consultas frecuentes, limitación de tasa y alertas sobre picos de uso inesperados.
• Bucle de retroalimentación: un mecanismo para que los usuarios marquen respuestas incorrectas, lo que alimenta tu conjunto de datos de evaluación y activa mejoras en la calidad de los datos.

Opciones de frameworks

No tienes que construir cada componente desde cero. Dos frameworks destacan para RAG en producción:

• LlamaIndex Workflows: diseñado específicamente para RAG, con cargadores de documentos listos para producción, estrategias de fragmentación, módulos de recuperación y herramientas de evaluación. Si RAG es tu caso de uso principal, LlamaIndex Workflows ofrece la experiencia más completa de fábrica.
• LangGraph: un framework de orquestación de flujos de trabajo basado en grafos (independiente de LangChain) que sobresale cuando tu pipeline de RAG incluye lógica condicional, revisión humana en el proceso o cadenas de razonamiento de múltiples pasos.

Ambos frameworks te permiten intercambiar modelos de embedding, bases de datos vectoriales y proveedores de LLM sin tener que reescribir tu pipeline. Comienza con un framework si quieres avanzar rápido; recurre a código personalizado cuando necesites el máximo control sobre una capa específica.

Próximos pasos

Si estás planeando un sistema RAG y quieres saltarte meses de prueba y error, nuestro servicio de sistemas RAG cubre el diseño de la arquitectura, la implementación y la optimización continua. Para los equipos que ya tienen un pipeline de RAG básico y necesitan escalarlo, nuestra guía sobre escalar RAG a producción profundiza en el ajuste del rendimiento, la multi-tenencia y los marcos de evaluación.

RAG no es un proyecto de fin de semana, pero es el patrón individual más efectivo para hacer que los LLMs sean genuinamente útiles con tus propios datos. Haz bien los cimientos y tendrás un sistema que se vuelve más inteligente a medida que crece tu base de conocimientos, cuesta una fracción de lo que costaría un ajuste fino y ofrece respuestas en las que tus usuarios realmente confían.