Fine-Tuning de SLM para Procesamiento de Documentos: Convirtiendo PDFs Empresariales en Datos Estructurados

Toda empresa tiene un problema con los PDFs. Las firmas de construcción tienen décadas de presupuestos de obra, planos e informes de inspección. Los bufetes de abogados mantienen archivos de contratos que abarcan cientos de miles de documentos. Los proveedores de salud acumulan notas clínicas, resúmenes de alta y resultados de laboratorio. Los bancos procesan estados financieros, informes regulatorios y solicitudes de crédito por millones.

La información dentro de estos documentos es valiosa. El formato en que está almacenada no lo es. Los PDFs están diseñados para lectura humana, no para procesamiento por máquinas. La brecha entre "un humano podría leer esto" y "una máquina puede extraer datos estructurados de esto" es donde la mayoría de los proyectos de AI empresarial se estancan.

Los modelos de lenguaje grandes genéricos — GPT-4, Claude, Gemini — pueden extraer datos de PDFs. Pueden leer un BOQ de construcción y extraer partidas. Pueden escanear un contrato e identificar partes y fechas. Pero lo hacen con suficiente deficiencia, y de manera suficientemente costosa, como para que el enfoque no escale a volúmenes empresariales.

Los modelos de lenguaje pequeños ajustados resuelven ambos problemas. Son suficientemente precisos para uso en producción y suficientemente económicos para procesar cientos de miles de documentos sin destruir un presupuesto.

Por Qué los LLMs Genéricos Fallan en la Extracción Empresarial de Documentos

Cuando alimentas un BOQ de construcción a GPT-4 y le pides extraer partidas con cantidades, unidades y precios unitarios, obtendrás algo que se ve aproximadamente correcto. Quizás el 65-75% de los campos se extraen con precisión. Eso suena aceptable hasta que ves cómo luce el 25-35% restante.

Confusión de formato. Los modelos genéricos nunca han visto el diseño específico del BOQ de tu empresa. Confunden descripciones de sub-partidas con descripciones de partidas principales. Fusionan líneas de continuación incorrectamente. Analizan mal tablas donde las columnas están separadas por puntos guía en vez de bordes visibles.

Malinterpretación de unidades. "CUM" significa metros cúbicos en construcción. Un modelo genérico lo lee como un total acumulado. "RM" significa metros lineales, pero el modelo lo lee como una abreviatura monetaria del Ringgit malayo. "NR" significa "número" como unidad, pero el modelo a veces lo trata como "no requerido."

Errores de precisión numérica. Cantidades de BOQ como "1,234.50" se analizan correctamente, pero "1.234,50" (notación decimal europea) no. Las cifras de estados financieros entre paréntesis como "(1,234)" — significando negativo — a veces se extraen como valores positivos.

Ceguera estructural. Un contrato legal tiene una estructura jerárquica: artículo, sección, subsección, cláusula. Los modelos genéricos aplanan esta jerarquía. Cuando pides "obligaciones de la Parte A," obtienes un subconjunto — las obligaciones que estaban expresadas de una forma que el modelo reconoció, no las que están incrustadas en definiciones o referenciadas cruzadamente desde anexos.

El problema fundamental: estos modelos fueron entrenados con texto de internet. Vieron algunos PDFs durante el pre-entrenamiento, pero no tus PDFs. Tienen capacidad amplia y conocimiento superficial del dominio. Para la extracción de documentos a escala empresarial, necesitas lo inverso — capacidad estrecha y conocimiento profundo del dominio.

Qué Cambia el Fine-Tuning

Ajustar un modelo de lenguaje pequeño (7B-14B parámetros) con 500-1,000 ejemplos etiquetados de tu tipo específico de documento produce un modelo que entiende la estructura particular, la terminología y las convenciones de diseño de tus documentos.

La diferencia de precisión es significativa:

Estos no son números teóricos. Reflejan el patrón observado en proyectos de extracción de documentos: los modelos genéricos se estancan alrededor del 60-75% de precisión en documentos específicos del dominio, mientras que los modelos ajustados entrenados con unos cientos de ejemplos etiquetados alcanzan 90%+ de precisión.

Las ganancias de precisión provienen de tres cosas que el modelo ajustado aprende:

1. Estructura del documento. Aprende que tu BOQ tiene un diseño de columnas específico, que las cantidades aparecen en la columna 5, que los precios unitarios están en la columna 6 y que las descripciones de partidas pueden abarcar múltiples líneas pero siempre comienzan con un código numérico.

2. Vocabulario del dominio. Aprende que "CUM" significa metros cúbicos, que "PC Sum" significa suma de costo provisional, que "P&G" en construcción significa preliminares y partidas generales — no Procter & Gamble.

3. Patrones de extracción. Aprende tu formato de salida específico. Si lo entrenas para producir JSON con campos item_code, description, quantity, unit, rate, amount, produce exactamente esa estructura, consistentemente, sin la deriva de formato que afecta a los enfoques basados en prompt engineering.

El Pipeline de Procesamiento de Documentos

Convertir PDFs empresariales en datos estructurados mediante SLMs ajustados es un pipeline de cinco etapas. Cada etapa aborda una brecha específica entre la entrada cruda del documento y la salida estructurada limpia.

Etapa 1: Ingestión — Analizar PDFs en Texto + Diseño

La primera etapa convierte PDFs en texto legible por máquina preservando la información de diseño. Esto no es OCR estándar. Los documentos empresariales requieren análisis consciente del diseño que entienda tablas, estructuras de múltiples columnas y las relaciones espaciales entre elementos de texto.

Para PDFs creados digitalmente (exportados desde Word, Excel o software específico del dominio), la extracción de texto es directa. El desafío es reconstruir las estructuras de tabla a partir de las coordenadas internas del PDF, ya que los PDFs almacenan texto como glifos posicionados, no como filas y columnas.

Para documentos escaneados, se requiere OCR. Los motores de OCR modernos como Tesseract 5, PaddleOCR o servicios de OCR en la nube manejan bien los escaneos limpios. El desafío son los escaneos de mala calidad: texto desvanecido, páginas sesgadas, sellos superpuestos al texto y anotaciones manuscritas mezcladas con contenido impreso.

La salida de la Etapa 1 es texto analizado con metadatos de diseño: qué texto pertenece a qué celda de tabla, dónde están los encabezados, dónde los saltos de página interrumpen el contenido y qué elementos son anotaciones versus contenido del cuerpo.

Etapa 2: Limpiar y Desidentificar

Los documentos empresariales contienen información de identificación personal (PII) y, en salud, información de salud protegida (PHI). Las notas clínicas tienen nombres de pacientes, fechas de nacimiento y números de registro médico. Los contratos tienen nombres de firmantes, direcciones y números de identificación. Los estados financieros tienen números de cuenta e identificadores fiscales.

Esta información debe redactarse antes de que entre al pipeline de entrenamiento. En industrias reguladas, usar PII/PHI no redactada en datos de entrenamiento es una violación de cumplimiento — el Artículo 5(1)(c) del GDPR, la sección 164.502 de HIPAA y estatutos similares en otras jurisdicciones aplican.

La etapa de limpieza también maneja:

• Eliminación de duplicados. Los archivos grandes de documentos contienen múltiples versiones del mismo documento. Entrenar con duplicados sesga el modelo hacia tipos de documentos sobrerepresentados.
• Normalización de codificación. Documentos de diferentes fuentes usan diferentes codificaciones de caracteres. Caracteres turcos, números árabes en documentos financieros, símbolos especiales en notación de ingeniería — todos necesitan codificación consistente.
• Estandarización de formato. Fechas que aparecen como "03/06/2026", "6 March 2026", "2026-03-06" y "06.03.2026" en diferentes documentos deberían normalizarse a un solo formato.

Etapa 3: Etiquetar Ejemplos de Extracciones Correctas

Aquí es donde la experiencia del dominio entra en el pipeline. Un experto del dominio — un profesional de presupuestos para documentos de construcción, un paralegal para contratos, un codificador clínico para registros médicos — anota ejemplos de extracciones correctas.

El proceso de etiquetado funciona así:

1. Presentar al experto un documento analizado (salida de la Etapa 1+2).
2. Pedirle que identifique y extraiga los campos objetivo.
3. Registrar sus extracciones como datos estructurados emparejados con el texto fuente.

El resultado es un conjunto de pares prompt/completación:

{
  "prompt": "Extract BOQ line items from the following text:\n\n[parsed document text]",
  "completion": "{\"items\": [{\"code\": \"3.2.1\", \"description\": \"Reinforced concrete grade C35/45 to pile caps\", \"quantity\": 245.5, \"unit\": \"CUM\", \"rate\": 185.00, \"amount\": 45417.50}]}"
}

La calidad importa más que la cantidad. 500 ejemplos etiquetados con precisión superan consistentemente a 5,000 ejemplos con 10-15% de errores de anotación. Cuando un experto del dominio etiqueta "CUM" como "metros cúbicos" en cada ejemplo, el modelo aprende la correspondencia. Cuando un no experto lo etiqueta inconsistentemente — a veces "acumulativo", a veces "metros cúbicos" — el modelo hereda la confusión.

El esfuerzo práctico de etiquetado para la mayoría de los tipos de documentos:

Estas son inversiones de tiempo significativas. Pero son inversiones únicas que producen un modelo reutilizable, en contraposición al costo recurrente del procesamiento manual.

Etapa 4: Ajustar el SLM

Con datos etiquetados preparados, el paso de fine-tuning es comparativamente sencillo. Un modelo de 7B parámetros (Mistral 7B, Llama 3.1 8B, Qwen 2.5 7B) ajustado con LoRA sobre 500-1,000 ejemplos típicamente se entrena en 2-6 horas en una sola GPU.

Parámetros clave de fine-tuning para extracción de documentos:

• Selección de modelo base. Para tareas de extracción estructurada, los modelos base instruction-tuned funcionan mejor. Ya entienden el formato instrucción/respuesta; el fine-tuning les enseña tu tarea de extracción específica.
• Rango LoRA. Rango 16-32 es suficiente para la mayoría de las tareas de extracción de documentos. Rangos más altos agregan tiempo de entrenamiento sin ganancias significativas de precisión cuando la tarea está bien definida.
• Épocas de entrenamiento. 3-5 épocas. El sobreajuste es el riesgo principal — el modelo memoriza documentos específicos en vez de aprender patrones de extracción. Monitorea la pérdida de validación y detén cuando se estabilice.
• Tasa de aprendizaje. 1e-4 a 2e-4 para fine-tuning con LoRA. Tasas más bajas son más estables pero entrenan más lento.

La salida es un adaptador LoRA — un archivo pequeño (50-200 MB) que modifica el comportamiento del modelo base para tu tarea de extracción específica. Los pesos del modelo base no cambian.

Etapa 5: Desplegar y Procesar a Escala

El modelo ajustado procesa el archivo de documentos restante. En tiempo de inferencia, un modelo 7B con cuantización de 4 bits procesa una página de documento típica en 1-3 segundos en hardware GPU de consumo, o 2-5 segundos en CPU.

Para volúmenes empresariales:

Compara esto con el procesamiento manual: 100,000 documentos a 30 minutos cada uno equivalen a 50,000 horas-persona. A $25/hora, eso es $1.25 millones. El enfoque de SLM ajustado — 500 ejemplos etiquetados a 30 minutos cada uno (250 horas de tiempo de experto del dominio = ~$6,250) más cómputo — cuesta menos de $7,000 en total. Eso es una reducción de costos de 178x.

Incluso con tarifas más altas de expertos — $75/hora para un profesional senior de presupuestos, $100/hora para un especialista en codificación clínica — la economía es abrumadora. 250 horas a $100/hora son $25,000. Agrega $5,000 de cómputo. Total: $30,000 versus $1.25 millones. Todavía una reducción de costos de 40x.

Aplicaciones Específicas por Industria

Construcción: Partidas de BOQ y Cantidades de Material

Las empresas constructoras procesan BOQs que contienen cientos a miles de partidas. Cada partida especifica un material, cantidad, unidad, precio unitario y monto total. Extraer estos datos permite:

• Estimación automatizada de costos. Alimentar datos históricos de BOQ a modelos de fijación de precios.
• Verificación de cuantificación de materiales. Cruzar cantidades extraídas contra cantidades del modelo de diseño.
• Comparación de subcontratistas. Estructurar datos de BOQ de múltiples ofertas de subcontratistas para comparación lado a lado.

El modelo ajustado maneja desafíos específicos de construcción: descripciones de partidas multilínea, sistemas de numeración jerárquica (CESMM, NRM, formatos propietarios), sumas provisionales, partidas de costo primo y asignaciones de contingencia.

Legal: Cláusulas de Contratos y Obligaciones

Los bufetes de abogados y departamentos legales corporativos necesitan extraer datos estructurados de contratos: nombres de las partes, fechas de vigencia, condiciones de terminación, términos de pago, topes de responsabilidad, cláusulas de indemnización y provisiones de ley aplicable.

Un SLM ajustado entrenado en los tipos específicos de contratos de una firma (por ejemplo, subcontratos de construcción, licencias de software, NDAs) aprende las estructuras particulares de cláusulas y patrones de referencia cruzada utilizados en esos tipos de documentos. Identifica obligaciones incluso cuando no están en una sección de "Obligaciones" — incrustadas en definiciones, anexos o condiciones precedentes.

Salud: Notas Clínicas a Códigos Estructurados

Las notas clínicas están escritas en una taquigrafía que varía por especialidad, institución y clínico individual. "Pt c/o SOB x 3d, worse w/ exertion" significa "paciente se queja de falta de aire por 3 días, peor con esfuerzo." Un SLM ajustado entrenado en el estilo de documentación específico de un hospital mapea estas notas a códigos diagnósticos ICD-10 y códigos de procedimientos CPT.

Las implicaciones son altas: la codificación incorrecta lleva a denegaciones de reclamaciones, pérdida de ingresos y riesgo de auditoría. La codificación clínica manual cuesta $0.50-2.00 por encuentro. Con 500,000 encuentros por año para un sistema hospitalario mediano, eso es $250,000-1,000,000 anuales en mano de obra de codificación.

Finanzas: Estados Financieros a Campos Estandarizados

Los bancos y firmas de inversión procesan estados financieros de prestatarios, empresas del portafolio y contrapartes. Extraer ingresos, EBITDA, covenants de deuda y ratios de capital de trabajo de estados financieros no estandarizados es una tarea manual persistente.

Un modelo ajustado entrenado en los formatos específicos de estados financieros que encuentra una firma — informes anuales, reportes trimestrales, estados auditados de diferentes firmas contables — extrae campos estandarizados que alimentan directamente modelos crediticios y analítica de portafolio.

La Preparación de Datos Es el Cuello de Botella

En cada proyecto de procesamiento de documentos, el cronograma se ve igual:

• Semana 1-2: Configurar la infraestructura de análisis. Esto es sencillo.
• Semana 3-8: Etiquetar datos de entrenamiento. Este es el cuello de botella.
• Semana 9-10: Ajustar el modelo. Esto toma días, no semanas.
• Semana 11-12: Validar, ajustar y desplegar. Trabajo de ingeniería estándar.

La fase de etiquetado consume el 60-70% del tiempo total del proyecto. Requiere expertos del dominio que son caros y están ocupados. Requiere una interfaz de etiquetado que funcione con los tipos específicos de documentos. Requiere control de calidad para detectar errores de anotación antes de que se conviertan en errores del modelo.

Este es el pipeline que importa: no la arquitectura del modelo, no el framework de entrenamiento, no el motor de inferencia. El pipeline que convierte documentos empresariales crudos en datos de entrenamiento limpios y etiquetados determina si el proyecto tiene éxito o fracasa.

El Ciclo de Control de Calidad

Después del despliegue inicial, el modelo encontrará documentos que caen fuera de su distribución de entrenamiento. Un BOQ de un nuevo subcontratista con un formato diferente. Una plantilla de contrato que fue revisada desde que se crearon los datos de entrenamiento. Una nota clínica de un nuevo especialista usando abreviaturas desconocidas.

El pipeline de producción necesita un mecanismo de enrutamiento basado en confianza:

1. Alta confianza (mayor a 0.95): Aceptar la extracción automáticamente.
2. Confianza media (0.80-0.95): Marcar para revisión humana.
3. Baja confianza (menor a 0.80): Enrutar a procesamiento manual.

Las extracciones revisadas y corregidas retroalimentan los datos de entrenamiento. El modelo se reentrena periódicamente en el dataset expandido. Con el tiempo, el porcentaje de documentos que requieren revisión humana disminuye a medida que la distribución de entrenamiento del modelo se expande.

Este enfoque de humano en el ciclo no es un compromiso — es la forma arquitectónicamente correcta de desplegar extracción de documentos a escala. Ningún modelo alcanza 100% de precisión en documentos que nunca ha visto. El objetivo es reducir el procesamiento manual del 100% de los documentos al 5-10%, y tener un mecanismo claro para manejar las excepciones.

Cómo Se Ve Esto de Extremo a Extremo

Una empresa constructora con 100,000 documentos BOQ históricos quiere construir una base de datos de costos para estimación potenciada por AI.

Sin fine-tuning: Contratan un equipo de profesionales de presupuestos para extraer datos manualmente. A 30 minutos por documento, son 50,000 horas de trabajo. A $25/hora, el presupuesto es $1.25 millones. El proyecto toma 12-18 meses con un equipo de 10.

Con fine-tuning: Tienen 500 documentos BOQ etiquetados por un profesional senior de presupuestos durante 6 semanas (~250 horas, $6,250 a $25/hr). Ajustan un modelo 7B en 4 horas. Procesan 100,000 documentos en 3.5 días en un solo servidor GPU. Costo total: menos de $7,000. Cronograma total: 8-10 semanas incluyendo etiquetado.

El modelo ajustado extrae 95%+ de los campos correctamente. El 5% marcado para revisión humana toma 2,500 horas adicionales — todavía un orden de magnitud menos que el procesamiento completamente manual.

La base de datos de costos, una vez construida, potencia estimación automatizada, análisis de ofertas y optimización de adquisiciones. El mismo modelo ajustado continúa procesando nuevos documentos BOQ a medida que llegan, convirtiendo un cuello de botella manual en un pipeline automatizado.

Eso es lo que los SLMs ajustados hacen por el procesamiento de documentos. No una capacidad teórica. Un pipeline práctico que convierte experiencia en software, una vez, y luego la escala a todo un archivo de documentos.