Back to blog
    Cómo construir un pipeline de preparación de datos on-premise para fine-tuning de LLM
    data-preparationon-premisefine-tuningdata-pipelinellmregulated-industriessegment:service-provider

    Cómo construir un pipeline de preparación de datos on-premise para fine-tuning de LLM

    Una guía completa para construir pipelines de preparación de datos on-premise para fine-tuning de LLM — cubriendo las 5 etapas desde la ingesta hasta la exportación, comparaciones de herramientas y arquitectura para entornos regulados.

    EErtas Team·

    Si entregas fine-tuning o soluciones de IA a empresas en salud, finanzas, legal o gobierno, ya conoces la restricción: los datos no pueden salir del edificio. No a una API en la nube. No a una plataforma SaaS de etiquetado. Ni siquiera a una instancia "privada" del proveedor ejecutándose en el centro de datos de alguien más.

    Esa restricción reconfigura todo el pipeline de preparación de datos. La mayoría de las herramientas open-source asumen acceso a la nube, almacenamiento en la nube y cómputo en la nube. Cuando eliminas esas suposiciones, el stack que te queda es fragmentado, difícil de mantener y difícil de entregar a equipos de clientes que carecen de experiencia en ingeniería ML.

    Esta guía cubre cómo construir un pipeline completo de preparación de datos on-premise para fine-tuning de LLM — las cinco etapas que todo pipeline necesita, las opciones reales de herramientas en cada etapa y dónde el enfoque fragmentado de open-source se descompone.


    Por qué la preparación de datos on-premise importa para proveedores de servicios

    Los proveedores de servicios — consultoras, integradores de sistemas, boutiques de ML — enfrentan una versión específica del problema on-premise. No estás construyendo un pipeline solo para tu propio equipo. Estás construyendo pipelines que deben:

    • Ejecutarse dentro de la infraestructura del cliente que no controlas
    • Producir rastros de auditoría que satisfagan al equipo de cumplimiento del cliente
    • Ser operables por expertos de dominio (enfermeras, abogados, analistas) que no van a escribir scripts de Python
    • Soportar múltiples formatos de exportación porque el modelo y caso de uso downstream varían por proyecto

    Cuando un sistema hospitalario te contrata para preparar notas clínicas para fine-tuning, necesitan el pipeline ejecutándose en su hardware, con registro completo, y su personal clínico necesita revisar y corregir etiquetas. Cuando un banco te contrata para construir un modelo de clasificación de documentos, las mismas restricciones aplican — excepto que ahora es SOC 2 y SR 11-7 en lugar de HIPAA.

    El hilo común: cero salida de datos, rastro de auditoría completo, accesible para no ingenieros.


    Las 5 etapas de un pipeline completo de preparación de datos

    Todo pipeline de preparación de datos para fine-tuning de LLM pasa por cinco etapas. Omite cualquiera y pasarás semanas depurando por qué tu modelo ajustado tiene bajo rendimiento.

    Etapa 1: ingesta

    Los documentos empresariales crudos — PDFs, archivos Word, hojas de cálculo Excel, formularios escaneados, dibujos CAD — necesitan ser parseados en texto estructurado. Esto es más difícil de lo que parece.

    Un PDF escaneado de 1998 requiere OCR. Un PDF moderno con diseños de tabla complejos requiere extracción consciente del diseño. Un documento Word con control de cambios requiere lógica de decisión sobre qué versión extraer. La ingesta multiformato a escala empresarial significa manejar más de 50 tipos de archivo de manera confiable.

    Para una mirada más profunda a los desafíos de ingesta y opciones de OCR, consulta nuestra guía sobre configurar ingesta local de documentos para IA empresarial.

    Etapa 2: limpieza

    El texto ingestado rara vez está listo para entrenamiento. Contiene registros duplicados, artefactos de codificación, PII/PHI que debe redactarse, formato inconsistente y secciones de baja calidad que degradarán el rendimiento del modelo.

    La limpieza incluye deduplicación (exacta y casi-duplicados vía MinHash), normalización de texto, detección y redacción de PII, y filtrado de calidad. Cada uno de estos pasos debe ocurrir localmente — sin enviar texto a un servicio NER en la nube para detección de PII.

    Nuestra guía sobre limpieza de datos on-premise para datasets de entrenamiento ML cubre deduplicación, normalización y puntuación de calidad en detalle.

    Etapa 3: etiquetado

    El fine-tuning requiere datos etiquetados — pares instrucción/respuesta, etiquetas de clasificación, anotaciones de entidades o clasificaciones de preferencia. El etiquetado a escala requiere ya sea anotadores humanos con experiencia de dominio o pre-anotación asistida por IA seguida de revisión humana.

    Usar LLMs locales para pre-anotación es ahora práctico. Un modelo 7B que sigue instrucciones ejecutándose vía Ollama puede generar borradores de etiquetas que los expertos de dominio luego corrigen — reduciendo el tiempo de etiquetado en 40-60% mientras mantiene todos los datos on-premise.

    Consulta etiquetado de datos asistido por LLM local sin salida de datos para la configuración técnica.

    Etapa 4: aumento

    Los datasets pequeños son la norma en entornos empresariales. Un hospital podría tener 2,000 notas clínicas relevantes. Un bufete podría tener 500 contratos del tipo correcto. Cuando los datos reales son escasos, la generación de datos sintéticos llena los vacíos — paráfrasis, generación de instrucciones a partir de documentos, creación de pares DPO y expansión de ejemplos semilla.

    En entornos de red aislada, toda la generación debe usar modelos locales. Esto te limita a modelos de pesos abiertos pero aún produce expansión sustancial del dataset.

    Nuestra guía sobre generación de datos sintéticos en entornos de red aislada recorre el flujo de trabajo.

    Etapa 5: exportación

    El mismo dataset preparado a menudo necesita exportarse en múltiples formatos: JSONL para fine-tuning de LLM, texto en chunks para pipelines RAG, anotaciones COCO o YOLO para visión por computadora, CSV para ML clásico y JSON estructurado para entrenamiento de agentes.

    La mayoría de las herramientas solo manejan un formato de exportación. Si necesitas tres, mantienes tres scripts de exportación — cada uno una fuente potencial de errores de formato y deriva de datos.

    Consulta exportación multiformato desde un solo pipeline de datos para el desglose completo.


    El stack fragmentado de open-source: cómo se ve realmente

    El stack más común de preparación de datos on-premise en 2026 une tres a siete herramientas separadas:

    EtapaHerramienta comúnLimitación
    IngestaDocling, Unstructured.ioSin limpieza o etiquetado integrado; la salida requiere parseo personalizado
    LimpiezaCleanlab, scripts Python personalizadosRequiere experiencia en ingeniería ML; sin GUI
    EtiquetadoLabel Studio, ProdigyDespliegue separado; sin integración nativa de LLM local
    AumentoDistilabel, scripts personalizadosSolo pipeline; requiere fluidez en Python
    ExportaciónScripts personalizados por formatoMantenidos ad hoc; sin validación integrada

    Esto funciona. Los equipos envían proyectos con este stack cada día. Pero los costos son reales:

    Impuesto de integración: Cada herramienta tiene su propio formato de datos, configuración y requisitos de despliegue. Mover datos desde la salida de Docling a través de Cleanlab a Label Studio hasta un script de exportación personalizado significa escribir y mantener código de unión en cada frontera.

    Sin rastro de auditoría unificado: Cuando un equipo de cumplimiento pregunta "muéstrame cada transformación aplicada al registro #4,721," necesitas reconstruir la respuesta de los logs de cinco herramientas diferentes — asumiendo que todas registran al nivel de detalle requerido.

    Los expertos de dominio no pueden usarlo: Una enfermera no puede ejecutar un pipeline de deduplicación de Cleanlab. Un abogado no puede configurar Distilabel para generación de paráfrasis. El pipeline solo funciona cuando los ingenieros de ML lo operan, lo que crea un cuello de botella y retrasa cada ciclo de iteración.

    Brechas de reproducibilidad: Si re-ejecutas el pipeline seis meses después, ¿obtienes la misma salida? Con cinco herramientas en cinco versiones diferentes, la respuesta es "probablemente no."


    Enfoques alternativos

    Algunos proyectos buscan resolver partes de este problema:

    IBM Data Prep Kit proporciona un marco modular para preparación de datos con enfoque en casos de uso empresarial. Cubre ingesta y algunos pasos de limpieza pero no incluye etiquetado, aumento ni exportación multiformato. Es code-first — útil para ingenieros ML, no accesible para expertos de dominio.

    OnPrem.LLM se enfoca en ejecutar inferencia LLM localmente para procesamiento de documentos. Maneja algunas tareas de ingesta y generación pero es una biblioteca, no una herramienta de pipeline completa. Sin rastro de auditoría, sin GUI, sin validación de exportación.

    Argilla ofrece anotación y recopilación de retroalimentación con algo de puntuación de calidad. Maneja bien la etapa de etiquetado pero no cubre ingesta, limpieza ni exportación.

    Cada uno de estos cubre una o dos etapas. Ninguno proporciona un pipeline unificado con un solo modelo de datos, registro de auditoría consistente y una interfaz que no ingenieros puedan operar.


    Arquitectura para un pipeline de preparación de datos on-premise

    Un pipeline on-premise bien diseñado tiene estas propiedades arquitectónicas:

    Modelo de datos único: Cada registro pasa por las cinco etapas dentro del mismo sistema. Sin conversiones de formato de archivo entre herramientas. Sin serialización/deserialización de datos en los límites de etapas.

    Log de auditoría inmutable: Cada transformación — archivo parseado, duplicado eliminado, etiqueta aplicada, ejemplo sintético generado, exportación creada — se registra con timestamp, operador y estado antes/después. Este log es consultable y exportable para revisiones de cumplimiento.

    Integración de LLM local: Las características asistidas por IA (pre-anotación, puntuación de calidad, generación sintética) usan inferencia de modelo local vía Ollama o llama.cpp. No se requieren llamadas de red. El sistema funciona idénticamente ya sea que la máquina tenga acceso a internet o no.

    Acceso basado en roles: Los ingenieros ML configuran las etapas del pipeline. Los expertos de dominio revisan y corrigen etiquetas. Los gerentes de proyecto monitorean progreso y exportan reportes. Cada rol ve la interfaz apropiada para su experiencia.

    Exportación multiformato con validación: Exporta a JSONL, COCO, YOLO, CSV, texto en chunks o JSON estructurado — todo desde el mismo proyecto, con validación de esquema asegurando la corrección del formato antes de que la exportación se finalice.

    Ertas Data Suite implementa esta arquitectura como una aplicación de escritorio nativa construida con Tauri 2.0 (Rust + React). Se ejecuta enteramente on-premise sin internet requerido en runtime, integra las cinco etapas del pipeline en una sola herramienta, y proporciona el rastro de auditoría y accesibilidad para expertos de dominio que los stacks fragmentados carecen. Maneja más de 64 tipos de archivo para ingesta, incluye deduplicación y puntuación de calidad integradas, soporta etiquetado y aumento asistido por LLM local vía Ollama/llama.cpp, y exporta a todos los formatos principales desde un solo proyecto.


    Recomendaciones prácticas

    Si estás construyendo pipelines de preparación de datos on-premise para clientes en industrias reguladas:

    1. Presupuesta 60-70% del tiempo del proyecto para preparación de datos. Esto no es relleno — es el promedio empírico en proyectos de IA empresarial.

    2. Elige herramientas que el equipo de tu cliente pueda operar después de que te vayas. Si solo tus ingenieros ML pueden ejecutar el pipeline, el cliente te llamará de vuelta para cada actualización de dataset — lo cual podría ser bueno para los ingresos pero malo para la relación.

    3. Construye rastros de auditoría desde el día uno. Retrofitear linaje de datos después de que el pipeline está corriendo es caro y propenso a errores. Los equipos de cumplimiento lo pedirán. Planifícalo.

    4. Prueba formatos de exportación temprano. No descubras problemas de formato cuando estás intentando iniciar el fine-tuning. Exporta un lote pequeño en cada formato objetivo durante la configuración del pipeline y valida downstream.

    5. Usa LLMs locales para acelerar el etiquetado. La ganancia de productividad de la pre-anotación asistida por IA es sustancial incluso con modelos más pequeños. Un modelo 7B generando borradores de etiquetas que expertos de dominio corrigen es más rápido que expertos de dominio empezando desde cero.


    Dónde encaja esto en el panorama general

    La preparación de datos on-premise es la base que hace todo lo demás — fine-tuning, despliegue, monitoreo — posible para clientes empresariales regulados. Sin datos limpios, bien etiquetados y correctamente formateados, ninguna cantidad de hardware GPU o sofisticación de arquitectura de modelo producirá un modelo que funcione en producción.

    Esta guía es el hub para una serie que cubre cada etapa del pipeline en profundidad. Explora las guías específicas enlazadas a lo largo del texto para detalles técnicos sobre ingesta, limpieza, etiquetado, aumento, exportación y puntuación de calidad.

    Ship AI that runs on your users' devices.

    Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

    Keep reading