En y réfléchissant un peu, un texte, des phrases, des mots, ne sont que de simples suites de caractères, tout comme une image n'est qu'une simple matrice de pixels. Cependant, notre cerveau est capable d'interpréter cet enchaînement de caractères, et de l'associer à des concepts, en d'autres termes de lui donner du sens. Si on prend un peu de recul là-dessus, on peut se dire que notre cerveau est sur bien des aspects clairement impressionnant.
Un enjeu de ces dernières années, c'est entre autres de permettre aux ordinateurs d'imiter cet aspect notre cerveau, en leur donnant la capacité de trouver le sens de la donnée avec laquelle ils travaillent. C'est par exemple ce que tente de faire l'intelligence artificielle.
Je vous rassure tout de suite, on ne va pas du tout parler d'intelligence artificielle (même si cela serait extrêmement intéressant). On va cependant réduire notre champ de travail et essayer de comprendre comment il est possible d'attribuer un score de corrélation entre un texte donné et une multitude d'autres. Et pour cela, on va se pencher sur la manière dont se prend ElasticSearch (ou plutôt Apache Lucene) pour répondre à cette problématique.
Bienvenue en terminale, vous avez deux heures. Cette équation (simplifiée) représente une manière de calculer ce fameux score de corrélation, et c'est exactement ce que nous allons décortiquer.
Dans un second temps, nous verrons comment nettoyer un texte "humain" afin de faciliter sa compréhension par un ordinateur. Char filters, tokenizers, token filters, tant d'outils qui permettront de réduire un texte à son sens profond, de réduire son "bruit" afin d'optimiser les scores de corrélation.
Et petit bonus, vous pourrez même briller en société en étant en mesure de placer dans vos soirées mondaines des termes comme "Term frequency", "Inverse document frequency", "Coordination factor", "Inverted index"...
_ Mathias Arlaud : Bonjour. Bonjour à tous. Ça fait vraiment plaisir de faire partie de cette édition du Forum PHP 2022. Vous êtes nombreux. Il y a presque plus de place. Ça me stresse un peu. Nous allons être honnêtes. Ça fait moins de deux ans que je donne des conférences, et je n'arrive pas à m'y faire. On a peur de bégayer et d'oublier ses mots. Ça ne change pas. Nous avons peur d'avoir des problèmes techniques.
D'ailleurs, en parlant de problèmes techniques, on m'a donné une astuce. Elle peut se trouver dans le livre de Pascal. Il faut qu'elle y soit. L'idée, c'est de dupliquer sa première slide. Elle y est ? C'est bon. Comme ça, on peut tester la zapette sans dévoiler le contenu de son talk. Ici, j'ai changé de slide. Je suis sur la deuxième. Vous ne voyez que du feu, mais je me suis assuré que mon matériel fonctionne. C'est une astuce qui permet de réduire le stress.
On s'en fout un peu. On va parler aujourd'hui d'ElasticSearch. Ou plutôt de son moteur. Apache Lucene. On va voir ensemble comment Apache Lucene est capable de comprendre le sens qu'il y a dans les textes et attribuer un score de corrélation entre les deux textes. Ce sera la première partie. Ensuite, nous verrons du côté d'ElasticSearch pour voir quels outils il nous met à disposition pour nettoyer des textes qui sont écrits par les humains. Nous faisons beaucoup de bruit qui masque le son*. Nous voyons comment nettoyer son texte. Ce sera pas mal.
Ça commence super bien. Ça fait 30 secondes, 59 secondes que je vous parle. Je vous ai déjà menti. Vous allez voir, c'est pour la bonne cause. À vrai dire, les deux slides que je vous ai montrées, elles ne sont pas identiques. Nous sommes sur la seconde. Elle est un petit peu plus claire que la première. Avec le rétro, ça ne se voit pas trop. Mais ce n'est pas exactement les mêmes. Pour vous, les deux slides représentent la même chose. Deux personnes dans les vignes. Mon père et mon grand-père. Ça représente la même chose. Cependant, pour un ordinateur, pas un seul pixel n'est pareil. Ce sont deux images qui sont fondamentalement différentes. Je trouve que c'est un super exemple pour montrer la différence entre le super cerveau humain et le cerveau plus brut de décoffrage un ordinateur qui est dépourvu d'interprétation.
Je vais me présenter rapidement. Moi, c'est Mathias. Je suis développeur PHP chez Les Tilleuls. Je suis un aficionado d'Open Source. Je travaille beaucoup avec Symfony. J'aime beaucoup comprendre comment les choses fonctionnent. Je me suis demandé comment fonctionnait ElasticSearch pour trouver la correspondance en termes de sciences entre deux textes. Ce que j'ai trouvé, je l'ai trouvé très intéressant. J'ai eu envie de le partager avec le plus grand nombre.
Ici, j'ai écrit : Moi, c'est Mathias. J'aurais pu écrire : Je m'appelle Mathias. Pour vous, c'est encore la même chose. C'est une personne ici présente qui se présente. Mais pour un ordinateur, on va entrer dans la technique. Pour ce qui est de l'information, un ordinateur utilise des bytes. Des uns et des zéros. Pour que nous ayons plus de facilité à les lire, nous les regroupons par paquets de quatre. Ça fait 16 valeurs différentes possibles. On va leur assigner des caractères. Qui vont de zéro à neuf. Et ensuite, de A à F. C'est le code hexadecimal. On retrouve le texte codé en hexadecimal. Si jamais vous voulez écrire "Mathias" en exemple, ce sera disponible. Ce qu'on distingue, c'est écrit en gros. On voit que Mathias est identique. C'est plus dur ici de voir que ça a le même sens et la même implication. C'est ce que voit l'ordinateur. Nous comprenons l'ampleur du travail que va devoir mener Apache Lucene. À quel point ça va être complexe pour résoudre cette problématique. Je vous rassure, pour la suite de ce talk, on ne va plus utiliser hexadecimal, mais l'alphabet.
Avant de décortiquer tout cela, je vais parler d'ElasticSearch dans les grandes lignes. Pour que tout le monde soit sur la même longueur d'onde. Quand nous recherchons quelque chose. Voilà ce qui se passe. ElasticSearch va parcourir tous les documents de la base de données. Un à un. Attribuer un score de corrélation entre la byte de recherche et le texte du document. Ensuite, ElasticSearch va envoyer les documents attribués par score.
Comment on pourrait essayer de deviner les scores maintenant ? On cherche comment quitter vim.
Premier document, on sent bien que le salon du vigneron indépendant n'a pas trop de sens, de lien avec cette recherche. On pourrait lui donner un score de 0,6. Quitter son emploi avec rupture conventionnelle. Il y a un petit peu plus de liens. Nous avons la notion de quitter. Mais c'est tout. On pourrait avoir un score un peu plus élevé. 1,2. Vim pour les nuls. Ça pourrait avoir un score plus élevé. Nous avons la notion de vim qui coïncide. C'est quand même moins fréquent que de quitter. Ça aura plus d'importance vu un score plus élevé. Si on regarde : Impossible de quitter vim. Nous avons les deux notions. Nous avons la notion de quitter, fermer, vim. Ce serait le document avec le plus haut score. Ce serait celui qui serait renvoyé en premier dans la liste des documents que retournerait ElasticSearch.
Nous avons attribué des scores au doigt mouillé. Nous allons voir la fonction mathématique qui se cache derrière pour attribuer ces fameux scores.
C'est bon ? Personne ne s'en va ? Je vous présente (équation). Je dois vous dire que ce n'est pas ce qu'on va regarder. C'est l'équation qui est utilisée par Apache Lucene. Mais elle est trop complexe à vulgariser. Ce n'est pas celle-ci que j'ai choisi de vulgariser. Nous allons voir une ancienne version de l'équation qui est plus simple et qui reprend les mêmes idées et les mêmes concepts. On peut imaginer que celle-ci fasse grosso modo la même chose. Voici l'autre. Ça va mieux ? Elle est plus simple. C'est bon ? Personne ne s'en va. C'est cool. Mais si vous avez envie de partir, laissez-moi vous rassurer, ce n'est pas si compliqué. À partir du moment où on va décortiquer l'équation, prendre les éléments un à un, nous allons regarder les concepts qui se cachent derrière. C'est pour vous faire peur que j'ai fait cela. Ce n'est pas compliqué.
En gros, comment ça marche, le score d'un document D pour une recherche Q. On utilise chaque élément de la recherche. Pour chaque mot de la requête, on va multiplier deux choses : le term frequency et IDF. On va la multiplier par le coordinator factor. On les modifie. Normalement, on la modifie comme cela. C'est plus digeste. Mais on n'a toujours rien compris. Nous sommes d'accord. C'est pour cela que nous allons nous pencher sur chacun des éléments tranquillement. Avant de faire cela, j'aimerais m'assurer que nous soyons tous sur la même longueur d'onde. Nous allons décortiquer un petit peu l'équation.
Ici, nous recherchons vim pour les nuls. Le score d'un document donné, c'est sigma DTF par IDF. Ça va donner... (équation) c'est la version éclatée de sigma. Nous multiplions le tout par C. voilà.
Nous allons enfin pouvoir entrer dans le détail. Nous allons commencer par le fameux TF : term frequency. C'est l'élément de base du calcul de la pertinence de documents. C'est simple. Chercher la valeur de TF, ça revient à se demander si un mot d'une requête apparaît souvent dans un document. Plus un mot dans une requête apparaît souvent dans un document, plus il y a de chance que ce document soit en lien avec la requête. Logique. Comment on traduit cela avec les outils mathématiques ? C'est plutôt simple. TF d'une enquête T, ça revient à compter la récurrence du T dans le document. On va appliquer une racine carrée. Ça nous sert à éviter que les scores partent dans la lune et deviennent trop gros. C'est pour contenir le nombre d'occurrences de T dans le document D. TF de T, c'est ça. Le nombre d'occurrences de T dans un document D. Plutôt simple. Nous allons illustrer tout cela avec un exemple. Cet exemple va nous suivre tout au long du talk.
Nous disposons d'une base de données ElasticSearch plutôt orientée développement. Avec un moult document. Nous avons décidé de garder deux documents sur lesquels nous allons nous concentrer. Vim et nano. Comparer avec un autre. On va rechercher vim et développeurs.
Pour rappel, chercher le term frequency dans vos données revient à compter le nombre d'occurrences de ce mot dans la recherche, dans le document. Si on prend le premier document, nous remarquons que vim apparaît une seule fois. TF de vim = racine carrée de 1. Mais développeur n'apparaît pas dans le premier document. Term frequency de développeur = racine de 0.
Nous avons nos term frequency. Ce qu'on peut essayer de faire, c'est de le remplacer dans notre équation. On se retrouve avec le premier document. (équations rapides)
S'il n'est pas dans le deuxième. Ça ne sert à rien. Mais vous m'avez compris. Racine carrée de 1, ça vaut 1. Racine carrée de zéro, ça vaut zéro. Nous pouvons simplifier l'équation.
(coupure de son)
Nous avons déjà bien avancé, non ? C'est plus compréhensible. Il nous reste à trouver les autres inconnus qui sont les différents IDF et les différents C.
Nous passons à IDF. Il faudra s'accrocher. Chercher inverse documents frequency de vos données. Ça devient à se demander si ce mot est vraiment pertinent pour la recherche. Si nous cherchons vim. Il a plus de sens que le mot E. C'est ce que le inverse document frequency va faire apparaître dans notre écart. Avec les maths. C'est plus complexe. Mais... c'est 1 + le logarithme, c'est comment nous avons de documents dans notre base de données, divisé par le nombre de documents dans notre base de données qui contient la recherche D. 1 + log ici, c'est là pour des soucis de normalisation. Pour contenir le score. Si on oublie tous les outils, on peut simplifier comme cela. IDF d'un mot T... ça va servir à lisser les mots qui paraissent souvent. Dans la base de données. Les données moins d'importance. Exemple. Si on prend le mot "le", il y a de grandes chances qu'il apparaisse dans un très grand nombre de documents de notre base de données. N de T sera grand. Plus il est grand, plus la division est importante. Plus le score va être petit. C'est comme cela qu'on va donner moins d'importance au moult. Je trouve cela ultramalin.
Reprenons un exemple. Nous n'avons pas listé la totalité des documents disponibles dans notre base de données. Nous allons supposer les différents IDF. Vim n'est pas très courant. Nous lui donnons un IDF de 1,7. Et, c'est un mot de liaison. Il aura un petit IDF de 0,8. Pour les développeurs, on peut imaginer qu'il est là moins souvent que le mot "et", mais plus souvent que le mot vim. On peut trouver un IDF entre les deux. C'est une supposition.
Si on reprend notre équation et qu'on remplace les IDF par leur valeur respective, on se retrouve avec le premier document qui a 1,5 x C, et le troisième document qui a 3 x C. J'ai oublié de vous parler... J'avais peur de faire une gaffe. Quand je vous ai présenté les deux documents au début, je voulais qu'on prenne un peu de recul et qu'on se dise : on peut essayer de deviner quel document a le plus haut score. Nous avons vim et nano, la comparaison. Et ensuite, développer avec vim, introduction pour un développeur débutant. On sent que le deuxième document a plus de lien avec la recherche que le premier. Le premier, il va faire intervenir la notion de vim. Il y a seulement vim qui marche. Tandis que développer avec vim, introduction pour développeurs débutants, on voit que ça contient la relation entre vim et les développeurs. Nous aimerions que le score du deuxième document soit plus haut. Ça commence à transparaître dans l'équation. Pourquoi ? Nous avons deux mots qui matchent. C'est grâce à IDF pour l'instant. Nous avons vim qui matche pour les deux documents. Le mot "V", il apparaît souvent. Il a un petit IDF. Développeur, c'est plus important. Il y a un écart entre les deux documents.
Fin de la parenthèse. Il nous reste à trouver les valeurs de C. Après, fini avec les maths. C'est dur. Jeudi matin. 9h00. Je suis désolé.
Dernier élément, le coordinator factor. Il est là pour compenser et valoriser les documents avec le plus haut pourcentage de mots de la requête présents. Ça paraît logique. Plus nous avons de mots de la requête qui se trouvent dans le document, plus nous avons de chance que le document soit en lien et pertinent pour nous. Voilà, C. C'est plutôt simple. C'est le nombre de mots de la requête qui se trouve dans le document divisé par le nombre total de mots de la requête. Il faut le voir comme un pourcentage. Le pourcentage du nombre de mots de la requête qui se trouvent dans un document donné. Avec un exemple, c'est simple. Premier document, il a deux mots de la requête qui sont présents. Le deuxième document, même chose, mais pas les mêmes. C'est donc deux tiers. Nous reprenons l'équation une dernière fois, nous reprenons les derniers inconnus. Nous nous retrouvons avec les scores finaux. Nous avons un score de 1,6 pour le premier document et de 2 pour le deuxième. Ça représente notre intuition tardive du fait que le deuxième document est plus pertinent que le premier. C'est cool. Mais je ne suis pas très satisfait ici. Oui, le deuxième document score plus important que le premier. Mais l'écart n'est pas très important. C'est le signe que le programme ou la fonction mathématique n'a que partiellement saisi le sens de ces trois textes.
Nous, les humains, quand nous écrivons des textes, nous aimons faire des trucs en plus. Nous allons ajouter de la ponctuation, nous allons faire des déclinaisons. Des métaphores, si ça nous fait plaisir. Nous allons mettre plein de bruit, notre texte sera plus agréable à lire. Mais ça va ajouter du bruit sur le sens profond de ce qu'on veut faire passer. Ça parasite le sens profond de ces trois textes. Ça brouille les pistes de notre équation. Elle sera moins efficace. Elle va donner des scores qui sont moins pertinents. Nous entrons dans la deuxième partie de notre talk, voir comment il sera possible de nettoyer ces textes et d'enlever tout le bruit que nous avons mis nous les humains. Pour aider l'équation à avoir des scores plus pertinents et importants.
Nouvel exemple. Nous avons un texte écrit par un humain. Nous avons un texte écrit à la va-vite. Nous avons des majuscules là où il ne faudrait pas. Et nous avons des emojis. Il manque des espaces. Nous avons une entité HTML. Celui qui a écrit ça a fait n'importe quoi. Mais je crois que la totalité d'entre vous, en un coup d'œil, nous avons compris ce qu'on a vu. Les développeurs aiment développer avec vim. Vrai ou pas ? C'est un autre débat.
Ce qu'on va devoir faire, c'est nettoyer ce texte. Pour cela, ElasticSearch propose des outils très cool qu'on appelle des Analyzers. Ils seront là pour nettoyer la chaîne et la transformer en tokens. Les analyseurs sont développés en plusieurs familles. Les filtres de caractère, les générateurs de tokens, et les filtres de tokens. En tant que développeur, notre job sera de créer un flux d'analyseur pour nettoyer au mieux notre chaîne de caractère et avoir les tokens les plus adaptées possibles. Il n'existe pas un enchaînement universel. Ça dépend de nos besoins. L'enchaînement ou le flux d'analyseur que je vais vous présenter aujourd'hui est là à titre pédagogique. N'essayez pas ça à la maison. Il en existe vraiment beaucoup qui sont très bien documentés. Mieux. Moi, c'est mieux pour vous expliquer ce qui se passe derrière.
Alors, commençons avec la première grande famille d'analyseurs. Ce sont les filtres de caractère. Un filtre de caractère, il va s'appliquer sur la chaîne de caractères dans sa grande globalité. Il va être en mesure d'ajouter des caractères, de modifier des caractères, de supprimer des caractères. Il en existe plusieurs. J'en ai noté trois. Html_strip. Supprimer des balises HTML. Le filtre de caractère mapping pour remplacer un caractère sur un autre. Et pattern_replace qui remplace des caractères, mais basés sur un truc régulier. Je vous invite à aller voir la documentation d'ElasticSearch. Elle est bien faite. Avec de bons exemples. Allez y jeter un œil.
À titre d'exemple, ce que j'ai fait, nous pouvons voir ici qu'on peut appliquer un code de César juste avec un filtre de caractère. Qu'est-ce qu'un code de César ? C'est une méthode de chiffrement par substitution avec une clé de décalage de trois. En langage humain, si nous prenons une chaîne, une lettre dans un alphabet et qu'on la déplace trois fois, trois places plus loin. C'est une ancienne méthode pour chiffrer nos textes. Nous prenons le U trois places plus tard, ça fait un X. Ce serait possible de le faire avec un mapping.
Nous prenons un exemple qui va nous faire avancer. J'ai choisi d'appliquer le filtre de caractère html_strip. Pour rappel, il prend les balises HTML, il les supprime. Il prend les entités HTML et les décale. Ici, le petit (propos indistincts), il le décale. Notre chaîne est un peu plus propre déjà. Ce n'est pas grand-chose, mais c'est pas mal. Il nous reste beaucoup de travail. Nous allons passer à la deuxième grande famille d'analyseurs. Ce sont les générateurs tokens. Apache Lucene requiert de travailler avec des tokens. Dans toute la première partie avec toutes les maths, on travaille avec des mots. J'ai toujours utilisé le terme "mots". Nous avions acté qu'un mot égale un token. Mais un token, ça peut être n'importe quoi. Une portion de texte isolé. Apache Lucene requiert de travailler avec des tokens. Mais nous avons une chaîne de caractères ici. L'étape de génération de tokens va être obligatoire. Nous allons devoir spécifier un seul générateur de tokens. ElasticSearch en propose plusieurs. J'ai mis Letter. Quand il voit un générateur qui n'est pas une lettre, il met un nouveau caractère. Simple_pattern, si vous avez envie d'utiliser des expressions régulières pour faire ce genre de choses. Il en existe énormément. Je vous ai mis un petit exemple. Nous avons la chaîne de caractères foo+bar = baz. Nous avons appliqué le générateur de token letter. Qu'est-ce qu'il va faire ?
(coupure de son)
... Z j'arrive à la fin. Ce qu'il me reste, c'est un token.
Dans notre usercase, on veut récupérer grossièrement les mots et c'est pour cette raison qu'on veut utiliser whitespace. Pour découper notre chaîne de caractères dès qu'il y a un espace. Sans grande surprise, ça va générer des tokens suivants. Ça marche assez bien. On se retrouve avec le mot "les" "développeurs", "développer"... Ce n'est pas parfait, mais nous allons régler cela juste après.
Ça nous amène à la troisième et dernière grande famille d'analyseurs d'ElasticSearch. Ce sont les filtres de tokens. Les filtres de tokens, ça marche comme les filtres de caractères. Mais ça agit sur chaque token individuellement. Il en existe beaucoup. Je vous en ai noté quelques-uns. Il y a synonym qui permet de remplacer un token par un autre. Basé sur une table de mapping. Phonetic qui permet de remplacer un token par sa valeur phonétique. Quand nous ne parlons pas anglais, ou ce genre de choses. Stopwords qui va pouvoir supprimer des tokens qui sont des mots liaisons, etc. Allez voir la doc d'ElasticSearch, il en existe énormément à ce mot. C'est là où la magie et le nettoyage du texte vont intervenir.
Donc, commençons avec un premier filtre de token. Le word_delimiter. Nous sommes un petit peu sur la séparation de token. Il va couper un token dès qu'il va... quand il rencontre un changement de casse, quand on passe de minuscules à majuscules. Quand il rencontre un caractère spécial aussi. Comme un tiret. Underscore pour... il le fait aussi pour les virgules et les points d'interrogation. Pour "avec virgule vim ?", on va se retrouver avec ces deux tokens.
On a déjà nettoyé. Il faut être satisfait de ce qu'on a accompli jusqu'à présent. On va ensuite appliquer le filtre de token lowercase, en règle générale, la casse, s'il y a des D majuscules, ça ne porte pas de sens. Nous arrivons à dénicher le sens que ce soit écrit en min ou maj. Il faut enlever un maximum de bruit. La casse, la plupart du temps, c'est du bruit. On va appliquer le filtre lowercase qui va faire tomber la case de tous nos tokens. Nous avons les mêmes tokens qu'au-dessus. Mais tout est écrit.
Nous continuons. Stopwords. Est-ce que vous vous souvenez de la mécanique de IDF ou de ce à quoi servait IDF ? Très bien. Pour rappel, IDF va faire peser le moins possible les mots qui apparaissent souvent. Les mots de liaison. Stopwords fait la même chose. Mais c'est plus violent. Il va purement et simplement supprimer les tokens représentant des mots de liaison. Les mots de liaison ne vont pas moins puiser dans le résultat final. Ils ne vont plus être petits du tout. Ils n'existeront plus. Il en existe en plusieurs langues. Ça existe en français. Si nous appliquons le filtre stopwords à nos tokens, nous voyons que les tokens ont disparu. On se retrouve à : développeur développer vim. Ce qui présente le sens de nos chaînes de caractères. Nous allons avoir notre score, il sera basé sur ces tokens.
Les synonymes, l'emoji est sympa, il rend bien sur la slide. Mais ça ne va pas aider ElasticSearch. Pour la machine, c'est seulement un caractère spécial. Lucene ne va pas voir tout l'amour que porte ce petit token. Nous allons utiliser le filtre synonym. Il remplace un token par un autre basé sur une table de synonymes. Pour transformer notre emoji plein d'amour avec une chaîne de caractères qui présente autant d'amour. Pour cela, nous allons nous servir de la table de mapping créée par nos amis de JoliCode. Ça permet de mapper un Emoji avec sa valeur actuelle. Nous allons se retrouver avec : Développeur aimer développer vim. Si on cherche notre texte, on va trouver des documents avec le mot aimer. Ou si on tape aimer, on peut se retrouver avec des documents qui contiennent l'emoji.
J'aimerais vous parler du Stemmer. Appliquer un Stemmer sur un mot, qu'est-ce que c'est ça ? C'est réduire un mot à ses racines. Je vais vous montrer le résultat directement. Plus simple. "Développeurs" la racine, c'est develop. Même chose pour développer. Vim, c'est vim. Si on cherche un truc sur les développeurs, sur le fait de développer, les développeuses, ce qu'on recherche, c'est quelque chose qui est relatif aux développements. L'algorithme de Stemmer va nous permettre de le faire. Le Stemmer utilise l'algorithme de stemming. Vous pouvez aller faire joujou en ligne avec le lien que je vous ai mis. Vous pouvez y passer beaucoup de temps. J'ai passé trop de temps sur ce truc. Pour deviner la racine d'un mot. Allez jouer avec cela, c'est rigolo. Je vais accélérer.
Nous avons fini de nettoyer la chaîne de caractères, nous avions cela en entrée, et nous nous retrouvons avec cela en sortie. Nous avons bien fait notre travail. Si on lit : les développeurs aiment développer avec vim. Nous avons à la fin: develop, aime, vim. Nous avons gardé le sens.
Vous vous souvenez du début. Il fallait nettoyer le texte. Nous avions supposé que c'était à cause du bruit. Au début, j'avais masqué la notion de token. Je l'avais remplacé par des mots. Mais ce qu'on avait, c'était ces mots. Qu'est-ce qui se passe si on applique le flux d'analyseur sur tout ça ? Ça va nous donner les tokens suivants. Vim et développeurs, ça va nous donner : vim develop.
Si nous prenons l'équation, ça va changer les choses. Ici, je ne vous détaille pas la totalité. Nous allons nous retrouver avec le token vim qui marche fois IDF. Coordination de facteurs. Si on regarde le token develop, il va apparaître deux fois. Le tout par le coordination factor, ça va donner un score qui a beaucoup plus d'écart. Ça représente mieux ce qu'on veut vraiment.
J'ai un peu accéléré parce que je me suis étendu au début. J'ai fait le tour de ce que je voulais aborder. J'ai survolé une grande partie. Allez voir la documentation d'ElasticSearch. Elle est bien faite. Vous allez pouvoir comprendre beaucoup de choses là-dessus. J'espère que vous avez compris dans les grandes lignes comment juste avec une petite fonction mathématique, c'est possible de doter une machine d'une sorte d'interprétation. Je vous remercie. N'hésitez pas à me faire des retours pour que la prochaine fois que je la donne, elle sera mieux cette conférence. Allez suivre AFUP, c'est cool. Allez suivre Les Tilleuls. Nous avons un stand. Venez nous parler. Pendant ces deux jours. Merci beaucoup.
(applaudissements)
Tweets