Synthèse des opérateurs proposés

Cette section 6.3 a présenté rapidement comment construire automatiquement, grâce la compilation d’une description, un programme d’interprétation symbolique du contenu d’une page (dès lors qu’on dispose de détecteurs d’objets visuels primitifs), et a décrit en détail comment rendre interactif un tel programme.

L’approche que nous avons proposée est basée sur la décomposition d’un mécanisme de détection et correction d’erreur pour permettre son fonctionnent asychrone, dans des processus distincts. Les étapes de résolution d’un problème sont alors :

La détection d’erreur La détection automatique de problème peut être basée sur le constat d’une incohérence entre plusieurs données extraites, sur l’impossibilité de détecter un élément indispensable, sur la détection d’une construction problématique qu’on au- rait décrite, ou encore sur la détection d’un cas non prévu.

connaissances dans la description de la page, ce qui permet la mise en œuvre d’un mécanisme de détection automatique, spécifique au type de contenu interprété, qui générera des questions (avec l’opérateur raise_question) réclamant la connaissance manquante à l’environnement du module d’interprétation de page.

Si la détection automatique d’erreur n’est pas possible, le mécanisme d’interaction spontanéeautorise une détection (plus coûteuse à l’exécution, mais moins à la concep- tion) hors du module d’interprétation de page, grâce à l’opérateur spontaneous. La correction d’erreur Elle est toujours faite en fournissant au module d’interprétation de

page l’information qui lui manque, c’est à dire qui n’est pas dans l’image courante ou dans la connaissance à priori qu’il utilise. Cette correction impose de réviser partiel- lement l’interprétation proposée par le module d’interprétation de page à l’itération précédente. La réinterprétation de la page, et l’annotation des fragments de la des- cription qui pourront être ignorés avec l’opérateur raise_question, autorisent la mise en place d’une réintégration automatique de cette information pour faire progresser l’interprétation, sans perturber la façon de décrire le contenu d’une page.

La récupération sur erreur Cette étape optionnelle permet de faire progresser l’interpré- tation d’une page dans des parties indépendantes lorsqu’un problème est détecté, afin de générer plusieurs questions à chaque itération et accélérer le processus de correc- tion. L’opérateur catch_question permet au concepteur de structurer la description de la page en blocs qui peuvent être interprétés indépendamment.

Ces étapes essentielles sont gérées automatiquement grâce aux propriétés exprimées par les opérateurs que nous avons proposés. L’implémentation de ces derniers peut évoluer sans nécessiter de modification dans la description d’une page. Il est également possible de se servir du premier niveau de description pour ajouter facilement de nouveaux éléments, comme par exemple pour indiquer qu’un élément est indispensable dans la page :

indispensable(T, Rauto) −→

var zR

zR← acces_zone_recherche

catch_question(T,

Rauto| raise_question(zR, T, { txt : "Elément requis manquant [...]" }))

(6.54)

6.4 Conclusion

Dans ce chapitre, nous avons proposé des outils et des méthodes qui permettent de concevoir simplement un module d’interprétation de page qui s’intègre dans un mécanisme global et itératif d’interprétation, et échange de façon asynchrone des connaissances avec son environnement. Ces éléments sont facilement réutilisables, et ce à trois niveaux diffé- rents et relativement indépendants entre eux.

1. Les éléments de la section 6.1visent à donner des outils de niveau algorithmique permettant la mise en place d’une communication entre le module d’interprétation de page et son environnement. Elle décrit globalement la gestion de la mémoire visuelle qu’il est nécessaire de mettre en place pour pouvoir modifier le comportement du module en lui apportant de nouvelles données.

Ces éléments peuvent être repris par toute approche algorithmique, pour reprendre la terminologie duchapitre 4.

2. Les éléments de lasection 6.2constituent une formalisation rigoureuse d’un module d’interprétation de page minimaliste mais réaliste (car capable de retour arrière) gé- néré automatiquement par la compilation d’une description du contenu de la page. La formalisation de ce socle nous permet alors de spécifier précisément la gestion de la mémoire à mettre en œuvre.

Cette formalisation peut être utile à toute approche basée sur une description décla- rative, et générant une analyse guidée par le but.

3. Les éléments de lasection 6.3donnent un ensemble de propriétés utiles pour gérer automatiquement l’échange d’information entre le module d’interprétation de page et son environnement afin de faire progresser l’interprétation, grâce à l’expression de propriétés naturelles à propos du contenu des pages.

L’identification de ces propriétés pourra intéresser tout concepteur de système d’in- terprétation de documents, et les règles de compilation proposées pour les opérateurs permettent l’exploitation de ces mécanismes presque directement pour les approches basées sur une analyse guidée par le but.

Nous pensons en effet que les opérateurs proposés peuvent être adaptés à des ap- proches guidées par les données (dites« ascendantes ») à condition de mettre en œuvre une fonction conserver_resultat. La communauté de la compilation de langages dis- pose d’une littérature importante sur le sujet, ainsi que de représentations appropriées pour décrire les règles de compilation des opérateurs : construction monadiques, etc. La conception d’un module d’interprétation de page à l’aide des outils proposés au- torise la mise en place rapide de scénarios d’interprétation qui permettent de tirer profit d’informations contextuelles, ce qui facilite alors la production de résultats fiables, et li- mite l’effort de correction nécessaire, comme nous le verrons dans lechapitre 8. Dans la mesure où l’information contextuelle fournie concerne le contenu de l’image, et non des paramètres du système comme un seuil de binarisation par exemple, les opérateurs humains peuvent directement participer à l’apport d’information, de façon homogène aux processus automatiques, et surtout de façon complémentaire, car ils excellent particulièrement dans la production de résultats abstraits et riches en contexte.

— Validation —

Réalisation et exploitation d’un

système complet

Réalisation d’un système complet

Introduction

Dans la partie précédente de ce document, nous avons spécifié, dans lechapitre 5, l’ar- chitecture globale d’un système permettant l’interprétation contextuelle et assistée de fonds documentaire, basée sur un mécanisme d’interprétation itératif autorisant l’échange asyn- chroned’informations entre les parties du système. Dans lechapitre 6, nous avons ensuite montré comment il est possible de générer le programme d’un module d’interprétation de page, qui gère automatiquement l’échange d’informations avec son environnement, grâce à une extension simple et peu perturbante du langage de description des pages. Le système générique que nous avons proposé permet une diminution potentielle de l’effort de correc- tion manuel requis en post-traitement, pour des scénarios bien construits, sans augmenter la difficulté de la conception nécessaire à la spécialisation du système à un fonds documentaire donné.

Dans ce chapitre, nous allons montrer que nos propositions peuvent être appliquées pour réaliser un système complet, intégrant un certain nombre de modules de diverses origines, et que l’extension d’un module d’interprétation de page peut être effectivement réalisée selon nos recommandations.

Du point de vue des concepteurs et développeurs, notre travail a donc permis de combi- ner facilement les outils réalisés par différentes personnes sans perturber la description du contenu d’une page qui reste unitaire, ni le traitement page par page habituel. Le découpage automatique de l’interprétation de chaque page en plusieurs tâches, traitées par des modules divers communiquant de façon asynchrone, est déterminé par la connaissance disponible à propos des pages et du fonds, ainsi que par l’état des données à traiter.

Ce chapitre reprend la progression de la partie IIpour permettre une description glo- bale de la mise en œuvre du système, avant de se focaliser sur l’extension d’un module d’interprétation de page existant à l’aide de nos propositions.

– Lapremière sectiondressera donc un tableau large des modules mis en œuvre, les technologies utilisées, et indique les principaux auteurs afin de positionner plus clai- rement nos travaux. Elle permettra de donner une présentation générale des compo- sants utilisés dans les expérimentations qui seront présentées auprochain chapitre. – Laseconde sectionprésentera la méthode DMOS-P, qui permet la génération auto-

matique de modules d’interprétation de page, et comment nous avons complété cette méthode pour permettre la génération d’un nouveau type de module adapté à un mé- canisme d’interprétation global itératif.

7.1 Vision d’ensemble du système

Le système développé a respecté trois principes fondateurs.

1. Faciliter l’enchaînement de traitements simples, faciles à concevoir et à réaliser, qui peuvent être soit automatiques, soit impliquer des opérateurs humains. Certains trai- tements peuvent travailler sur des données unitaires (page, zone de page) mais beau- coup nécessitent de considérer un ensemble de données, en particulier si des opéra- teurs humains sont sollicités, et travaillent de façon asynchrone.

2. Permettre l’indexation et le regroupement des données produites dans différentes pages, pour autoriser des mécanismes de validation, de correction, d’apprentissage ou simplement une utilisation finale (recherche, principalement).

3. Autoriser l’interprétation en plusieurs passes de chaque image en limitant le surcoût en complexité de conception et en temps de calcul.

Intégrant dans notre démarche la contrainte liée à la quantité des données à traiter, nous nous sommes assez naturellement tournés vers des outils et méthodes dédiés à l’analyse massive de données, tels ceux utilisés par les moteurs de recherche récents. En particulier, nous nous sommes intéressés à des approches telles que « map-reduce » [31] permettant la répartition de calculs sur une grille de machines1_{en minimisant les transferts de données}2_;

ou à des bases de données autorisant une grande flexibilité dans le schéma utilisé [16]. Au niveau de l’architecture globale du système, le framework Apache Hadoop3 _dédié

à l’analyse distribuée de données (et utilisé par des sociétés telles que Yahoo! et Amazon) a été un des supports du projet.

Si notre utilisation de ces outils extrêmement performants n’a sans doute été que su- perficielle dans la mise en œuvre de ce système expérimental, pour des raisons de temps ou d’infrastructures disponibles, nous avons toutefois pris soin de conserver, dans notre dé- marche, la possibilité d’un passage à l’échelle en respectant le mode de conception associé à ces approches.