IA para Construcción: Convirtiendo 700GB de Archivos de Proyecto No Estructurados en un Modelo Específico de Dominio

La mayoría de las empresas constructoras ya tienen la materia prima para un sistema de IA poderoso. Está en un disco compartido en algún lugar — una década de archivos de proyecto, PDFs, planos, informes de inspección, presupuestos de cantidades, fotos de avance y RFIs, acumulados proyecto por proyecto y organizados lo suficientemente bien como para encontrar cosas manualmente.

El desafío no es la escasez de datos. Es lo opuesto: datos que son ricos, densos en conocimiento de dominio, y casi totalmente inutilizables por sistemas de IA en su forma actual.

Esta guía cubre cómo abordar ese problema de conversión: qué requiere realmente la IA para construcción, por qué los datos son difíciles de trabajar, cómo se ve el pipeline completo de procesamiento, y qué obtienes al final.

El Alcance del Problema

Una empresa constructora mediana con diez a quince años de historial de proyectos típicamente tendrá entre 200GB y 1TB de documentos de proyecto. Una firma que ha operado por treinta años, o una que ha gestionado grandes proyectos de infraestructura civil, puede tener considerablemente más.

Dentro de ese archivo, los tipos de documentos son heterogéneos:

Planos: Arquitectónicos, estructurales, MEP, civiles, drenaje — PDFs exportados de CAD que van desde planos de planta simples hasta cortes de sección 3D complejos
Presupuestos de cantidades: Documentos tabulares de costos generados desde software de medición de cantidades
Especificaciones: Secciones de especificaciones técnicas en Word o PDF, frecuentemente de cientos de páginas por proyecto
Informes de inspección y pruebas: Formularios estructurados y narrativa de texto libre, frecuentemente incluyendo fotografías
RFIs y correspondencia: Cadenas de preguntas y respuestas, instrucciones de sitio, órdenes de variación
Exportaciones BIM: Archivos IFC, hojas COBie, informes de detección de interferencias
Fotos de avance: JPEGs con nomenclatura inconsistente, frecuentemente el único registro de condiciones as-built

La clave, capturada claramente por profesionales de IA para construcción: "El problema no es el fine-tuning sino la limpieza y preparación de los datos diversos." El modelo es la parte fácil. Los datos son la parte difícil.

Qué Casos de Uso de IA para Construcción Son Realmente Valiosos

Antes de procesar un solo documento, vale la pena ser específico sobre qué modelos de IA estás tratando de construir. El diseño del pipeline de datos depende del caso de uso downstream.

Modelos de estimación de costos. Un modelo entrenado con datos históricos de BOQ — descripciones de ítems, cantidades, tarifas, tipo de proyecto, ubicación y fecha — puede sugerir tarifas para nuevos ítems de estimación, señalar valores atípicos contra rangos históricos y mejorar la consistencia de estimación en todo el equipo. Esto requiere datos de BOQ estructurados y normalizados de proyectos completados.

Búsqueda de documentos (RAG). Un sistema de generación aumentada por recuperación sobre la biblioteca de especificaciones de la empresa, especificaciones de proyecto y estándares técnicos permite a los ingenieros consultar el archivo en lenguaje natural. "¿Cuál es la resistencia mínima a compresión especificada para el concreto en columnas de planta baja en proyectos Tipo A?" recupera la cláusula relevante del documento relevante. Esto requiere texto limpio, dividido en chunks con buenos metadatos.

Análisis de inspecciones. Un modelo entrenado con datos de informes de inspección — tipo de defecto, ubicación, severidad, acción de remediación, fase del proyecto — puede clasificar nuevos hallazgos de inspección, sugerir acciones de remediación y señalar patrones que se correlacionan con problemas downstream. Esto requiere extracción estructurada de formularios de inspección más anotación NER de terminología de defectos.

Búsqueda y coordinación de planos. Un sistema que entiende el contenido de los planos — no solo los nombres de archivo — puede responder "encuentra todos los detalles que muestren conexiones de columnas RC a vigas de acero" entendiendo qué hay en los planos en lugar de depender de convenciones de nomenclatura de archivos. Esto requiere un modelo entrenado con contenido de planos anotado.

Cada uno de estos requiere un enfoque de preparación de datos algo diferente. Un solo archivo puede producir datasets para múltiples casos de uso, pero el procesamiento debe planearse por caso de uso, no ejecutarse genéricamente.

Por Qué las Herramientas en la Nube Están Fuera de Alcance

La respuesta inmediata de la mayoría de los equipos de datos cuando se enfrentan a un archivo grande de documentos es pasarlo por una API en la nube. AWS Textract, Azure Document Intelligence, Google Document AI — son herramientas capaces. El problema no es la tecnología.

El problema es la gobernanza de datos.

Los documentos de proyectos de construcción contienen información comercialmente sensible: cantidades, tarifas, precios de subcontratistas y especificaciones que representan inteligencia competitiva. También pueden contener información personal sobre trabajadores del sitio, subcontratistas y clientes. Enviar esos datos a una API en la nube significa que salen del entorno de la empresa. Dependiendo de la jurisdicción, eso puede requerir acuerdos de procesamiento de datos, evaluaciones de impacto de privacidad o consentimiento explícito.

En algunas jurisdicciones, simplemente no es posible dentro de un plazo razonable. El proceso de aprobación de procesamiento de datos bajo la PPIA de Pakistán, por ejemplo, puede tomar más de un año para transferencias transfronterizas de datos. Una empresa esperando esa aprobación no puede comenzar a construir su capacidad de IA.

La consecuencia práctica: el pipeline de procesamiento debe ejecutarse localmente. OCR, extracción de tablas, análisis de layout, anotación, puntuación de calidad — todo debe ocurrir en hardware que la empresa controla, sin llamadas de red a servicios externos.

El Pipeline Completo para Datos de Construcción

Un pipeline de preparación de datos de construcción tiene cinco etapas. Estos no son pasos secuenciales rápidos; cada etapa puede tomar un tiempo significativo en un archivo grande.

Etapa 1: Ingestar y clasificar. Cada archivo en el archivo es ingestado y clasificado por tipo de documento. Esto no es opcional — la lógica de procesamiento para un plano es completamente diferente de la lógica de procesamiento para un BOQ o una sección de especificación. La clasificación usa una combinación de metadatos de archivo (convenciones de nomenclatura, estructura de directorios), análisis de layout de página y muestreo de contenido. Salidas: un inventario clasificado de cada documento en el archivo, con complejidad de procesamiento estimada.

Etapa 2: Extracción. Cada tipo de documento se procesa con lógica apropiada al tipo. Los planos pasan por OCR basado en zonas con detección de símbolos y parseo de anotaciones. Los BOQs pasan por reconstrucción de tablas con parseo de ítems de línea y normalización de unidades. Las especificaciones pasan por segmentación de secciones y extracción de cláusulas. Los informes de inspección pasan por extracción de campos de formulario y parseo de texto libre. Esta etapa es computacionalmente intensiva y se ejecuta durante la noche o un fin de semana para archivos grandes.

Etapa 3: Limpieza. Los datos extraídos se deduplican (el mismo BOQ puede existir como tres versiones — primera emisión, revisión A, revisión B), las inconsistencias se señalan y se asignan puntuaciones de calidad. Los registros por debajo del umbral de calidad se señalan para revisión humana en lugar de pasarse a la siguiente etapa.

Etapa 4: Anotación. Para datos de entrenamiento específicamente, los registros extraídos necesitan etiquetas. Para modelos de estimación, estos son datos de tarifas de proyectos completados. Para modelos NER, son etiquetas de entidades aplicadas por expertos de dominio (medidores de cantidades, ingenieros de sitio). Para modelos de clasificación, son etiquetas de categoría aplicadas a hallazgos de inspección. Esta etapa requiere la participación de expertos de dominio — no ingenieros de ML.

Etapa 5: Exportación. Los datos anotados y limpiados se exportan en el formato requerido por el sistema downstream: JSONL para fine-tuning de modelos de lenguaje, texto dividido en chunks con metadatos para indexación RAG, CSV para analítica tradicional, o registros estructurados para ingesta en base de datos.

Cómo Se Ve un Dataset de Entrenamiento de Construcción Terminado

Al final del pipeline, deberías tener:

Para una base de conocimiento RAG: 50,000 a 200,000 chunks de texto, cada uno de 300–800 tokens, con campos de metadatos para tipo de documento, tipo de proyecto, fecha, encabezado de sección y documento fuente. Los chunks están limpios, correctamente ordenados y libres de artefactos de OCR.

Para un dataset de fine-tuning (estimación): 30,000 a 100,000 registros estructurados, cada uno representando un ítem de línea de BOQ con su descripción, unidad, contexto de cantidad y tarifa — normalizado entre proyectos por fecha y ubicación. En formato JSONL, con un registro por línea.

Para un dataset de fine-tuning (NER de inspección): 5,000 a 20,000 oraciones anotadas de informes de inspección, con etiquetas de entidad para tipo de defecto, ubicación, severidad y acción de remediación. En formato JSONL con anotaciones de span a nivel de token.

Estos no son datasets enormes por estándares generales de IA. Un modelo a escala GPT se entrena con billones de tokens. Pero el fine-tuning específico de dominio funciona con muchos menos datos que el pre-entrenamiento general. Un modelo de estimación de construcción ajustado con 50,000 registros estructurados de BOQ de proyectos del mismo tipo puede superar significativamente a un modelo de propósito general en tareas específicas de construcción.

Cronograma y Esfuerzo Esperado

El cronograma depende del tamaño del archivo, la calidad de los documentos y la complejidad de los casos de uso que se estén abordando.

Para un archivo de 700GB de documentos de construcción mixtos:

Ingestar y clasificar: 1–2 días de tiempo de cómputo, más 2–3 días de revisión humana para validar la calidad de clasificación y corregir errores sistemáticos
Extracción: 5–10 días de tiempo de cómputo (depende fuertemente de la proporción de PDFs rasterizados que requieren OCR)
Limpieza: 3–5 días de tiempo de cómputo, más revisión de expertos de dominio de registros señalados
Anotación: Esta es la variable. Para datos de BOQ donde las tarifas ya existen en los documentos, la anotación es automática. Para anotación NER de informes de inspección, espera 2–4 semanas de tiempo de expertos de dominio para un dataset de 10,000 oraciones anotadas
Exportación y validación: 1–2 días

Tiempo total transcurrido para un primer dataset utilizable de un archivo de 700GB: 6–10 semanas, asumiendo que la disponibilidad de expertos de dominio no es un cuello de botella.

El cuello de botella es casi siempre la etapa de anotación. Los expertos de dominio — medidores de cantidades, ingenieros de sitio, inspectores — no están disponibles a tiempo completo para etiquetado de datos. Planificar alrededor de su disponibilidad, y diseñar interfaces de anotación que no requieran Python o acceso a terminal, es crítico para mantener el cronograma razonable.

Qué Puedes Hacer Ahora Mismo

El primer paso no es procesar. Es inventariar.

Antes de ejecutar cualquier herramienta, entiende lo que tienes: cuántos archivos, qué tipos, qué rango de fechas, qué proyectos. Un inventario simple — conteos de archivos por tipo, tamaño total por tipo de documento, metadatos de proyecto — te dice dónde se concentrará el esfuerzo de extracción y qué casos de uso son factibles con los datos que tienes.

La mayoría de las empresas constructoras encuentran que su archivo de BOQs es el punto de partida más tratable. Los datos son estructurados (o casi estructurados), los casos de uso son de alto valor (estimación), y la carga de anotación es menor porque los datos de tarifas frecuentemente ya están presentes en los documentos.

Comienza ahí. Procesa los BOQs, exporta el JSONL, y prueba un modelo de estimación ajustado con una muestra pequeña. Ese primer resultado, aunque sea imperfecto, es más útil para construir aceptación organizacional que cualquier cantidad de documentación de planificación.

Your data is the bottleneck — not your models.

Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

Book a Discovery Call Learn about Ertas Data Suite →