Los documentos han pasado décadas protegiendo obstinadamente su contenido contra el software. A fines de la década de 1960, las primeras técnicas de OCR (reconocimiento óptico de caracteres) convirtieron los documentos escaneados en texto sin formato. Al indexar y buscar el texto de estos documentos digitalizados, el software aceleró proyectos de investigación y descubrimiento legal que antes eran laboriosos. Actualmente, Google, Microsoft y Amazon ofrecen OCR de alta calidad como parte de sus ofertas de servicios en la nube. Pero los documentos siguen estando infrautilizados en las cadenas de herramientas de software y los datos valiosos languidecen en . El desafío ha pasado de identificar texto en documentos a convertirlos en datos estructurados aptos para consumo directo por flujos de trabajo basados en software o almacenamiento directo en un sistema de registro. billones de archivos PDF La suposición predominante es que el aprendizaje automático, a menudo embellecido como "IA", es la mejor manera de lograr esto, reemplazando las técnicas obsoletas y frágiles basadas en plantillas. Esta suposición es equivocada. La mejor manera de es utilizar la próxima generación de plantillas poderosas y flexibles que encuentran datos en un documento como lo haría una persona. convertir la gran mayoría de los documentos en datos estructurados Las promesas y los fracasos del aprendizaje automático La promesa del aprendizaje automático es que puede entrenar un modelo una vez en un gran corpus de documentos representativos y luego generalizar sin problemas a diseños de documentos fuera de muestra sin volver a entrenar. Por ejemplo, desea entrenar un modelo ML en las pólizas de seguro de hogar de la empresa A, B y C, y luego extraer los mismos datos de documentos similares emitidos por la empresa Z. Esto es muy difícil de lograr en la práctica por tres razones: La extracción de documentos es una tarea inusualmente granular para el aprendizaje automático Su objetivo suele ser extraer docenas o cientos de elementos de datos individuales de cada documento. Un modelo en el nivel de granularidad del documento con frecuencia perderá algunos de estos valores, y esos errores son bastante difíciles de detectar. Una vez que su modelo intenta extraer esas docenas o cientos de elementos de datos de tipos de documentos fuera de la muestra, obtiene una explosión de oportunidades para fallas en la generalización. Los elementos de datos en los documentos suelen tener una relación jerárquica entre sí Si bien algunos documentos simples pueden tener una ontología clave/valor plana, la mayoría tendrá una subestructura: piense en una lista de deficiencias en un informe de inspección de una casa o el conjunto de transacciones en un extracto bancario. En algunos casos, incluso encontrará subestructuras anidadas complejas: piense en una lista de pólizas de seguro, cada una con un historial de reclamaciones. Necesita su modelo de aprendizaje automático para inferir estas jerarquías, o necesita parametrizar manualmente el modelo con estas jerarquías y la ontología general deseada antes del entrenamiento. Un "documento" es un objetivo vago para un proyecto Ml ¡Un documento es cualquier cosa que cabe en una o más hojas de papel y contiene datos! Los documentos son en realidad bolsas de representaciones de datos diversas y arbitrarias. Tablas, etiquetas, texto libre, secciones, imágenes, encabezados y pies de página: usted lo nombra y un documento puede usarlo para codificar datos. No hay garantía de que dos documentos, incluso con la misma semántica, utilicen las mismas herramientas de representación. No sorprende que los proyectos de análisis de documentos basados en ML puedan llevar meses, requieran toneladas de datos por adelantado, generen resultados poco impresionantes y, en general, sean "agotadores" (para citar directamente a un participante en uno de esos proyectos con un proveedor líder en el espacio). ). El desafío con las plantillas Estos problemas sugieren fuertemente que el ángulo de ataque apropiado para estructurar documentos está en el nivel del elemento de datos en lugar del nivel del documento completo. En otras palabras, necesitamos extraer datos de tablas, etiquetas y texto libre; no de un “documento” holístico. Y a nivel de elementos de datos, necesitamos herramientas poderosas para expresar la relación entre el universo de modos de representación que se encuentran en los documentos y las estructuras de datos útiles para el software. Así que volvamos a las plantillas. Históricamente, las plantillas han tenido un medio pobre de expresar ese mapeo entre el modo de representación y la estructura de datos. Por ejemplo, podrían indicar: vaya a la página 3 y devuelva cualquier texto dentro de estas coordenadas de cuadro. Esto se descompone inmediatamente por varias razones, incluso si: un escaneo está inclinado hay una portada, o el autor del documento agregó una sección adicional antes de los datos objetivo. Ninguno de estos cambios menores en el diseño del documento perturbaría a un lector humano. Un lenguaje de consulta para documentos Para que el software estructure con éxito documentos complejos, desea una solución que evite la batalla de los proyectos de ML de meses de duración frente a las plantillas frágiles. En su lugar, construyamos un lenguaje de consulta específico del documento que (cuando corresponda) incruste ML en el nivel del elemento de datos, en lugar del nivel del documento. En primer lugar, desea primitivas (es decir, instrucciones) en el lenguaje que describa los modos de representación (como un par de etiqueta/valor o subsecciones repetidas) y que se mantenga resistente a las variaciones de diseño típicas. Por ejemplo, si dices: "Encuentre una fila que comience con esta palabra y tome la cantidad en dólares más baja de ella" Desea un reconocimiento de "filas" resistente a la variación de espacios en blanco, la fluctuación vertical, las portadas y la inclinación de los documentos, y desea una detección y filtrado de tipos potentes. En segundo lugar, para las representaciones de datos con un componente visual o de lenguaje natural, como tablas, casillas de verificación y párrafos de texto libre, las primitivas deben incorporar ML. En este nivel de análisis, Google, Amazon, Microsoft y OpenAI tienen herramientas que funcionan bastante bien de serie. Tiempo para valorar como una estrella del norte adopta precisamente ese enfoque: combinar plantillas potentes y flexibles con el aprendizaje automático. Con , nuestro lenguaje de consulta para documentos basado en JSON, puede extraer datos estructurados de la mayoría de los diseños de documentos en minutos con una sola muestra de referencia. No hay necesidad de miles de documentos de capacitación y meses dedicados a ajustar algoritmos, y no hay necesidad de escribir cientos de reglas para tener en cuenta las pequeñas diferencias de diseño. Sensible SenseML La amplia gama de primitivas de SenseML le permite asignar rápidamente modos de representación a estructuras de datos útiles, incluidas subestructuras anidadas complejas. En los casos en que las primitivas no usan ML, se comportan de forma determinista para proporcionar un comportamiento sólido y garantías de precisión. E incluso para la salida no determinista de nuestras primitivas impulsadas por ML, como las tablas, las reglas de validación pueden identificar errores en la salida de ML. Lo que esto significa es que el análisis de documentos con Sensible es increíblemente rápido, transparente y flexible. Si desea agregar un campo a una plantilla o corregir un error, es sencillo hacerlo. La contrapartida del rápido tiempo de valorización de Sensible es que cada diseño de documento significativamente distinto requiere una plantilla separada. Pero esta compensación resulta no ser tan mala en el mundo real. En la mayoría de los casos de uso comercial, hay una cantidad contable de diseños (p. ej., docenas de transportistas que generan confirmaciones de tarifas en los EE. UU., un puñado de sistemas de software que generan informes de inspección de viviendas). Nuestros clientes no crean miles de plantillas de documentos; la mayoría genera un gran valor con solo unas pocas. Por supuesto, para cada formulario de impuestos, póliza de seguro y verificación de empleo ampliamente utilizados, colectivamente solo necesitamos crear una plantilla una vez. Es por eso que hemos presentado… Biblioteca de código abierto de plantillas prediseñadas de Sensible Nuestro código abierto es una colección de más de 100 de los diseños de documentos analizados con más frecuencia, desde a , , , y . Si tiene un documento que es de amplio interés, haremos la incorporación por usted y luego lo pondremos a disposición del público de forma gratuita. También será gratis para que lo use hasta 150 extracciones por mes en nuestro nivel de cuenta gratuita. Biblioteca de configuración sensible pólizas de seguro de auto Formularios ACORD carreras de pérdida formularios de impuesto más Creemos que este enfoque híbrido es el camino para resolver de manera transparente y eficiente el problema de convertir documentos en datos estructurados para una amplia gama de industrias, incluidas la logística, los servicios financieros, los seguros y la atención médica. Si desea unirse a nosotros en este viaje y conectar sus documentos al software, o ! programar una demostración Regístrese para obtener una cuenta gratuita
