Un archivo TIFF en escala de grises colapsó una vez nuestra detección de texto. No tenía ningún defecto. Simplemente almacenaba 16 bits por píxel, y la mayoría del código de imagen espera 8.
Todo analizador en producción acumula archivos como este. Al evaluar si construir vs comprar analizador de documentos y decidir basar tu propio analizador de documentos en un LLM, esta publicación es un adelanto de lo que te espera en tu cola de soporte.
Puntos Clave
- Un prototipo de analizador de documentos sobre un LLM toma un fin de semana. Hacer que sobreviva a archivos reales de clientes toma años.
- La mayoría de los fallos ocurren antes de que el LLM vea el documento. Las fuentes asignan los caracteres incorrectamente, las cajas de página empiezan bajo cero, los escaneos usan píxeles de 16 bits y las marcas de agua se filtran en el texto.
- Un modelo más avanzado no soluciona estos errores; solo adivina mejor sobre una entrada que ya está defectuosa.
- La base de código de Parseur tiene un estimado de 150 a 300 correcciones para entradas raras del mundo real, construidas a lo largo de 4,588 commits desde 2015 y respaldadas por 294 archivos de prueba.
- Cada corrección comenzó con un archivo de cliente que falló. Un equipo que construye su propio analizador se encuentra con los mismos archivos a través de tickets de soporte individuales.
- Construye cuando los documentos provengan de unas pocas fuentes conocidas cuyo formato nunca cambie. Compra cuando provengan de clientes, proveedores y sus respectivos sistemas.
Un analizador de documentos en producción, en números
Lo que dejan atrás 11 años de archivos reales de clientes
- commits en la base de código de Parseur desde 2015
- 4,588
- de ellos, según nuestra estimación, solucionan entradas raras del mundo real
- 150 a 300
- archivos de prueba evitan que esos errores regresen
- 294
- documentos procesados, y todavía nos sorprenden
- 100M+
Por qué tu analizador de fin de semana falla con el primer archivo real de un cliente
Un analizador de documentos de fin de semana falla en archivos reales porque la parte difícil no es la IA, es todo lo que convierte un archivo en algo que la IA puede leer. El LLM recibe texto o píxeles. Si la fuente miente, la caja de página es extraña o el formato de imagen es inusual, el modelo lee basura y, de todos modos, responde con confianza.
Dónde falla un analizador de documentos
Los seis archivos en esta publicación rompieron el pipeline antes de que el LLM los viera
Paso 1
Archivo del cliente
PDF, escaneo o imagen, de cualquier remitente
Paso 2: dónde se rompieron los seis archivos
Convertir el archivo en texto y píxeles
-
Fuentes y codificaciones
Archivos 1 al 3: códigos (cid:72), letras dobles, una fuente que miente sobre su codificación
-
Geometría de página
Archivo 4: una caja de página que empieza bajo cero
-
Formatos de imagen
Archivo 5: un escaneo en escala de grises de 16 bits
-
Ruido
Archivo 6: una marca de agua DRAFT dentro del total
Paso 3
LLM
Lee lo que le entregue el paso 2, esté roto o no
Funcionó en tus archivos de prueba porque tus archivos de prueba eran simples y ordenados.
Los archivos reales de clientes son complejos y enredados. Llevamos solucionándolos desde 2015. Nuestra base de código cuenta con 4,588 commits, y estimamos que entre 150 y 300 de ellos solucionan entradas raras del mundo real. 294 archivos de prueba aseguran que esos errores no regresen, y muchos de ellos corresponden exactamente al documento del cliente que rompió el sistema.
Aquí están seis de nuestros favoritos.
El PDF muestra texto. La capa de texto no está de acuerdo.
Un PDF que muestra texto en pantalla no siempre almacena ese texto de una manera legible. Tres archivos lo demostraron.
1. (cid:72) significa "e", si le sumas 29
Algunos PDF no almacenan letras. Almacenan el número del dibujo de cada letra dentro de la fuente, un poco como el número de un asiento en un teatro. pdfminer, la biblioteca que usamos para leer texto de PDF, no puede convertir ese número nuevamente en una letra, por lo que devuelve un código como (cid:72).
El truco: muchas de estas fuentes enumeran sus dibujos en el mismo orden, el orden estándar de Mac. En esa lista, el espacio es el dibujo número 3. En ASCII, los números que las computadoras usan para las letras, el espacio es 32. A cada letra le falta el mismo valor de 29. Suma 29 a 72 y obtendrás 101, el número ASCII para la "e".
Sin esta corrección, el total de una factura se lee como una fila de códigos (cid:...). El LLM ve ruido y tiene que adivinar.
2. TToottaall
Algunas herramientas PDF dibujan cada carácter dos veces exactamente en el mismo lugar, probablemente para simular una fuente en negrita. En pantalla se ve bien. En la capa de texto, "Total" se convierte en "TToottaall".
La solución elimina cualquier carácter que se encuentre exactamente en la misma posición que otro. Simple, una vez que sabes que esto ocurre.
3. La fuente que miente sobre su propia codificación
El estándar PDF dice que una fuente TrueType mapea sus caracteres en UTF-16BE. Algunas fuentes reales afirman estar en UTF-8 en su mapa de caracteres. pdfminer les cree y lee basura.
Aplicamos un parche al propio pdfminer para ignorar esa afirmación y decodificar esas fuentes de la forma en que realmente fueron escritas. Una biblioteca de código abierto te brinda la especificación. Los parches encima de ella son tu trabajo.
¿Dónde empieza una página? No siempre en cero
4. Una página A4 válida que tiene 0 pt de alto
La caja de página de un PDF son dos esquinas: inferior izquierda y superior derecha. La mayoría de los PDF empiezan en el punto (0, 0), por lo que los últimos dos números resultan ser el ancho y el alto. El código que lee solo esos dos números funciona en casi todos los archivos.
Luego llegó un PDF con una caja de página de [0, -841.89, 595.28, 0]. Esa es una página A4 normal que empieza por debajo de cero. Si se lee de forma directa, tiene 0 pt de alto. Nuestra verificación de resolución rechazó el documento como inválido. Cualquier visor de PDF lo abre sin inmutarse.
Imágenes con más bits de los que planeabas
5. El escaneo de 16 bits
Volviendo al TIFF de la introducción. Sus píxeles usaban 16 bits de gris, y la conversión antes de la detección de texto del OCR se rompió. La solución convierte la imagen a 8 bits desde su propio rango de valores. Ese detalle importa. Algunos escáneres escriben datos de 12 bits en un archivo de 16 bits, y una conversión simple volvería todo el escaneo negro.
Ruido que se lee como texto
6. La marca de agua DRAFT que se une a la oración
Una marca de agua diagonal "DRAFT" (BORRADOR) también es texto. Sus letras se interponen entre las palabras reales, y el texto extraído puede convertirse en "Total DR 1,250.00 AFT". Tu LLM se esforzará mucho por darle sentido a eso.
La solución elimina los caracteres que están ligeramente rotados. El texto real se asienta de forma plana sobre la línea base. Una marca de agua suele estar inclinada.
El costo real de construir: tus clientes se convierten en tu suite de pruebas
Cada corrección anterior comenzó con un archivo del cliente que falló, y ninguna de ellas se puede encontrar leyendo únicamente la especificación de PDF. Un equipo que construye su propio analizador de documentos se enfrenta a los mismos archivos, en su propio orden, a través de sus propios tickets de soporte.
Cada uno ejecuta el mismo bucle: un usuario confundido, un archivo de muestra, horas para encontrar la causa, una solución y una prueba para que el error no vuelva a ocurrir. Ahora multiplícalo por unos cientos.
Un LLM no se salta ese bucle. Lee lo que le da la extracción. Cuando la extracción es incorrecta, el modelo se equivoca con confianza, y nadie se da cuenta hasta que un total cae en la columna equivocada. Nuestro artículo sobre LLMs para procesamiento de documentos cubre el lado del modelo de esa historia, y el debate de construir vs comprar analizador de documentos se vuelve crítico. Nuestra comparación de costos de construir vs comprar pone números en el lado de la ingeniería para facturas.
¿El próximo modelo no arreglará esto?
Los modelos mejoran cada pocos meses. Ninguna de las seis correcciones anteriores desaparecería. Un modelo más inteligente que recibe (cid:72) en lugar de una "e", o "DR 1,250.00 AFT" en lugar de un total, solo puede hacer una mejor conjetura. Tu proveedor de modelos ofrece una mejor capacidad de razonamiento, pero no te proporciona el pipeline de procesamiento de PDF.
Cuándo construir tu propio analizador es la decisión correcta
Constrúyelo cuando tus documentos provengan de unas pocas fuentes conocidas y su formato nunca cambie. Una exportación fija desde tu propio sistema es un buen ejemplo. El prototipo de fin de semana podría ser todo lo que siempre necesitarás.
Compra cuando los archivos provengan de clientes, proveedores y sus escáneres. Entonces, cada caso extremo que puedan enviar se convierte en tuyo, y llega en forma de ticket de soporte.
Tráenos tu peor archivo
Sí, vendemos un analizador de documentos, así que lee esta publicación con eso en mente. Los seis archivos anteriores siguen siendo reales, al igual que los tickets de soporte detrás de ellos.
Hemos procesado más de 100 millones de documentos, y todavía nos sorprenden. El próximo archivo raro en tu bandeja de entrada tiene muchas posibilidades de ser uno con el que ya nos hayamos encontrado.
Así que envíanos el archivo que rompió tu última herramienta. Si también rompe a Parseur, arreglarlo es problema nuestro.
Última actualización el
