Preparación de datos de IA para construcción: BOQs, planos y PDFs técnicos

Las empresas de construcción están sentadas sobre algunos de los archivos de datos sin explotar más grandes de cualquier industria. Cientos de gigabytes de documentación de proyectos — presupuestos de cantidades de obra (BOQs), planos técnicos, especificaciones, RFIs, submittals, órdenes de cambio — acumulados durante décadas de proyectos. Estos datos representan un enorme conocimiento del dominio, y están casi completamente encerrados en formatos no estructurados.

Convertir estos archivos en datos de entrenamiento listos para IA es el prerrequisito para cada caso de uso de IA en construcción: estimación automatizada de cantidades, clasificación de documentos, verificación de cumplimiento de especificaciones y pronóstico de costos. Pero los desafíos de preparación de datos en construcción son únicos.

Qué hay en el archivo

El archivo de documentos de una empresa de construcción mediana a grande típica incluye:

Presupuestos de cantidades de obra (BOQs): Tablas estructuradas que listan materiales, mano de obra, cantidades, precios unitarios y montos — pero en formatos tremendamente inconsistentes. Algunos son hojas de cálculo de Excel, algunos son exportaciones PDF, algunos son documentos de papel escaneados. La jerarquía (secciones, subsecciones, ítems, sub-ítems) varía por contratista, región y era.

Planos técnicos: Archivos DWG, exportaciones PDF de dibujos CAD, planos escaneados. Estos contienen información espacial, dimensiones, anotaciones y símbolos que representan elementos de construcción específicos.

Especificaciones: Documentos de cientos de páginas que definen materiales, métodos y requisitos de calidad. Mezcla de secciones estructuradas y descripciones en texto libre.

RFIs (Solicitudes de Información): Preguntas y respuestas entre contratistas, arquitectos e ingenieros. A menudo en cadenas de email, PDFs o exportaciones de sistemas de gestión de proyectos.

Submittals: Hojas de datos del fabricante, planos de taller, certificados de materiales. Formatos variados, a menudo escaneados.

Órdenes de cambio: Modificaciones al alcance original con implicaciones de costo y cronograma. Mezcla de formularios estructurados y descripciones narrativas.

Por qué la preparación de datos de construcción es especialmente difícil

Inconsistencia de formato

A diferencia de la salud (donde existen estándares HL7/FHIR) o las finanzas (donde XBRL proporciona estructura), la construcción no tiene un estándar de datos universal. Un BOQ de un contratista se ve completamente diferente de otro. Los nombres de columnas, jerarquías, convenciones de unidades y formato varían de proyecto en proyecto.

Modalidades mixtas

Los documentos de construcción combinan texto, tablas, planos e imágenes — a menudo en la misma página. Una especificación puede tener un párrafo de texto, una tabla de propiedades de materiales y una referencia cruzada a un número de plano. Parsear esto requiere entender la relación entre estos elementos.

Escala

Un solo proyecto grande puede generar más de 50,000 páginas de documentación. Una empresa con 20 años de historial de proyectos puede tener cientos de miles de documentos. El procesamiento manual a esta escala es impráctico.

Especificidad del dominio

Entender los documentos de construcción requiere experiencia en el dominio. Un ingeniero de ML no puede determinar si un ítem de BOQ está correctamente clasificado sin entender los oficios de construcción, las convenciones de medición y las especificaciones de materiales. Este es conocimiento que vive en los medidores de cantidades y gerentes de proyecto, no en los científicos de datos.

Cumplimiento y sensibilidad

Los datos de proyectos de construcción a menudo contienen información comercialmente sensible: precios, tarifas de contratistas, presupuestos de clientes. En algunas regiones (particularmente Medio Oriente y el Sur de Asia), las regulaciones de soberanía de datos restringen dónde se puede procesar esta información.

El pipeline de preparación de datos para construcción

Etapa 1: Ingestión

• OCR para documentos escaneados con detección de diseño
• Extracción de tablas de BOQs (manejo de celdas combinadas, jerarquías anidadas)
• Parseo de archivos de planos (extracción de anotaciones, dimensiones, identificación de elementos)
• Análisis de estructura de PDF (distinción de secciones, apéndices, referencias)

Etapa 2: Limpieza

• Normalización de unidades (conversión entre métrico e imperial)
• Estandarización de terminología (mapeo de términos específicos del contratista a vocabulario común)
• Deduplicación entre documentos de proyecto (la misma sección de especificación a menudo aparece en múltiples documentos)
• Puntuación de calidad (niveles de confianza para salida OCR, precisión de extracción de tablas)

Etapa 3: Etiquetado

• Clasificación de oficios de construcción (civil, mecánico, eléctrico, plomería)
• Categorización de tipo de documento (especificación, BOQ, plano, RFI, submittal)
• Extracción de entidades (nombres de materiales, cantidades, tarifas, referencias de proyecto)
• Mapeo de relaciones (qué sección de especificación se relaciona con qué ítem de BOQ)

Etapa 4: Aumento

• Generación de datos sintéticos para tipos de documentos subrepresentados
• Muestreo balanceado entre oficios y tipos de proyecto
• Referencias cruzadas entre documentos para construir datos de entrenamiento relacionales

Etapa 5: Exportación

• JSONL para fine-tuning de modelos de lenguaje de construcción
• Texto fragmentado para bases de conocimiento RAG
• JSON estructurado para modelos de clasificación y extracción
• CSV para modelos de ML tradicional de estimación de cantidades

Por qué esto debe suceder on-premise

La preparación de datos de construcción tiene un caso sólido para procesamiento on-premise:

1. Sensibilidad comercial: Los datos de precios, tarifas de contratistas y presupuestos de clientes no pueden exponerse a servicios en la nube
2. Soberanía de datos: Las empresas que operan en regiones con requisitos de localización de datos (países del GCC, la PPIA de Pakistán) necesitan que los datos permanezcan en infraestructura local
3. Volumen: Enviar cientos de gigabytes a servicios en la nube es lento y costoso
4. Participación de expertos del dominio: Los medidores de cantidades y gerentes de proyecto que necesitan participar en el etiquetado no deberían necesitar cuentas en la nube y soporte de DevOps

Primeros pasos

Si tu empresa de construcción está sentada sobre un gran archivo de documentos y explorando la adopción de IA, el camino a seguir es:

1. Audita tu archivo: ¿Qué tipos de documentos tienes? ¿Qué formatos? ¿Qué volumen?
2. Identifica el primer caso de uso: Comienza con un alcance reducido — la clasificación automatizada de BOQ es un primer proyecto común
3. Evalúa la calidad de los datos: ¿Cuánto de tu archivo es digital nativo vs. escaneado? Los documentos escaneados requieren mejor OCR.
4. Involucra a expertos del dominio: Los medidores de cantidades y gerentes de proyecto necesitan definir el esquema de etiquetado — ellos saben qué importa.

Plataformas como Ertas Data Suite están construidas exactamente para este flujo de trabajo — manejando el pipeline completo desde la ingestión hasta la exportación, on-premise, con una interfaz de escritorio nativa que los expertos del dominio pueden usar directamente. El archivo de PDFs de 700GB no es un problema para resolver después. Es el activo que hace posible la IA en construcción.