Rapport de veille
Utilisation du langage de programmation Python et de son écosystème dans le domaine de la science
Une étude de cas pour la recherche dans le domaine de la reconnaissance de la parole
Tous droits réservés 2013 CRIM Le 21 mai 2013
Page 3
1. PROBLÉMATIQUE
La validation des hypothèses et des concepts en recherche passe souvent par
l’implémentation d’algorithmes permettant de conclure sur l’efficacité d’une méthode
en observant ses effets sur des données expérimentales. Le chercheur passera donc
beaucoup de temps à programmer tout en modifiant continuellement les processus
développés, même si l’implémentation elle-même n’est pas le but premier de son
travail. Ses outils se doivent donc d’être flexibles et agiles.
Le traitement de la parole est une tâche intensive qui demande une efficacité des
programmes en exécution. Ainsi, les systèmes de traitement de la parole ont été
traditionnellement implémentés en utilisant des langages permettant une bonne
optimisation de l’utilisation des ressources système. Conséquemment, le C ou même le
C++ ont été et demeurent des langages très populaires en reconnaissance de la parole.
Il y a donc un large patrimoine de solutions informatiques que les chercheurs
voudraient réutiliser sans avoir à les programmer à nouveau suivant l’avènement de
nouvelles approches algorithmiques ou même de nouveaux paradigmes d’exploitation
(e.g. :SaaS).
Or, dans la perspective du travail expérimental d’un chercheur, les langages compilés
et statiquement typés tels que le C/C++ ne se prêtent pas toujours aussi bien aux
exigences de flexibilité du travail expérimental que les langages dits de « scripts » tels
que Perl, BASH/CSH, etc. C’est pour cela que bon nombre de solutions de
reconnaissance de la parole utilisées dans la recherche (Kaldi, CMU Sphinx) sont en fait
un assemblage de langages compilés et interprétés. Les logiciels compilés sont
typiquement encapsulés en tant que processus distincts par des scripts permettant une
exploration facile des variantes algorithmiques, mais cela amène un bon nombre de
désavantages et contraintes logicielles causées par ce découplage. Citons par exemple
la nécessité, souhaitable ou non, de passer par des données transitoires dans des
formats et interfaces variés causant une explosion des types. Par ailleurs, les
traitements numériques ou statistiques sont souvent réalisés avec des langages tels que
Fortran, MATLAB ou R, en raison de leur expressivité pour ces tâches, ajoutant une
autre base de code.
Finalement, mentionnons la tendance lourde de la diminution du prix de la vitesse de
calcul et l’augmentation du coût de la main d’œuvre spécialisée en recherche. Si à une
époque il était beaucoup plus dispendieux de mettre la main sur des processeurs très
rapides, on peut dire que cela est une considération contemporaine moins importante
avec la prolifération des solutions de grappes de calcul et d’infonuagique plus
facilement accessibles. Or, l’exploitation de ces solutions se doit d’être standardisée
et facile. Ainsi, il devient généralement plus important pour un gestionnaire de
recherche d’optimiser le temps de développement d’une solution et de valoriser une
polyvalence future, garante d’une plus grande valeur patrimoniale, plutôt que
d’optimiser le temps d’exécution de cette même solution, sans dire pour autant que
cela n’a plus d’importance.
Tous les éléments mentionnés ci-haut posent un certain nombre de dilemmes dans les
choix technologiques des chercheurs et il y a des approches diverses pour tenter de
répondre aux priorités les plus pressantes de chacun. Or, chaque approche apporte son
lot d’avantages et d’inconvénients et il devient parfois difficile à accorder l’une avec