Cuando los documentos contraatacan

Página 1: Resumen de cuenta, dos columnas. Página 15: Misma cuenta, tres columnas, nombres de encabezado diferentes. Página 47: Un escaneo con una mancha de café. Página 89: La página de totales, que hace referencia a transacciones que extrajiste hace 70 páginas.

Esto es un único "documento".

Tu pipeline de extracción funciona de maravilla en él. Página por página, cada transacción aterriza en la columna correcta. Los importes se analizan limpiamente. Las fechas parecen correctas. Lo envías a producción.

Entonces llama contabilidad. Los créditos y débitos no cuadran. Tienen un desfase de 3.200 €. No porque una sola página estuviera mal, sino porque la página 12 usa comas para los decimales y la página 68 usa puntos. Tu analizador manejó ambos correctamente, de forma aislada. Juntos, produjeron dos interpretaciones diferentes de "1.234" y nadie se dio cuenta hasta que la ecuación de balance se rompió.

La extracción de páginas individuales puede ser perfecta mientras que el documento en su conjunto es basura.

Un documento, quince personalidades

Los documentos largos no son monolíticos. Son secciones unidas con diferentes diseños, diferentes calidades de escaneo y diferentes ideas sobre cómo deberían verse los números.

Un extracto bancario real de 120 páginas que procesamos tenía:

Cambios de diseño: - Páginas 1-10: Vertical, tabla de transacciones de dos columnas - Páginas 11-50: Horizontal, tres columnas con un saldo acumulado - Páginas 51-80: De vuelta a vertical, nombres de encabezado completamente diferentes - Páginas 81-120: Páginas de resumen con totales agregados

Variación de calidad: - Páginas 1-40: PDF nativo, capa de texto limpia - Páginas 41-60: Escaneado en algún momento, necesita OCR - Páginas 61-80: Escaneado con anotaciones manuscritas en los márgenes - Páginas 81-120: PDF nativo de nuevo

Sorpresas semánticas: - Tres cuentas separadas agrupadas en un solo extracto - Sub-extractos anidados dentro del extracto principal - Totales en la página 118 que hacen referencia a una transacción en la página 3

Cualquier sistema de extracción que trate esto como "un documento, una pasada" lo va a pasar mal. El diseño en la página 11 invalida las suposiciones de la página 1. La calidad del escaneo en la página 45 requiere una estrategia de extracción completamente diferente a la del PDF limpio de la página 5.

La pregunta no es "¿extrajimos cada página correctamente?". Es "¿extrajimos todo el conjunto de manera consistente?".

Qué sucede cuando no divides

El enfoque ingenuo es lanzar todo el documento a una sola pasada de extracción y esperar lo mejor. Esto es lo que realmente sucede:

Las ventanas de contexto se llenan. Incluso los modelos grandes se ahogan con 120 páginas de datos de transacciones. Empiezan a omitir filas alrededor de la página 40, silenciosamente. Sin error, sin advertencia. Simplemente faltan transacciones que solo salen a la luz cuando alguien ejecuta la conciliación.

La confusión del diseño se agrava. El modelo aprende el diseño de dos columnas de las páginas 1-10, luego se encuentra con tres columnas en la página 11. A veces se adapta. A veces fusiona dos columnas y produce transacciones fantasma con descripciones concatenadas. En la página 51, cuando el diseño cambia de nuevo, todo es impredecible.

Una mala página lo envenena todo. ¿Ese escaneo con mancha de café en la página 47? En una extracción de una sola pasada, un importe mal leído provoca una cascada. El saldo acumulado cambia, el modelo "corrige" las transacciones posteriores para que coincidan, y ahora tienes datos de apariencia plausible que son incorrectos de formas que no puedes detectar fácilmente.

La solución es la segmentación: dividir el documento en fragmentos coherentes, extraer cada uno de forma independiente y luego volver a ensamblar con validación cruzada entre segmentos.

Pero el diseño no es lo único que varía a lo largo de 120 páginas. La calidad física de las páginas también contraataca.

El escáner siempre gana

Los cambios de diseño son al menos lógicos. Alguien diseñó un formato de tres columnas para las páginas 11-50 y un formato de dos columnas para el resto. Puedes razonar sobre ello.

La calidad del escaneo es el caos.

Llega un extracto bancario de 120 páginas. Las páginas 1-40 son PDF nativo: capa de texto limpia, coordenadas perfectas, extraíble hasta el glifo. Luego llega la página 41 y la capa de texto desaparece. Alguien imprimió el extracto, lo escaneó de nuevo y fusionó el resultado. Ahora estás haciendo OCR sobre píxeles en lugar de leer texto de un documento estructurado.

Ese es el caso fácil. Esto es lo que realmente entra por la puerta:

La foto del teléfono. Alguien sostuvo su teléfono sobre el extracto en lugar de usar un escáner. El flash de la cámara quema la esquina superior derecha, exactamente donde vive el saldo de cierre. La imagen es nítida en el centro y borrosa en los bordes. Los reflejos sobreexpuestos crean manchas blancas que se tragan los dígitos. Detectamos esto midiendo las proporciones de píxeles sobreexpuestos y las manchas de brillo especular. Si más del 15% de una página está quemada, estás viendo una foto, no un escaneo.

La reliquia de fax a 75 DPI. Un extracto que pasó por una máquina de fax en algún momento de su vida. La resolución es tan baja que un "8" y un "6" son indistinguibles. Un "3" podría ser un "8". La confianza del OCR cae por debajo del 50%, y ahora estás adivinando los importes. A 75 DPI, la nitidez de los bordes colapsa. La magnitud del gradiente Sobel que marca 15+ en un escaneo limpio cae por debajo de 2.5. Los caracteres individuales dejan de tener bordes.

El sangrado de fondo. Un rodillo desgastado en el alimentador de documentos del escáner deja una franja gris en cada página. O peor: la tinta de la página anterior se transfirió durante la alimentación, y ahora la página 47 tiene texto fantasma de la página 46 mostrándose a través. El OCR no sabe qué capa de texto es la real. Extrae ambas, y de repente tienes transacciones fantasma que no existen.

La sección rotada. Las páginas 51-60 se escanearon en horizontal pero los metadatos del PDF dicen vertical. El texto está de lado. El OCR a veces puede manejar una rotación de 90 grados, pero ¿2-3 grados de inclinación por una página mal alineada en el alimentador? Eso convierte las líneas rectas de la tabla en líneas ligeramente curvas, y la alineación de columnas, eso de lo que depende tu lógica de extracción, se vuelve blanda.

El abismo de calidad dentro de un solo documento:

Este es el problema real. No es que algunos documentos sean malos escaneos. Es que la página 40 es prístina y la página 41 es terrible, en el mismo archivo. Tu pipeline necesita manejar ambos extremos y todo lo que hay en medio, y necesita saber, por página, cuánto confiar en lo que extrajo.

Aquí es donde los modelos de ML visuales se ganan el sueldo. El OCR tradicional mira caracteres individuales y adivina. Un modelo de visión ve la página completa: la estructura de la tabla, la alineación de las columnas, el contexto alrededor de ese dígito manchado de café. Puede leer "12.345,67 €" incluso cuando el punto decimal está oscurecido, porque entiende cómo se ve un extracto bancario, no solo lo que decodifican los glifos individuales.

El cambio del OCR a nivel de texto a la comprensión visual a nivel de página es lo que hace que los escaneos degradados sean sobrevivibles. Una reliquia de fax que derrota al reconocimiento de caracteres todavía tiene una estructura visible: filas, columnas, importes en posiciones predecibles. Un modelo de visión que ha visto miles de extractos bancarios puede extraer del patrón incluso cuando los píxeles son ásperos.

El campo minado de la ecuación de balance

Para los extractos bancarios, hay una ecuación implacable: start_balance + credits - debits = end_balance.

Cuatro términos. Infinitas formas de romperlos.

Referencias entre páginas. El saldo de apertura está en la página 1. El saldo de cierre está en la página 120. La ecuación abarca cada segmento, cada ejecución, cada cambio de diseño intermedio. Si cualquier segmento se extrae incorrectamente, la ecuación se rompe. ¿Pero cuál? Con 7 segmentos y 4.000 transacciones, encontrar los datos incorrectos es un problema en sí mismo.

Transacciones con salto de página. Una descripción de transacción abarca las páginas 47-48: - Página 47: "TRANSFERENCIA A ACME CORP" - Página 48: "REF: 12345 - PAGO DE FACTURA"

¿Una transacción o dos? Cuéntala dos veces y el saldo se rompe exactamente por el importe de una transacción. El tipo de error que parece plausible hasta que alguien audita. La solución es la superposición: cuando dividimos el documento en segmentos, las páginas límite se comparten entre ejecuciones adyacentes. Ambas ejecuciones ven la transacción, pero el agregador deduplica por coordenadas de página durante el reensamblaje. Solo sobrevive una copia.

Ruleta de configuración regional (locale). Mismo banco, mismo extracto: - Segmento 1: 1.234,56 € (coma decimal) - Segmento 2: 1,234.56 € (punto decimal)

Analiza ambos "correctamente" según su convención local y obtendrás dos números diferentes. A la ecuación de balance no le importan las convenciones. Solo ve que la suma es incorrecta.

Caos en la convención de signos. Banco A: los débitos son negativos. Banco B: todos los importes positivos, con una columna D/C separada. Banco C: débitos entre paréntesis, (1,234.56). La ecuación asume signos consistentes. Si la extracción no normaliza antes de sumar, los créditos cancelan los débitos y el extracto parece vacío.

La trampa de la tolerancia de 0,02 €. Un extracto de 120 páginas puede tener miles de transacciones, cada una analizada a partir de texto renderizado y con el riesgo de redondeo a nivel de fuente. Exigir una coincidencia exacta rechaza documentos válidos. Demasiada tolerancia oculta errores reales. 0,02 € es en lo que aterrizamos después de ejecutar datos de producción. Lo suficientemente ajustado para detectar errores, lo suficientemente holgado para sobrevivir al redondeo.

Estricto, luego inteligente, luego desesperado

Cuando estábamos construyendo el pipeline de validación de Holofin, intentamos ejecutar todas las correcciones a la vez. Enmascaraba problemas de calidad de datos. Documentos que deberían haber sido marcados pasaban sin problemas. Así que lo reconstruimos en tres etapas. El orden es el diseño.

Etapa 1: Estricto. Cada transacción debe tener una fecha de valor. Cada importe debe poder analizarse. La ecuación de balance debe mantenerse dentro de la tolerancia. Si el modo estricto pasa, los datos son de alta calidad y hemos terminado. La mayoría de los documentos limpios se detienen aquí.

Si el modo estricto falla, anotamos qué falló y continuamos.

Etapa 2: Normalización. Los datos se extrajeron limpiamente, pero las convenciones chocan entre segmentos. Separadores decimales mixtos: comas en el segmento 1, puntos en el segmento 3. Fechas ambiguas: 01/02/2024 podría ser el 2 de enero o el 1 de febrero dependiendo de la configuración regional del banco. Convenciones de signos que cambian entre segmentos. La normalización unifica esto antes de volver a ejecutar la comprobación de balance.

Etapa 3: Revisión humana. Cuando la automatización no puede resolverlo, el documento se marca para un operador. No "algo está mal, buena suerte", sino "segmento 4, páginas 41-60, los créditos son 3,20 € más altos de lo esperado. Empieza por ahí".

Por qué importa este orden: lo estricto primero preserva la calidad de los datos. Solo normalizamos cuando lo estricto falla. Solo involucramos a un humano cuando la normalización no es suficiente.

Ejecutar todo a la vez enmascararía problemas. Un documento que necesitaba revisión humana debe tratarse de manera diferente a uno que pasó el modo estricto. El orden es la señal de calidad.

Cuando la mayor parte del documento está bien

Has segmentado al monstruo de 120 páginas. Cada segmento se extrajo de forma independiente. Puntuaciones de calidad adjuntas por página. ¿Ahora qué?

Los segmentos deben convertirse en un solo documento de nuevo. Saldo de apertura del primer segmento, saldo de cierre del último, cada crédito y débito sumado a través de todos ellos. Luego, la ecuación de balance se ejecuta una última vez, no por segmento, sino a través de todo el conjunto.

Cuando pasa, has terminado. Cuando falla, la pregunta interesante es dónde.

Aquí es donde la mayoría de los pipelines toman la decisión equivocada. El saldo tiene un desfase de 3,20 €, por lo que se rechaza todo el documento. El operador vuelve a subir, re-extraer, re-validar, las 120 páginas, porque un segmento tropezó.

Esa es la respuesta incorrecta. En producción, la mayoría de los documentos son mayormente correctos.

Digamos que el segmento 4 de 7 tiene la discrepancia. Los otros seis segmentos están limpios, validados, conciliados, exportables. No los tiramos a la basura. Marcamos el segmento 4, resaltamos la discrepancia y dejamos que el operador resuelva el conflicto con el PDF fuente lado a lado. El buen trabajo se queda bien. El segmento malo recibe atención humana.

La fuente: un escaneo real de extracto bancario con cambios de calidad a mitad del documento

La extracción: las cajas delimitadoras rastrean cada valor hasta su fuente, incluso en páginas degradadas

El operador ve exactamente lo que necesita arreglo. No "tu documento falló", sino "segmento 4, páginas 41-60, los créditos son 3,20 € más altos de lo esperado, y la página 47 tuvo baja confianza de OCR (34%). Empieza por ahí".

Esa es la diferencia entre un pipeline que procesa documentos y uno que respeta el tiempo del operador.

Los principios que sobreviven a producción

Si estás construyendo algo similar, estas son las lecciones que se quedaron:

• Segmenta antes de extraer. Trata los cambios de diseño como límites, no como ruido.
• Mide antes de confiar. Las puntuaciones de calidad por página te dicen dónde es frágil la extracción.
• Valida entre segmentos, no solo dentro. Una página puede ser correcta mientras que el documento es incorrecto.
• Degrada con elegancia, en orden. Validación estricta primero. Normalización segundo. Revisión humana al final. El orden codifica la calidad.
• Registra todo lo que el usuario no pidió. Las correcciones del sistema son invisibles en la UI y visibles en el registro de auditoría.

Los extractos bancarios son la prueba de estrés, miles de transacciones, múltiples diseños, calidad de escaneo que cambia a mitad del documento y una ecuación de balance que exige perfección en todo ello. Si tu pipeline sobrevive a eso, las facturas de una sola página son un error de redondeo.

La extracción se resuelve en la página 1. La consistencia se resuelve en la página 120. Y el espacio entre ellas, los cambios de diseño, las manchas de café, las reliquias de fax, las convenciones de signos, es donde los pipelines ingenuos van a morir y la ingeniería cuidadosa se gana el sueldo.

Construye para el monstruo de 120 páginas desde el primer día. Los documentos de una sola página se cuidarán solos.