Cómo crear un RAG de producción: ingesta, embeddings, recuperación, reranking y evaluación

Si has implementado un sistema RAG sencillo, conoces el patrón: fragmentar documentos, generar embeddings, almacenarlos en una base de datos vectorial, recuperar los top-k para una consulta e incluirlos en el prompt. Funciona en una demostración; en producción suele decepcionar.

La distancia entre un RAG de demostración y uno de producción es considerable. Los documentos reales son desordenados, las consultas son ambiguas y la calidad varía mucho según su tipo. El coste y la latencia imponen restricciones reales, y tanto las actualizaciones como el versionado importan.

Este artículo cubre cómo se ve un pipeline de RAG de producción — las seis etapas, los patrones en cada una y la disciplina de evaluación que distingue los sistemas que funcionan de los que decepcionan.

El pipeline

Un sistema RAG de producción tiene seis etapas lógicas:

[Documents] 
    ↓ 
1. Ingestion (parsing, cleaning, metadata extraction)
    ↓
2. Chunking (splitting into retrieval units)
    ↓
3. Embedding (vectors + storage)
    ↓
[Query]
    ↓
4. Retrieval (semantic + lexical + filters)
    ↓
5. Reranking (top-k → top-N)
    ↓
6. Generation (LLM + context)
    ↓
[Response]

Cada etapa tiene sus propias preocupaciones de calidad. Mejorar cualquiera mejora el conjunto.

Vamos a revisar cada una.

Etapa 1: Ingesta

Si entran datos deficientes, saldrán resultados deficientes. La calidad de la ingesta determina el techo de todo el sistema.

Tipos de fuentes que encontrarás:

• PDFs (suelen ser los peores).
• Documentos de Word.
• Páginas HTML.
• Markdown.
• Hojas de cálculo.
• Diapositivas (PowerPoint, Google Slides).
• Correos electrónicos.
• Código.
• Datos estructurados (CSV, JSON).

Cada uno tiene sus propios desafíos de análisis.

Procesamiento de PDF. Un PDF es un formato de presentación, no de datos, y resulta especialmente difícil de procesar. Estrategias:

• PDFs basados en texto: pdfplumber, pymupdf, unstructured. Funcionan para texto limpio.
• PDFs escaneados: OCR con Tesseract, Google Cloud Vision o AWS Textract.
• Con reconocimiento del diseño: LayoutLM, Mathpix o procesamiento mediante IA (GPT-4 vision) para diseños complejos, como tablas o varias columnas.

Enfoque moderno para PDFs difíciles: usar un modelo de lenguaje con capacidad visual para OCR y estructurar el contenido. El coste es mayor, pero la calidad es significativamente mejor que el OCR tradicional.

Gestión de tablas. Las tablas dentro de texto no estructurado son problemáticas. Opciones:

• Convertir a tablas de markdown (preserva la estructura).
• Linealizarlas como prosa («Fila 1: el cliente A realizó 50 pedidos…»).
• Tratar como unidades recuperables separadas con un esquema estructurado.

La elección correcta depende de las consultas que recibirás.

Extracción de metadatos. Cada documento tiene metadatos importantes:

• Título, autor, fecha, versión.
• Tema, categoría, etiquetas.
• URL o ubicación de la fuente.
• Permisos y visibilidad.

Captura esto en la ingesta. Se convierte en parámetros de filtro en el momento de la recuperación.

Limpieza. Elimina elementos innecesarios:

• Encabezados/pie de página que se repiten en cada página.
• Navegación, anuncios, banners de cookies.
• Páginas de “índice de contenido”.
• Párrafos vacíos o duplicados.

Un corpus limpio recupera mejor. Los elementos innecesarios causan coincidencias falsas.

Verificaciones de calidad.

• ¿El analizador extrajo realmente texto? (Algunos PDF devuelven cadenas vacías).
• ¿Hay problemas de codificación?
• ¿Se preservan las tablas?
• ¿Se etiquetan o se omiten las figuras?

Incorpora comprobaciones básicas de coherencia al pipeline de ingesta. Detecta los procesos fallidos antes de que contaminen el índice.

Etapa 2: Fragmentación

Tienes documentos limpios. Ahora los divides en unidades de recuperación (fragmentos).

El compromiso fundamental:

• Fragmentos pequeños: recuperación precisa (enfocada en la pregunta), pero falta contexto.
• Fragmentos grandes: más contexto, pero menos precisión porque la parte pertinente queda enterrada.

Ambos extremos pierden calidad. El punto óptimo varía según el tipo de contenido.

Estrategias comunes:

Fragmentos de tamaño fijo con solapamiento. Divide el contenido en fragmentos de N tokens (300-800 tokens) con un solapamiento de 50-100 tokens. Es sencillo y funciona como punto de partida.

Fragmentación basada en oraciones. Dividir en límites de oración (usando nltk, spaCy o similar). Evita divisiones en medio de oraciones.

Basado en párrafos. Cada párrafo es un fragmento. Funciona para documentos con párrafos bien estructurados.

Jerárquica (pequeño + grande). Dos índices:

• Fragmentos pequeños (300 tokens) para recuperación precisa.
• Fragmentos grandes (1500 tokens) o secciones completas para contexto. Durante la recuperación se localizan los pequeños, pero se entregan a la IA sus fragmentos padre de mayor tamaño.

Basada en la estructura del documento. Utiliza encabezados y secciones para definir los fragmentos. Cada sección se convierte en un fragmento y conserva su jerarquía.

Fragmentación semántica. Utiliza embeddings para localizar puntos de corte naturales, donde cambia el tema. Es más costosa, pero mejora algunos tipos de contenido.

Fragmentación basada en resúmenes generados por IA. Los documentos largos se resumen de forma jerárquica en varios niveles —párrafo, sección y documento—. La IA los genera una sola vez durante la ingesta.

La estrategia correcta depende del contenido. Artículos y wikis: párrafo o jerárquico. Código: nivel de función. Conversaciones: basado en turnos. Documentos técnicos: consciente de la estructura.

Metadatos de fragmentos. Cada fragmento debe llevar:

• ID y URL del documento de origen.
• Ruta de la sección (capítulo > sección > subsección).
• Número de página (para citar).
• Encabezados por encima de este fragmento (para contexto).
• Metadatos a nivel de documento (fecha, autor, tipo).

Estos metadatos permiten filtrar y citar en la respuesta final.

Etapa 3: Embeddings

Convierte los fragmentos en vectores.

Elección del modelo de embeddings.

En 2026:

• OpenAI text-embedding-3-large: todo en uno, caro.
• Voyage Voyage-3: competitivo, a menudo mejor en contenido técnico.
• Cohere embed-v4: fuerte en multilingüe.
• BAAI bge-large: fuerte en código abierto.
• Nomic embed-text: una buena opción de código abierto, gratuita para alojamiento propio.
• Modelos especializados en dominio: para código (Voyage Code, OpenAI text-embedding-3-large también funciona para código), legal, médico, etc.

Elegir un modelo: prueba contra tu dominio. No asumas que el ganador de la lista es el mejor para tus datos.

Dimensión de los embeddings. Los modelos ofrecen 256-3072 dimensiones. Más dimensiones suelen aportar mayor calidad, pero aumentan el coste y el almacenamiento. Para la mayoría de los casos, 768-1536 es el punto óptimo.

Versionado. Los modelos de incrustación se actualizan; quizás quieras cambiar. Planifica esto:

• Registra qué versión del modelo de embeddings produjo cada vector.
• Vuelve a generar todos los embeddings al migrar o utiliza una transición con dos índices.
• No mezcles vectores de diferentes modelos en la misma búsqueda.

Coste. Generar embeddings de millones de fragmentos cuesta dinero: €0.10-€0.50 por millón de tokens, según el proveedor. Para corpus grandes, calcula el coste de antemano.

Almacenamiento. Los vectores son grandes. 1M fragmentos × 1536 dimensiones × 4 bytes = 6GB. Planifica el almacenamiento en consecuencia.

Etapa 4: Recuperación

La consulta llega. Debes encontrar fragmentos relevantes.

Búsqueda vectorial (recuperación densa). Genera el embedding de la consulta y busca sus vecinos más próximos. Captura la similitud semántica y constituye el enfoque estándar.

Búsqueda por palabras clave (BM25 / léxico). Búsqueda de texto tradicional. Captura coincidencias exactas, términos raros, nombres específicos. A menudo complementa la búsqueda vectorial.

Búsqueda híbrida. Ejecuta ambos métodos y fusiona los resultados. La fusión por rango recíproco (RRF) es el enfoque habitual.

def reciprocal_rank_fusion(rankings, k=60):
    scores = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: -x[1])

En la práctica, la búsqueda híbrida supera a la búsqueda vectorial o por palabras clave en la mayoría de los benchmarks. Úsala por defecto.

Filtrado por metadatos. Aplica los filtros antes de puntuar: «solo documentos de 2025+», «solo documentos accesibles para el usuario» o «solo documentos de tipo política».

Crítico para sistemas multiinquilino: cada consulta está limitada a los documentos accesibles del inquilino.

Comprensión de la consulta. Preprocesa la consulta:

• Corrección ortográfica. “engineerin” → “engineering.”
• Expansión de acrónimos. “MFA” → “Autenticación de múltiples factores MFA.”
• Sinónimos / expansión de consulta. Genera alternativas de formulación; busca con cada una.
• Descomposición. Preguntas de múltiples partes se dividen en subconsultas, cada una recuperada por separado.

Estos pasos de preprocesamiento mejoran significativamente la recuperación en consultas del mundo real.

HyDE (embeddings de documentos hipotéticos). Genera con IA una respuesta ideal hipotética, calcula su embedding y utilízalo como consulta de recuperación. Suele funcionar mejor que generar directamente el embedding de la pregunta, porque el texto hipotético se parece más a los documentos que contienen respuestas reales.

def hyde_retrieve(query, k=20):
    hypothetical = llm("Write a passage answering: " + query)
    embedding = embed(hypothetical)
    return vector_search(embedding, k=k)

Compromiso: llamada adicional de IA por consulta (latencia, coste). Vale la pena para consultas difíciles; excesivo para consultas simples.

Recuperación multivector. En lugar de un vector por fragmento, utiliza varios: uno para el contenido, otro para un resumen y otro para preguntas hipotéticas. Añade almacenamiento y complejidad, pero mejora la recuperación en ciertos tipos de contenido.

Etapa 5: Reranking

Después de la recuperación inicial (top-k, k=20-50), utiliza un reranker para puntuar los candidatos con mayor precisión.

¿Por qué aplicar reranking?

La recuperación inicial es rápida, pero imprecisa. La similitud vectorial solo aproxima la relevancia. Un reranker —normalmente un modelo de codificación cruzada— compara la consulta con cada candidato y produce una puntuación más precisa.

Opciones de reranking:

• Cohere Rerank. Estándar de la industria. Buena calidad, alojado.
• Voyage Rerank. Fuerte competidor.
• BGE Rerank-large. De código abierto y gratuito para alojamiento propio.
• MiniLM codificadores cruzados. Más pequeños, más rápidos, menor calidad.
• Reranking basado en IA. Utiliza un modelo pequeño para puntuar pares de consulta y candidato. Ofrece más calidad, pero también un coste mayor.

El impacto.

Añadir reranking suele mejorar la calidad de la tarea final en la mayoría de los sistemas RAG. Considera el intervalo citado habitualmente de 10-20% como una estimación de planificación que debes verificar con tus propias evaluaciones. Casi siempre compensa la latencia y el coste.

Configuración típica:

• Recupera 30-50 candidatos con búsqueda híbrida.
• Aplica reranking para obtener los top 5-10.
• Envía los resultados principales a la IA.

Reranking adaptativo.

Si el primer resultado presenta una similitud vectorial alta —una coincidencia clara—, omite el reranking. Si varios candidatos tienen puntuaciones próximas, aplícalo de forma exhaustiva.

Etapa 6: Generación

La IA genera la respuesta usando el contexto recuperado.

Estructura del prompt:

You are an assistant answering questions based on the provided context.

Context:
[Document 1 - title, URL]
[chunk 1 content]
[Document 2 - title, URL]
[chunk 2 content]
...

User question: {query}

Instructions:
- Answer based only on the provided context.
- If the context doesn't contain the answer, say so. Don't make up information.
- Cite sources using [Source N] notation.
- Be concise but complete.

Los patrones de prompt que importan:

• Etiquetado de fuentes. Cada fragmento de contexto se etiqueta con su fuente para citar.
• Instrucciones de fundamentación. Dile explícitamente al modelo que use solo el contexto.
• Requisito de citación. Obliga a citar. Captura alucinaciones.
• Instrucción de respuesta alternativa. «Si el contexto no contiene la respuesta, indícalo». Evita la confabulación.

Gestión de citas.

Un patrón habitual consiste en incluir enlaces a las fuentes para que la interfaz pueda mostrarlos como vínculos.

"The company's remote work policy allows up to 4 days/week from home [1].
[1]: https://wiki.company.com/policies/remote-work"

Esto hace que la respuesta sea verificable. Los usuarios confían más en respuestas fundamentadas.

Gestión del tamaño del contexto.

Los contextos extensos degradan el rendimiento. La mayoría de los modelos funcionan mejor con 5-10 fragmentos muy pertinentes que con todo el corpus volcado en el prompt. La calidad disminuye cuando el contexto se infla.

Si debes incluir mucho contexto, resume los elementos menos relevantes en lugar de incluirlos en su totalidad.

Evaluación en cada etapa

No puedes optimizar lo que no midas. Cada etapa necesita sus propias evaluaciones.

Evaluación de ingesta. ¿Los documentos se analizaron correctamente? Muestra documentos; verifica que el contenido clave se preserve.

Evaluación de fragmentación. ¿Los fragmentos están en el tamaño correcto? ¿Preservan el contexto? ¿Se rompen en límites sensibles?

Evaluación de embeddings. ¿Los conceptos similares producen vectores próximos? En un conjunto de pares conocidos como similares o distintos, ¿la similitud coseno coincide con lo esperado?

Evaluación de recuperación. Dada una consulta, ¿los fragmentos relevantes están en los top-K? Métrica común: recall@K (¿qué porcentaje de consultas tiene al menos un fragmento relevante en los top K).

Evaluación del reranking. Dados los candidatos recuperados, ¿el reranker coloca primero el más pertinente? Métricas: NDCG (ganancia acumulada normalizada) o MRR (rango recíproco medio).

Evaluación de generación. Dado el contexto y la consulta, ¿la IA produce una respuesta correcta? Métricas: fidelidad (¿la respuesta usa el contexto?), corrección (¿la respuesta es correcta?), utilidad (¿aborda la intención del usuario?).

Evaluación end-to-end. Ante una consulta real, ¿produce el sistema la respuesta correcta? Es la evaluación más importante y depende de todas las etapas.

Necesitas conjuntos de prueba para todas ellas. Un punto de partida habitual:

• Construye 50-100 consultas con respuestas conocidas como buenas.
• Para cada consulta, identifica qué documento(s) contienen la respuesta.
• Usa esto para evaluar la recuperación (¿recuperamos los documentos correctos?) y la generación (¿la respuesta es correcta?).

Herramientas: Ragas, TruLens, suites personalizadas. La herramienta exacta importa menos que ejecutar las evaluaciones.

Preocupaciones operativas

Unas pocas realidades de producción:

Pipelines de indexación. Llegan documentos nuevos, deben generarse nuevos embeddings, actualizarse los índices y gestionarse las modificaciones y eliminaciones. El pipeline se ejecuta de forma continua, no solo durante la configuración inicial. Constrúyelo como un sistema, no como un script aislado.

Latencia.

Desglose típico:

• Incrustación (consulta): 50-200ms.
• Búsqueda vectorial: 50-200ms.
• Reordenamiento: 200-500ms (dependiendo de K).
• Generación: 1-5 s (dependiendo del contexto y el modelo).
• Total: 1.5-6 s.

Optimización:

• Caché de embeddings para consultas frecuentes.
• Caché de resultados de reranking para pares repetidos de consulta y candidato.
• Generación en streaming.
• Paralelización donde sea posible.

Para conseguir una latencia inferior a 2 s, normalmente se necesita un modelo de embeddings rápido, una base de datos vectorial eficiente y un reranker rápido, o bien omitir el reranking en consultas sencillas o almacenadas en caché.

Costo.

Costos por consulta:

• Incrustación: ~€0.0001.
• Búsqueda vectorial: ~€0.0001 (dependiendo de la infraestructura).
• Reordenamiento: €0.001-0.01 (dependiendo del modelo).
• Generación: €0.005-0.05 (dependiendo del modelo y el contexto).
• Total: ~€0.01-0.05 por consulta.

A gran escala, esto suma. Un millón de consultas = €10K-50K.

Optimización de costes:

• Caché.
• Usa modelos más económicos donde la calidad lo permita.
• Comprime el contexto —resúmenes frente a fragmentos completos—.

Actualizaciones. Los documentos cambian. Patrones:

• Versionado: cada documento tiene una versión; las versiones antiguas se conservan o eliminan según la política.
• Incremental: las nuevas versiones vuelven a fragmentarse y a generar sus embeddings; los fragmentos antiguos se eliminan.
• Consciente de diferencias: solo las secciones modificadas se reprocesan.

Para escenarios de alta actualización, esto importa significativamente.

Permisos. RAG sobre datos privados: los documentos tienen controles de acceso; la recuperación debe respetarlos.

• Filtro basado en metadatos (cada fragmento tiene metadatos de accesibilidad).
• Índices aislados por inquilino para aislamiento estricto.
• Registro de auditoría de quién accedió a qué.

No confíes en la IA para aplicar los permisos. Impónlos en la capa de recuperación.

Modos de falla comunes

Algunos patrones que vemos en sistemas RAG fallidos:

Fallo 1: Fragmentación mala. Fragmentos divididos en medio de un pensamiento, tablas rotas entre fragmentos, encabezados separados de su contenido. Solución: mejor estrategia de fragmentación.

Fallo 2: Recuperación que no encuentra la respuesta. El fragmento relevante existe pero no se recupera. A menudo es un desajuste entre consulta y documento. Solución: HyDE, expansión de consulta, mejores incrustaciones.

Fallo 3: Fragmentos correctos, orden incorrecto. El fragmento pertinente se recupera, pero queda en una posición baja. La IA utiliza otros menos relevantes con mayor puntuación. Solución: reranking.

Fallo 4: Fragmentos correctos, alucinación. Los fragmentos son correctos pero la IA inventa información adicional. Solución: instrucciones de fundamentación más estrictas, requisito de citación, temperatura más baja.

Fallo 5: Fragmentos correctos, respuesta incorrecta. Los fragmentos contienen la respuesta pero la IA extrae la parte equivocada. Solución: mejor instrucción de generación, posiblemente un modelo más grande.

Fallo 6: Datos obsoletos. El índice no se ha actualizado. Solución: pipeline de ingesta continua.

Fallo 7: Fugas de permisos. Los usuarios ven fragmentos que no deberían. Solución: impón filtrado en la recuperación; auditoría.

Fallo 8: Costes descontrolados. La latencia y el coste aumentaron al crecer el corpus y el tráfico. Solución: caché, enrutamiento de modelos y, posiblemente, cambios de arquitectura.

Ejemplo práctico: sistema RAG de base de conocimiento de empresa

Para hacerlo concreto: un sistema típico de RAG de base de conocimiento de empresa.

Corpus: ~50,000 documentos (páginas de wiki, políticas, runbooks, notas de reunión, hilos de Slack).

Pipeline:

1. Ingesta:

   • Notion: exportación por API.
   • Slack: exportación de archivo, filtrada a canales relevantes.
   • Google Drive: exportación por API de carpetas aprobadas.
   • Limpieza: eliminar mensajes con solo emojis, firmas de plantilla.

2. Fragmentación:

   • Jerárquica: fragmentos pequeños a nivel de párrafo, fragmentos padres a nivel de sección.
   • ~250K fragmentos totales a nivel pequeño.
   • Metadatos: fuente, ruta de sección, última actualización, accesible a.

3. Incrustación:

   • Incrustaciones Voyage-3, 1024 dimensiones.
   • Almacenadas en Pinecone (gestionado).
   • Embeddings regenerados cada semana para los documentos modificados.

4. Recuperación:

   • Híbrida: búsqueda vectorial + BM25 (vía Pinecone híbrida).
   • HyDE para la consulta.
   • Filtro de metadatos para accesibilidad.
   • Recuperados los top 30.

5. Reranking:

   • Cohere Rerank.
   • Top 30 → top 8.

6. Generación:

   • Claude Sonnet 5.
   • Top 8 fragmentos padres (no fragmentos pequeños) proporcionados como contexto.
   • Requisito de citación en la respuesta.

Evaluación:

• 100 pares de consulta/respuesta elaborados a mano.
• Recall@30 de recuperación: ~92%.
• Corrección de la respuesta final: ~85%.
• Fidelidad (sin alucinación): ~95%.

Operaciones:

• Ingesta incremental diaria.
• Regeneración semanal de embeddings para los documentos modificados.
• Observabilidad por consulta.
• Reevaluación mensual y monitorización de tendencias.
• Revisión trimestral del registro de consultas para detectar nuevos patrones de falla.

Costos:

• Incrustación: ~€500/mes (estado estable).
• Almacenamiento de base de datos vectorial: ~€800/mes (Pinecone).
• Recuperación + generación por consulta: ~€0.02.
• Total: ~€2,500/mes + €0.02 × volumen de consultas.

Para la mayoría de las empresas, este coste queda plenamente justificado por las mejoras de productividad.

Plan de construcción de RAG en 90 días

Si estás empezando desde cero:

Días 1-30: MVP.

• Identifica el corpus y el caso de uso principal.
• Construye una ingesta básica (una fuente).
• Fragmentación básica (tamaño fijo con superposición).
• Modelo estándar de embeddings.
• Solo búsqueda vectorial (sin reranking).
• Prompt de generación simple.

Días 31-60: Calidad.

• Elabora un conjunto de evaluación manual (50-100 consultas).
• Identifica modos de falla.
• Añade reranking.
• Añade búsqueda híbrida.
• Mejora la fragmentación.

Días 61-90: Operaciones.

• Pipeline de ingesta continua.
• Observabilidad.
• Automatización de evaluación.
• Permisos y autenticación.
• Monitorización de costes.

Después de 90 días, tendrás un sistema que no solo puede demostrarse, sino que resulta realmente útil y en el que los usuarios pueden confiar.

La calidad vive en cada etapa

El RAG de producción es un pipeline de seis etapas con preocupaciones de calidad en cada etapa. Los patrones que distinguen los sistemas que funcionan de los que decepcionan:

• Ingesta: análisis completo, preservación de estructura, captura de metadatos.
• Fragmentación: estrategia adecuada para el tipo de contenido, a menudo jerárquica.
• Embeddings: modelo de calidad, versionado y planificación de las migraciones.
• Recuperación: híbrida por defecto, comprensión de consulta, filtrado de metadatos.
• Reranking: casi siempre merece la pena.
• Generación: fundamentación, citas y respuesta segura cuando no se conoce la respuesta.
• Evaluación: en cada etapa, continuamente.

Ninguna de estas cosas es opcional. La brecha entre un RAG que alcanza el 60% de calidad de respuesta y un RAG que alcanza el 90% vive en estos detalles.

La inversión es real: crear un RAG de producción lleva meses, no semanas. La recompensa es un sistema en el que los usuarios pueden confiar. Ese es el umbral importante.