vendredi 30 novembre 2018

Cette fonctionnalité est-elle vraiment utile ?

"Il y a des choses qui sont prévues pour être utilisées et d'autres pour être achetées... il n'y a pas forcément une correspondance parfaite entre les deux..." (moi)

Dans le secteur de l'édition de logiciel on arrive souvent à discuter de l'intérêt de créer ou garder certaines fonctionnalités. En effet accumuler des fonctionnalités peut être un problème pour plein de raisons :
  • coût du développement de ces nouvelles fonctionnalités
  • plus de bugs potentiels
  • augmentation du périmètre de maintenance
  • complexité accrue pour l'utilisateur
Il y a même des entreprises qui font du test A/B pour évaluer l'intérêt de garder une nouvelle fonctionnalité. Chez Booking par exemple, ils font des tests A/B pour s'assurer qu'une fonctionnalité leur rapporte de l'argent. Si ce n'est pas le cas, la fonctionnalité est supprimée.

Cependant, toutes ces approches négligent un aspect important de la raison d'exister d'une fonctionnalité.

« Il y a des choses qui sont prévues pour être utilisées et d'autres pour être achetées... il n'y a pas forcément une correspondance parfaite entre les deux... »

Certaines fonctionnalités sont prévues pour "faire vendre" mais ne seront pas utilisées. Cela peut paraître étrange, mais c'est une réalité. Pour vous en convaincre demandez vous combien d'acheteurs de véhicules 4x4 utilisent réellement la "fonctionnalité 4x4" ? Très peu, d'autant plus que ce type de véhicule sont souvent populaires en région très urbaine. On peut se dire que c'est le look du 4x4 qui fait vendre, et dans ce cas ça peut être vu comme une "fonctionnalité" utilisée... Mais dans ce cas on pourrait aussi se dire que les constructeurs pourraient simplement créer des véhicules ayant le look 4x4, mais pas le poids (et la consommation), ni la puissance moteur et encore moins le complexes système de transmission 4x4... Pour autant (et à ma connaissance) ce type de véhicule n'existe pas vraiment, peut être justement parce que l'acheteur veut réellement un 4x4, même s'il sait qu'il n'utilisera pas la fonctionnalité spécifique du 4x4.


Certaines fonctionnalités font vendre, mais ne seront pas utilisées par les acheteurs!

On peut croire que ce mode de choix un peu schizophrénique, est uniquement présent en B2C, là où le choix ne dépend et n'impacte qu'une seule personne. Cela illustrant parfaitement l'achat plaisir, qui par définition n'est pas rationnel. Mais cela arrive pourtant aussi en B2B!

Cette irrationalité est même facilement mesurable quand on vend un service en SaaS, puisqu'on peut facilement tracker l'utilisation de chaque fonctionnalité.

Cette irrationalité peut s'expliquer par la méthodologie des choix de services en entreprise.

Voici comment ça marche. Une personne est mandatée pour choisir un service parmi une longue liste. Cette personne n'est malheureusement pas la personne qui utilisera le service en question, car souvent considéré comme simple exécutant, l'entreprise lui préférera un cadre ayant une approximative expertise dans un domaine connexe. Puisqu'on parle se logiciel, assez naturellement c'est souvent un directeur informatique qui sera choisi. Comme il n'a pas d'expertise dans le domaine d'application du service en question, il va  essayer de rationaliser son choix en faisant une feuille de tableur. Une ligne pour chaque service, et une colonne pour chaque fonctionnalité du produit. Il va alors balayer toutes la documentation disponible et remplir le tableau avec des oui/non qui résumeront la présence ou non de chaque fonctionnalité pour chaque service. A la fin il donnera une note pour chaque service, simplement en comptabilisant les oui/non de chaque service. Et souvent sans pondération, toutes les fonctionnalité ayant le même poids, simplement par ce qu'il n'est pas celui qui utilisera le service et que fondamentalement il ne comprend pas ce qu'il y a derrière le nom de chaque fonctionnalité.

On arrive alors à la situation où les éditeur logiciels sont condamnés à proposer certaines fonctionnalités, même si celles-ci ne seront pas utilisées. À partir du moment où suffisamment de concurrents la proposent, alors il faut l'avoir pour avoir une chance dans les appels d'offres.

Donc, réfléchissez y a deux fois avant de dire qu'une fonctionnalité est inutile. ;)
Je conclu en citant Jérôme Bonaldi  :

« C'est totalement inutile et donc rigoureusement indispensable ! »

Et en remerciant Rémi Aubert (CEO et fondateur d'AB Tasty) qui m'a fait comprendre ce mécanisme.

mardi 2 octobre 2018

livre sur l'e-commerce

Le 24 octobre 2018 paraîtra un livre sur l'e-commerce, dans lequel j'ai (modestement) participé.
Ma contribution est sur les outils de type Intelligence Artificielle (IA) qui participent à la gestion marketing des sites e-commerce.



Pour plus d'info sur les autres auteurs, ainsi que des chapitres gratuits, allez directement sur le site d'auteur principal : Jean-Eric Pelet.

Et pour l'acheter c'est ici. 

mercredi 5 septembre 2018

How does a machine learn?


How does a machine learn?
Preamble : This article is a article aimed to explain “Machine Learning” basics in a intuitive fashion for developers.

Introduction

Today there is a huge hype about “Artificial Intelligence”, more especially about “machine learning”. This programming paradigm is very different from the classic old one. The origin of programming is based on the algorithm principle which is a formal description sequence of unitary operations to be made in order to perform the desired task. On the other side “Machine Learning” (ML) is about using examples of solved task to train a “model”, like a teacher showing examples to his students. This is considéred as a more powerful programming paradigm since a lot of tasks cannot be described as a formal sequence of unitary operations. Think about recognising a familiar face, identifying the voice of someone, extracting the sentiment from a text, detecting trolls on a forum, etc… All these tasks can be described with examples but not with a formal sequence of unitary operations.
This covers why machine learning is so interesting. However it does not explain how machines learn...  
Spoiler!: The trick to machine learning is to transform a learning problem into an optimization problem (which is something engineers easily deal with). This is explained in the rest of this article while explaining what is a “example”, a “model”, a “training”, and why does all this sometimes fail.

Ok, this introduction already yields some questions.

What do you mean by  “example“?

It’s a pair of (input,output) information, the input side is the information your have about the task, for instance a person’s picture for an identification task. The output is the solution of that given task (ie. the name of the person on the picture). These informations are transformed into numbers in order to be fed into a “model”. Typically a picture is a set of pixel which are numerical values. On the other hand the expected output in this example is a name, which is not numerical. Thus, it must be transformed into a number, in this case index of a list of all names. This list is necessary in order to be able to show a human readable answer at the end of the process.
Generally, when training a model, a training database is used: a large number of (input, output) pairs, enough to obtain a viable model for the targeted task.
Since input & output may have more than one dimension we often refer them as input & output vector. But for the sake of simplicity let’s consider them as one dimensional values (scalars), which allow an interesting graphical representation: Laying the input on the x axis, and the output on the y axis, shows the training database as a point cloud.

So what is exactly a “model”?

Considering the above figure, the “model” is a curve that fit to the point could. Specifically it’s a “class of curves”, since there is not a unique solution. Consider the model as a type of curve that has the ability to fit the point cloud with given properties.
One can see the machine learning paradigm as a interpolation problem : with a new input value (X) what would be a credible (Y) value ?
A model can be seen as an “empty brain”. Since input & output of the task are seen as numbers, one can see the model as a mathematical formula. This curve is in fact a mathematical function, a parametric function. The parameter are values that can be estimated in order to fit the point cloud, but they are not set for the moment (we will see that later).

modelparameters(input) = output


This mathematical function is where the magic happens. It transforms the input number into a numerical output (the result) that will, in a later stage, be transformed back into a usable information (for instance an index, that will be transformed back into a name from a list). At this stage the model is still “empty” so the answer is random (or undefined). A model needs to be “trained” in order to provide meaningful answers.
There is a lot of different models ((deep) neural networks, linear regression, etc…). All are mathematical functions with different properties more or less suited to different kind of tasks.

What does it mean to “to train a model with examples” ?

Training a model means finding parameters of the underlying formula in order to produce correct answers for given inputs. The output of a model is numerical and known (remember: the example task is already solved outside of the model), this means we can express the error a model makes as a numerical value. We are then facing a “classic” equation resolution problem:
modelparameters(input) = output
At the beginning, model parameters are unknown and usually initialised at random, hence producing an irrelevant output at this stage.  We can measure the error of the model as:
Error = modelparameters(input) - expected output
In practise, we use more complex error formula, but the main idea remains. When the error is minimized, the learning is done.
The error is basically the distance between the point cloud and the curve. The learning process is a step by step optimisation of the parameter of the model, in order to fit the point cloud. 




The same process can be viewed as this block diagram :


The learning problem becomes an optimization problem!
Optimization is an old mathematical field, well known by engineers. Given an input/output dataset and a model (with unknown parameters), the optimization process outputs model parameter values.
Common optimization strategies are: stochastic gradient descent, Monte Carlo Markov Chain, BFGS, …
This process can be quite long and heavy depending on the model complexity and the learning database size (with far more than 3 learning steps).
When a model, its parameters and input are known, one can easily compute the output from new and previously unseen input data : it’s just evaluating a function.
This phase is very fast (regarding to the learning phase).


And sometimes it fails !
One important thing the point cloud analogy help to understand, is that there is more than one solution, because more than one curve can fit a point set. The less training point one have, the more different solutions are possible. That’s why ML need a lot of data to produce accurate results. As a consequence GAFAM, that hold most of the internet data, have a great advantage. 
And sometimes, the learning procedure can still fail, even when the measured error is very small. This graph shows how a model can fit data with a very low error, but can still be totally wrong when tested on new data.


What is the main difference with classical programming?
  • ML gives the ability to a programmer to train a model on a task that he is unable to do by himself (assuming he can obtain a training dataset for that task)!
A classical developer can only make program that automates things he could do by himself. It’s even more powerful that human learning: a teacher can’t teach you something he doesn’t know! A ML practitioner trains a computer to do something he can’t do by himself. This is a real shift in human potential.
For instance I built DNA analysis softwares while lacking any biology degree.
  • Algorithm used in classical programming are often mathematically proved. This means that they are more reliable. Most of the times the bugs comes from error in the implementation (ie. the translation of the algorithm principles into a programming language).
ML programs cannot be proved to be 100% accurate, but they tackle problems that cannot be solved at all with classical programming. One still has to handle the fact that there will be errors. Good ML practitioners are able to measure the validity of their models, and know how to handle risks and consequences of errors.
(One third of introductory course on ML are about evaluating a model.)
  • The model and the optimisation phase still use classical programs, hence why ML practitioners are mainly computer scientists... with a slightly different profile. They are more math friendly people than typical developers. These kind of profile is quite rare, regarding to the high number of developers. This means that they are highly demanded. ML is not new, but it gained popularity quite recently, with the shift of all sort of business activities (e-commerce, advertisement, ...) toward the web where data collection is cheap & easy.

jeudi 24 août 2017

Minimum Detectable Effect calculator


MDE calculator

This form calculates the Minimum Detectable Effect for an AB test.
Enter the number of visitors you have and the conversion rate of the page you want to test, then clic on the run button...
You will get the size of the Minimum Detectable Effect of your experiment.

Total number of visitors :
Initial conversion rate : %

Minimal Detectable Effect :


Feel free to ask questions in the comment section or via twitter (@hwassner).

Go to the AB Tasty website for a nicer interface of that tool.

lundi 21 août 2017

Minimum Detectable Effect

La fin du "sample size calculator"


Dans la pratique du test A/B, il est recommandé de prévoir la taille de l'échantillon de visiteurs que l'on va tester. Ce conseil provient de la pratique industrielle, pour laquelle la taille de l'échantillon est importante, car elle définira le coût de l'expérience. L'objectif est de maintenir ce coût le plus bas possible.
C'est à cela que les "sample size calculator" servent. Ils demandent le taux de réussite actuel (taux de conversion) ainsi que la taille de l'effet minimum que l'on cherche à mesurer. Le résultat du calcul est la taille de l'échantillon nécessaire pour que l'on puisse conclure d'une telle expérience.

Cela se transpose mal dans le monde du web car la situation est différente :
  • Mesurer les conversions ne coûte rien (contrairement à l'industrie)
  • Le nombre de visiteurs est une donnée du problème (pas la réponse)
  • L'effet de la variation est difficilement prévisible.
    (en pratique c'est même précisément la question qu'on se pose!)
Cela rend très difficile l'usage des calculatrices de taille d'échantillon.

Pour autant, être capable de savoir ce que l'on peut vraiment mesurer est très important.

Pour le web il faut une formule qui marche dans l'autre sens.

On spécifie :
  • Le taux de conversion actuel 
  • Le trafic de la page à tester
 Et la formule donne la taille minimale de l'effet induit par la variation qu'on sera capable de détecter :le MDE (Minimal Detectable Effect).

J'ai développé une telle calculatrice, vous pouvez y accéder ici, dites moi ce que vous en pensez.

mardi 31 janvier 2017

Régulation des algorithmes (suite)

Hier soir j'étais à une réunion de présentation à CAP Digital,sur le sujet de la "régulation des algorithmes"... (vous pouvez lire l'article précédent sur ce sujet ici.)

Je suis plutôt content car les gens qui on présenté le problème semblent bien avoir compris quelques subtilités du problème comme :
  • Surveiller à la fois les algorithmes mais aussi les données utilisées pour les paramétrer. Dans le domaine du "machine learning", on parle de données d'entraînement. Ces données , plus que l'algorithme lui-même, décide du comportement prédictif. 
  • Certains algorithmes sont, par constitution, non-analysable, non-explicable. On parle de boite noire, mais pas par volonté de cacher les chose, mais fonctionnement de base.
  • L'INRIA, partenaire scientifique, ne se positionne que comme centre de ressources de solution scientifique/technique de mesure.
Bref, ils ont comprit qu'il s'agit d'un problème fondamentalement complexe pour lequel il n'existe pas de solution technique aujourd'hui. C'est rassurant.

Ce qui l'est moins :
  • Aucune start-up du domaine ne fait partie des rapporteurs.
  • Personne n'a soulevé le risque de créer une régulation qui serait dangereuse pour les entreprises françaises travaillant dans le "machine learning". En effet, imposer une régulation implique avoir un levier d'action envers les contrevenants, or aujourd'hui les GAFA (Google, facebook, Amazon, etc...) sont totalement intouchables (elles ne payent même pas les impôts sur le bénéfice fait sur le sol français). Une régulation franco-française ne ferait donc que les avantager encore plus par rapport aux start-up française.
    L'effet de la régulation serait alors inverse à l'objectif, car ces algorithmes seraient alors totalement pilotés par des entreprises étrangères non soumis à la réglementation, et donc totalement hors de contrôle.
    Sans parler de la destruction d'emploi et la perte de revenu fiscal.
Bref, tous les acteurs ont bien identifiés qu'on est incapable aujourd'hui de faire quelque action censée que ce soit dans ce domaine. Mais je crois que c'était a peu près la même situation pour HADOPI : personne ne croyait vraiment pouvoir endiguer la copie illégale par manque de solution technique. Pourtant HADOPI a bien été crée, et a gaspiller beaucoup d'argent pour rien.
J'espère juste que ce cela ne se reproduira pas.

Je ne vois donc pas de risque imminent, mais c'est tout de même un sujet à "surveiller".


lundi 30 janvier 2017

Régulation des algorithmes ?

Vous en avez peut être entendu parler : l'état français réfléchit à créer une instance de "régulation des algorithmes". En clair il s'agit de placer des limites éthiques d'utilisation du "machine learning".
Je vais ce soir à une réunion de présentation à CAP Digital, j'espère y avoir quelques éléments de réponse à ces questions qui me sont venues à l'esprit :
  • Ce contrôle n'est-il pas un frein au développement du "machine learning" et de l'Intelligence Artificielles en France ?
  • Comment, en pratique, contrôler un algorithme?
    • Bien souvent, ces algorithmes sont considérés comme des secrets industriels.
    • En "machine learning" les algorithmes sont souvent "neutres", c'est les données qui les pilotent vraiment. Or ces données sont souvent confidentielles, et en plus elles peuvent changer très rapidement. Les algorithmes devraient alors être surveillé en permanence!?
    • Alors qu'on manque déjà de gens pour créer ces algorithmes, où trouver des gens pour les contrôler? Il semblerait que des gens de l'INRIA composerait une commission. Problème : l'INRIA vend aussi de tels algorithmes, peuvent-il être juge et partie ? et en plus avoir le droit de consulter tous les algorithmes de leur potentiels concurrents ?
    • Beaucoup de techniques de "machine learning" produisent des algorithmes dont même leur créateurs sont incapable de définir précisément les modes de fonctionnement. Cette incapacité est souvent due à des raisons théorique (ou l'absence de théorie suffisamment avancée) et non à l'incompétence de leur créateurs.
Si d'autres questions vous semblent intéressantes suggérez-les moi via Twitter (ou en commentaire de cet article).

Je ferai prochainement, ici, un bilan de ce que j'aurai entendu à cette réunion.