Par: Thibaud VIBES

Introduction

L’activité de Recherche et Développement consiste à mettre au point un produit ou un service qui répond à une problématique nouvelle. Ce produit (ou service) pourra être dit “innovant”.

Onyme propose des “prestations” de R&D, plus particulièrement dans le domaine du Traitement Automatisé des Langues. Nos clients viennent nous voir avec des données (textes) et une problématique à résoudre et nous élaborons avec eux un plan de R&D. Ce plan inclue systématiquement une évaluation continue de la R&D.

Dans ce billet nous vous présenterons notre démarche R&D pilotée par les tests. Un second billet viendra par la suite illustrer cette démarche avec un cas client et des exemples de codes.

Dans R&D il y a Recherche

Le principe de la recherche implique nécessairement une notion d’incertitude et le prestataire (Onyme) ne peut s’engager sur des résultats. Cela relève du bon sens mais aussi du cadre fiscal si le client déclare ses dépenses de R&D en vue d’un crédit d’impôt (CIR). En effet, nos clients ne pourraient en aucun cas déclarer nos prestations en Crédit Impôts Recherche, si nous sommes certains d’atteindre les objectifs demandés et que nous nous engageons contractuellement dessus.
Seuls l’obligation de moyens peut-être contractualisée.

A l’inverse, ce n’est pas parce que la prestation ne définit pas clairement des objectifs qu’il s’agit de R&D : toute prestation que nous facturons fait apparaître la part de R&D. Le client peut donc reporter cette part dans ses dépenses “éligibles CIR” puisque nous avons obtenu l’agrément. Cela peut faire l’objet de contrôles, et s’il s’avère que nous surévaluons la part de recherche dans dans le projet, nous pourrions nous voir retirer l’agrément. Nous mettrions alors nos clients en difficulté qui pour l’Etat auraient “surestimés” leur dépenses de R&D éligibles au CIR. Le risque étant de devoir rembourser le crédit d’impôts, voir de payer une amende.

Présentation de la démarche

S’il n’est pas permis de s’engager sur un niveau de qualité des traitements, il est en revanche permis (et conseillé) de s’engager sur une stratégie d’évaluation de ces résultats.
Pourquoi? Parce qu’il n’est pas question de laisser le client dans un tunnel pendant toute la durée du projet, pour lui indiquer au final :

finalement nous n’avons rien trouvé, voici notre rapport de recherche et nos conclusions …

(traduction: vous n’avez perdu que 60% de la somme grâce aux réductions fiscales, et vous avez quand même un beau rapport de 200 pages)

Chez Onyme, nous incluons contractuellement cette stratégie d’évaluation dans la démarche projet.
La définition intervient généralement en début de projet (voir en avant-vente) et conduit à la production d’un document cadre : le protocole d’évaluation. Il rappelle :

  • le périmètre du projet, c’est à dire la problématique à résoudre. A partir ce périmètre nous pouvons décrire précisement les données et les traitements à mettre au point.
  • les niveaux de qualités attendus par le client (la cible à atteindre). Ce n’est pas parce qu’Onyme ne peut s’engager sur ces niveaux que le client n’a pas le droit d’avoir d’exigence / une idée précise de ce qu’il souhaite obtenir.
  • les indicateurs de mesure de qualité. On parle aussi de “performance”.
  • les modalités du reporting : fréquence des rapports d’évaluation, format, destinataires, …
  • les jeux de données employés pour réaliser les mesures.

L’idéal étant de pouvoir automatiser l’évaluation du système et la génération des rapports…

Difficultés et enjeux de l’évaluation

The essential problem of NLP evaluation is that the evaluator has to advance between Scylla and Charybdis
Karen Sparck Jones, 1994, Towards Better NLP System Evaluation

(source: http://www.aclweb.org/anthology-new/H/H94/H94-1018.pdf)

Traduction: Dans le domaine du TAL, définir un bon un outil de mesure de la qualité du traitement est aussi complexe que la mise au point du traitement lui même, car cela revient (dans l’idéal) à résoudre la problématique en elle même. Dans cette citation de Karen Sparck Jones (merci à Benoît), le problème est alors comparé en terme de difficulté à celui d’échapper aux monstres Charybde et Scylla.

L’évaluation doit, d’autre part, reposer sur un jeu de données. Celui-ci doit avoir les caractéristiques suivantes :

  • Représentatif des futures données à traiter
  • Stable dans le temps pour pouvoir comparer 2 rapports d’évaluation
  • Couvrant tous les aspects du problème

Le principal enjeu est d’impliquer le client afin de construire un jeu réaliste, car c’est lui qui maîtrise le mieux les données à traiter.

La consitution du jeu de données initial ainsi que la solution d’évaluation automatique peu paraître fastidieuse au départ. Heureusement, avec Internet on ne part jamais vraiment de 0. Il existe de plus en plus de site qui partagent des données qui peuvent correspondre à la problématique de départ (au moins en partie). Un exemple avec : http://www.freebase.com/
Il est aussi possible de faire appel à l’ “altruisme” et l’esprit communautaire des gens. En ce moment, le laboratoire LIDILEM (université Stendhal – Grenoble 3) propose de “faire don de vos SMS à la science” afin de constituer un corpus de 30 000 SMS (rendez vous sur http://www.alpes4science.org/)

Conclusion

Dans cet article nous enfonçons quelques portes ouvertes, mais ceci dans un seul but: montrer que l’évaluation continue doit faire partie intégrante du projet de R&D.
C’est un point crucial car sous-traiter sa R&D est une affaire de confiance.

Une fois opérationnelle, la solution d’évaluation continue apporte une vision globale sur les performances du système développé, permet d’évaluer les impacts de toutes modifications, de mesurer les progrès effectués… Au final elle permet de prendre consciencieusement LA décision vraiment importante : doit-on poursuivre l’investissement de R&D?

Dans un prochain article, nous vous présenterons concrètement des outils, du code pour produire une solution d’évaluation qui rassure le client.