Programmer des règles, ou apprendre à partir d'exemples

Un développeur qui calcule une taxe lit la règle dans le code des impôts, il l'écrit, la machine l'applique, et la réponse tombe. Programmer, c'est cela : on donne les règles et les données, la machine rend les réponses.

Maintenant, demandez à ce développeur le prix d'un appartement : il n'a plus de code des impôts, et le prix dépend de la surface, du quartier, de l'étage, de l'état du bâtiment, de ce qui s'est vendu dans la rue le mois dernier. Personne n'a écrit cette règle-là, et personne ne l'écrira.

L'agence, elle, a mille ventes dans ses fichiers, et pour chacune ce qu'était le bien et ce qu'il a coûté.

Dessinons trois boîtes : les règles, les données, les réponses. En programmant, les deux premières entrent et la troisième sort.

Maintenant échangeons-les : les données et les réponses entrent, et ce qui sort, c'est la règle.

La machine ne devine pas ce qu'on cherche. Quelqu'un doit lui donner trois choses avant qu'elle commence : la forme des règles qu'elle a le droit d'essayer, les exemples sur lesquels travailler, et la façon de compter ce qu'une mauvaise réponse coûte.

« Personne ne sait écrire la règle » se mesure. Prenons les 6 131 images du chiffre 3 d'un fichier public de chiffres manuscrits, chacune en 28 sur 28 pixels, soit 784 pixels par image. Un pixel est encré quand il porte de l'encre, et blanc sinon.

Cherchons un pixel encré sur toutes ces images à la fois : il n'y en a aucun. Cherchons ceux qui ne sont encrés sur aucune : il y en a 242, et ce sont les bords, toujours vides.

Entre les deux, rien de commun : deux 3 ne se ressemblent pas pixel à pixel.

Ce qui fait qu'un 3 est un 3 tient dans l'arrangement de l'encre, pas dans les pixels pris un à un.