Cómo leer planos de carreteras sin perder el dibujo: una mirada a PlanSightRAG

Imagina una lámina de planos de un departamento de transporte estatal (DOT) para un enlace de autopistas. Una línea de cota se extiende desde el poste de un guardarraíl hasta el borde del pavimento con la etiqueta "24'-0"". Cerca de allí, una llamada apunta a una alcantarilla con una nota sobre el diámetro de la tubería. Nada de esto tiene un orden de lectura natural. El número 24 no significa nada sin la flecha a la que está unido, y la flecha no significa nada sin los dos puntos que conecta. Ahora pasa esa página por un OCR. Lo que obtienes es una bolsa de texto: "24'-0"", "CULVERT", el diámetro de una tubería, algunos números de estación; todas cadenas extraídas con total exactitud, y todas inservibles, porque aquello que les daba sentido (qué línea toca qué objeto, en qué lugar de la página se sitúa) ha desaparecido.

Ese es el problema que intenta resolver un nuevo artículo de investigación titulado PlanSightRAG, y representa un claro ejemplo de un modo de fallo fácil de pasar por alto si se asume que el OCR es un problema resuelto. No está resuelto para dibujos técnicos. Está resuelto para documentos formados principalmente por oraciones.

Por qué los planos de ingeniería civil rompen el esquema estándar de la IA documental

La mayoría de los sistemas de generación aumentada por recuperación (RAG) para documentos siguen la misma receta: pasar la página por un OCR para convertirla en texto, dividir el texto en fragmentos (chunks), generar los embeddings de dichos fragmentos y dejar que un modelo de lenguaje recupere y razone sobre ellos. Esto funciona razonablemente bien para contratos, facturas e informes, porque la información reside en las palabras y las palabras se leen en orden.

Los planos estándar de ingeniería civil no funcionan así. Una sola lámina de un conjunto de planos de un departamento de transporte estatal (DOT) puede combinar:

• Una vista en planta (vista cenital directa) y una vista de perfil (elevación lateral) en la misma página, a diferentes escalas
• Líneas de cota y líneas de referencia (leaders) que codifican relaciones únicamente a través de la geometría
• Símbolos y patrones de sombreado (hatching) que significan cosas específicas por convención, no mediante etiquetas de texto
• Referencias cruzadas a otras láminas, tablas y a un pliego de especificaciones independiente que define los límites numéricos reales

Si eliminas la maquetación y disposición espacial con OCR, habrás desechado la mayor parte de lo que hace legible el dibujo. Los autores lo expresan con claridad en su resumen: la automatización basada en OCR "despoja la geometría y la disposición esenciales para interpretar estos planos". Los ingenieros siguen realizando la verificación de cumplimiento de todo esto a simple vista, lámina por lámina, cotejándola con documentos de especificaciones que pueden tener cientos de páginas. Es un proceso lento y es exactamente el tipo de tarea repetitiva y propensa a errores en la que la automatización debería destacar, salvo por el hecho de que el conjunto de herramientas estándar de la IA documental no encaja aquí.

La solución: dejar de convertir el dibujo en texto por completo

La jugada central de PlanSightRAG consiste en omitir por completo la extracción de texto mediante OCR para la indexación y la recuperación. En lugar de convertir una lámina de planos en texto y luego buscar en él, trata cada página como una imagen y busca imágenes a partir de imágenes.

La columna vertebral de la recuperación es un modelo llamado ColNomic-3B. Para comprender qué implica esto, conviene conocer la familia a la que pertenece. La recuperación de documentos convencional toma una página completa y la comprime en un único vector (una lista de números) que supuestamente resume todo su contenido. Esto es rápido, pero con pérdidas (lossy): una página con doce notas y llamadas distintas se reduce a un vector del mismo tamaño que el de una página con un solo párrafo. En cambio, ColNomic utiliza un enfoque multivectorial derivado de un método llamado ColPali: divide la imagen en una cuadrícula de parches (patches) y genera un vector independiente para cada parche, de modo que una consulta puede coincidir con la región específica de la página donde realmente reside el contenido relevante, y no simplemente con un promedio de toda la lámina. Cuando consultas al sistema (por ejemplo, "¿cuál es el gálibo o distancia mínima para este tipo de guardarraíl?"), compara tu consulta con cada parche de cada página y localiza las coincidencias más sólidas. Es por esto que la geometría sobrevive: en ningún momento se le pide a un modelo que describa primero el dibujo con palabras.

Sobre esa capa de recuperación se sitúa lo que el artículo denomina un pipeline agéntico Planner-Retriever-Auditor-Synthesizer. Se trata de cuatro roles, cada uno gestionado por una etapa del pipeline en lugar de un único prompt monolítico:

• Planner desglosa lo que la pregunta plantea en realidad (qué tipos de láminas son relevantes, qué se necesita verificar)
• Retriever extrae las páginas de planos candidatas y las páginas de especificaciones de referencia mediante la búsqueda multivectorial de ColNomic
• Auditor comprueba si la evidencia recuperada realmente respalda una respuesta, en lugar de dar por bueno cualquier resultado obtenido
• Synthesizer genera la respuesta final o el dictamen de cumplimiento, fundamentado en las páginas recuperadas

El otro elemento que merece la pena destacar es lo que denominan mapas de calor MaxSim (MaxSim heatmaps). Dado que el modelo de recuperación calcula puntuaciones de similitud a nivel de parche, es posible visualizar qué parches de una página impulsaron la coincidencia. Esto genera un mapa de calor superpuesto al dibujo original, que muestra con precisión dónde cree el sistema que se encuentra la cota, el símbolo o la nota relevante. Esto importa mucho más de lo que podría parecer a simple vista. Una verificación de cumplimiento que solo devuelve "PASS" o "FAIL" no es algo que un ingeniero pueda validar y firmar. Una verificación de cumplimiento que devuelve "FAIL, y este es el punto exacto del dibujo que lo provocó" sí es algo que se puede auditar con confianza, o corregir si es erróneo.

Qué dicen realmente las cifras

El equipo construyó un benchmark a partir de material real: 1,898 páginas de planos estándar procedentes de cinco DOT estatales, convertidas en 4,056 pares de preguntas y respuestas. En recuperación zero-shot (lo que significa que el modelo no fue ajustado previamente con este conjunto específico de planos), PlanSightRAG alcanzó un 91.47% en Recall@5. Esta métrica indica si, para una pregunta determinada, la página de origen correcta figura entre las 5 mejores páginas que recupera el sistema. Acertar más del 91% de las veces en dibujos tan densos y carentes de estructura es un resultado sólido.

La cifra más convincente, a mi juicio, es lo que ocurrió con un corpus retenido (held-out) del DOT de Michigan que no formaba parte de los cinco estados originales: 91.40% en Recall@5, prácticamente idéntico al resultado in-distribution. Los distintos estados dan formato a sus planos estándar de manera diferente. Un sistema que solo funciona con los planos sobre los que fue ajustado no resulta de gran utilidad para un DOT que no estuvo en el conjunto de entrenamiento. Generalizar con tanta limpieza al formato de planos de un estado inédito es el resultado que verdaderamente sugiere que el método está captando la estructura general de lectura de planos, en lugar de memorizar un puñado de plantillas.

Donde el artículo se vuelve más honesto y más interesante

Los resultados de verificación de cumplimiento son el punto donde conviene detenerse, porque la cifra titular requiere un asterisco que el propio artículo se encarga de proporcionar.

En dibujos de cumplimiento sintéticos generados paramétricamente (planos creados con valores conocidos y controlados mediante programación para que la respuesta correcta sea inequívoca), un pipeline basado en Qwen2.5-VL-72B —un modelo de visión y lenguaje de 72 mil millones de parámetros— alcanza un 100% de precisión en los dictámenes. Pero solo bajo una condición muy específica: cuando al sistema se le entrega el umbral de la regla contra el que debe contrastar, ya resuelto como un número. En otras palabras, si le dices al modelo "el valor máximo permitido aquí es de 6 pulgadas", este compara correctamente la dimensión del dibujo con esas 6 pulgadas en todas y cada una de las ocasiones.

Se trata de un techo controlado, y el artículo reconoce de forma transparente que es un techo, no una demostración de verificación de cumplimiento de extremo a extremo (end-to-end). Nos indica que el modelo puede comparar correctamente un número en un plano con otro número, algo que resulta útil constatar, pero que no constituye la parte difícil de la tarea. La comparación verdaderamente informativa es la siguiente: una línea base de OCR sin VLM, sin ningún modelo de visión involucrado, ya alcanza un 76.4% bajo esa misma configuración. Por lo tanto, una gran parte de este benchmark en particular se puede resolver sin comprender en absoluto la geometría del dibujo, simplemente extrayendo cifras y comparándolas. La brecha entre el 76.4% y el 100% es real, pero es más estrecha de lo que una confrontación entre "OCR frente a un sofisticado sistema de visión" podría sugerir a primera vista, y conviene tenerlo presente cuando un artículo abre con una cifra del 100%.

El resultado que considero la contribución más importante del artículo es el más modesto y menos llamativo del final: el anclaje autónomo de reglas (autonomous rule-grounding). En lugar de recibir el umbral de cumplimiento preestablecido, el sistema extrae el límite numérico directamente de un corpus de especificaciones, sin que ningún humano proporcione la regla de antemano. Esa es la versión de la tarea que se asemeja a lo que la verificación de cumplimiento exige en la práctica: no te dan el valor de la regla masticado, tienes que ir a buscarlo al manual de especificaciones y luego aplicarlo correctamente sobre el plano. Este es un problema considerablemente más difícil que comparar dos números ya resueltos, y es en el que este sistema debe destacar con fiabilidad para que merezca la pena su despliegue en producción. El artículo demuestra que funciona, sin ofrecer una cifra de precisión titular para ello, lo cual constituye en sí mismo una señal reveladora de cuánto le falta recorrer a este componente antes de estar listo para un benchmark riguroso.

Por qué esto importa a quienes construyen o adquieren IA documental

Si estás desarrollando pipelines de procesamiento de documentos que abarcan dibujos de ingeniería, planos arquitectónicos, esquemas eléctricos o cualquier otro contenido donde el significado resida en la relación espacial entre trazos y marcas más que en las palabras propiamente dichas, este artículo ofrece un argumento contundente a favor de una regla que vale la pena interiorizar: no apliques OCR primero para luego hacerte preguntas. Convertir a texto descarta información que no se puede reconstruir con facilidad, y ningún nivel de sofisticación en el prompting sobre la salida del OCR logrará recuperarla.

Para los equipos de producto que evalúan proveedores de OCR o de IA documental, las cifras de recuperación expuestas aquí (más del 91% en Recall@5, manteniéndose ante el formato de planos de un estado no visto) representan un punto de referencia verdaderamente útil para comparar si trabajas con documentos donde prima la distribución visual: mapas, dibujos técnicos, formularios con tablas complejas o cualquier soporte donde "leer de arriba abajo" no sea la forma en que un humano abordaría la página.

Y para quien se sienta tentado a citar la cifra del 100% en dictámenes de cumplimiento en una presentación, conviene leer primero la letra pequeña. Ese porcentaje describe a un sistema que verifica un valor para el cual ya se le había especificado la regla. La prueba real —el anclaje autónomo de reglas a partir de un corpus de especificaciones sin una hoja de respuestas de por medio— es la que hay que vigilar de cerca, y es también la que todavía carece de una cifra limpia de precisión. Esto no es una crítica desmerecedora hacia el artículo: ser honesto acerca de qué parte del pipeline está demostrada y qué parte es una demostración preliminar prometedora resulta mucho más útil para los profesionales que un porcentaje triunfalista aislado.

Lo que todavía falta

Hay varios aspectos que conviene no perder de vista. Las cifras de recuperación del benchmark provienen de Recall@5 sobre pares de preguntas y respuestas construidos a partir de planos de cinco estados, lo que supone un comienzo sólido pero queda muy lejos de reflejar toda la diversidad de convenciones de formato de los DOT en los cincuenta estados, por no hablar de las normas municipales y de condado que ni siquiera siguen las plantillas de los DOT. El pipeline de cumplimiento depende de un modelo de 72 mil millones de parámetros, algo que dista de ser ligero de ejecutar en producción, y el artículo no reporta métricas de coste ni de latencia que permitan discernir si esto es viable de operar al volumen que requeriría una oficina real de revisión de un DOT. Además, los dibujos de cumplimiento sintéticos, si bien representan una forma razonable de obtener un ground truth limpio, son mucho más simples que los caóticos juegos de planos con décadas de antigüedad y anotaciones manuscritas sobre los que aún se apoya gran parte de la revisión real de infraestructuras.

Nada de esto menoscaba la idea central. Tratar una lámina de planos como una imagen sobre la cual buscar, en lugar de una página para transcribir, es el enfoque correcto para este tipo de documentos, y los resultados de recuperación lo respaldan. La faceta referente a la verificación de cumplimiento se encuentra en una etapa más temprana de lo que el marco general sugiere, pero el artículo resulta reconfortantemente transparente respecto a dónde se sitúa exactamente esa línea divisoria, algo que no puede decirse de la mayoría de los benchmarks en este campo.