5 Algorithme de compressions
5.1.1 Description de l’algorithme et de l’expérience
Le but d’un algorithme de découpage est de conserver dans le PBM les sous-paramètres qui reconstitue des plus gros sous-paramètres (ex : s’il existe des sous-paramètres « le chat ||| the cat ||| <scores> » et « est noir ||| is black ||| <scores2> » alors on peut supprimer le paramètre « le chat est noir ||| the cat is black » ).
Décrivons l’algorithme en Figure 5-2. Pour chaque paramètre du PBM « s ||| t |||
<scores> » on génère tous les découpages binaires de la partie source s (comme dans la Figure 5-1).
le ciel est bleu ||| the sky is blue ||| 0.99
Les découpages binaires de la phrase source donne :
(« le », « ciel est bleu »), (« le ciel », « est bleu »), (« le ciel est », « bleu »).
Figure 5-1. Exemple de découpages binaires possibles pour la partie source « le ciel est bleu »
Pour chaque couple (s1, s2), nous recherchons tous les paramètres dont les parties sources correspondent à s1 et s2 (nous obtenons donc deux listes de paramètres, qu’on appellera X et Y). Pour chaque paramètre de X et Y, on vérifie si la concaténation des parties cibles (t1 et t2) donne bien t.
Si c’est le cas, nous avons trouvé un découpage du paramètre « s ||| t ||| <scores> », donc nous n’avons plus besoin de ce paramètre dans ce PBM, car il en existe une version
« découpée ».
32
PBM
Figure 5-2. Algorithme proposé pour la compression par découpage binaire, la concaténation entre deux chaînes est symbolisé par « + »
L’algorithme est illustré dans la Figure 5-3, pour un PBM et un paramètre donné :
le chat est noir ||| the cat is black ||| <score(s)>
Découpages binaire de la partie source
Partie(s) source(s) de X + partie(s) source(s) Y = “the cat is black » ? sous-liste X
sous-liste Y le chat est noir ||| the cat is black ||| <score(s)>
le chat ||| the cat ||| <score(s)>
le chat ||| a cat ||| <score(s)>
est ||| is ||| <score(s)>
est ||| be ||| <score(s)>
est noir ||| is black ||| <scores>
est noir ||| is dark ||| <scores>
noir ||| black ||| <score(s)>
noir ||| dark ||| <score(s)>
PBM
Figure 5-3. Application de l’algorithme du découpage binaire sur le paramètre « le chat est noir »
33
Avec cette heuristique, nous espérons voir comment le décodeur va se comporter lors de la traduction. Même si l’algorithme semble simple, il sera entre autre intéressant de voir de quel ordre sera la perte de BLEU et quel sera le taux de compression.
5.1.2 Résultats
Nous avons compressés les PBM filtré sur les textes test2006-rest et test2006-ood (en français, espagnol et allemand), ensuite ces textes ont été traduits en utilisant les PBM compressés. Les scores BLEU obtenus à la suite de l’expérience sont présentés en Figure 5-4 et les taux de compression en Figure 5-5.
Sur la colonne de colonne de gauche, on peut lire les performances standards (c'est-à-dire sans compression ) et sur la colonne de droite avec compression .
texte source sans compression Avec compression Test2006-rest (fr) 30.35 25.28
Test2006-ood (fr) 20.31 18.02
Test2006-rest (es) 30.80 25.56
Test2006-ood (es) 25.17 22.45
Test2006-rest (de) 24.91 21.55
Test2006-ood (de) 15.90 13.91
Figure 5-4. Scores BLEU obtenus sur les traductions après compression binaire
PBM filtrés sans compression (en Mo)
avec compression (en Mo)
test2006-rest (français) 107 39
test2006-ood (français) 59 28
test2006-rest (espagnol) 108 42
test2006-ood (espagnol) 57 28
test2006-rest (allemand) 74 35
test2006-ood (allemand) 40 23
Figure 5-5. Taille (en Mo) des PBM obtenus après compression binaire
On observe que sur des PBMs filtrés, le taux de compression est de 40% à 60%, mais il s’accompagne d’une perte de BLEU considérable de 2% à 5%.
34
Nous avons observé par la suite la répartition des paramètres dans les PBM compressés (comme dans la section 4.1). La majorité des paramètres présents après compression sont des paramètres qui ont des longueurs de phrases sources ou cibles d’au maximum 3. Ceci explique la mauvaise qualité des traductions, poussant le décodeur à traduire presque « mot à mot ». De plus on ne s’est pas assuré de retrouver la traduction initiale, par rapport à l’exemple Figure 5-3 « le chat est noir » a pu être traduit en « the cat is dark » au lieu de « the cat is black », ce qui nous pénalise en qualité de traduction.
Les taux de compression sont en moyenne de 50 %, bien que satisfaisants, ils sont accompagnés de mauvais résultats en terme de BLEU.
En dehors des résultats obtenus précédemment, l’algorithme a un autre point faible : son temps de calcul. Pour un PBM d’environ 100 Mo, il faut environ 17h de calcul pour obtenir un PBM compressé. L’idée est d’avoir un algorithme assez rapide pour le lancer sur un PBM non filtré, afin d’obtenir le taux de compression pour des modèles beaucoup plus grands dont la taille est de l’ordre du Go.
On a donc étudié l’algorithme pour y trouver des possibilités d’optimisation. Les résultats sont en Annexe dans la section « Optimisation de l’algorithme ».
5.5.22 Compression par découpage n-aire incluant les scores
5.2.1 Principe
Le principe du découpage n-aire est de généraliser l’approche du découpage binaire et on inclut les scores lorsqu’on prend la décision de retirer ou pas un paramètre. En utilisant les scores on espère pouvoir retrouver nos découpages lors de la traduction.
Nous avons utilisé la programmation dynamique pour programmer cet algorithme.
Mais celui-ci étant compliqué à décrire nous allons partir d’un exemple.
Il faut savoir que l’algorithme est appliqué seulement aux paramètres de longueur supérieure ou égale à 4 mots. La Figure 5-6 est un PBM simple sur lequel on va s’appuyer pour donner une idée générale de l’algorithme.
35
Mr le président , je veux ||| Mr speaker , I want ||| 0.2 0.1 0.5 0.9 2.718
Figure 5-6. Exemple de PBM auquel on va appliquer le découpage n-aire au paramètre «Mr le président , je veux»
Pour chaque paramètre, on crée une matrice de taille NxN (N étant la longueur de la partie source). La partie source de ce paramètre sera notée . Une cellule (i,j) (avec
N
i≤ ) de la matrice représente la sous-phrase ).
Pour chaque cellule (i, j) de la matrice, s’il existe des paramètres dont la phrase source est . On ajoute ces paramètres à la cellule(i,j) en tant qu’hypothèses de traduction. On obtient alors un tableau initialisé comme sur la
j
pi
Figure 5-7.
Figure 5-7. Phase d’initialisation de l’algorithme appliquée sur l’exemple le pbm en Figure 5-6, les
« * » représentent les cases initialisées, les cases vides ne contiennent pas d’hypothèses et les X sont des cases inexistantes. Sens de l’optimisation
i j
36
Sur le tableau obtenu précédemment, on applique l’algorithme de maximisation en Équation 4.
Équation 4 – Algorithme de maximisation utilisé pour le découpage n-aire. La fonction « cout » renvoie les couts de toutes les hypothèses associés à pij.
( )
Cette équation est récursive, on la lance à partir de la cellule (1,6) (celle entourée en rouge dans la Figure 5-7), car on veut récupérer le résultat dans la case représentant « Mr le président , je veux », le paramètre que l’on cherche à découper. Sans rentrer dans les détails, cette équation permet de trouver le meilleur découpage en en faisant intervenir les scores comme critère de découpage. Un paramètre est retiré seulement si son découpage a un meilleur score que lui.
Nous n’irons pas plus loin dans les explications de cet algorithme, il faut juste retenir l’idée générale de l’algorithme : trouver un découpage du paramètre en faisant intervenir le score pour prendre notre décision. Pour plus de détails voir la section
« Découpage n-aire : explications » en Annexe.
Ci-dessous, l’algorithme du découpage n-aire écrit en pseudo-code :
37
Hypothèse cell[][] ; Pour nbmots 2 à N-1{
Pour i=1 à N-nbmots+1{
Pour j=i à i+nbword-2{
X Å nbmots+i-1;
Si ∃ cell[i,j] && ∃cell[j+1,X] { match(i,j,j+1,X);
} }
} }
Figure 5-8. Algorithme général du découpage n-aire
float S;
bitset T;
liste d’hypothèse H1,H2,H3 Fonction match(i,j, X){
k=j+1;
H1 Å cell[i,j];
H2 Å cell[k,l];
H Å cell[i,l];
Pour h1∈H1{
Pour h2∈H2{
T Å target(h1,h2); % si h1 et h2 incompatible STOP S Å score(h1) + score(h2);
∀h∈H / target(h)=T{
Si s > score(h){
MAJ(h,s,k);
} }
} }
Figure 5-9. Algorithme de la fonction MATCH
38
Fonction MAJ(hypothese,score,backpointer){
hypotheseÆscore=score;
hypotheseÆbackpointer=backpointer;
}
Figure 5-10. Algorithme de la fonction MAJ
5.2.2 Résultats
Nous observons sur la Figure 5-11 que les pertes varient selon la taille du PBM en entrée, généralement lorsque le PBM est filtré sur les corpus test2006-ood, résultant en un PBM de petite taille (proche de 60 Mo) on observe des pertes de moins d’1% par rapport au BLEU initial par contre pour les PBMs filtrés sur les corpus test2006-rest nos pertes sont entre 1.33% et 1.63%. Les taux de compression (Figure 5-12) varient entre 5% et 15% et sont encore proportionnels à la taille des PBMs.
Pour une analyse plus précise, comparons les résultats obtenus avec les baselines en Annexe. Nous rappelons que nous avons appliqué nos découpages seulement aux paramètres dont la partie source est supérieure à 4, ce qui revient à comparer avec les modèles élagués dont on a conservé les phrases sources de taille 3 (les lignes « [3-1] » « [3-2] » … « [3-7] »). En général, nos résultats sont un peu meilleurs pour ce qui est du score BLEU mais nos gains en compression sont légèrement inférieurs.
Cette approche montre d’assez bons résultats, comparés à nos baselines, mais nous ne pouvons aller plus loin car il faudrait à partir de là utiliser le modèle de langue pour s’assurer de la « reconstruction » de nos paramètres lors de la traduction, ce qui est trop complexe et hors de notre portée par rapport au temps qu’il nous reste avant la fin du stage. Nous allons désormais tenter de compresser les PBM à l’aide d’heuristique.
Pbm source Sans
test2006-rest (fr) 30.35 25.28 28.55 28.72
Pbm filtré sur
Figure 5-11. Evaluation des scores BLEU obtenus par compression n-aire (colonne de droite), comparés avec les performances standards, les résultats du découpage binaire et le baseline.
39
pbm source Sans
compression Baseline avec compression n-aire
Pbm filtré sur test2006. lower-rest
(fr) 107 78 90
Pbm filtré sur test2006.lower-ood
(fr) 59 49 54
Pbm filtré sur test2006.lower-rest
(es) 108 82 95
Pbm filtré sur test2006.lower-ood
(es) 57 49 54
Figure 5-12. Taille en Mo des PBMS obtenus par compression n-aire (colonne de droite)
40
5
5..33 Compression sans perte
C’est à partir de cette section la « compression sans perte » que nous abandonnons les méthodes de découpage et introduisons les méthodes heuristiques. Elle consiste à établir des critères de compression à partir d’observation sur différents PBMs.
5.3.1 Principe
En étudiant le comportement du décodeur, nous nous sommes rendu compte que certains paramètres peuvent être supprimés dans le PBM car ils ne seront jamais sélectionnés par le décodeur lors des traductions.
Lorsque nous listons pour une source donnée tous les paramètres correspondants, il arrive que certaines parties cibles commencent et finissent de la même manière, ces paramètres ont une propriété spécifique, on les appellera « paramètres concurrents ». Un exemple de « paramètres concurrents » est donné dans la figure ci-dessous.
le ciel est bleu ||| the sky is blue ||| <scores>
le ciel est bleu ||| the sky is really blue ||| <scores 1>
le ciel est bleu ||| the sky is clear and blue ||| <scores 2>
Un seul de ces 3 paramètres sera choisi quoiqu’il
arrive
le ciel est bleu ||| it’s a blue sky ||| <scores 3>
Figure 5-13. Exemple de paramètres concurrents
Par rapport à la Figure 5-13, si le décodeur doit traduire « le ciel est bleu », il choisira parmi les paramètres commençant par « the sky » et finissant par « blue » qu’un seul des trois, on peut alors retirer les 2 autres paramètres.
Supprimer ces paramètres inutiles devrait d’une part nous permettre de gagner en terme de compression mais d’autre part cela n’entraînera aucune perte de qualité de traduction, en théorie.
Il nous reste à savoir dans quelle proportion ce phénomène apparaît dans nos PBMs pour savoir si on doit vraiment s’y intéresser. Dans ce but, nous allons programmer un algorithme qui établira des statistiques, il donnera principalement le pourcentage de phrase sources pour lesquelles on trouve des parties cibles qui sont « concurrentes ». Cet algorithme est donné en Figure 5-14.
41
int occ=0;
Pour chaque paramètre (src,tgt) du PBM {
Si src appartient à DÉJÀ_VU on passe au prochain paramètre;
X = lister_paramètre(src);
Pour tous les paramètres p=(X_src, X_tgt) de X {
Pour tous les paramètres p=(X_src’, X_tgt’) de X {
Si (X_tgt’ commence et finit comme X_tgt) alors { On ajoute X_src à la liste DÉJÀ_VU;
occ++;
} }
} }
Retourne occ;
Figure 5-14. Algorithme pour la compression sans perte en pseudo-code
5.3.2 Résultats
Nous avons effectué nos tests sur les PBM filtrés sur test2006-ood et test2006-rest en allemand, français et espagnol. Les résultats sont décevants, seulement en moyenne 2% des différentes phrases sources d’un PBM peuvent être réduites à un seul paramètre.
Nous n’envisagerons pas de tests de compressions dans cette voie-là, car le gain est trop faible même si cette méthode est dite « sans perte ».
5.5.44 Compression heuristique : la ponctuation
5.4.1 Principe
Lors de l’apprentissage de nos PBMs, on retrouve beaucoup de symboles de ponctuation dans nos paramètres, en partant du principe que les symboles de ponctuations ne devraient être traduits que par des symboles de ponctuations.
On devrait n’en retrouver que dans des règles du type « <symbole de ponctuation>
||| <symbole de ponctuation> ||| <scores> », or ce n’est pas le cas (cf. Figure 5-15).
42
% , est ||| % , is ||| 0.2 0.189001 1 0.387482 2.718
% , les ||| % , the ||| 0.2 0.0808288 1 0.291821 2.718
% , ||| % , and ||| 0.047619 0.337495 0.003861 0.0201153 2.718
% , ||| % , that ||| 0.2 0.61601 0.003861 0.0158547 2.718
% , ||| % and ||| 0.0540541 0.0589794 0.023166 0.0304763 2.718
% , ||| % annual ||| 1 0.00345983 0.003861 8.86579e-06 2.718
% , ||| % as ||| 0.181818 0.0282689 0.00772201 0.005347 2.718
! je souhaite ||| , i wish ||| 0.00617284 1.68351e-05 1 0.00166323 2.718
! je ||| , i ||| 0.000191394 0.000139081 0.666667 0.0137175 2.718
! je ||| but i ||| 0.000307031 0.000107753 0.111111 0.000870976 2.718
! ||| ! ||| 0.784547 0.757348 0.591233 0.577009 2.718
! ||| , ||| 0.00018397 0.0002202 0.009467 0.0156755 2.718
! ||| - and here ||| 0.0526316 0.0006014 0.000129685 6.42018e-08 2.718
! ||| - and ||| 0.000510986 0.0006014 0.000129685 2.14557e-05 2.718
! je souhaite ||| , i wish ||| 0.00617284 1.68351e-05 1 0.00166323 2.718
! je ||| , i ||| 0.000191394 0.000139081 0.666667 0.0137175 2.718
! ||| , and ||| 0.000344656 0.00016865 0.00116716 6.82558e-05 2.718
" , les ||| " , the ||| 0.125 0.0577128 0.166667 0.0597613 2.718
" , les ||| ' , the ||| 0.129032 0.0234883 0.666667 0.144463 2.718
" , nous ||| " , we ||| 1 0.28765 0.5 0.0914984 2.718
" , nous ||| ' is ||| 0.008 2.16383e-05 0.125 0.00512641 2.718
" , nous ||| ' we ||| 0.0136986 0.0204718 0.125 0.335108 2.718
Figure 5-15. Exemple de modèle bruité (extrait d’un PBM), on voit que les symboles de ponctuation peuvent prendre une place importante dans les modèles de traduction.
De plus, cette méthode pourrait en théorie améliorer la qualité de nos traductions car les symboles de ponctuations parasitent nos paramètres. Par exemple, pour le paramètre « ! je souhaite ||| , i wish ||| <scores> », il risque d’être rarement utilisé lors d’une traduction car il est peu probable de traduire « ! je souhaite ». Par contre, traduire
« je souhaite » l’est beaucoup plus.
Le principe est de prendre chaque paramètre du PBM et retirer la ponctuation qui entoure la phrase cible et source, comme dans l’exemple Figure 5-16. Principe du
« nettoyage » de paramètre:
43
. / le ciel est bleu ? ||| * & the sky is blue ; ||| <scores>
Î le ciel est bleu ||| the sky is blue ||| <scores>
Figure 5-16. Principe du « nettoyage » de paramètre
J’appellerai cette opération le « nettoyage »; elle peut s’appliquer à un paramètre entier (c'est-à-dire à la phrase source et cible) ou juste à une phrase source ou cible.
Puis nous vérifions si la version « nettoyée » du paramètre n’existe pas ailleurs dans le PBM. Si c’est le cas, nous retirons le paramètre courant, sinon nous le conservons, on évite ainsi la création des doublons dans le PBM.
5.4.2 Résultat
Les tableaux Figure 5-17 et Figure 5-18 nous permettent de comparer les scores obtenus grâce à notre heuristique avec ceux du découpage n-aire, des baselines et sans compression. On peut observer une perte beaucoup moins importante en BLEU par rapport aux baseline. Une chose étonnante est qu’on ne s’attendait pas à perdre en BLEU, car cette heuristique contrairement aux autres méthodes est moins risquée par rapport aux méthodes de découpage. Il serait intéressant de voir d’où vient cette perte.
Nos Pertes en BLEU varient de 0.02% à 0.60 %. Cette perte est assez négligeable et les gains en compression sont assez importants, de l’ordre de 15% à 20 % sur des PBMs filtrés. Ce qui prouve que la ponctuation prend une place relativement importante dans nos modèles.
test2006.fr.lower-rest 30.35 28.72 29.50 29.82
PBM filtré sur
test2006.fr.lower-ood 20.31 19.48 19.24 20.28
PBM filtré sur
test2006.es.lower-rest 30.80 29.47 29.39 30.20
PBM filtré sur
test2006.es.lower-ood 25.17 24.56 24.70 24.92
Figure 5-17. Scores BLEU obtenus après compression heuristique sur la ponctuation (sur la droite)
44
Pbm sans compression
Baseline
(avec des scores équivalents)
avec compression (heuristique sur la
ponctuation) PBM filtré sur
Test2006.fr.lower-rest 107 100 86
PBM filtré sur
Test2006.fr.lower-ood 59 52 48
PBM filtré sur
Test2006.es.lower-rest 108 98 91
PBM filtré sur
Test2006.es.lower-ood 57 56 49
Figure 5-18. Taux de compression obtenu après compression heuristique sur la ponctuation (sur la droite)
En comparant avec les baselines en annexe nous avons de meilleurs résultats en termes de compression et de BLEU, ce qui n’était pas le cas avec les méthodes précédentes.
Pour aller plus loin, nous avons effectué les tests de compression sur des PBMs de base en français et espagnol (vers l’anglais). Les résultats sont dressés dans le tableau ci-dessous.
PBM sans compression avec compression
PBM français 1.4 Go 1.1 Go
PBM espagnol 1.7 Go 1.5 Go
Figure 5-19. compression heuristique sur des PBM de plus de 1Go
Les taux de compressions sont approximativement de 11% pour la langue espagnole et de 20% pour le français.
En conclusion, les méthodes de découpages se révélant pour l’instant assez difficiles à mettre en place, cette méthode ouvre la voie aux méthodes de compression heuristique. Les résultats obtenus sont bons et assez encourageants pour continuer à émettre de nouvelles heuristiques.
45
5.5.55 Compression heuristique : pertinence des paramètres
5.5.1 Principe
On a vu lors de l’introduction au PBM que tous les paramètres n’étaient pas pertinents (cf. Figure 5-20). On cherche un critère qui pourrait départager les paramètres qui sont potentiellement utilisables lors de la traduction de ceux qui ne le sont pas. Pour déterminer ce critère, on va se baser sur les scores.
Le principe est de faire la somme des quatre premiers scores (le dernier étant toujours égal à 2.718) et de déterminer un seuil, si le paramètre dépasse ce seuil alors on le garde dans notre PBM sinon il est rejeté. On appellera cette compression
« compression par seuil ».
En observant plusieurs PBM, on a décidé de fixer le seuil à 0,1.
avoir ||| very ||| 5.93331e-05 0.0001622 0.000181028 0.000466 2.718
avoir ||| want to ||| 0.000225327 0.0034105 0.000181028 0.000428439 2.718 avoir ||| want ||| 0.000940144 0.0034105 0.000543085 0.0039146 2.718 avoir ||| was ||| 0.000429943 0.0003664 0.00162925 0.0017709 2.718 avoir ||| we all ||| 0.00444444 0.0003767 0.000181028 5.10276e-05 2.718 avoir ||| we did ||| 0.00265252 0.0006233 0.000181028 6.42888e-06 2.718
Figure 5-20. Extrait de paramètres « non pertinent » dont la phrase source est « avoir », ces traductions seront probablement pas utilisées pour la traduction.
5.5.2 Résultats
Les figures Figure 5-21 et Figure 5-22 présentent les résultats de nos tests de compressions sur les PBM filtré sur les textes test2006-rest et test2006-ood, ceci en français et en anglais.
46
Pbm filtré sur Sans
test2006.lower-ood(espagnol) 25.17 24.92 25.23
Figure 5-21. Score BLEU obtenus après compression par seuil (colonne de droite), on note un gain de bleu pour les corpus « ood » et une légère perte sur les corpus « rest » par rapport aux
Figure 5-22. Tailles de PBM obtenus après compression par seuil (colonne de droite), celles des PBM originaux sont sur la colonne « sans compression »
Les résultats de cette expérience sont meilleurs que ceux de l’expérience précédente (cf. Compression heuristique : la ponctuation), les taux de compression ont atteint les 50% pour des scores BLEU proche de ceux observés avec la compression par ponctuation.
Le bilan de cette expérience est positif, avec cette heuristique on a prouvé qu’il était possible de déterminer des critères simple mais qui se révèle efficace pour la compression des PBM.
47
6 Conclusion
6.6.11 Bilan de l’étude
Nous avons vu tout au long de nos expériences à quel point la compression de PBM est subtile à mettre en place, chaque modification sur les PBMs détériore plus ou moins la qualité de nos traductions.
En général, nous avons observé des pertes importantes avec les méthodes par découpage, mais il est bon de rappeler qu’à ce niveau nous n’avions pas tous les éléments en main pour retrouver les découpages lors des traductions. Ce qui a conduit à des résultats moins bons.
Les méthodes de compression heuristique ont donné de meilleurs résultats pour l’instant. Mais généralement les critères d’élagages sont difficiles à déterminer, et la proportion des paramètres qui peuvent être élagués varient fortement d’un modèle à un autre. Ce qui rend les résultats assez imprévisibles.
Par rapport au baseline fixé, la dernière approche a donné des résultats positifs. On a même réussi à compresser sans pertes de BLEU avec des taux très intéressants.
Cela ne remet pas en cause la possibilité de compresser les PBMs d’avantages. Il reste encore diverses heuristiques et approches à essayer (et des détails à régler) dans les méthodes que nous avons utilisées.
6.6.22 Conclusion personnelle
Ce stage a été très enrichissant. D’une part, j’ai eu la chance de découvrir de plus près l’environnement d’un laboratoire de recherche et de voir sous un autre angle
Ce stage a été très enrichissant. D’une part, j’ai eu la chance de découvrir de plus près l’environnement d’un laboratoire de recherche et de voir sous un autre angle