Chapitre VII          Construction de systèmes de TA et support à la RI multilingue pour MUMIA

Résumé

Le corpus CLEF-IP 2011 contient 3,5 millions de documents de brevet ; il a été distribué dans le cadre du projet MUMIA. Nous en avons extrait les segments parallèles, et puis nous avons construit les mémoires de traductions correspondantes. Pour augmenter la quantité de segments multilingues, tout d’abord, nous avons filtré les fichiers XML pour supprimer les segments traduits, ensuite nous avons transformé les fichiers XML en format HTML, et les avons importé dans notre plate-forme SECTra_w/iMAG. Enfin, nous avons fait la post-édition pour l’élargissement à d’autres langues.

Introduction

VII.1      Contexte et motivations

VII.1.1      Description du projet MUMIA et du WG2

Le projet MUMIA  (EU COST Action) a pour but de construire et mettre en réseau une communauté de chercheurs travaillant dans le domaine de l’accès à l’information multilingue, multimodale, et multifacette, et plus particulièrement  aux documents de brevet. Il encourage la recherche et la communication de la technologie dans les domaines généraux de la traduction automatique, de la recherche d’information, et de l’accès multimodèle, multilingues à l’information interactive, visant à faciliter le développement de systèmes de recherche de prochaine génération.

Pour augmenter le synergie entre les communautés de RI et de TA, une série d'activités ont été organisées (par exemple réunion interdisciplinaire MUMIA GT à Tallinn et à Amsterdam, réunion WG/atelier ouvert à Hissar) pour discuter des ressources, et des outils linguistiques pour la recherche de développement des systèmes, et aussi pour soutenir la production des prochains systèmes de recherche multilingue.

Du point de vue de l'action COST MUMIA, la principale motivation de ces activités était d'accroître la communication entre les scientifiques RI/TAL/TA sur les problèmes et les défis principaux suivant : (1) le développement/l’aide/l'intégration des ressources et des outils linguistiques pour le développement des systèmes de RI, et (2) la clarification des ressources et des solutions technologiques pour la mise en œuvre de RI multilingue dans les systèmes de recherche professionnels modernes.

Par exemple, un progrès technologique est le travail sur la production de corpus parallèles de haute qualité et sur l'évaluation permanente basée sur les tâches de plusieurs systèmes de TA pour les brevets. Une vitrine des corpus parallèles développés en utilisant la MT de CLEF-IP est disponible sur la page web de MUMIA. L’autre exemple est l'intégration de divers services de TA pour soutenir la recherche multilingue dans un système fédératif de RI sur les brevets (PerFedPat).

L’Action MUMIA COST contient cinq groupes de travail (GT) (Integrating and Managing Language Resources, Processing Infrastructures for IR and MT, User Centered Aspects of MUMIA, Semantic Search and Faceted Search, Visualization, Distributed and Social Search). J’ai participé au WG2. L'objectif de ce groupe de travail est l'étude de nouvelles infrastructures pour la recherche plus efficace dans les grands environnements numériques.

VII.1.2      PerFedPat et Khresmoi

Le système PerFedPat (Salampasis and Hanbury, 2014), basé sur le cadre ezDL, fournit des services basiques de RI en utilisant une méthode qui fédère l’accès à de multiples systèmes (en ligne) de RI concernant les brevets (actuellement Espacenet[1], Google Patents, PATENTSCOPE[2] et MAREC[3]), et qui repose sur un accès parallèle à de multiples sources de brevet.

PerFedPat cache la complexité à l'utilisateur qui utilise un outil unique pour interroger tous les ensembles de données de brevets. PerFedPat fournit des services comme la recherche par champ, la fusion, le regroupement et le filtrage des résultats. Il offre un soutien pour l'historique de la requête en cours et des sessions de recherche. La deuxième caractéristique innovante de PerFedPat est qu'il a une architecture enfichable (par plugins) et extensible.

 

Description : Mavericks:Users:lingxiaowang:Desktop:Capture decrain:Capture d’écran 2015-06-09 à 16.16.15.png

Figure 33 : Architecture de PerFedPat[4]

Actuellement les outils intégrés concernent la recherche CIB (Classification internationale des brevets), la navigation à facettes, le regroupement des résultats de la recherche et la TA des requêtes. Le système est disponible en téléchargement à partir d'Internet[5].

KHRESMOI[6]  (Hanbury et al., 2011) est un système de recherche multilingue/multimodèle, et d’accès d’information pour l’information biomédicale, construit dans le cadre du projet éponyme KHRESMOI. KHRESMOI utilise des données disponible en ligne, comme les sites de santé certifiés par Health on the Net[7] et des revues en accès ouvert.

Description : Mavericks:Users:lingxiaowang:Desktop:Capture d’écran 2015-09-11 à 16.11.43.png

Figure 34 : KHRESMOI

VII.1.3      Objectif poursuivi

Nous travaillons pour supporter la recherche en RI multilingue sur les brevet. Les systèmes de recherche existant, comme PerFedPat et KHRESMOI, utilisent des systèmes de TA pour réaliser la fonction de recherche en contexte multilingue. La qualité du système de TA détermine la qualité du résultat de la recherche. Par exemple, PerFedPat utilise GT pour traduire les requêtes, mais le résultat n’est pas satisfaisant, et il est impossible d’améliorer la qualité de traduction.

Un document de brevet contient des « segments multilingues » au sens défini plus haut (p.21) : un élément XML correspondant à un segment contient ses versions en plusieurs langues). Si nous pouvions construire des systèmes de TA (STA) avec ces segments parallèles, nous pourrions améliorer la qualité de la RI translingue. C’est ce que nous avons fait.

VII.2      Construction de MT et de STA à partir des corpus CLEF-IP 2011

VII.2.1      Description du corpus CLEF-IP

La collection CLEF-IP contient des brevets, physiquement stockés comme une collection de fichiers XML encodant des documents de brevets. Un document de brevet peut être un document de demande de brevet, un rapport de recherche, ou un document de brevet accordé. À chaque document de brevet est attribué un code de type, qui apparaît comme un suffixe attaché à l'identifiant du brevet (par exemple, EP-nnnnnnn-A1, WO-nnnnnnnnnn-A2). Dans le cas de l'OEB (EPO), les documents de demande de brevet qui incluent un rapport de recherche portent le code A1, les rapports de recherche de demandes de brevet portent le code A3, les documents de brevets accordés portent le code B1, etc.[8].

La collection de données CLEF-IP 2011 est basée sur les données de 2010, et est extraite à partir du corpus de données MAREC. La collection CLEF-IP contient principalement des documents brevets publiés par l'OEB (EPO).

Deux ajouts importants ont été apportés au corpus de la collection 2010. Le premier a été d'inclure dans le corpus distribué certains brevets publiés par l'Organisation mondiale de brevets intellectuels OMPI (WIPO). Un pourcentage élevé des brevets de l'OEB (EPO) figurant dans le corpus CLEF-IP sont des demandes de brevet déposées à l'échelle internationale dans le cadre du Traité de coopération en matière de brevets (PCT), auquel cas l'OEB ne republie pas la demande de brevet en totalité, mais seulement une entrée bibliographique faisant référence à la demande originale. Pour ces brevets, CLEF-IP 2011 a ajouté leur équivalent de l'OMPI à la collection, afin de fournir une collection qui soit à la fois plus grande et plus réaliste. Le deuxième ajout à la collection CLEF-IP concerne l'une des nouvelles tâches basées sur les images contenues dans les brevets, à savoir la tâche de recherche basée sur les images des brevets. Pour cette tâche, nous avons ajouté à la collection cible CLEF-IP les images des brevets pour trois classes d'ICP: A43B, A61B, et H01L.

Dans nombre de documents, ajouter les documents de brevets de l'OMPI (WIPO) au corpus de la collection l'a augmentée de 1,2 million de documents de brevets, arrivant à un nombre final d'environ 3,5 millions de documents XML, correspondant à environ 1,5 million de brevets. Les images correspondant aux 47 000 documents XML dans les trois classes de la CIB (ICP) dans la tâche Img Pac occupent 5,4 Go, pour 290 880 fichiers TIFF.

Comme dans les années précédentes, le corpus de la collection de test a été livré aux participants sans fusionner les documents relatifs à un même brevet en un seul document. Chaque brevet est identifié par un numéro de brevet unique, une chaîne identifiant le bureau éditeur («EP» pour l'OEB et «WO» pour l'OMPI), suivie par une série de chiffres. Pour chaque brevet, il y a un répertoire contenant les documents XML représentant les documents de brevet liés à ce brevet. Pour les brevets de l'EP, le format du nom est 00000n/nn/nn/nn/*.xml, où la séquence de chiffres dans le nom du répertoire correspond à celle du nom du brevet. Pour les brevets WO, le format du nom est 00000n/nn/nn/nn/*.xml, où les 4 premiers chiffres (après « 00 ») représentent l'année de publication du document.

Par exemple, le brevet EP 09 81 2 01 correspond aux répertoire contenant les fichiers EP-0981201-A2.xml, EP-0981201-A3.xml, et EP-0981201-B1.xml:

EP/000000/98/12/01

Au brevet WO 1994030029 correspond le répertoire contenant le fichier WO-1994030029-A1.xml:

WO/001994/03/00/29 → WO-1994030029-A1.xml

Les fichiers d'images des brevets sont stockés comme des fichiers TIF dans un dossier séparé, la correspondance entre le fichier d'images et son fichier XML est établie par un petit ensemble de règles.

Tous les documents textuels de la collection CLEF-IP contiennent les principaux champs XML suivants: données bibliographiques, des résumés, résumé et revendications. Tous les documents n'ont pas nécessairement de contenu dans ces champs. Le contenu des différents champs XML peut être de l'anglais, de l'allemand ou du français. Certains champs peuvent apparaître plus d'une fois, chaque fois avec une langue différente. Un fichier de brevet XML a également une langue du document (anglais, allemand ou français), ce qui n'exclut pas que ses sous-champs apparaissent avec un attribut de langue différent de la langue du document. Par exemple, les documents de brevet EP (EP-nnnnnnn-Bn.xml) accordé doivent contenir les revendications en trois langues (anglais, allemand et français).

La dernière version de la collection est la même que celle utilisée dans le CLEF-IP 2011 lab (le corpus de données utilisé en 2012 et 2013 est le même que celui utilisé en 2011), de sorte que notre travail est basé sur la collection CLEF-IP 2011.

Figure 35 : Exemple de fichier XML Dans CLEF-IP

VII.2.2      Extraction de MT à partir de CLEF-IP 2011 (3 p.)

VII.2.2.1      Analyse du corpus (1 p.)

Nous avons analysé les brevets en ce qui concerne la structure de leurs champs XML. Nous avons constaté que quatre grands champs peuvent avoir des segments parallèles: <invention-title>, <abstract>, <description>, et <claims>. Chaque champ peut avoir des sous-champs, par exemple, un champ <claims> peut contenir 6 sous-champs <claim> dans EP-0260000-B1.xml (Figure 36).

Figure 36 : Exemple de champ <claims> contenant 6 sous-champs <claim> dans EP-0260000-B1.xml

Nous commençons par ces champs, en cherchant des champs qui apparaissent plus d'une fois dans le document de brevets et tels que chaque champ ait un attribut de langue différente. Par exemple, Figure 37 montre un champ <invention-title> avec 3 attributs de langue différents (lang = "DE", lang = "EN", et lang = "FR"). Chaque champ contient également du contenu, dans la langue qui correspond à son attribut.

Figure 37 : Exemple d'un champ <invention-title> avec 3 attributs de langue différents et les contenus correspondants en 3 langues différentes

Il est bien connu que les corpus parallèles ont aussi un problème avec la direction de la traduction, car la relation de traduction est symétrique au niveau des termes, mais pas des phrases. Si une MT contient des directions de traduction différentes, cela affecte directement notre travail. Lorsque nous traitons la collection CLEF-IP 2011, nous devons donc également tenir compte de la langue source de chaque document de brevet. Chaque document XML de CLEF-IP 2011 comporte une indication de sa langue de départ. Par exemple, la Figure 38 montre un document de brevet en langue anglaise. Au cours de notre processus d'extraction, nous considérons la langue du document comme état la langue source de tous ses segments.

Figure 38 : Un champ <patent-document> avec attribut lang = "EN"

VII.2.2.2       Traitement du corpus (1 p.)

(Utiyama and Isahara, 2007) ont utilisé les parties du champ de description "description détaillée des modes de réalisation préférés" (Detailed Description of the Preferred Embodiments) et "Contexte de l'invention" de chaque brevet pour trouver des segments parallèles (japonais-anglais), car ils ont constaté que ces deux parties ont plus de traductions que d'autres. Parce qu'ils avaient moins de paires de brevets, (Lu et al., 2009) ont utilisé toutes les parties des documents de brevet pour trouver des segments parallèles (chinois-anglais). Dans notre travail, nous avons extrait toutes les parties des documents de brevet, mais dans le but d'assurer la qualité du corpus parallèle, nous avons rendu le champ <invention-title> et les parties <claims> disponibles dans la première version du corpus parallèle CLEF; les autres parties du corpus parallèle seront disponibles dans la prochaine version.

Notre travail est basé sur 3,5 millions de documents de brevet (fichiers XML), et nous voulons en extraire autant de segments parallèles utiles que possible. Tout d'abord, nous parcourons chaque document de brevet. Pour chaque document de brevet, nous sélectionnons la langue source à partir du champ <patent-document>, selon l'attribut de langue de ce champ. Deuxièmement, nous recherchons les segments parallèles contenus dans les quatre champs principaux (<invention-title>, <abstract>, <description>, et <claims>). Parfois, certains champs ont un attribut de langue différent de la langue du document. Par exemple, dans EP-0260000-B1.xml, l'anglais est la langue du document, mais <claims> segments ne existent pas en anglais, seules les versions allemandes et françaises sont disponibles. Même s'il est toujours souhaitable de collecter autant de texte que possible, il est encore plus important de veiller à la qualité des textes, de sorte que, dans ce cas, nous ne stockons pas les parties en allemand et en français comme un segment parallèle, parce que nous ne savons pas laquelle est la source.

Tous les champs qui apparaissent plus d'une fois dans un document de brevet et qui ont différents attributs de langue sont traités comme une collection. En général, un document de brevet OEB (IPO) a un maximum de 3 langues (anglais, français et allemand). Nous avons choisi comme segment source un segment dont l'attribut langue est compatible avec la langue source, puis avons ensuite extrait le segment parallèle cible à partir des autres champs. Par exemple, dans EP-0301015-B1.xml, la langue source est l'anglais, et <revendications> champ apparaît 3 fois. Donc, nous utilisons la partie anglaise des champs de revendications comme segments source, et nous considérons les parties en français et en allemand comme les segments cibles. Le segment source et les segments cibles sont ensuite stockés séparément dans des fichiers différents. Dans l'exemple ci-dessus, le segment source a été stocké dans CLEF_claims_en-fr.en et CLEF_ claims_en-de.en, et les segments cibles dans CLEF_ claims_en-fr.fr et CLEF_claims_en-de.de, respectivement. Afin de réduire le bruit dans les données, nous ne gardons que le texte extrait, et enlevons toutes les balises.

Toutes les données extraites ne sont pas entièrement adaptées à une utilisation directe pour les applications de TAL (NLP). Nous devons nettoyer les données extraites et éliminer un peu de bruit. Pour l'alignement, nous avons utilisé LF Aligner[9], un outil open-source basé sur Hunalign (Varga et al., 2007) développé par András Farkas, qui, surtout, a la couverture linguistique la plus large (un total de 32 langues), et permet la génération automatique des dictionnaires dans une combinaison quelconque de ces langues. Les segments alignés sont préparés de façon bilingue pour 4 types (titre, résumé, description et revendications), et toutes les 6 paires de langues (de_en, de_fr, en_de, en_fr, fr_de, fr_en).

Le Tableau 56 montre le nombre de segments et de mots qui sont extraits à partir des champs de titre et de revendications en source et en cible après l'alignement des segments. Toutes les phrases parallèles extraites sont enregistrées dans les formats TMX et TXT, et peuvent être trouvées à http://membres-liglab.imag.fr/wang/downloads.  

Tableau 56 : Nombre de segments extraits comme source et cible après l'alignement de segments dans les champs <title> et <claims>

Pairs de langues

Titre

Revendications

Segments

Mots

Segments

Mots

de-en

De

311,298

2,038,785

1,696,498

62 M

En

2,582,703

71 M

de-fr

De

311,184

2,036,112

1,661,419

79 M

Fr

2,482,257

86 M

en-de

En

884,759

6,661,481

5,218,024

332 M

De

5,508,289

296 M

en-fr

En

884,727

6,661,322

5,373,452

330 M

Fr

8,538,012

380 M

fr-de

fr

106,211

963,508

572,356

36 M

de

1,204,439

37 M

fr-en

fr

106,246

1,285,467

586,498

38 M

en

1,048,374

37 M

VII.2.3      Construction des systèmes de TA (2 p.)

Nous avons utilisé notre corpus parallèle extrait (le titre et les champs de revendication) pour construire des systèmes de TA avec le Toolkit Moses. Tout d'abord, pour la préparation de l'ensemble du développement et de l'ensemble de test, nous avons extrait 2000 phrases pour la le réglage des poids de fonctionnalités de Moses, et extrait 1000 phrases pour les tests. Ensuite, nous avons utilisé le reste pour former les modèles de traduction de Moses. Nous avons en fait construit des systèmes de TA pour seulement 3 directions: de-fr, de-fr, et en-fr.

Les systèmes comprennent également des modèles de langage 5-grammes formés sur le côté cible correspondant des textes parallèles à l'aide de IRSTLM. Les poids de fonctionnalités requises par le décodeur de Moses ont encore été déterminés avec MERT en optimisant les scores BLEU sur l'ensemble de développement (1000 phrases). Les ensembles de test ont été traduits par les systèmes qui en résultent et ensuite utilisés pour évaluer les systèmes en termes de scores BLEU, comme indiqué dans Tableau 57.

Tableau 57 : Scores BLEU des systèmes de TA tirés de CLEF-IP

Paires de langues

Jeu de développement

Jeu de test

de-en

37.46

31.67

de-fr

35.41

28.72

en-de

43.16

36.01

en-fr

42.59

38.82

fr-en

44.12

42.61

fr-de

34.85

30.14

 

VII.3      Expérimentation et élargissement à d'autres langues

VII.3.1      Reconstruction de trois sites Web de brevets monolingues

Le corpus de brevets CLEF-IP contient certain nombre segments monolingues, par exemple, dans la Figure 39, ce fichier XML est en anglais (dans la balise <document>, l’attribut de langue est lang=EN“), et son titre anglais est traduit en français et en allemand, mais le champ <claims> n’est pas traduit. CLEF-IP contient environs 500K fichiers monolingues.

 

Description : Mavericks:Users:lingxiaowang:Desktop:QQ截图20150630152513.jpg

Figure 39 : Exemple de fichier XML monolingue

L'expression des phrases du document de brevet est très similaire dans un document, et beaucoup de mots-clés sont présentés plusieurs fois. Par exemple, nous voyons les revendications du fichier XML EP0203923B1.xml. Chaque revendication dans le champ <claims> change quelques mots entre eux, mais la structure de phrase est presque la même.

 

Clavier à touches capacitives selon la R1 caractérisé en ce que le choix de fréquences élevées (supérieures à 500 KHz) pour les oscillateurs de touche permet un fonctionnement fiable jusqu'à une épaisseur de la paroi diélectrique (2) atteignant 30 mm de verre courant.

Clavier à touches capacitives selon les R1, R2, R3 caractérisé en ce qu'un réglage immédiat et simple permet d'adapter le fonctionnement du clavier à l'épaisseur de la paroi diélectrique (2).

Clavier à touches capacitives selon les R1 et R2 caractérisé en ce que la circuiterie associée aux touches comprend un compteur d'adresse, un décodeur et les oscillateurs, et peut être reliee au microprocesseur par un câble limité à 5 fils et pouvant atteindre 10 mêtres de longueur.

Figure 40 : Exemple de revendication dans le fichier EP0203923B1.xml

Un système de TA entraîné avec notre MT pourra fournir des traductions de haute qualité, ce qui facilitera beaucoup la post-édition des segments ne contenant pas leur version dans la langue cible.  Nous avons post-édité les segments monolingues et bilingues (nous avions 3 langues au total) pour agrandir la MT.

D’abord, nous filtrons les fichiers XML du corpus CLEF-IP, et utilisons JSoup[10] pour analyser la langue source. Nous trouvons la langue dans le champ <document>. Ensuite, nous cherchons les balises qui contiennent l’attribut lang, et où la valeur de l’attribut lang est différente de la langue source du document. Enfin, nous supprimons les balises et leurs contenus. Par exemple, dans le fichier EP-0000004-B1.xml, l’attribut lang dans le champ <document> est l’anglais. Les trois champs <title> sont en anglais, en français, et en allemand, et le champ <claims> (revendications) est en anglais. Donc nous supprimons le champ <title> en français et en allemand, et conservons le champ <claims>.

Après le prétraitement, il faut adapter nos fichiers XML monolingues à SECTra_w/iMAG. Le fichier XML doit avoir l’aide de l’outil pour la visualisation de contexte. Nous le transformons au format HTML. Pour conserver la structure XML du document de brevet, nous reconstruirons les balises du fichier XML, et nous utilisons les balises HTML/CSS pour décorer les balises XML (avec les couleurs et le style). Dans le Figure 41, on donne un exemple de fichier XML monolingue présenté en format HTML.

Description : Mavericks:Users:lingxiaowang:Desktop:QQ截图20150630152513.jpg

Figure 41 : Exemple de fichier HTML décoré

VII.3.2      Accès multilingue en utilisant les systèmes de TA créés

Nous avons construit 3 sites Web pour les fichiers monolingues, et chaque site Web contient tous les fichiers monolingues traités. Nous avons aussi créé 3 iMAG dédiées à ces 3 sites Web monolingues. Dan Figure 42, Le site Web anglais est présenté dans AXiMAG. Ces 3 iMAG dédiées partagent la MT CLEF-IP. Nous importons les segments parallèles dans la MT CLEF-IP. Quand une iMAG dédiée à un site Web monolingue de CLEF-IP (une page Web monolingue) est accédée par l’utilisateur, l’iMAG d’abord cherche d’abord sa traduction dans la MT CLEF-IP. Si elle existe, il l’affiche dans la page Web traduite, sinon elle appelle nos systèmes de TA via Tradoh.

Par exemple, le page Web xxxxxxxx est traduit de l’anglais vers le français, le champ <title> a déjà traduit par l’ONU, donc iMAG a trouvé sa traduction dans la MT. Dans Figure 43, les segments avec les balises vertes sont trouvé dans la MT. S’il n’y pas de traduction dans la MT, notre système de TA fournis la traduction. Les segments avec les balises rouges sont traduits par le système de TA.

 

Figure 42 : Interface de iMAG CLEF

Nous avons entraîné 3 systèmes de TA (anglaisfrançais, françaisanglais, et allemandfrançais) en utilisant les MT extraites du corpus CLEF-IP. Pour fournir le service de traduction, nous avons intégré le plugin Moses dans Tradoh, puis traduit les segments monolingues.

Dans Figure 43, nous pouvons voir le résultat du système de TA CLEF-IP (anglaisfrançais). Ce résultat est plus proche le segment de MT.

 

Figure 43 : Traduction du système de TA CLEF-IP anglaisfrançais

 

VII.3.3      Accès multilingue utilisant d'autres systèmes et pour d'autres langues

Sur SECTra, nous pouvons ajoutons des différents systèmes de TA pour traduire les segments source. Il nous aide à évaluer la qualité des différents systèmes de TA.

VII.3.3.1      Comparaison sur les mêmes langues

Pour comparer la qualité du système de TA sur les même langues, nous utilisons GT à retraduire les 3 sites Web monolingues Les segments traduits sont sauvegardés dans la MT CLEF-IP, et ils sont présentés dans SECTra.

Description : Mavericks:Users:lingxiaowang:Desktop:Capture d’écran 2015-10-21 à 02.57.17.png

Figure 44 : PE en mode avancé, avec pseudo-trace montrant les différences entre les sorties de TA, la post-édition (utilisée comme référence), et la MT.

Dans le carré rouge de la Figure 44, il y a 4 segments. Le premier segment (A) est la post-édition de l’utilisateur, le deuxième segment (B) est la MT de CLEF-IP, le troisième (C) est la traduction du système de TA entraîné avec la MT CLEF-IP, et le dernier (D) est la traduction de GT. Quand on clique sur le bouton « Trace », la distance entre les segments et la  référence peut être affiché dans la colonne « Suggestion ».

On remarque que le résultat de traduction de GT ne correspondant pas au segment source (Figure 43). Il est très différent de la référence. Si l’utilisateur fait la post-édition sur ce résultat, il aura besoin de plus de temps.

VII.3.3.2      Utilisation pour d'autres langues

Nous ajoutons les nouvelles langues dans la MT de CLEF-IP. Nous utilisons GT et les systèmes de TA pour traduire les segments monolingues vers d’autres langues.

Les pages Web sont segmentées, puis leurs segments sont sauvegardés dans la MT. Pour ajouter un nouveau système de TA ou ajouter une nouvelle langue, nous retraduisons tous les segments sous SECTra. Par exemple, pour ajouter la traduction chinoise, on coche notre système de TA françaischinois MosesLIG dans la colonne « MTs ». La Figure 45 montre comment nous retraduisons les segments du français vers le chinois dans le pseudo-document DOC6.

Description : Mavericks:Users:lingxiaowang:Desktop:Capture d’écran 2015-06-29 à 09.59.11.png

Figure 45 : Retraduction des segments du français vers le chinois pour DOC6 avec le système de TA françaischinois MosesLIG

VII.3.3.2.1Méthode

SECTra_w/iMAG a créé le pseudo-document pour chaque fichier CLEF-IP,

VII.3.3.2.2Expérimentation sur le chinois

Automatiquement, en incluant les PE de Wu Jian et Cheng Shi).

Performances des STA construits.

 

Conclusion


 


 



[1] http://worldwide.espacenet.com

[2] http://www.wipo.int/patentscope/fr/

[3] http://www.ifs.tuwien.ac.at/imp/marec.shtml

[4] L’image est à partir du transparent de « PerFedPat patent search system »

[5] http://www.perfedpat.eu/index.php/download-perfedpat

[6] http://www.khresmoi.eu

[7] https://www.healthonnet.org

[8] https://register.epo.org/help?topic=kindcodes

[9] http://sourceforge.net/projects/aligner/

[10] http://jsoup.org