De 4 semanas a 45 minutos: diseño de un sistema de extracción de documentos para más de 4700 archivos PDF

y me preguntó si podía ayudar a extraer números de revisión de más de 4700 archivos PDF de dibujos de ingeniería. Estaban migrando a un nuevo sistema de gestión de activos y necesitaban el valor REV actual de cada dibujo, un pequeño campo escondido en el bloque de título de cada documento. La alternativa era que un equipo de ingenieros abriera cada PDF uno por uno, localizara el bloque de título e ingresara manualmente el valor en una hoja de cálculo. A dos minutos por dibujo, eso equivale aproximadamente a 160 horas-persona. Cuatro semanas del tiempo de un ingeniero. A tarifas completamente cargadas de aproximadamente £50 por hora, eso representa más de £8,000 en costos laborales para una tarea que no produce ningún valor de ingeniería más allá de llenar una columna de una hoja de cálculo.

Este no fue un problema de IA. Era un problema de diseño de sistemas con limitaciones reales: presupuesto, requisitos de precisión, formatos de archivos mixtos y un equipo que necesitaba resultados en los que pudieran confiar. La IA fue un componente de la solución. Las decisiones de ingeniería en torno a esto fueron las que realmente hicieron que el sistema funcionara.

La complejidad oculta de los archivos PDF “simples”

Los dibujos de ingeniería no son archivos PDF ordinarios. Algunos se crearon en software CAD y se exportaron como archivos PDF basados ​​en texto donde se puede extraer texto mediante programación. Otros, en particular los dibujos heredados de la década de 1990 y principios de la de 2000, se escanearon a partir de originales en papel y se guardaron como archivos PDF basados ​​en imágenes. Toda la página es una imagen rasterizada plana sin ninguna capa de texto.

📷 [FIGURE 1: Annotated engineering drawing] Un dibujo de ingeniería representativo con el bloque de título (abajo a la derecha), la tabla del historial de revisiones (arriba a la derecha) y las letras de referencia de la cuadrícula (borde) resaltadas. El valor REV “E” se encuentra en el bloque de título junto al número de dibujo, pero la tabla del historial de revisiones y las letras de la cuadrícula son fuentes comunes de falsos positivos.

Nuestro corpus se basó aproximadamente en un 70-80% en texto y en un 20-30% en imágenes. Pero incluso el subconjunto basado en texto fue traicionero. Los valores REV aparecían en al menos cuatro formatos: versiones numéricas con guiones como 1-0, 2-0 o 5-1; letras individuales como A, B, C; letras dobles como AA o AB; y ocasionalmente campos vacíos o faltantes. Algunos dibujos se rotaron 90 o 270 grados. Muchos tenían tablas de historial de revisiones (registros de cambios de varias filas) justo al lado del campo REV actual, lo cual es una trampa obvia de falsos positivos. Las letras de referencia de la cuadrícula a lo largo del borde del dibujo podrían confundirse fácilmente con revisiones de una sola letra.

Por qué un enfoque totalmente basado en IA fue la elección equivocada

Podrías tirar todos los documentos a GPT-4 Vision y dar por terminado el día, pero a aproximadamente $0,01 por imagen y 10 segundos por llamada, es decir, $47 y casi 100 minutos de tiempo API. Más importante aún, estaría pagando por inferencias costosas en documentos donde unas pocas líneas de Python podrían extraer la respuesta en milisegundos.

La lógica era simple: si un documento tiene texto extraíble y el valor REV sigue patrones predecibles, no hay razón para involucrar un LLM. Guarde el modelo para los casos en los que fallen los métodos deterministas.

La arquitectura híbrida que funcionó

📷 [FIGURE 2: Pipeline architecture diagram] Canalización híbrida de dos etapas: cada PDF ingresa a la Etapa 1 (extracción basada en reglas de PyMuPDF). Si se devuelve un resultado confiable, va directamente al CSV de salida. De lo contrario, el PDF pasa a la Etapa 2 (GPT-4 Vision a través de Azure OpenAI).

Etapa 1: extracción de PyMuPDF (determinista, costo cero). Para cada PDF, intentamos una extracción basada en reglas utilizando PyMuPDF. La lógica se centra en el cuadrante inferior derecho de la página, donde se encuentran los bloques de título, y busca texto cerca de anclajes conocidos como “REV”, “DWG NO”, “SHEET” y “SCALE”. Una función de puntuación clasifica a los candidatos según su proximidad a estos anclajes y su conformidad con los formatos REV conocidos.

def extract_native_pymupdf(pdf_path: Ruta) -> Opcional[RevResult]: “””Pruebe la extracción de texto nativo de PyMuPDF con filtrado espacial.””” intente: best = process_pdf_native( pdf_path, brx=DEFAULT_BR_X, # umbral X inferior derecho bry=DEFAULT_BR_Y, # umbral Y inferior derecho blocklist=DEFAULT_REV_2L_BLOCKLIST, edge_margin=DEFAULT_EDGE_MARGIN ) si es mejor y mejor.valor: valor = _normalize_output_value(best.value) return RevResult( file=pdf_path.name, value=value, motor=f”pymupdf_{best.engine}”, confianza=”high” if best.score > 100 else “medium”, notes=best.context_snippet ) return Ninguno excepto Excepción: return Ninguno

La lista de bloqueo filtra los falsos positivos comunes: marcadores de sección, referencias de cuadrícula, indicadores de página. Restringir la búsqueda a la región del bloque de título reduce las coincidencias falsas a casi cero.

Etapa 2: GPT-4 Vision (para todo lo que falla la Etapa 1). Cuando la extracción nativa vuelve vacía, ya sea porque el PDF está basado en imágenes o porque el diseño del texto es demasiado ambiguo, representamos la primera página como PNG y la enviamos a GPT-4 Vision a través de Azure OpenAI.

def pdf_to_base64_image(self, pdf_path: Ruta, page_idx: int = 0, dpi: int = 150) -> Tupla[str, int, bool]: “””Convierta una página PDF a PNG base64 con manejo de rotación inteligente.””” rotación, debería_corregir = detectar_and_validate_rotation(pdf_path) con fitz.open(pdf_path) como doc: página = doc[page_idx]
pix = page.get_pixmap(matrix=fitz.Matrix(dpi/72, dpi/72), alpha=False) si rotación!= 0 y debería_corregir: img_bytes = correct_rotation(pix, rotación) return base64.b64encode(img_bytes).decode(), rotación, Verdadero en caso contrario: return base64.b64encode(pix.tobytes(“png”)).decode(), rotación, Falso

Nos decidimos por 150 DPI después de las pruebas. Las resoluciones más altas aumentaron la carga útil y ralentizaron las llamadas API sin mejorar la precisión. Las resoluciones más bajas perdieron detalles en los escaneos marginales.

Lo que se rompió en la producción

Sólo aparecieron dos clases de problemas cuando revisamos el corpus completo de 4.700 documentos.

Ambigüedad de rotación. Los dibujos de ingeniería se almacenan con frecuencia en orientación horizontal, pero los metadatos PDF que codifican esa orientación varían enormemente. Algunos archivos configuran /Rotate correctamente. Otros rotan físicamente el contenido pero dejan los metadatos en cero. Resolvimos esto con una heurística: si PyMuPDF puede extraer más de diez bloques de texto de la página sin corregir, la orientación probablemente esté bien independientemente de lo que digan los metadatos. De lo contrario, aplicamos la corrección antes de enviarla a GPT-4 Vision.

Alucinación inmediata. A veces, el modelo se aferraba a los valores de los propios ejemplos del mensaje en lugar de leer el dibujo real. Si cada ejemplo mostraba REV “2-0”, el modelo desarrollaba una tendencia a generar “2-0” incluso cuando el dibujo mostraba claramente “A” o “3-0”. Solucionamos esto de dos maneras: diversificamos los ejemplos en todos los formatos válidos con advertencias explícitas contra la memorización y agregamos instrucciones claras que distinguen la tabla del historial de revisiones (registro de cambios de varias filas) del campo REV actual (valor único en el bloque de título).

REGLAS CRÍTICAS – EVITE ESTAS: ✗ NO extraiga de las TABLAS DE HISTORIAL DE REVISIONES (columnas: REV | DESCRIPCIÓN | FECHA) – Queremos la REV ACTUAL del bloque de título (valor único) ✗ NO extraiga letras de referencia de la cuadrícula (A, B, C a lo largo de los bordes) ✗ NO extraiga marcadores de sección (“SECCIÓN CC”, “SECCIÓN BB”)

Resultados y compensaciones

Validamos con una muestra de 400 archivos con datos reales verificados manualmente.

MetricHybrid (PyMuPDF + GPT-4)Solo GPT-4Precisión (n=400)96%98%Tiempo de procesamiento (n=4730)~45 minutos~100 minutosCosto API~$10-15~$47 (todos los archivos)Tasa de revisión humana~5%~1%

La brecha de precisión del 2% fue el costo de una reducción del tiempo de ejecución de 55 minutos y costos limitados. Para una migración de datos en la que los ingenieros verificarían un porcentaje de los valores de todos modos, el 96 % con una tasa de marcado para revisión del 5 % era aceptable. Si el caso de uso hubiera sido el cumplimiento normativo, habríamos ejecutado GPT-4 en cada archivo.

Posteriormente comparamos modelos más nuevos, incluido GPT-5+, con el mismo conjunto de validación de 400 archivos. La precisión fue comparable a la del GPT-4.1 con un 98%. Los modelos más nuevos no ofrecieron ningún impulso significativo para esta tarea de extracción, con un mayor costo por llamada y una inferencia más lenta. Enviamos GPT-4.1. Cuando la tarea es la coincidencia de patrones con restricciones espaciales en una región de documento bien definida, el techo es el aviso y el preprocesamiento, no la capacidad de razonamiento del modelo.

En el trabajo de producción, el objetivo de precisión “correcto” no siempre es el más alto que se puede alcanzar. Es el que equilibra el costo, la latencia y el flujo de trabajo posterior que depende de su producción.

Del script al sistema

El producto inicial fue una herramienta de línea de comandos: aliméntela con una carpeta de archivos PDF y obtenga un CSV de resultados. Se ejecutó dentro de nuestro entorno Microsoft Azure, utilizando puntos finales de Azure OpenAI para las llamadas de GPT-4 Vision.

Después de que la migración inicial tuvo éxito, las partes interesadas preguntaron si otros equipos podrían utilizarla. Envolvimos la canalización en una aplicación web interna liviana con una interfaz de carga de archivos, para que los usuarios sin conocimientos técnicos pudieran ejecutar extracciones a pedido sin tocar una terminal. Desde entonces, el sistema ha sido adoptado por equipos de ingeniería en múltiples sitios de la organización, cada uno ejecutando sus propios archivos de dibujos para tareas de migración y auditoría. No puedo compartir capturas de pantalla por razones de confidencialidad, pero la lógica de extracción principal es idéntica a la que describí aquí.

Lecciones para practicantes

Comience con el método viable más barato. El instinto cuando se trabaja con LLM es utilizarlos para todo. Resístelo. La extracción determinista manejó del 70 al 80% de nuestro corpus sin costo alguno. El LLM solo agregó valor porque lo mantuvimos enfocado en los casos en los que las reglas no eran suficientes.

Valide a escala, no en muestras seleccionadas. La ambigüedad de rotación, la confusión en la tabla del historial de revisiones, la cuadrícula hace referencia a falsos positivos. Ninguno de estos apareció en nuestro conjunto de prueba inicial de 20 archivos. Su conjunto de validación debe representar la distribución real de los casos extremos que verá en producción.

La ingeniería rápida es ingeniería de software. El mensaje del sistema pasó por múltiples iteraciones con ejemplos estructurados, casos negativos explícitos y una lista de verificación de autoverificación. Tratarlo como texto desechable en lugar de un componente cuidadosamente versionado es la forma en que terminas con resultados impredecibles.

Mida lo que le importa a la parte interesada. A los ingenieros no les importaba si el oleoducto usaba PyMuPDF, GPT-4 o palomas mensajeras. Les importó que se procesaran 4700 dibujos en 45 minutos en lugar de cuatro semanas, con un costo de entre 50 y 70 dólares en llamadas API en lugar de más de £ 8000 en tiempo de ingeniería, y que los resultados fueran lo suficientemente precisos como para proceder con confianza.

El proceso completo consta de aproximadamente 600 líneas de Python. Ahorró cuatro semanas de tiempo de ingeniería, costó menos que un almuerzo de equipo en tarifas de API y desde entonces se ha implementado como herramienta de producción en múltiples sitios. Probamos los últimos modelos. No eran mejores para este trabajo. A veces, el trabajo de IA de mayor impacto no consiste en utilizar el modelo más potente disponible. Se trata de saber dónde pertenece un modelo en el sistema y mantenerlo allí.

Obinna es ingeniera sénior de datos e inteligencia artificial con sede en Leeds, Reino Unido, y se especializa en inteligencia de documentos y sistemas de inteligencia artificial de producción. Crea contenido sobre ingeniería práctica de IA en @DataSenseiObi en X y Wisabi Analytics en YouTube.