Extracción de Datos de Presupuestos de Cantidades: Una Guía para Proyectos de IA en Construcción

Un presupuesto de cantidades es uno de los documentos con mayor densidad de información en la construcción. Cada partida codifica una especificación, una cantidad, una unidad de medida y — en proyectos finalizados — una tarifa. En conjunto, el archivo histórico de BOQ de una empresa representa años de conocimiento acumulado de costos, calibrado para tipos de proyectos, ubicaciones y condiciones de mercado específicos.

Para la IA en construcción, ese archivo es datos de entrenamiento esperando ser desbloqueados. El principal obstáculo es que los documentos BOQ fueron diseñados para lectores humanos y software de mediciones, no para pipelines de machine learning. Extraerlos correctamente requiere comprender tanto el formato del documento como las convenciones del dominio.

Esta guía cubre la estructura de los documentos BOQ, por qué la extracción es más difícil de lo que parece, cómo abordar el pipeline de extracción y cómo debería verse la salida para casos de uso de entrenamiento de IA.

Qué Contiene un BOQ y Por Qué Importa para la IA

Un presupuesto de cantidades es un documento estructurado de costos y cantidades producido durante la fase previa o posterior a la licitación de un proyecto de construcción. Sirve como base para la fijación de precios, administración del contrato y liquidación de la cuenta final.

El contenido está organizado jerárquicamente. En el nivel superior están las divisiones — que típicamente corresponden a categorías de trabajo como subestructura, superestructura, acabados, servicios MEP. Dentro de cada división hay secciones, cada una cubriendo un tipo de trabajo específico. Dentro de cada sección hay partidas, cada una representando una unidad discreta de trabajo con una cantidad medida.

Cada partida codifica:

Código de partida: Un número de referencia jerárquico (p. ej., 03.04.12)
Descripción: Una especificación técnica del trabajo, que a menudo referencia materiales, grados, normas y métodos
Cantidad: Una cantidad medida (p. ej., 127.5)
Unidad: La unidad de medida (p. ej., m3, m2, m, Nr, suma)
Tarifa: El precio unitario (presente en BOQs con precios de proyectos finalizados)
Monto: Cantidad x Tarifa
Referencias cruzadas: Números de planos y referencias a cláusulas de especificación integradas en la descripción

Para el entrenamiento de IA, el campo más valioso es la descripción. Es donde reside el conocimiento del dominio. Una descripción como "Concreto reforzado, grado C35/45, mezcla diseñada, en columnas sobre la losa de planta baja, incluyendo encofrado, vibrado y curado de acuerdo con la Cláusula 5.4.2 de la Especificación del Proyecto; ref planos S-201, S-202" contiene: una especificación de grado de concreto, un especificador de ubicación, una lista de actividades incluidas, una referencia cruzada a la especificación y dos referencias a planos. Todo en una sola línea.

Un corpus de 100,000 de estas partidas de proyectos finalizados es una representación densa y estructurada del conocimiento de construcción — mucho más útil para entrenar un modelo de estimación de construcción que el texto general de la web.

Por Qué la Extracción Es Más Difícil de Lo Que Parece

Los documentos BOQ son generados por software de mediciones (CostX, CANDY, Buildsoft, CCS, WinQS) y exportados a PDF para distribución. El problema es que PDF es un formato de presentación, no un formato de datos. El software renderiza la tabla visualmente de manera perfecta, pero el PDF subyacente puede almacenar el texto de cada celda como un elemento de texto posicionado por separado sin relación estructural con sus vecinos.

El problema de alineación de columnas. En un PDF nativamente digital, el texto en una columna de tabla está alineado por coordenada X. Pero las coordenadas X de los fragmentos de texto de diferentes versiones de software, diferentes impresoras y diferentes configuraciones de exportación no son consistentes. Una tabla que se ve limpia en pantalla puede tener "Tarifa" en X=412 en un documento y en X=418 en otro. La detección de columnas por coordenada X requiere manejo de tolerancia y calibración por documento.

Descripciones multilínea. Las descripciones largas se envuelven en múltiples líneas dentro de la misma celda. Cada línea es un fragmento de texto separado. La reconstrucción requiere detectar que las líneas pertenecen a la misma partida — usando indentación, la ausencia de una cantidad en la columna adyacente y la no ocurrencia de un código de partida al inicio de la línea.

Continuación entre páginas. Los documentos BOQ a menudo tienen cientos de páginas. Una sección puede comenzar en la página 47 y continuar hasta la página 83. Los encabezados de página se repiten en la parte superior de cada página, y los totales de sección aparecen en la parte inferior. La extracción ingenua de tablas página por página incluirá estos encabezados y totales repetidos como filas de datos, y dividirá las partidas que cruzan un salto de página.

PDFs rasterizados. Algunos BOQs son documentos de papel escaneados o son exportados por software que rasteriza la salida (produciendo un PDF basado en imagen en lugar de uno basado en texto). Estos requieren OCR antes de que pueda ocurrir cualquier extracción de tablas. El OCR en contenido tabular introduce errores de alineación que amplifican el problema de detección de columnas.

Texto de especificación incrustado. Algunos formatos de BOQ — particularmente aquellos que siguen el Standard Method of Measurement — incluyen cláusulas de preámbulo sobre cada sección que definen la especificación aplicable a todas las partidas de esa sección. Estos preámbulos no son partidas pero deben asociarse con las partidas debajo de ellos para proporcionar contexto completo para el entrenamiento de IA.

El Enfoque de Extracción

Un pipeline de extracción de BOQ tiene cuatro sub-etapas: detección de estructura, análisis de partidas, normalización y extracción de referencias cruzadas.

Detección de estructura. Antes de analizar partidas individuales, el pipeline debe identificar la disposición de columnas del documento y las ubicaciones de encabezados, preámbulos, saltos de sección y encabezados de páginas de continuación. Esto se hace analizando la distribución de coordenadas X del texto a través de una muestra de páginas para inferir los límites de columnas, y escaneando patrones que indiquen la estructura de sección (títulos de sección en mayúsculas, cambios en el formato de código de partida, totales acumulados).

Análisis de partidas. Con la estructura de columnas establecida, cada página se procesa para extraer registros de partidas. El analizador lee los fragmentos de texto en orden de lectura, asigna cada fragmento a una columna basándose en su coordenada X, detecta descripciones multilínea verificando códigos de partida y cantidades, y maneja la continuación de saltos de página llevando el estado actual de la partida a través de las páginas.

La salida de esta etapa es un registro sin procesar para cada partida con su código, descripción, cantidad, unidad, tarifa y monto. En este punto, los registros están sin procesar — las descripciones contienen el texto completo incluyendo referencias a especificaciones, las cantidades son cadenas de texto sin procesar y las unidades no han sido normalizadas.

Normalización. Las cadenas de cantidades se convierten a valores numéricos, manejando separadores de miles y marcas decimales específicas por localización. Las cadenas de unidades se normalizan a formas canónicas: "m3", "CUM", "cum", "M3", "metro cúbico" y "cu.m" todas se normalizan a "m3". Los códigos de partida se analizan en sus componentes jerárquicos. Los montos se validan contra Cantidad x Tarifa donde ambos están presentes.

Extracción de referencias cruzadas. Las referencias a planos y las referencias a cláusulas de especificación se extraen del texto de la descripción usando coincidencia de patrones. Las referencias a planos típicamente siguen patrones como "dwg S-201", "ref. drawing A/301" o "S-201/Rev.A". Las referencias a cláusulas de especificación típicamente siguen patrones como "Clause 5.4.2", "BS EN 206" o "to Spec Section 4". Estas se extraen como campos estructurados en lugar de dejarse incrustadas en el texto de la descripción.

Controles de Calidad para Datos de BOQ

La extracción sin procesar produce registros que van desde alta confianza (PDF tabular limpio, estructura de columnas clara) hasta baja confianza (PDF rasterizado escaneado, disposición irregular). Los controles de calidad deben ejecutarse antes de que cualquier dato extraído ingrese a un dataset de entrenamiento.

Consistencia de código de partida. Dentro de un documento, los códigos de partida deben seguir un formato de numeración consistente. Las partidas que rompen el patrón — componentes faltantes, niveles de profundidad inesperados — se marcan para revisión.

Completitud de normalización de unidades. Cualquier cadena de unidad que no se normalice a una forma canónica conocida se marca. Los BOQs de construcción usan un conjunto finito de unidades de medida; una cadena de unidad no reconocida generalmente indica un error de análisis.

Continuidad entre páginas. La suma de los montos de las partidas dentro de una sección debe coincidir con el total de sección al final de la sección. Cuando no coinciden, es probable que haya errores de continuación entre páginas.

Completitud de descripción. Los campos de descripción que son muy cortos (menos de 10 caracteres) o que contienen artefactos obvios de OCR (cadenas de símbolos, secuencias de caracteres sin separación de palabras) se marcan.

Detección de duplicados. El mismo BOQ puede existir en múltiples revisiones en el archivo. Los registros de diferentes revisiones del mismo documento deben deduplicarse usando la revisión más reciente.

Un umbral práctico de calidad: los registros con código de partida, descripción de al menos 20 caracteres, cantidad numérica y unidad reconocida pasan automáticamente. Los registros que fallan en cualquier verificación se ponen en cola para revisión humana. En un archivo digital de BOQ de alta calidad, se esperan tasas de aprobación automática del 80-90%. En un archivo mixto que incluye documentos escaneados, se espera del 50-70%.

Formatos de Salida para Entrenamiento de IA

JSONL para fine-tuning de modelos de estimación. Cada partida se convierte en un registro JSON:

{"item_code": "03.04.12", "description": "Reinforced concrete, grade C35/45, in columns above ground floor slab, including formwork and curing", "quantity": 127.5, "unit": "m3", "rate": 285.00, "project_type": "office", "region": "southeast", "date": "2024-Q2"}

Este formato entrena un modelo para predecir tarifas a partir de descripciones, o para sugerir descripciones para una especificación dada.

CSV para analítica de costos. Los mismos registros en forma tabular, con una columna por campo, permiten análisis estadístico: distribuciones de tarifas por tipo de partida, tendencias de costos a lo largo del tiempo, variaciones regionales de tarifas.

Texto fragmentado para RAG. Las partidas de BOQ pueden incrustarse como fragmentos de texto para un sistema de recuperación, permitiendo consultas como "¿qué se especificaba típicamente para columnas de concreto armado en proyectos de oficinas comerciales?" El campo de descripción, combinado con metadatos del proyecto, forma una unidad de recuperación efectiva.

Tamaños de Dataset Esperados para IA en Construcción

Para un modelo de estimación significativo, necesitas suficientes registros para representar el rango de partidas, tipos de proyectos y períodos de tiempo en tus datos. Umbrales aproximados:

Dataset mínimo viable: 10,000 partidas de al menos 10 proyectos finalizados, cubriendo las principales categorías de trabajo
Dataset útil: 50,000 partidas de más de 30 proyectos a través de múltiples tipos de proyecto
Dataset sólido: 150,000+ partidas de más de 80 proyectos con datos completos de tarifas y metadatos del proyecto

La mayoría de las empresas con una década de historial de proyectos encontrarán suficientes datos de BOQ para alcanzar el umbral "útil" dentro de su archivo. La restricción es típicamente la calidad de extracción, no el volumen de datos.

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 →