 Track this topic | Pages sur ce sujet: < [1 2 3 4 5] | | Utilisateur | Auteur du fil: Eric Hahn Impossible de traduire sans comprendre ? |
|---|
Didier Caizergues
France
Local time: 19:24
anglais vers français
+ ...
|
... Sur les ressources quasi-infinies de Google ! Ceci étant, je me demande si la "conceptualisation du langage" est bien la seule pierre d'achoppement ici. Car franchement, depuis qu'on manipule des langages, qu'on les compare, qu'on fournit ces données comparatives à des machines de plus en plus performantes, on devrait quand même obtenir autre chose que de vagues approximations. La méthode joue beaucoup : si on va sur Google Trad et qu'on tente de traduire un texte anglais en français, le logiciel (appelons-le comme ça faute de mieux) va de parti pris en parti pris ; il choisit délibérément de substituer tel mot à tel autre, parce que c'est ce que son dictionnaire lui dit de faire, mais il ne propose pas de solution alternative. Autrement dit, on le bride, sans doute volontairement, afin qu'il propose une traduction pré-digérée du texte de départ, avec adhérence à des règles statistiques définies (du genre, "s'il y a 80% de chances que le mot 'rock' signifie 'rocher', je vais proposer 'rocher' ; peu importe que le mot 'rock' soit ici un verbe, ou qu'il fasse référence à une drogue, ou autre...).
Tu parles de fermes informatiques, mais elles existent déjà, et les moteurs de traduction ne se privent pas pour mettre des ressources considérables, non derrière le traitement de cette traduction-ci ou de celle-là, mais sur la création de correspondances entre groupes de mots. C'est la nouvelle frontière de la traduction machine : raisonner à l'échelle de la phrase entière, non plus à celle du mot à mot ou de la locution. Et pour cela, il faut plus que des "bécanes" super-puissantes ; il faut des programmes aptes à tourner sans relâche sur ces bécanes, à recouper les correspondances en s'appuyant sur autre chose que des statistiques et les probabilités qui en découlent.
Une autre limite, toute bête : la consommation d'énergie, et son vilain corollaire, le dégagement de chaleur. N'importe quelle firme informatique un peu friquée peut mettre des serveurs en parallèle jusqu'à plus soif, mais lorsqu'il s'agit de payer sa note d'électricité, on entend tousser dans le bureau du CFO, car non seulement il faut abreuver les bécanes, mais il faut aussi les refroidir. Pas gratuit, ça non plus...
Au final, il me semble que c'est bien dans une meilleure utilisation des performances sans cesse plus mirifiques de nos ordinateurs que se situera la prochaine marche à franchir. Il faudra mieux utiliser les cycles de calcul, pas en posséder davantage.
  | | | | Didier Caizergues
France
Local time: 19:24
anglais vers français
+ ...
| | Et je crois me rappeler... | Aug 3 |
... qu'on parle de "goulet d'étranglement", non de "goulot d'étranglement". Mais on pinaille, là...
| | | | sylver
Hong Kong
Local time: 02:24
anglais vers français
|
Didier Caizergues wrote:
... qu'on parle de "goulet d'étranglement", non de "goulot d'étranglement". Mais on pinaille, là... |
|
Les deux sont acceptés, selon le Grand Robert.
| | | | sylver
Hong Kong
Local time: 02:24
anglais vers français
| | Commentaires divers... | Aug 3 |
Didier Caizergues wrote:
... Sur les ressources quasi-infinies de Google ! Ceci étant, je me demande si la "conceptualisation du langage" est bien la seule pierre d'achoppement ici. Car franchement, depuis qu'on manipule des langages, qu'on les compare, qu'on fournit ces données comparatives à des machines de plus en plus performantes, on devrait quand même obtenir autre chose que de vagues approximations. La méthode joue beaucoup : si on va sur Google Trad et qu'on tente de traduire un texte anglais en français, le logiciel (appelons-le comme ça faute de mieux) va de parti pris en parti pris ; il choisit délibérément de substituer tel mot à tel autre, parce que c'est ce que son dictionnaire lui dit de faire, mais il ne propose pas de solution alternative. Autrement dit, on le bride, sans doute volontairement, afin qu'il propose une traduction pré-digérée du texte de départ, avec adhérence à des règles statistiques définies (du genre, "s'il y a 80% de chances que le mot 'rock' signifie 'rocher', je vais proposer 'rocher' ; peu importe que le mot 'rock' soit ici un verbe, ou qu'il fasse référence à une drogue, ou autre...).
|
|
Le problème reste un problème d'algo. Pour faire une traduction automatique, le logiciel doit prendre des decisions. Il utilise des statistiques et des mémoires de traduction colossales pour tenter de prendre les meilleures décisions, mais cela reste une question de statistiques et donc de probabilité. La méthode statistique considère également les fréquences d'utilisation des mots à proximité d'autres mots pour améliorer ses chances.
Cet algorithme, qui donne des résultats relativement acceptables, est un pari perdu d'avance pour ce qui est d'une traduction de qualité: Les sources de données ne sont pas fiables (voir le nombre de traductions douteuses qui servent de référence) et les sources d'ambiguités sont innombrables. Comme les ressources ne sont pas la cause du problème, une amélioration de la performance ne permettra jamais à elle seule de résoudre le problème.
Ce n'est pas parce que les systèmes actuels sont "bridés", mais simplement parce que la solution actuelle est défaillante. Elle n'est pas mauvaise, mais on sait dès le départ qu'elle ne pourra jamais donner le résultat final attendu.
Bref, pour développer une traduction machine qui tienne la route, il va falloir trouver un autre algorithme.
Un détail: la méthode statistique ne se limite pas à mesure la fréquence d'usage d'un mot. Elle tient également compte du contexte (lorsque les mots X et Y sont présents, Z est plus souvent traduit par Z'), entre autres choses.
Tu parles de fermes informatiques, mais elles existent déjà, et les moteurs de traduction ne se privent pas pour mettre des ressources considérables, non derrière le traitement de cette traduction-ci ou de celle-là, mais sur la création de correspondances entre groupes de mots. C'est la nouvelle frontière de la traduction machine : raisonner à l'échelle de la phrase entière, non plus à celle du mot à mot ou de la locution. Et pour cela, il faut plus que des "bécanes" super-puissantes ; il faut des programmes aptes à tourner sans relâche sur ces bécanes, à recouper les correspondances en s'appuyant sur autre chose que des statistiques et les probabilités qui en découlent.
|
|
Bien sûr qu'elles existent déjà, ces fermes informatiques! Google fonctionne avec depuis plus de dix ans. Et cette "nouvelle frontière" dont tu parles, c'était l'approche de Systrans il y a presque 20 ans de cela. Le problème n'a rien à voir avec la puissance de calcul. Comme la plupart des problèmes de mathématiques, le plus difficile consiste à formuler le problème. Et c'est loin d'être facile quand on considère le nombre de variables. Nous avons déjà toute la puissance de calcul nécessaire. La difficulté réside dans la définition des calculs à effectuer, autrement dit, l'élaboration d'un algorithme viable.
Pour faire un parallèle simple, donne un super ordinateur dernier cri à quelqu'un qui n'y connait rien de rien. Résultat? La puissance de l'ordinateur ne sert strictement à rien par ce que l'utilisateur ne sait pas s'en servir.
Notre situation actuelle avec la traduction machine est assez similaire: nous avons la puissance de calcul, mais aucune idée de la méthode (algorithme) qui nous permettrait d'obtenir le résultat voulu.
Une autre limite, toute bête : la consommation d'énergie, et son vilain corollaire, le dégagement de chaleur. N'importe quelle firme informatique un peu friquée peut mettre des serveurs en parallèle jusqu'à plus soif, mais lorsqu'il s'agit de payer sa note d'électricité, on entend tousser dans le bureau du CFO, car non seulement il faut abreuver les bécanes, mais il faut aussi les refroidir. Pas gratuit, ça non plus...
Au final, il me semble que c'est bien dans une meilleure utilisation des performances sans cesse plus mirifiques de nos ordinateurs que se situera la prochaine marche à franchir. Il faudra mieux utiliser les cycles de calcul, pas en posséder davantage. |
|
Ca n'avance en rien le problème de la traduction machine: avant d'optimiser les calculs, il faudrait encore pouvoir définir précisément quels sont les calculs a effectuer. On en est là.
| | | | | Pages sur ce sujet: < [1 2 3 4 5] | To report site rules violations or get help, contact a site moderator | Impossible de traduire sans comprendre ? |
