Etiquetado de Datos Sin Código para Equipos de Ingeniería y Construcción

Un quantity surveyor mira una partida de un presupuesto de cantidades — "Suministro e instalación de tubería HDPE de 150mm de diámetro, PN10, incluyendo todos los accesorios, zanjado a 1.2m de profundidad, cama, relleno y restitución, completo" — e inmediatamente sabe que esta es una tarifa compuesta que agrupa material, mano de obra, movimiento de tierras y restitución. Sabe que la clasificación de presión PN10 significa que es una línea de suministro de agua, no drenaje. Sabe que la profundidad de 1.2m sugiere que está por debajo de la línea de helada pero por encima de la profundidad típica de alcantarillado.

Un ingeniero de ML lee la misma partida y ve texto.

La IA para construcción — ya sea para estimación de costos, análisis de especificaciones, interpretación de planos o evaluación de riesgos de proyecto — depende precisamente del tipo de conocimiento de dominio que vive en las cabezas de ingenieros, quantity surveyors, gerentes de proyecto y supervisores de obra. Llevar ese conocimiento a datasets de entrenamiento es el desafío.

Por Qué los Datos de Construcción Son Especialmente Difíciles de Etiquetar

Los datos de construcción e ingeniería tienen características que los hacen resistentes al etiquetado por cualquier persona sin experiencia en la industria.

La terminología no estándar varía por región, empresa y proyecto. "BOQ" significa lo mismo en todas partes, pero las partidas dentro de él varían enormemente. El "monto provisional para condiciones imprevistas del terreno" de una empresa es la "contingencia — riesgo geotécnico" de otra. Una "tarifa por día" en el Reino Unido es una "tarifa T&M" en Estados Unidos. Un ingeniero de ML que construye un modelo de clasificación no tiene un marco para normalizar esta variación.

Las abreviaturas son densas y dependen del contexto. "RC" podría significar concreto reforzado, costo de operación o centro de recursos. "GF" es planta baja en planos arquitectónicos pero relleno general en especificaciones de movimiento de tierras. "PC" es costo primo en presupuestos pero concreto prefabricado en diseño estructural. La interpretación correcta requiere conocer el tipo de documento y la sección.

Los datos visuales requieren razonamiento espacial. Los planos de construcción codifican información en grosor de línea, tipo de línea, patrones de sombreado, dimensiones, anotaciones y relaciones espaciales. Un ingeniero estructural lee una sección transversal y entiende que un patrón de sombreado particular indica concreto vaciado con refuerzo a profundidades de recubrimiento específicas. Un ingeniero de ML ve formas geométricas. Etiquetar elementos de planos para modelos de detección de objetos requiere experiencia de dominio en cada paso.

Las cantidades tienen restricciones implícitas. Una entrada de presupuesto de cantidades para "100m3 de concreto C30/37 para cimentaciones" lleva información implícita: el grado de concreto implica uso estructural, la especificación para cimentaciones implica requisitos específicos de colocación, y 100m3 son aproximadamente 230 toneladas — una vaciada significativa que implica entrega con bomba y posible faseado. Etiquetar el nivel de complejidad de esta entrada, los requerimientos de recursos o el perfil de riesgo requiere conocimiento de construcción que ninguna cantidad de búsqueda en Google proporcionará.

La interpretación de especificaciones requiere experiencia. Las especificaciones de construcción usan términos técnicos — "deberá," "debería," "podrá" — con significados contractuales específicos. "El concreto deberá alcanzar una resistencia a compresión mínima de 30 N/mm2 a los 28 días" es un requisito estricto con implicaciones de prueba y cumplimiento. Un ingeniero de ML podría no distinguir esto de una descripción general.

El Estado Actual: Los Ingenieros No Pueden Acceder a las Herramientas

A pesar de tener el conocimiento para producir etiquetas de alta calidad, los profesionales de construcción están casi completamente excluidos de las herramientas de anotación de ML.

El entorno técnico típico del profesional de construcción se ve así: Microsoft Office, software de gestión de proyectos (Primavera, Microsoft Project), herramientas de estimación de costos (CostX, Bluebeam), software BIM (Revit, Tekla) y herramientas CAD (AutoCAD). Su zona de confort computacional son aplicaciones de escritorio con interfaces visuales.

Las herramientas de anotación requieren un universo diferente de habilidades. Configurar Label Studio requiere Docker. Prodigy requiere Python y pip. Las plataformas en la nube requieren subir datos potencialmente propietarios — planos de proyecto, documentos de licitación, datos de costos — a servidores externos.

La mayoría de las empresas de construcción tratan los datos de licitación, bases de datos de costos y documentos de proyecto como información comercial altamente confidencial. Subir estos datos a plataformas de anotación en la nube genera preocupaciones competitivas que van más allá de la seguridad de TI — un competidor con acceso a tus datos históricos de licitación obtiene una ventaja comercial directa.

El resultado: el desarrollo de IA para construcción procede sin profesionales de construcción en el ciclo de etiquetado. Los ingenieros de ML etiquetan partidas de BOQ que no entienden, clasifican elementos de planos que no pueden interpretar y categorizan cláusulas de especificaciones cuyas implicaciones contractuales no comprenden.

Qué Necesitan los Equipos de Construcción

Hemos trabajado con equipos de ingeniería y construcción que van desde contratistas tier-1 hasta subcontratistas especializados. Sus requisitos para una herramienta de etiquetado convergen en cinco puntos.

Instalación de escritorio sin dependencia de TI. Los equipos de TI de construcción están enfocados en servidores BIM, plataformas de gestión de proyectos y conectividad en obra. No tienen la capacidad ni la experiencia para desplegar contenedores Docker o mantener aplicaciones web autoalojadas. La herramienta de etiquetado debe instalarse como CostX o Bluebeam — descargar un instalador, ejecutarlo, listo.

Procesamiento local de datos. Los documentos de licitación, datos de costos y planos de proyecto son comercialmente sensibles. No pueden subirse a plataformas en la nube. La herramienta debe trabajar con archivos almacenados localmente o en el servidor de archivos de la empresa, sin transmisión externa de datos.

Soporte para formatos de datos de construcción. Los BOQs vienen en Excel y CSV. Las especificaciones vienen en PDF y DOCX. Los planos vienen en PDF, DWG y formatos de imagen. La herramienta debe abrir estos formatos directamente sin requerir conversión a un formato de anotación especializado.

Interfaz visual de etiquetado. Los profesionales QS, gerentes de proyecto e ingenieros están acostumbrados a herramientas visuales. Hacen clic, arrastran, resaltan y anotan. Una interfaz de etiquetado que use estos patrones de interacción verá adopción. Una que requiera escribir JSON o seleccionar de menús desplegables estilo código no la verá.

Tipos de etiquetas relevantes para construcción. La capacidad de crear esquemas de etiquetado usando terminología de construcción — categorías de oficios (divisiones CSI MasterFormat), tipos de costos (material, mano de obra, maquinaria, subcontratista), niveles de riesgo (bajo, medio, alto), tipos de especificación (prescriptiva, de rendimiento, propietaria) — sin mapearlos a vocabulario genérico de ML.

Flujos de Trabajo Prácticos para Etiquetado de Construcción

Así es como los expertos de dominio de construcción pueden contribuir a los datos de entrenamiento de IA cuando se elimina la barrera de herramientas.

Clasificación de BOQ. Un quantity surveyor abre un presupuesto de cantidades en la herramienta de etiquetado. Para cada partida, asigna categoría de oficio, tipo de costo, calificación de complejidad y cualquier marca (tarifa compuesta, monto provisional, costo primo). Un QS senior puede etiquetar 80-120 partidas por hora — aproximadamente 4 veces más rápido que un ingeniero de ML que debe investigar cada partida.

Análisis de Especificaciones. Un gerente de contratos revisa secciones de especificaciones y las etiqueta por tipo (requisito de rendimiento, requisito prescriptivo, estándar de referencia, requisito administrativo), aplicabilidad (todos los oficios, oficios específicos) y método de verificación de cumplimiento (prueba, inspección, documentación). Este etiquetado requiere entender cómo las especificaciones interactúan con las condiciones del contrato — conocimiento que existe solo en profesionales de construcción experimentados.

Clasificación de Elementos de Planos. Un ingeniero estructural revisa planos estructurales y etiqueta elementos — columnas, vigas, losas, cimentaciones, detalles de refuerzo — con propiedades estructurales extraídas de las anotaciones del plano. Un ingeniero de instalaciones hace lo mismo para planos MEP. Cada experto etiqueta su dominio más rápido y con mayor precisión que un generalista.

Etiquetado de Evaluación de Riesgos. Un gerente de proyecto revisa documentos del proyecto — RFIs, órdenes de variación, avisos de retraso — y los etiqueta por categoría de riesgo, severidad y resultado probable. Este etiquetado requiere entender la dinámica del proyecto, los mecanismos contractuales y las practicidades de la construcción que ningún modelo de ML puede aprender solo del texto.

La Oportunidad de Escala

Una empresa de construcción mediana tiene 20-50 ingenieros, profesionales QS y gerentes de proyecto que podrían contribuir al etiquetado. Si cada uno contribuye 30 minutos por semana — un pedido modesto — la empresa produce 2,000-5,000 ejemplos etiquetados por mes.

Eso es suficiente para construir modelos de clasificación significativos para análisis de BOQ, análisis de especificaciones o categorización de documentos en un solo trimestre. Sin participación de expertos de dominio, el mismo dataset le tomaría a un equipo de ML 6-12 meses producirlo, con menor calidad de etiquetas.

La industria de la construcción genera enormes volúmenes de datos estructurados y semi-estructurados — BOQs, especificaciones, RFIs, submittals, informes diarios, órdenes de variación — que están casi completamente sin etiquetar. El conocimiento para etiquetarlos existe en miles de profesionales experimentados. La barrera son las herramientas.

Eliminando la Barrera

Ertas Data Suite está construido exactamente para este caso de uso. Es una aplicación de escritorio nativa que se instala como cualquier otro software de ingeniería. Los profesionales de construcción la apuntan a sus archivos locales — BOQs en Excel, especificaciones en PDF, imágenes de planos — y etiquetan a través de una interfaz visual. Sin Python, sin Docker, sin subida a la nube.

Los esquemas de etiquetado se configuran visualmente usando la terminología que el equipo utilice. Las exportaciones producen formatos estándar de entrenamiento de ML que el equipo de IA consume directamente. Los expertos de dominio nunca ven una línea de código. Los ingenieros de ML nunca tienen que interpretar terminología de construcción que no entienden.

El resultado es IA de construcción entrenada con conocimiento de construcción — que es la única forma de construir modelos en los que los profesionales de construcción realmente confiarán.