Preparación de Datasets para RAG vs Fine-Tuning: Pipelines Diferentes, Mismos Datos de Origen

La mayoría de los equipos de IA empresarial terminan construyendo dos pipelines de datos separados: uno para preparar documentos para RAG (generación aumentada por recuperación), y otro para preparar datos de entrenamiento para fine-tuning. Ambos pipelines parten de los mismos documentos crudos — los mismos PDFs, las mismas wikis internas, los mismos manuales de políticas. Comparten las mismas etapas de ingesta y limpieza. Luego divergen.

Ejecutar estos como dos pipelines independientes significa duplicar el 60-70% del trabajo. Ingieres los mismos PDFs dos veces. Limpias el mismo texto dos veces. Extraes las mismas entidades dos veces. Depuras los mismos errores de parsing dos veces. Y cuando un documento se actualiza, tienes que recordar reprocesarlo en ambos pipelines — lo cual inevitablemente se olvida.

El mejor enfoque es un pipeline unificado que comparte las etapas comunes y se bifurca en dos rutas de exportación. Una fuente, dos salidas. Este artículo cubre exactamente dónde los pipelines comparten trabajo, dónde divergen y cómo ejecutar ambos desde un solo proyecto de preparación de datos.

Los Dos Formatos de Salida

Antes de entrar en el pipeline, entiende cómo debe verse cada salida.

Salida RAG: Texto Fragmentado + Metadatos para Vector DB

Los sistemas RAG recuperan fragmentos de texto relevantes en tiempo de consulta y los alimentan al modelo como contexto. La salida es:

{
  "chunk_id": "doc-4421-section-3-chunk-2",
  "text": "The maximum credit exposure for Category A clients shall not exceed 15% of tier-1 capital...",
  "metadata": {
    "source_document": "Credit Risk Policy v4.2",
    "section": "3. Exposure Limits",
    "page": 12,
    "date": "2025-11-01",
    "entities": ["Category A", "tier-1 capital"],
    "doc_type": "policy"
  },
  "embedding": [0.0234, -0.1891, 0.0442, ...]
}

Cada fragmento es lo suficientemente autónomo para responder una pregunta, lleva metadatos para filtrado y atribución, e incluye un embedding vectorial para búsqueda semántica.

Salida de Fine-Tuning: Pares Instrucción/Respuesta en JSONL

Los datasets de fine-tuning enseñan conocimiento de dominio al modelo directamente. La salida son pares de pregunta-respuesta derivados de los documentos fuente:

{
  "messages": [
    {
      "role": "system",
      "content": "You are a credit risk analyst assistant."
    },
    {
      "role": "user",
      "content": "What is the maximum credit exposure limit for Category A clients?"
    },
    {
      "role": "assistant",
      "content": "The maximum credit exposure for Category A clients shall not exceed 15% of tier-1 capital, as defined in Credit Risk Policy v4.2, Section 3."
    }
  ]
}

Cada par captura una pieza específica de conocimiento de los documentos fuente, formateada como un intercambio conversacional.

Por Qué Generalmente Necesitas Ambos

La decisión generalmente no es "RAG o fine-tuning". Para despliegues empresariales con requisitos de precisión serios, la respuesta es ambos.

RAG maneja la cola larga: Documentos que se actualizan frecuentemente, conocimiento de nicho que aplica a consultas poco frecuentes, y cualquier información donde necesitas atribución exacta de la fuente. RAG recupera la fuente, para que el usuario pueda verificar.

Fine-tuning maneja el núcleo común: Las 200-500 preguntas que constituyen el 80% de todas las consultas de usuarios. Estos son fundamentos del dominio — definiciones, procedimientos estándar, cálculos comunes. Un modelo ajustado responde instantáneamente sin latencia de recuperación y con mayor consistencia.

Un equipo de servicios financieros encontró que el fine-tuning cubría el 78% de las consultas de analistas (definiciones regulatorias estándar, métodos de cálculo de riesgo, procedimientos de reporteo). RAG manejó el 22% restante (datos específicos de clientes, actualizaciones regulatorias recientes, detalles de productos de nicho). El sistema combinado superó a cualquiera de los dos enfoques por separado en un 23% en precisión de respuestas.

Construir ambas salidas desde un solo pipeline no solo es más eficiente — produce mejores resultados porque el mismo trabajo de limpieza y estructuración aplica a ambos.

Etapas Compartidas: Ingesta, Limpieza, Extracción de Entidades

Las primeras tres etapas del pipeline son idénticas independientemente del formato de salida.

Ingesta

Parsear documentos crudos en un formato intermedio estandarizado. PDF, Word, HTML, correo electrónico, exportaciones de wiki — todo convertido a texto limpio con marcadores estructurales (encabezados, secciones, tablas, listas) y metadatos de origen.

Esta etapa depende del formato, no de la salida. Un PDF es un PDF ya sea que lo estés fragmentando para RAG o extrayendo pares Q&A para fine-tuning. Ejecútalo una vez.

Limpieza

Eliminar artefactos de OCR, deduplicar documentos, normalizar Unicode, eliminar contenido repetitivo (encabezados, pies de página, marcas de agua). Validar que el proceso de limpieza no eliminó contenido significativo.

Los errores de limpieza se propagan a ambas salidas. Un término mal escrito en el texto limpio se convierte en un fragmento mal escrito en la base vectorial y una respuesta mal escrita en el dataset de fine-tuning. Corrígelo una vez en la etapa de limpieza, no dos veces en la etapa de exportación.

Extracción de Entidades y Estructura

Identificar la estructura del documento (secciones, subsecciones, tablas), extraer entidades nombradas (productos, regulaciones, personas, fechas) y etiquetar metadatos. Esta información estructural alimenta ambos pipelines:

• RAG la usa para recuperación filtrada por metadatos ("muéstrame solo documentos de la Sección 3 de la Política de Riesgo")
• Fine-tuning la usa para generación de preguntas ("¿Qué dice la Sección 3 de la Política de Riesgo sobre los límites de exposición?")

Ejecuta la extracción de entidades una vez. Ambos pipelines consumen las mismas anotaciones estructurales.

El Punto de Divergencia

Después de la limpieza y la extracción de estructura, el pipeline se bifurca. El mismo texto limpio y estructurado alimenta dos procesos paralelos.

Rama A: Pipeline RAG

Fragmentación: Dividir el texto estructurado en fragmentos optimizados para recuperación. La estrategia de fragmentación depende del tipo de documento:

• Documentos de políticas: fragmentar a nivel de sección, con superposición en los límites de sección
• Manuales técnicos: fragmentar a nivel de procedimiento/paso
• Correspondencia: fragmentar a nivel de mensaje (para hilos de correo) o nivel de párrafo
• Tablas: mantener tablas como fragmentos únicos con contexto circundante

Tamaño objetivo de fragmento: 256-512 tokens para la mayoría de los modelos de embedding. Incluir un prefijo de contexto (título del documento + encabezado de sección) en cada fragmento para que el fragmento tenga sentido de forma aislada.

Etiquetado de metadatos: Adjuntar metadatos filtrables a cada fragmento: documento fuente, sección, fecha, entidades, tipo de documento, puntuación de confianza.

Embedding: Ejecutar cada fragmento a través de un modelo de embedding para generar representaciones vectoriales. Para despliegues on-prem, usar un modelo de embedding local — BGE-large, E5-large, o el modelo de embedding Nomic vía Ollama. Procesamiento por lotes: una sola GPU genera embeddings de 10,000-50,000 fragmentos por hora dependiendo de la longitud del fragmento y el tamaño del modelo.

Indexación: Cargar fragmentos y embeddings en una base de datos vectorial (Qdrant, Milvus o Chroma, todos disponibles para despliegue on-prem). Crear índices de metadatos para búsqueda filtrada.

Rama B: Pipeline de Fine-Tuning

Generación de preguntas: Para cada unidad estructural (sección, párrafo, tabla), generar preguntas que el contenido responde. Usar un LLM local para esto:

• Alimentar el contenido a Llama 3.3 70B o Qwen 2.5 72B vía Ollama
• Prompt: "Genera 3-5 preguntas que este texto responde. Las preguntas deben ser específicas y respondibles solo con el texto."
• Filtrar preguntas generadas: eliminar duplicados, eliminar preguntas demasiado vagas o demasiado específicas

Esto produce 5-15 preguntas por página de contenido fuente. Un documento de políticas de 100 páginas genera 500-1,500 pares Q&A antes del filtrado de calidad.

Extracción de respuestas: Para cada pregunta generada, extraer la respuesta del texto fuente. La respuesta debe ser una respuesta directa, no un copy-paste del párrafo fuente. Usar el LLM local para generar respuestas concisas y precisas del contenido fuente.

Conversión de formato: Convertir pares Q&A al formato JSONL esperado por tu framework de fine-tuning. Agregar system prompts apropiados al caso de uso (por ejemplo, "Eres un asistente de cumplimiento" o "Eres un analista de riesgo").

Validación: Verificar que cada respuesta esté respaldada por el texto fuente — sin información alucinada, sin hechos de otros documentos, sin números inventados. Esta es una puerta de calidad crítica. Rechazar cualquier par donde la respuesta no pueda rastrearse a un pasaje específico en la fuente.

Los Requisitos de Calidad Difieren

RAG y fine-tuning tienen diferente tolerancia al ruido, lo cual afecta cuán agresivamente necesitas filtrar.

RAG tolera algo de ruido porque el paso de recuperación actúa como un filtro secundario. Si un fragmento contiene un error menor de OCR, el sistema de recuperación podría aún mostrarlo para la consulta correcta, y el modelo puede trabajar alrededor del error al generar la respuesta. Una tasa de ruido del 2-5% en el corpus de fragmentos es aceptable para la mayoría de los despliegues RAG.

Fine-tuning requiere alta precisión por ejemplo porque cada ejemplo de entrenamiento moldea directamente el comportamiento del modelo. Un solo ejemplo de entrenamiento con información incorrecta enseña al modelo a producir esa información incorrecta con confianza. Apunta a una tasa de ruido inferior al 0.5% para datasets de fine-tuning — lo que significa validación agresiva y revisión humana de los pares Q&A generados.

Esta diferencia en tolerancia de calidad significa que la rama de fine-tuning necesita validación más pesada que la rama RAG. Presupuesta tiempo de revisión de expertos en consecuencia: planifica que los expertos de dominio revisen muestras del 5-10% de fragmentos RAG pero del 15-25% de pares de fine-tuning.

Ejecutando el Pipeline Unificado

El flujo de trabajo práctico funciona así:

1. Ingerir todos los documentos en el formato intermedio compartido. Una pasada.
2. Limpiar todo el corpus. Una pasada.
3. Extraer estructura y entidades. Una pasada.
4. Bifurcar a RAG: Fragmentar, etiquetar metadatos, generar embeddings, indexar. Esto se ejecuta como un trabajo por lotes, típicamente de noche.
5. Bifurcar a fine-tuning: Generar preguntas, extraer respuestas, formatear JSONL, validar. Esto se ejecuta en paralelo con el Paso 4 si tienes suficiente cómputo, o secuencialmente si no.
6. Revisión de expertos: Los expertos de dominio revisan una muestra de fragmentos RAG (revisión rápida) y una muestra más grande de pares de fine-tuning (revisión exhaustiva).
7. Exportar: Los fragmentos RAG van a la base de datos vectorial. Los pares de fine-tuning van al pipeline de entrenamiento.

Los pasos 1-3 son trabajo compartido. Los pasos 4-5 son paralelos pero independientes. El paso 6 es la puerta de calidad.

Ahorro de Tiempo y Costos

Ejecutar dos pipelines separados versus un pipeline unificado — aquí están los números para una base de conocimiento típica de 10,000 documentos:

El pipeline unificado ahorra aproximadamente un 33% en tiempo de cómputo y un 25% en tiempo de expertos. Más importante aún, elimina el problema de consistencia — ambas salidas están garantizadas de derivar de los mismos datos fuente limpios.

Actualizaciones de Documentos

Cuando los documentos fuente cambian, el pipeline unificado paga dividendos nuevamente.

Con pipelines separados, una actualización de documento significa: re-ingerir en el Pipeline A, re-limpiar en el Pipeline A, re-fragmentar y re-generar embeddings en el Pipeline A, luego recordar también re-ingerir en el Pipeline B, re-limpiar en el Pipeline B, re-generar pares Q&A en el Pipeline B. Olvida el segundo pipeline y tu sistema RAG tiene la información actualizada pero tu modelo ajustado aún tiene la versión anterior.

Con un pipeline unificado, una actualización de documento dispara una pasada de reprocesamiento a través de las etapas compartidas, luego bifurcación automática a ambas salidas. Ambas permanecen sincronizadas porque comparten una única fuente de verdad.

Para organizaciones que actualizan documentos de políticas trimestralmente, reentrenan modelos mensualmente y refrescan índices RAG semanalmente, esta sincronización no es una conveniencia — es un requisito para un comportamiento consistente del agente.

Cómo Ertas Data Suite Maneja la Salida Dual

Ertas Data Suite implementa este pipeline unificado de forma nativa. Creas un proyecto, importas tus documentos una vez, ejecutas limpieza y estructuración una vez, luego configuras dos destinos de exportación: formato de vector DB para RAG y JSONL para fine-tuning.

El sistema rastrea qué documentos han sido procesados a través de qué ramas, maneja actualizaciones incrementales cuando los documentos cambian y mantiene una pista de auditoría mostrando la trazabilidad desde el documento fuente hasta el fragmento RAG y el par de fine-tuning.

Para equipos que actualmente ejecutan pipelines separados — o peor, preparan datos RAG con una herramienta y datos de fine-tuning con otra — consolidar en un solo pipeline elimina una clase de bugs de consistencia que son costosos de depurar en producción.

Lectura Adicional

• Fine-Tuning vs RAG: Cuándo Usar Cuál — El marco de decisión estratégica para elegir entre RAG, fine-tuning, o ambos.
• Preparación de Datos de Entrenamiento Empresarial para Fine-Tuning — Profundización en el flujo de trabajo de preparación de datos de fine-tuning para equipos empresariales.
• Exportación Multi-Formato: Pipeline JSONL, COCO, YOLO — Cómo soportar múltiples formatos de exportación desde un solo pipeline de preparación de datos.