Más allá de la extracción manual de datos RFQ: Alternativas prácticas (y por qué los LLMs genéricos aún fallan en dibujos técnicos)

Los flujos de trabajo de RFQ aún se rompen en el mismo lugar: alguien abre un dibujo técnico, entrecierra los ojos ante las anotaciones, adivina las unidades, interpreta abreviaciones y escribe manualmente datos estructurados en una hoja de cotización, ERP o herramienta de costeo. Es lento, inconsistente y difícil de escalar, especialmente cuando los dibujos provienen de diferentes proveedores, países y disciplinas.

La buena noticia: hay alternativas reales a la extracción manual. La mala noticia: muchos enfoques de "IA" fallan por razones predecibles, especialmente cuando dependen de OCR genérico y LLMs de propósito general.

Este artículo describe los principales enfoques que puede usar hoy, en qué son buenos, dónde fallan y cómo elegir una estrategia de extracción que realmente sobreviva a dibujos del mundo real.

Las alternativas a la extracción manual (y sus compromisos)

1) Mantenerlo manual, pero estandarizar el proceso

Qué es: Extracción humana con listas de verificación, plantillas y entrenamiento.

Por qué los equipos lo hacen: Es flexible y maneja casos extremos.

Dónde falla:

• No escala con el volumen de RFQ
• Caro y difícil de dotar de personal
• La calidad depende de individuos
• Sin trazabilidad consistente entre revisores

El trabajo manual puede ser "optimizado", pero rara vez se convierte en una ventaja competitiva.

2) OCR genérico + reglas/regex + hojas de cálculo

Qué es: Ejecutar OCR en el PDF/TIFF, luego analizar el texto resultante con reglas (regex, diccionarios de palabras clave, heurísticas).

Dónde funciona:

• Bloques de título limpios
• Fuentes/orientación consistentes
• Familias de dibujos estrechas con convenciones estrictas

Dónde falla en producción:

• Problemas de rotación y orientación: notas rotadas, anotaciones angulares, escaneos espejados, orientaciones mixtas a través de ventanas de visualización
• Símbolos y notación de ingeniería: símbolos de diámetro, acabado superficial, marcos GD&T, tolerancias apiladas
• Fragilidad: un proveedor cambia el diseño, y su conjunto de reglas colapsa
• Ambigüedad: las reglas luchan por "decidir" el significado cuando el mismo token puede significar cosas diferentes

Este enfoque puede entregar victorias rápidas, pero tiende a convertirse en una pila creciente de excepciones.

3) Extracción impulsada por CAD/PLM (BOM, PMI, definición basada en modelo)

Qué es: Evitar dibujos y extraer de CAD nativo, PMI, BOMs y objetos PLM estructurados.

Dónde funciona:

• Fabricación interna con gobernanza CAD moderna
• Entornos de ingeniería de circuito cerrado
• Organizaciones que realmente tienen los archivos fuente autoritativos

Dónde falla:

• Los RFQs a menudo vienen solo como PDF/TIFF
• Los proveedores y clientes no comparten CAD nativo consistentemente
• Los dibujos heredados y archivos escaneados no estarán cubiertos
• La adopción de MBD es desigual entre industrias

Si puede moverse hacia CAD/PLM estructurado, genial. Pero la mayoría de la realidad RFQ aún funciona con dibujos.

4) LLMs multimodales para extracción de dibujos

Qué es: Alimentar la imagen/PDF del dibujo a un LLM capaz de visión y pedir salida estructurada.

Por qué parece atractivo:

• Configuración mínima
• Maneja muchos formatos
• "Entiende" el contexto mejor que regex puro, a veces

Los dos grandes problemas (en la práctica):

Problema A: OCR sigue siendo el cuello de botella (especialmente con rotación)

La mayoría de las pipelines de extracción basadas en LLM aún dependen de OCR bajo el capó. En dibujos reales, tienes:

• anotaciones rotadas (bloques de título de 90°, notas angulares, etiquetas de vista rotadas)
• orientaciones mixtas en la misma hoja
• sellos, sesgo de escaneo, texto tenue, DPI bajo
• anotaciones apretadas cerca de la geometría

Cuando OCR pierde o corrompe el texto, el LLM no puede recuperarse confiablemente. Terminas con omisiones silenciosas ("no extrajo la mitad del bloque de título") o conjeturas confiadas pero incorrectas.

Problema B: La ambigüedad del dominio no es un "problema de lenguaje", es un problema de contexto

La abreviación de dibujos técnicos no es universal. El mismo token puede significar cosas diferentes dependiendo del dominio, región y convenciones de dibujo.

Ejemplos:

• "C45": comúnmente interpretado como un grado de acero por muchos ingenieros, pero en otros contextos puede denotar un chaflán (longitud + ángulo), dependiendo del estilo de notación y práctica local.
• "SM2": en un contexto óptico/mecánico óptico puede denotar un estándar de rosca (ej. roscas de tubo de lente serie SM). En otros contextos (y en algunas abreviaciones regionales) el mismo patrón puede interpretarse como una definición de chaflán (longitud, ángulo).
• Rugosidad superficial (Ra) y unidades: Los dibujos de EE.UU. vs UE pueden presentar expectativas de rugosidad de manera diferente, y los bloques de título a menudo no hacen las unidades explícitas. Si el dibujo no define claramente las unidades, su sistema debe inferir o al menos marcar la ambigüedad.

Los LLMs genéricos tienden a "resolver todo a la vez", pero sin modelos de dominio profundos y explícitos no pueden remover consistentemente la libertad del dibujante (la abreviación creativa y convenciones locales) y convertirla en estructura determinística y auditable.

Cómo se ve un enfoque de grado de producción: extracción + normalización + interpretación

Si quiere que la extracción RFQ funcione a escala, típicamente necesita una pipeline que haga tres cosas bien:

1. Leer el dibujo confiablemente OCR robusto y manejo de símbolos a través de rotaciones, artefactos de escaneo y hojas de múltiples orientaciones.

2. Normalizar la libertad del dibujante Mapear muchas notaciones en una representación canónica (de la misma manera que los humanos lo hacen, pero consistentemente).

3. Interpretar en contexto Decidir qué significa un token basado en el dominio, origen, estándares y pistas circundantes del dibujo, y marcar cuando el sistema no puede estar seguro.

Esto es exactamente donde los sistemas específicos del dominio superan a los enfoques LLM de propósito general.

Cómo Werk24 se posiciona diferentemente de "extracción solo LLM"

Werk24 se ha enfocado en la comprensión de dibujos técnicos durante años, específicamente para eliminar los dos modos de falla más grandes arriba.

1) La rotación no es un caso especial

La pipeline de extracción de Werk24 está construida para manejar rotación y contenido de orientación mixta como un requisito de primera clase. Texto rotado, anotaciones angulares y realidades comunes de escaneo se tratan como entrada normal, no excepciones.

Resultado: no pierde la mitad del bloque de título porque está rotado, y no necesita una política de "PDF perfecto" para obtener salida consistente.

2) El conocimiento del dominio está integrado en la capa de interpretación

Werk24 está diseñado para desambiguar la notación de dibujos aplicando contexto consciente del dominio, porque la misma cadena puede legítimamente significar cosas diferentes.

En la práctica esto incluye:

• reconocer si un dibujo es óptico vs mecánico (y qué convenciones siguen)
• interpretar abreviaciones de manera diferente basado en esa clasificación
• manejar convenciones regionales (ej. hábitos de EE.UU. vs UE, influencia de estándares)
• inferir o marcar unidades faltantes (en lugar de adivinar silenciosamente)
• producir salidas estructuradas que permanecen consistentes a través de proveedores

El objetivo no es meramente "extraer texto", sino entregar datos RFQ utilizables: dimensiones, tolerancias, materiales, requisitos de superficie, roscas y metadatos, interpretados de la manera que un revisor experimentado los interpretaría, pero con repetibilidad y trazabilidad.

Una lista de verificación pragmática para elegir un enfoque de extracción

Al evaluar alternativas (OCR+reglas, LLMs, plataformas de dominio), haga estas preguntas:

• Rotación y orientación: ¿Maneja texto rotado/mixto confiablemente, o necesita "PDFs limpios"?
• Soporte de símbolos y notación: Diámetro, marcos GD&T, tolerancias apiladas, acabado superficial, roscas, ¿manejados nativamente?
• Manejo de ambigüedad: ¿Decide y explica, o adivina silenciosamente?
• Clasificación de contexto: ¿Reconoce el dominio del dibujo y la influencia de estándares (ISO/ASME, óptico/mecánico)?
• Unidades e info de bloque de título faltante: ¿Infiere/marca unidades faltantes y diferencias regionales?
• Auditabilidad: ¿Puede rastrear campos extraídos de vuelta a regiones de dibujo y confianza?
• Humano en el bucle: ¿Pueden los revisores verificar/anular eficientemente cuando sea necesario?
• Integración: ¿API-first? ¿Formatos de exportación? ¿Se ajusta a flujos de trabajo RFQ/costeo/ERP?
• Consistencia a escala: ¿Se degrada el rendimiento cuando los proveedores varían?

Dónde los LLMs aún ayudan (cuando se usan correctamente)

Los LLMs pueden ser valiosos en los bordes:

• resumir paquetes RFQ
• redactar preguntas de proveedores ("por favor confirme unidades de acabado superficial")
• hacer coincidir partes históricas similares después de que tenga datos estructurados confiables
• traducir notas (con validación cuidadosa)

Pero el paso de extracción central, especialmente de dibujos desordenados, necesita confiabilidad, normalización e interpretación de dominio. Ahí no es donde los LLMs genéricos brillan hoy.

Conclusión

Si su proceso RFQ depende de dibujos técnicos, el mayor desbloqueo no es "IA que puede leer imágenes". Es un sistema que puede:

• leer dibujos robustamente (incluyendo rotación),
• eliminar la variabilidad de notación,
• e interpretar significado en contexto, consistentemente.

Esa combinación es lo que convierte dibujos en entradas RFQ estructuradas en las que puede confiar, automatizar y escalar. Werk24 está construido específicamente para eso.