L'apprentissage automatique est la mauvaise façon d'extraire des données de la plupart des documents

Les documents ont passé des décennies à protéger obstinément leur contenu contre les logiciels. À la fin des années 1960, les premières techniques d'OCR (reconnaissance optique de caractères) transformaient les documents numérisés en texte brut. En indexant et en recherchant le texte de ces documents numérisés, les logiciels ont accéléré des projets de découverte et de recherche juridiques auparavant laborieux.

Aujourd'hui, Google, Microsoft et Amazon proposent une OCR de haute qualité dans le cadre de leurs offres de services cloud. Mais les documents restent sous-utilisés dans les chaînes d'outils logiciels et les données précieuses languissent dans milliards de PDF . Le défi est passé de l'identification du texte dans les documents à leur transformation en données structurées adaptées à une consommation directe par des flux de travail basés sur des logiciels ou à un stockage direct dans un système d'enregistrement.

L'hypothèse dominante est que l'apprentissage automatique, souvent qualifié d'"IA", est le meilleur moyen d'y parvenir, en remplaçant les techniques obsolètes et fragiles basées sur des modèles. Cette hypothèse est erronée. La meilleure façon de transformer la grande majorité des documents en données structurées est d'utiliser la prochaine génération de modèles puissants et flexibles qui trouvent des données dans un document comme le ferait une personne.

Les promesses et les échecs de l'apprentissage automatique

La promesse de l'apprentissage automatique est que vous pouvez entraîner un modèle une fois sur un grand corpus de documents représentatifs, puis généraliser en douceur à des mises en page de documents hors échantillon sans réentraînement. Par exemple, vous souhaitez former un modèle ML sur les polices d'assurance habitation des sociétés A, B et C, puis extraire les mêmes données de documents similaires émis par la société Z. Ceci est très difficile à réaliser en pratique pour trois raisons :

L'extraction de documents est une tâche inhabituellement granulaire pour l'apprentissage automatique

Votre objectif est souvent d'extraire des dizaines ou des centaines d'éléments de données individuels de chaque document. Un modèle au niveau de granularité du document manquera fréquemment certaines de ces valeurs, et ces erreurs sont assez difficiles à détecter. Une fois que votre modèle tente d'extraire ces dizaines ou centaines d'éléments de données à partir de types de documents hors échantillon, vous obtenez une explosion d'opportunités d'échec de généralisation.

Les éléments de données dans les documents ont généralement une relation hiérarchique les uns avec les autres

Alors que certains documents simples peuvent avoir une ontologie clé/valeur plate, la plupart auront une sous-structure : pensez à une liste de lacunes dans un rapport d'inspection de maison ou à l'ensemble des transactions dans un relevé bancaire. Dans certains cas, vous rencontrerez même des sous-structures imbriquées complexes : pensez à une liste de polices d'assurance, chacune avec un historique de sinistres. Soit vous avez besoin de votre modèle d'apprentissage automatique pour déduire ces hiérarchies, soit vous devez paramétrer manuellement le modèle avec ces hiérarchies et l'ontologie globale souhaitée avant la formation.

Un "document" est une cible vague pour un projet Ml

Un document est tout ce qui tient sur une ou plusieurs feuilles de papier et contient des données ! Les documents ne sont en réalité que des sacs de représentations de données diverses et arbitraires. Tableaux, étiquettes, texte libre, sections, images, en-têtes et pieds de page : vous le nommez et un document peut l'utiliser pour encoder des données. Il n'y a aucune garantie que deux documents, même avec la même sémantique, utiliseront les mêmes outils de représentation.

Il n'est pas surprenant que les projets d'analyse de documents basés sur ML puissent prendre des mois, nécessiter des tonnes de données à l'avance, conduire à des résultats peu impressionnants et, en général, être "exténuants" (pour citer directement un participant à un tel projet avec un fournisseur leader dans l'espace ).

Le défi avec des modèles

Ces problèmes suggèrent fortement que l'angle d'attaque approprié pour structurer les documents se situe au niveau de l'élément de données plutôt qu'au niveau du document entier. En d'autres termes, nous devons extraire des données de tables, d'étiquettes et de texte libre ; pas d'un « document » holistique. Et au niveau des éléments de données, nous avons besoin d'outils puissants pour exprimer la relation entre l'univers des modes de représentation trouvés dans les documents et les structures de données utiles aux logiciels.

Revenons donc aux modèles.

Historiquement, les modèles ont eu un moyen appauvri d'exprimer cette correspondance entre le mode de représentation et la structure des données. Par exemple, ils peuvent demander : allez à la page 3 et renvoyez tout texte dans ces coordonnées de boîte. Cela tombe en panne immédiatement pour un certain nombre de raisons, y compris si :

• un scan est incliné
• il y a une page de couverture, ou
• l'auteur du document a ajouté une section supplémentaire avant les données cibles.

Aucune de ces modifications mineures apportées à la mise en page du document ne dérangerait un lecteur humain.

Un langage de requête pour les documents

Pour qu'un logiciel structure avec succès des documents complexes, vous voulez une solution qui évite la bataille des projets ML de plusieurs mois contre les modèles fragiles. Au lieu de cela, construisons un langage de requête spécifique au document qui (le cas échéant) intègre ML au niveau de l'élément de données, plutôt qu'au niveau du document.

Tout d'abord, vous voulez des primitives (c'est-à-dire des instructions) dans le langage qui décrivent les modes de représentation (comme une paire étiquette/valeur ou des sous-sections répétitives) et restent résilientes aux variations de mise en page typiques. Par exemple, si vous dites :

"Trouvez une ligne commençant par ce mot et récupérez-en le montant le plus bas"

Vous souhaitez une reconnaissance des "lignes" résistante aux variations d'espaces blancs, à la gigue verticale, aux pages de couverture et à l'inclinaison des documents, et vous souhaitez une détection et un filtrage puissants des types.

Deuxièmement, pour les représentations de données avec un composant visuel ou de langage naturel, telles que des tableaux, des cases à cocher et des paragraphes de texte libre, les primitives doivent intégrer ML. À ce niveau d'analyse, Google, Amazon, Microsoft et OpenAI ont tous des outils qui fonctionnent assez bien dans le commerce.

Temps de valorisation en tant que North Star

Sensible adopte exactement cette approche : combiner des modèles puissants et flexibles avec l'apprentissage automatique. Avec SenseML , notre langage de requête basé sur JSON pour les documents, vous pouvez extraire des données structurées de la plupart des mises en page de documents en quelques minutes avec un seul échantillon de référence. Pas besoin de milliers de documents de formation et de mois passés à peaufiner les algorithmes, et pas besoin d'écrire des centaines de règles pour tenir compte des minuscules différences de mise en page.

La large gamme de primitives de SenseML vous permet de mapper rapidement des modes de représentation à des structures de données utiles, y compris des sous-structures imbriquées complexes. Dans les cas où les primitives n'utilisent pas ML, elles se comportent de manière déterministe pour fournir de solides garanties de comportement et de précision. Et même pour la sortie non déterministe de nos primitives alimentées par ML, telles que les tables, les règles de validation peuvent identifier les erreurs dans la sortie ML.

Cela signifie que l'analyse de documents avec Sensible est incroyablement rapide, transparente et flexible. Si vous souhaitez ajouter un champ à un modèle ou corriger une erreur, c'est simple.

Le compromis pour le délai de rentabilisation rapide de Sensible est que chaque mise en page de document significativement distincte nécessite un modèle distinct. Mais ce compromis s'avère pas si mal dans le monde réel. Dans la plupart des cas d'utilisation commerciale, il existe un nombre dénombrable de mises en page (par exemple, des dizaines de transporteurs routiers générant des confirmations de tarifs aux États-Unis ; une poignée de systèmes logiciels générant des rapports d'inspection à domicile). Nos clients ne créent pas des milliers de modèles de documents – la plupart génèrent une valeur considérable avec seulement quelques-uns.

Bien sûr, pour chaque formulaire fiscal, police d'assurance et vérification d'emploi largement utilisé, nous n'avons collectivement besoin de créer un modèle qu'une seule fois. C'est pourquoi nous avons introduit…

Bibliothèque open source de modèles prédéfinis de Sensible

Notre open-source Bibliothèque de configuration sensée est une collection de plus de 100 des mises en page de documents les plus fréquemment analysées, de polices d'assurance automobile à Formulaires ACORD , la perte court , les formulaires d'impôt , et Suite . Si vous avez un document d'intérêt général, nous ferons l'intégration pour vous et le mettrons ensuite gratuitement à la disposition du public. Il sera également gratuit pour vous d'utiliser jusqu'à 150 extractions par mois sur notre niveau de compte gratuit.

Nous pensons que cette approche hybride est la voie à suivre pour résoudre de manière transparente et efficace le problème de la transformation des documents en données structurées pour un large éventail de secteurs, notamment la logistique, les services financiers, les assurances et les soins de santé. Si vous souhaitez nous rejoindre dans ce voyage et connecter vos documents à un logiciel, planifier une démo ou Inscrivez-vous pour un compte gratuit !