Como Preparar Datos de Entrenamiento Empresariales para Fine-Tuning de Modelos Pequenos

El modelo no es la parte dificil. La infraestructura de entrenamiento no es la parte dificil. La parte dificil del fine-tuning empresarial es preparar los datos de entrenamiento.

Los datos empresariales viven en PDFs, documentos de Word, hojas de calculo de Excel, formularios escaneados, adjuntos de email y exportaciones de bases de datos heredadas. Ajustar un modelo de lenguaje requiere archivos JSONL estructurados conteniendo pares de prompt/completion — texto limpio, consistente y correctamente formateado con mapeos claros de instruccion-respuesta.

La brecha entre esos dos estados es el desafio de preparacion de datos. Es donde la mayoria de los proyectos de AI empresarial gastan 60-80% de su tiempo. Es donde ocurren los errores mas comunes y costosos. Y es donde se determina la diferencia entre un modelo que funciona en produccion y un modelo que falla en el despliegue.

Esta guia cubre las cinco etapas de preparacion de datos de entrenamiento empresariales para fine-tuning de modelos pequenos: ingestar, limpiar, etiquetar, aumentar y exportar. Cada etapa se mapea a un conjunto concreto de operaciones con herramientas especificas, metricas de calidad y modos de fallo.

Etapa 1: Ingestar — Parsear Documentos a Texto Estructurado

La primera etapa convierte documentos fuente en texto legible por maquina con estructura preservada. Esto suena simple. No lo es.

PDFs Digitales

Los PDFs creados por software (exportados desde Word, generados por sistemas ERP, producidos por herramientas CAD) contienen texto embebido. Pero el texto se almacena como glifos posicionados, no como parrafos y tablas. Un PDF que parece una tabla limpia de tres columnas para un lector humano se almacena internamente como cientos de fragmentos de texto individuales en coordenadas X-Y especificas, sin ningun objeto de tabla conectandolos.

La reconstruccion de tablas requiere agrupar fragmentos de texto por proximidad espacial, identificar limites de columna a partir de patrones de alineacion y ensamblar filas a partir de fragmentos que comparten una coordenada vertical dentro de una banda de tolerancia. Si la tolerancia esta mal, fusionas filas que deberian estar separadas, o divides una sola fila en dos.

Los layouts multi-columna presentan desafios similares. Los fragmentos de texto de un documento de dos columnas, leidos en orden ingenuo de izquierda a derecha, intercalan contenido de ambas columnas — produciendo texto sin sentido.

Documentos Escaneados

Los documentos escaneados requieren OCR antes de cualquier procesamiento de texto. Los motores de OCR modernos (Tesseract 5, PaddleOCR, EasyOCR) alcanzan 95-99% de precision a nivel de caracter en escaneos limpios de texto impreso. Pero los archivos empresariales contienen:

• Copias desvanecidas de fotocopiadoras antiguas, reduciendo el contraste de caracteres
• Escaneos torcidos donde las paginas se alimentaron en angulo
• Sellos y firmas superpuestos sobre texto impreso
• Anotaciones manuscritas mezcladas con contenido impreso
• Copias multi-generacion — una copia de una copia de un fax

Cada una de estas degrada la precision del OCR. Un escaneo que es 98% preciso a nivel de caracter produce aproximadamente un error por cada 50 caracteres — lo que significa que un documento de 500 palabras tiene aproximadamente 50 errores a nivel de caracter. Algunos de esos errores corrompen numeros (cambiando "1,234" a "1,2B4"), lo cual es catastrofico para datos financieros o de cantidades.

Hojas de Calculo y Archivos Estructurados

Los archivos de Excel, exportaciones CSV y volcados de bases de datos ya estan estructurados — pero inconsistentemente. Problemas comunes:

• Celdas combinadas en Excel que rompen la alineacion de columnas
• Filas y columnas ocultas conteniendo datos auxiliares o formulas
• Multiples hojas con diferentes esquemas en un libro de trabajo
• Discrepancias de codificacion entre archivos CSV exportados y el sistema consumidor
• Ambiguedad de formato de fecha — "03/06/26" es 6 de marzo o 3 de junio?

Formato de Salida de la Ingesta

La salida de la etapa de ingesta deberia ser un formato intermedio estandarizado — un documento por archivo JSON, conteniendo:

{
  "document_id": "DOC-2026-00142",
  "source_file": "contract_amendment_3.pdf",
  "source_type": "digital_pdf",
  "pages": [
    {
      "page_number": 1,
      "text_blocks": [...],
      "tables": [...],
      "metadata": {"ocr_confidence": null, "layout_type": "single_column"}
    }
  ],
  "ingest_timestamp": "2026-03-06T14:30:00Z",
  "ingest_version": "1.2.0"
}

Este formato intermedio desacopla el parseo del procesamiento posterior. Cuando mejoras tu OCR o extraccion de tablas, re-ejecutas la ingesta sin tocar el resto del pipeline.

Etapa 2: Limpiar — Eliminar Ruido, Estandarizar, Des-Identificar

La salida parseada cruda contiene ruido que degradara el entrenamiento del modelo si no se elimina. La etapa de limpieza tiene tres objetivos: eliminar artefactos, estandarizar formatos y redactar informacion sensible.

Eliminacion de Artefactos

• Encabezados y pies de pagina. Los encabezados de pagina repetidos ("CONFIDENCIAL — Empresa X") y pies de pagina ("Pagina 3 de 47") aparecen en la salida de texto de cada pagina. Si se dejan, el modelo se entrena con cientos de instancias de "Pagina N de M" — aprendiendo a reproducir boilerplate en lugar de extraer contenido util.
• Artefactos de OCR. Caracteres mal reconocidos, especialmente en tablas: caracteres de pipe leidos como "l" o "I", parentesis leidos como "C" o ")", simbolos de grado leidos como "o".
• Documentos duplicados. Los archivos grandes contienen multiples copias — original, enmendado, firmado, contrafirmado. Sin deduplicacion, el modelo sobrepondera estos documentos. Usa hashing basado en contenido (no en nombre de archivo) para detectar casi-duplicados. El hashing exacto omite documentos que difieren solo en un encabezado o numero de pagina; el hashing difuso (MinHash, SimHash) los detecta.

Estandarizacion de Formato

El formato inconsistente entre documentos fuente crea ruido en los datos de entrenamiento:

La estandarizacion debe ser determinista y reversible. Registra cada transformacion para que puedas rastrear un valor limpiado hasta su forma original. Esta trazabilidad no es opcional — es un requisito regulatorio bajo el EU AI Act.

Des-Identificacion de PII y PHI

Este es el paso que los equipos empresariales mas frecuentemente omiten, subestiman o hacen incorrectamente. Las consecuencias de hacerlo mal van desde multas de cumplimiento hasta responsabilidad penal.

Que debe redactarse:

• PII (todas las industrias): Nombres, direcciones, numeros de telefono, direcciones de email, numeros de identificacion nacional, numeros de cuenta bancaria, fechas de nacimiento
• PHI (salud): Todo lo anterior mas numeros de expediente medico, numeros de beneficiario de plan de salud, identificadores de dispositivos, identificadores biometricos y cualquier otro de los 18 identificadores de HIPAA
• Identificadores financieros: Numeros de cuenta, codigos SWIFT, numeros de identificacion fiscal

Metodos de redaccion:

1. Reemplazo con marcadores tipados. Reemplaza "John Smith" con "[PERSON_NAME_1]", no con un generico "[REDACTED]". Los marcadores tipados preservan la estructura semantica del texto. El modelo aprende que un nombre de persona aparece en esa posicion, aunque no aprende el nombre especifico.

2. Reemplazo consistente dentro de documentos. Si "John Smith" aparece 15 veces en un contrato, las 15 instancias deben reemplazarse con el mismo marcador. El reemplazo inconsistente — "[PERSON_NAME_1]" en un lugar y "[PERSON_NAME_2]" en otro para la misma entidad — ensena al modelo relaciones de entidad incorrectas.

3. Desplazamiento de fechas. Para datos de salud, las fechas deben desplazarse por un offset aleatorio consistente dentro de cada registro de paciente. La fecha de admision de un paciente del 1 de marzo y fecha de alta del 5 de marzo podrian convertirse en 15 de enero y 19 de enero — la duracion de 4 dias se preserva, pero las fechas reales no son recuperables.

Validacion: Despues de la des-identificacion, ejecuta un escaneo secundario para detectar PII omitido. Modelos de reconocimiento de entidades nombradas, patrones regex para identificadores estructurados (SSNs, numeros de telefono, emails) y coincidencia basada en diccionario para nombres conocidos sirven como capas de verificacion. Una tasa de aprobacion de escaneo de PII superior al 99.5% es el umbral minimo para industrias reguladas.

Etapa 3: Etiquetar — Expertos de Dominio Crean Ejemplos de Entrenamiento

El etiquetado es la etapa que convierte documentos limpios en datos de entrenamiento. Un experto de dominio revisa documentos y produce ejemplos de extracciones correctas que el modelo aprendera a replicar.

Como Se Ve un Ejemplo de Entrenamiento

Cada ejemplo de entrenamiento es un par instruccion-respuesta:

Instruccion (prompt): La entrada que el modelo recibira en tiempo de inferencia — tipicamente un documento parseado o seccion de documento, precedido por una instruccion de tarea.

Respuesta (completion): La salida estructurada que el modelo deberia producir — tipicamente JSON conteniendo los campos extraidos.

{
  "instruction": "Extract all contract parties, effective date, and termination clause from the following contract text:\n\n[cleaned document text]",
  "response": "{\"parties\": [{\"name\": \"Acme Construction LLC\", \"role\": \"contractor\"}, {\"name\": \"City of Portland\", \"role\": \"owner\"}], \"effective_date\": \"2026-01-15\", \"termination\": {\"type\": \"for_convenience\", \"notice_period_days\": 30, \"clause_reference\": \"Section 14.2\"}}"
}

Por Que Expertos de Dominio, No Ingenieros ML

Este es un punto donde los equipos consistentemente toman la decision equivocada. Los ingenieros ML estan disponibles. Los expertos de dominio son costosos y estan ocupados. La tentacion es hacer que el equipo de ML haga el etiquetado.

El resultado: la precision cae 15-20%.

Un ingeniero ML etiquetando un BOQ de construccion no sabe que "PC Sum" es una suma de costos provisionales — una asignacion presupuestaria, no un item de linea con precio. No saben que "Measured Work" y "Daywork" son mecanismos de precios fundamentalmente diferentes. Etiquetan lo que ven literalmente, omitiendo la semantica del dominio que hace que la extraccion sea util.

Un topografo de cantidades etiqueta el mismo BOQ con conocimiento implicito de como los datos se usaran aguas abajo. Saben que campos son criticos (cantidad, unidad, tarifa) y cuales son informativos (referencias de especificacion). Saben cuando un item de linea es un item principal versus un sub-item basandose en convenciones de numeracion que no estan documentadas en ningun lado — son practica de la industria.

El mismo patron se mantiene en todas las industrias. Un paralegal etiqueta contratos mejor que un ingeniero ML. Un codificador clinico etiqueta notas medicas mejor que un cientifico de datos. Un analista financiero etiqueta estados financieros mejor que un desarrollador de software.

Presupuesta tiempo de experto de dominio. Es la inversion de mayor impacto individual en un proyecto de fine-tuning.

Calidad Sobre Cantidad

La relacion entre volumen de datos de entrenamiento y precision del modelo no es lineal. Sigue una curva con rendimientos decrecientes:

Los rendimientos decrecientes por encima de 500-1,000 ejemplos significan que la calidad importa mucho mas que la cantidad a escalas empresariales. 500 ejemplos de alta calidad etiquetados por un experto de dominio consistentemente superan a 10,000 ejemplos ruidosos etiquetados por crowd workers o personal junior.

Control de Calidad en Datos Etiquetados

Todo proyecto de etiquetado necesita control de calidad. Tres mecanismos trabajan juntos:

1. Acuerdo entre anotadores. Haz que dos expertos de dominio etiqueten independientemente los mismos 50 documentos. Mide la tasa de acuerdo. Para tareas de extraccion de campos, un acuerdo superior al 90% indica guias de etiquetado claras. Por debajo del 85% significa que las guias son ambiguas y necesitan revision antes de proceder.

2. Revisiones por muestreo. Un experto de dominio senior revisa una muestra aleatoria del 10% de ejemplos etiquetados semanalmente. Los errores detectados en esta etapa son baratos de corregir. Los errores detectados despues del entrenamiento — cuando el modelo los reproduce — son costosos.

3. Verificaciones automatizadas de consistencia. Verificaciones con scripts que detectan errores mecanicos: campos requeridos faltantes, valores fuera de rangos esperados (una cantidad de -500, una fecha en 1900), violaciones de formato en el JSON de respuesta. Estas detectan errores tipograficos y errores de formato que los expertos de dominio cometen cuando estan fatigados.

Etapa 4: Aumentar — Expandir el Conjunto de Entrenamiento con Variaciones Sinteticas

500 ejemplos etiquetados pueden no cubrir la distribucion completa de documentos que el modelo encontrara en produccion. El aumento de datos sinteticos expande el conjunto de entrenamiento mientras mantiene la precision del dominio.

Tecnicas de Aumento

Variacion de plantilla. Toma un ejemplo etiquetado y genera variaciones mediante:

• Reformulacion de la instruccion (10-15 variaciones de la misma tarea de extraccion)
• Reordenamiento de campos en datos tabulares
• Agregar o eliminar campos opcionales que aparecen en algunos documentos pero no en todos

Generacion asistida por LLM. Usa un LLM local para generar documentos sinteticos basados en los patrones de tus ejemplos etiquetados. Proporciona 5 ejemplos reales y pide al modelo que genere 20 nuevos documentos con estructura similar pero contenido diferente. Luego haz que un experto de dominio verifique una muestra (20-30%) de los ejemplos generados.

Perturbacion. Introduce ruido realista: errores de caracter estilo OCR, campos faltantes, texto truncado. Esto ensena al modelo a manejar entrada imperfecta, que encontrara en produccion.

Proporciones de Aumento

Una estrategia conservadora de aumento:

• 500 ejemplos etiquetados reales -> conjunto de entrenamiento base
• 1,000 variaciones de plantilla -> expandir diversidad de instrucciones
• 500 documentos sinteticos -> expandir diversidad de contenido
• Total: ~2,000 ejemplos de entrenamiento a partir de 500 originales etiquetados por expertos

No aumentes mas alla de 4x-5x del conjunto etiquetado original. El sobre-aumento diluye la senal de los ejemplos reales con ruido de los sinteticos. El modelo comienza a aprender los patrones del proceso de aumento en lugar de los patrones de documentos reales.

Balance de Distribucion

Verifica que el dataset aumentado mantenga balance de clases. Si el 80% de tus items de BOQ etiquetados son concreto y acero, y solo el 5% son electricos y mecanicos, el modelo sera excelente extrayendo items de obras civiles y pobre extrayendo items MEP.

Balancea el conjunto aumentado sobre-muestreando categorias sub-representadas y sub-muestreando las sobre-representadas. Apunta a que ninguna clase represente mas de 3x la frecuencia de la clase mas pequena.

Etapa 5: Exportar — Convertir a JSONL Listo para Entrenamiento

La etapa final convierte el dataset aumentado al formato requerido por el framework de fine-tuning.

Formato JSONL

La mayoria de los frameworks de fine-tuning (Hugging Face TRL, Axolotl, LLaMA-Factory) aceptan JSONL — un objeto JSON por linea, cada uno conteniendo una instruccion y respuesta:

{"instruction": "Extract line items from...", "response": "{\"items\": [...]}"}
{"instruction": "Identify parties in...", "response": "{\"parties\": [...]}"}

Algunos frameworks usan un formato de mensajes para fine-tuning estilo chat:

{"messages": [{"role": "system", "content": "You are a document extraction assistant."}, {"role": "user", "content": "Extract..."}, {"role": "assistant", "content": "{...}"}]}

Division Entrenamiento/Validacion

Divide los datos 90/10 u 85/15 en conjuntos de entrenamiento y validacion. La division debe ser estratificada — cada tipo de documento y tarea de extraccion debe estar proporcionalmente representado en ambos conjuntos. No dividas aleatoriamente; asegura que todos los ejemplos de un solo documento fuente esten en la misma division, para prevenir filtracion de datos.

Metadatos para Trazabilidad

Incluye campos de metadatos en la exportacion para propositos de auditoria y depuracion:

{
  "instruction": "...",
  "response": "...",
  "metadata": {
    "source_document": "DOC-2026-00142",
    "labeled_by": "expert_qs_03",
    "labeled_date": "2026-02-15",
    "augmentation_type": "none",
    "quality_review": "passed",
    "pii_scan": "clean"
  }
}

Estos metadatos no se usan durante el entrenamiento — se eliminan antes de que los datos lleguen al modelo. Pero son esenciales para:

• Depurar errores del modelo. Cuando el modelo comete un error en un tipo de documento especifico, rastrealo hasta los ejemplos de entrenamiento de ese tipo.
• Cumplimiento regulatorio. El EU AI Act Articulo 10 requiere documentacion de datos de entrenamiento: que datos se usaron, como se prepararon, que medidas de calidad se aplicaron. El log de metadatos proporciona esta documentacion.
• Decisiones de re-entrenamiento. Cuando se agregan nuevos tipos de documentos, los metadatos te dicen que ejemplos existentes son relevantes y que nuevos ejemplos se necesitan.

Errores Comunes y Como Evitarlos

Error 1: Omitir la Des-Identificacion

"Lo haremos despues" es la frase mas cara en AI empresarial. PHI en datos de entrenamiento es una violacion de cumplimiento en el momento en que entra al pipeline de entrenamiento — no cuando el modelo se despliega. HIPAA, GDPR y regulaciones especificas del sector aplican al procesamiento de datos, no solo al almacenamiento de datos o la inferencia del modelo.

Solucion: La des-identificacion se ejecuta en la Etapa 2, antes de que comience cualquier etiquetado. Sin excepciones.

Error 2: Usar Anotadores No Expertos

Contratar crowd workers o usar personal junior para etiquetar datos especificos del dominio ahorra dinero a corto plazo y cuesta significativamente mas a largo plazo. El modelo aprende los errores de los anotadores. Corregir errores de anotacion despues del entrenamiento significa re-etiquetar y re-entrenar — duplicando el costo total.

Solucion: Presupuesta tiempo de experto de dominio desde el inicio. Si el presupuesto restringe el numero de ejemplos, etiqueta menos ejemplos con mayor calidad. 300 ejemplos etiquetados por expertos superan a 3,000 ejemplos etiquetados por crowd workers para extraccion de documentos empresariales.

Error 3: Sin Control de Calidad en Datos Etiquetados

Sin control de calidad, los errores de anotacion se acumulan. Si el 10% de los ejemplos contienen errores de etiquetado, y esos errores son inconsistentes (diferentes anotadores cometiendo diferentes errores), el modelo recibe senales de entrenamiento contradictorias. La precision se estanca muy por debajo de lo que la arquitectura del modelo puede lograr.

Solucion: Implementa verificaciones de acuerdo entre anotadores, revisiones por muestreo y validacion automatizada de consistencia. Mide la calidad antes del entrenamiento. Si el acuerdo de etiquetado esta por debajo del 90%, corrige las guias de etiquetado y re-etiqueta los ejemplos en desacuerdo antes de proceder.

Error 4: Entrenar con Volumen Sobre Calidad

Mas datos no siempre es mejor. 10,000 ejemplos de entrenamiento con formato inconsistente, calidad mixta y distribucion de clases desbalanceada producen un modelo peor que 500 ejemplos con formato limpio, calidad consistente y distribucion balanceada.

Solucion: Establece un umbral de calidad. Cada ejemplo de entrenamiento debe pasar verificaciones automatizadas (formato valido, campos presentes, valores en rango) y una muestra debe pasar revision de experto (semanticamente correcto, apropiado para el dominio). Elimina los ejemplos que fallen. Un dataset limpio mas pequeno supera a uno ruidoso mas grande.

Error 5: Sin Trazabilidad de Auditoria

Sin una trazabilidad de auditoria, no puedes explicar con que datos fue entrenado el modelo, como fueron preparados o que medidas de calidad se aplicaron. Esto es una falla de cumplimiento bajo el EU AI Act, y una falla practica cuando necesitas depurar el comportamiento del modelo o re-entrenar con datos actualizados.

Solucion: Registra cada paso del pipeline con timestamps, versiones y parametros. Etiqueta cada ejemplo de entrenamiento con su procedencia. Almacena los logs junto con los datos de entrenamiento. Cuando un auditor — interno o regulatorio — pregunte "con que datos fue entrenado este modelo y como fueron preparados", la respuesta deberia ser una consulta contra los metadatos, no una reconstruccion de memoria.

Metricas de Calidad de Datos: Que Medir

Antes de comenzar el fine-tuning, valida los datos de entrenamiento contra estas metricas:

Si cualquier metrica cae por debajo de su objetivo, corrige los datos antes del entrenamiento. Entrenar con datos deficientes desperdicia computo y produce un modelo que necesita re-entrenarse de todas formas.

El Cronograma de Preparacion

Para un proyecto tipico de fine-tuning empresarial apuntando a 500 ejemplos etiquetados:

La etapa de etiquetado domina el cronograma. Planifica para ella. Reserva tiempo de experto de dominio con anticipacion. Prepara las guias de etiquetado y las herramientas antes de que los expertos comiencen. Cada hora de tiempo de experto desperdiciada en instrucciones poco claras o herramientas rotas es una hora que no puedes recuperar.

La preparacion de datos no es trabajo glamoroso. No es la parte del proyecto de AI que se presenta en demos de proveedores o charlas de conferencias. Pero es la parte que determina si el modelo funciona. Prepara los datos correctamente y un modelo de 7B superara a un modelo de 70B en tu tarea especifica. Prepara los datos incorrectamente y ninguna cantidad de tamano de modelo o computo de entrenamiento compensara.