A la croisée de plusieurs disciplines, la Data Science s’appuie sur des méthodes et des algorithmes pour tirer des informations et de la connaissances à partir de données structurées et non structurées. Encore inconnus il y a quelques années, les métiers de la Data Science et du Machine Learning évoluent très vite. Compétences, méthodes, outils… dans cette série d’entretiens, nous confrontons notre expérience à celle du marché, avec la participation de Data Scientists et ingénieurs Machine Learning externes à Devoteam Revolve.

Nous recevons aujourd’hui Carole Lailler, Docteur en Sciences du langage et spécialiste de morphosyntaxe.

Peux-tu te présenter ?

Je suis docteur en sciences du langage. J’ai longtemps travaillé sur la grammaire de la langue française et sur la partie morphosyntaxique, c’est-à-dire le fonctionnement de la langue, l’articulation des mots, le contexte, etc.  J’ai fait ma thèse dans un laboratoire d’informatique, et c’est comme ça que j’ai commencé à m’intéresser aux données et aux outils d’IA : traitement automatique de la parole, reconnaissance du locuteur, traduction… bref tous les outils qui lient IA et langues.

Après une carrière académique, j’ai fait quelques incursions dans des startups, puis j’ai créé ma société Scribe Conseil il y a 4 ans, et aujourd’hui j’ai une double casquette. Je travaille d’une part sur le traitement de la langue, automatisé ou non, à travers l’étude de l’évolution des mots et des usages.

D’autre part, je travaille sur des outils d’IA, souvent basés sur le Machine learning, mais pas uniquement, pour traiter de voix et paroles, en interactions, de manière spontanée ou non. Il y a à la fois une partie du travail qui est très technique, comme la construction de systèmes ou de chatbots, les efforts de classification thématiques, avec en complément un regard attentif aux usages des locuteurs, pour capteur au mieux ces usages, et pour que les outils soient les plus adjuvants possibles en fonction des différentes utilisations.

Comment se répartit le travail entre la partie linguistique et la data science ?

Sur l’ensemble des projets, je dirais que c’est du 50/50, il y a à la fois de la construction technique et de l’analyse de l’évaluation, mais quand les résultats ne sont pas satisfaisants, je reprends ma casquette de linguiste. J’essaie alors de trouver les hiatus par rapport au locuteur ou au cas d’usage, de mesurer les écarts entre langue spontanée et langue écrite, etc.

Cela dépend vraiment de la typologie du projet. Il peut aussi y avoir un aspect UX design dans le projet, pour faire en sorte que l’expérience utilisateur soit la plus satisfaisante possible, en passant justement par le prisme du langage.

Avec quels interlocuteurs travaillez-vous dans vos projets ?

Il s’agit soit de startups qui proposent des outils d’IA et qui ont besoin d’un audit, afin de mieux faire correspondre les données et les cas d’usage, soit de grands groupes qui se dotent d’une brique d’IA (chatbot, reconnaissance de la parole, traduction, classification, chaîne de traitements complexe…). Comme ce sont souvent des données sensibles, dans ce cas tout est construit en interne, et mon travail se fait en collaboration avec les développeurs de l’entreprise.

Que valent les solutions de speech to text disponibles sur le marché ?

En français, elles sont généralement mauvaises à l’exception de quelques acteurs. Ces solutions fonctionnent par exemple assez mal avec du langage terminologique. Pour les cas d’usages avec des besoins très spécifiques, avec une ligne éditoriale, il faut alors adapter les systèmes avec des recalculs des modèles de langages, quelques heuristiques parfois.

Comment est-ce que vous construisez des modèles de NLP ?

En ce moment on parle beaucoup des transformers, j’utilise par exemple FlauBERT ou CamemBERT. En reconnaissance, on peut utiliser du tout neuronal, cela dépend du projet, des volumes de données, du budget ou de granularité de la réponse attendue. En fonction de ces critères, on peut choisir des classifieurs très complexes, ou un simple tf-idf avec un petit effort de classification algorithmique en sortie. Ce que j’apprécie dans mon métier, c’est de ciseler au plus près possible du cas d’usage.

Quelles sont les caractéristiques de l’entraînement des modèles liés au langage ?

Dans le cas des classifications thématiques, par exemple du SAV, une enquête de satisfaction employé, la notation d’un film ou des articles de presse à classer en rubriques, on a en entrée des verbatims utilisateurs, ou des textes, issus de l’oral ou de l’écrit. On dispose d’un jeu de données, plus ou moins annoté, et tout l’art du NLP est d’apprendre au classifieur ce qui fait la substantifique moelle thématique, sémantique, voir typographique de chaque thème. De cette façon, à chaque nouvelle entrée, le classifieur va pouvoir déterminer le thème le plus probable, en fonction d’un certain seuil défini au préalable.

Pour préparer l’apprentissage, il y a un travail de normalisation de la donnée : normaliser les dates, la casse, choisir de travailler à l’aune du mot ou du groupe de mots, au radical… Tous ces choix précèdent l’entraînement, et on peut les changer au cours des différentes phases d’apprentissage. On conserve toujours un test annoté qui correspond au résultat qu’on aimerait atteindre, annoté, à ce qu’on veut trouver. On passe ensuite l’algorithme sur ce test pour voir s’il répond à nos critères. Si c’est le cas, on le met en production, et on a un classifieur qu’il convient de ne pas oublier d’évaluer !

Quelle est la longueur d’un cycle de développement avant la mise en production ?

C’est difficile de répondre, cela dépend des données et des besoins, ça peut être entre 3 jours et 3 mois. S’il n’y a que très peu de données il est possible de commencer avec des calculs de distance, un Tf-IDF qui permet de pondérer l’utilisation du vocabulaire par rapport à son utilisation dans la langue. Certains mots sont très utilisés, ils sont grammaticalement utiles mais ne sont pas sémantiquement porteurs, on peut donc jouer sur cette prépondérance de certains mots par rapport à d’autres. On peut donc commencer par des travaux très simples, pour ensuite entraîner des modèles à plus grande échelle, jouer avec des embeddings, des sentence embeddings, une modélisation du langage complexe, des architectures dites de deep learning. Plus on a de données, plus il devient intéressant de descendre en granularité.

La préparation des données est-elle chronophage ?

C’est une phase prépondérante, mais j’apprécie cette partie du travail. Il y a des côtés répétitifs, parfois le système achoppe et on ne comprend pas pourquoi tel mot n’est pas pris, pourquoi les features ne sont pas choisies comme on l’imaginait, etc. Mais c‘est un travail qui m’amuse, car il permet à la linguiste que je suis de continuer à réfléchir à ce qu’est un mot, une phrase, un emploi.

On se rend compte aussi de l’évolution des usages, par exemple le fait que les gens n’acceptent pas leurs majuscules. Pour le système les mots avec majuscule et/ou accent “Élysées” et “Elysées”, ce n’est pas la même chose. Ce que l’œil humain lisse, le système ne le fait pas. Cette partie du travail permet aussi d’avoir des discussions avec les usagers, de comprendre les contraintes de leurs outils, pourquoi ils ont ces usages… on en arrive à des sujets qui débordent de mon cadre, comme l’ergonomie au travail, mais c’est intéressant.

Quels sont les cas d’usage en dehors des chatbots ou des classifications ?

Il y a pas mal de sujets sur la reconnaissance automatique de la parole, aussi bien pour générer du sous-titrage que pour alimenter des chatbots. Ce type de reconnaissance se fait en temps réel, au mot près, à la disfluence près (les euh, hum et autres ben). Le sous-titrage automatisé peut être à destination des personnes malentendantes, mais il a aussi d’autres avantages, comme de mettre le son moins fort, de pouvoir identifier correctement l’orthographe d’un nom propre, ou de mieux plus facilement.

Un autre cas d’usage très intéressant est l’entraînement à l’oral. Je travaille avec des start-up qui proposent ce type d’outils qui permet de mesurer la vitesse et le débit de la voix, de repérer les disfluences, les répétitions, etc. Cette technologie est par exemple proposée dans l’accompagnement au retour à l’emploi pour des personnes qui ne sont pas à l’aise avec la présentation à l’oral. Ce type d’entraînement leur permet de gagner en confiance et de s’améliorer : la machine est neutre, objective, elle fournit un simple comptage sans jugement et les axes d’amélioration sont donc bien perçus.

Quelles sont les contraintes de ce type de traitement en temps réel ?

La différence se fait surtout au niveau du code, dans la façon dont on apprend au système à travailler. Est-ce qu’on l’autorise ou non à itérer ? Est ce qu’on autorise le chatbot à calculer tous les chemins possibles pour une réponse ? C’est surtout là que la différence se fait.

Globalement, plus les données sont en lien avec le cas d’usage, mieux on sera loti dans l’usage quotidien, notamment lorsqu’il s’agit de deep learning, où le risque de dilution est présent. Avec le français c’est pire, entre les métaphores, l’homophonie, l’homophonie, ce n’est que grâce au contexte qu’on lève l’ambiguïté (le mouton, dans les prés, ou sous l’armoire ?). De nombreuses ambiguïtés lexicales et sémantiques en français sont résolues par le contexte. Il arrive que les systèmes de réseaux de neurones perdent cette pluralité contextuelle et diluent les usages les moins fréquents. 

Quels sont les biais de l’IA dans le NLP ?

C’est un sujet, ne serait-ce que pour l’ambiguïté lexicale dont on vient de parler. Nous avons par exemple le cas de traduction de certaines langues avec des pronoms personnels non genrés, une troisième personne du singulier qui peut être masuclin ou féminin, et que l’IA traduit toujours avec des biais. Certains verbes peuvent résoudre l’ambiguïté, “elle accouche”, c’est assez clair, mais sur d’autres verbes c’est du contextuel. Et là, la réussite est due à l’apprentissage,  au fait de nourrir le système avec des exemples.

Nous devons prendre conscience de ces biais, et en tant que linguiste, dans la préparation des données, il faut évaluer les corpus d’entrée et leur adéquation avec le cas d’usage. On essaie donc de trouver dans les données d’entrée ce que l’algorithme a pu choisir comme feature, afin de comprendre comment parvenir aux résultats les plus probants.

Virginie Mathivet citait l’exemple de la reconnaissance d’image avec des labradors et des husky. Un humain se focalisera sur des caractéristiques comme la couleur du pelage, la forme de la gueule, etc. Pour l’algorithme, c’est simple : s’il y a de la neige, c’est un husky, s’il n’y en a pas, c’est un labrador ! Cela montre bien que pour l’IA, la caractéristique la plus discriminante n’est pas celle qu’on pourrait formuler spontanément avec toutes nos connaissances sémantiques. Il faut faire un pas de côté, et se dire que la neige est un facteur comme un autre de discrimination. En résumé, il y a beaucoup à voir avec l’évaluation des corpus.

Est ce que le client comprend que le travail de préparation des modèles ne soit pas immédiatement productif, ou parfois plus long que prévu ?

Dans un premier cas de figure, le client nous contacte parce que le système s’est planté et qu’il faut résoudre le problème. Dans ce cas, oui, c’est facile de justifier le travail d’analyse d’erreurs. On essaie de déterminer à quel moment il y a dérive entre le résultat de l’algorithme et le résultat souhaité, ou bien pourquoi les retours utilisateurs sont mauvais. Par chance, on a rapidement des résultats, on voit souvent rapidement où se situe la dérive et on peut corriger la chaîne de traitement.

Deuxième possibilité, il s’agit d’un lancement de projet et là il faut faire preuve de beaucoup de pédagogie pour que le client comprenne la nécessité d’évaluer continuellement pour ne pas dériver. Les conséquences d’un modèle mal préparé peuvent être lourdes : impact financier, déficit d’image auprès des utilisateurs, etc. Le plus souvent on commence donc à travailler sur un périmètre restreint, puis on élargit petit à petit, ou bien on teste le modèle en amont sur un petit jeu de données, et si les résultats sont bons on passe en production.

Les équipes sont cependant assez promptes à appliquer cette politique de petits pas. Les experts métiers, RH, marketing, prennent d’ailleurs part à la construction des chatbots et ils sont conscients d’avoir leur rôle à jouer, de l’importance de leur inputs pour utiliser les bonnes données, et d’avoir des alertes si c’est nécessaire.

Quelle est la maturité du NLP en France ? Est-ce qu’il y a beaucoup de cas d’usage en production ?

Ça dépend des outils. Il y a eu beaucoup d’engouement sur les chatbots, certains fonctionnent très bien quand le cas d’usage ne demande pas une dimension interactive très complexe. Alexa ou Google Assistant, ce sont pour moi les post it de la voix. Je ne peux pas écrire car je suis dans la voiture, j’utilise mon assistant en mode post it pour noter quelque chose ou poser une question simple. Ce n’est pas très interactif, on donne un ordre, le système répond mais on ne construit pas un échange derrière. On a aussi des chatbots beaucoup plus scénarisés, qui évaluent par exemple la QVT au travail, et qui fonctionnent mieux qu’un échange avec un humain : il n’y a pas de jugement, on est moins dans l’émotion, et cela peut permettre un déclaratif plus fluide. 

Pour résumer, selon qu’on veuille on dimension interactive ou pas, on va mettre en place des systèmes plus ou moins complexes. On doit aussi parfois recourir à des experts pour évaluer le bot, et voir à quel moment l’humain doit reprendre la main pour exploiter les informations collectées. Cette partie du travail est passionnante, l’analyse d’erreurs permet d’apprendre beaucoup sur le cas d’usage traité.

Le mot de la fin ?

J’insiste sur le besoin d’évaluation, d’un point de vue quantitatif. Les métriques sont là : f-mesure, rappel, précision, WER, String error Rate, BLEU, etc. On peut jouer avec et obtenir une bonne idée de la performance des systèmes. Pour le qualitatif, on analysera aussi le caractère utile ou non, gênant ou non, de certaines erreurs chez les utilisateurs.

Un seul mot vous manque, et le monde est dépeuplé : si ce mot est hors vocabulaire, il entraîne des erreurs préjudiciables, et donc il faut réapprendre les systèmes. Et parfois, quelques petites erreurs nous font sourire, mais ne nous empêchent pas de comprendre.

En bonus, l’intervention de Carole lors de l’événement Inov’Dia :