Comprendre l'IA, une leçon à la fois

Il y a quelques années, on passait tous nos textes dans Google Translate, et ça se voyait à trois kilomètres. Aujourd'hui, Claude ou ChatGPT traduisent si bien qu'on ne remarque souvent même plus la traduction. Mais alors, qu'est-ce qui s'est passé entre les deux ?

Faisons l'expérience. Prenez une expression bien de chez nous : "Il pleut des cordes". Donnez-la à un traducteur qui remplace chaque mot par son équivalent, et vous obtenez "It's raining ropes". Tous les mots sont justes... et pourtant votre collègue anglais regarde le ciel en cherchant d'où tombe le matériel d'escalade.

Le problème, ce n'est pas le vocabulaire. C'est que le traducteur n'a pas compris la phrase.

Alors comment font les modèles actuels ? Leur secret, c'est qu'ils ne manipulent pas vraiment des mots. Ils manipulent des vecteurs.

Imaginez une immense carte. Pas une carte routière, une carte du sens. Sur cette carte, chaque mot a une position, et les mots qui parlent de choses proches se retrouvent voisins : "pluie", "orage", "averse" et "parapluie" habitent le même quartier. Petit détail : cette carte n'a pas deux dimensions, mais plusieurs milliers. Pas pratique à déplier dans la voiture, mais parfait pour un ordinateur.

Deuxième ingrédient : le contexte. Regardez ces deux phrases. "J'ai mangé un avocat." "J'ai appelé mon avocat." Même mot, deux sens complètement différents, et vaut mieux ne pas se tromper, surtout pour l'avocat. Pour s'en sortir, le modèle utilise un mécanisme qu'on appelle l'attention : chaque mot regarde ses voisins pour savoir ce qu'il veut dire ici. Avec "mangé", avocat file vers le rayon fruits et légumes. Avec "appelé", direction le cabinet juridique.

Revenons à nos cordes. Le modèle ne cherche pas corde = rope. Il construit une représentation de toute la phrase, qui atterrit sur la carte tout près de "il pleut très fort". Et de là, il n'a plus qu'à trouver l'équivalent anglais : "It's pouring", ou "It's raining cats and dogs". On ne traduit plus des mots, on traduit du sens.

Et cette mécanique-là, vous la retrouvez partout dans l'IA moderne : embeddings, similarité sémantique, RAG, recherche par intention. Une fois qu'on a compris la carte, beaucoup de choses deviennent moins magiques.

Mais il reste une grande question : qui place les mots sur la carte ? Parce que non, personne ne passe ses journées à positionner "pluie" et "parapluie" à la main. Ça, on le découvre dans le prochain post.

Dans le dernier post, je vous ai laissés avec une carte du sens où "pluie" et "parapluie" habitent le même quartier. Mais une question est restée en suspens : comment un ordinateur, qui ne connaît que des nombres, fait-il pour placer un mot sur cette carte ?

Commençons par une évidence. Quand vous lisez "chat", vous voyez peut-être un matou roulé en boule sur un canapé. L'ordinateur, lui, ne voit rien du tout. Pour lui, "chat" n'est qu'une suite de caractères, pas plus proche de "chien" que de "chaussette". Il faut donc lui donner autre chose à manipuler.

Cette autre chose, c'est un embedding : une liste de nombres qui sert de coordonnées sur la carte. Concrètement, ça ressemble à ça :

chat → [0.12, -0.47, 0.81, ...]
chien → [0.10, -0.42, 0.79, ...]
voiture → [-0.71, 0.20, 0.06, ...]

(En vrai, il y a quelques centaines à quelques milliers de nombres par liste. Je vous épargne la suite.)

Regardez bien les deux premières lignes : les nombres de "chat" et de "chien" se ressemblent, ceux de "voiture" partent complètement ailleurs. C'est exactement ce qu'on veut. Deux animaux domestiques à quatre pattes se retrouvent voisins, et la voiture est garée à l'autre bout de la carte.

Attention au piège : aucun de ces nombres ne veut dire "a des poils" ou "fait miaou". Un embedding n'est pas une définition, et personne n'a décidé que la troisième case mesurait le côté "animal". Ces valeurs sont apprises : on montre au modèle des quantités énormes de texte, et il ajuste les coordonnées jusqu'à ce que les mots qui apparaissent dans des contextes similaires finissent proches les uns des autres. "Chat" et "chien" se croisent tout le temps dans les mêmes phrases ("nourrir le ...", "emmener le ... chez le vétérinaire"), alors ils se rapprochent.

Et ça ne s'arrête pas aux mots. Selon le modèle utilisé, on peut calculer l'embedding d'une phrase, d'un paragraphe ou d'un document entier. Une annonce immobilière, un ticket de support ou une page de documentation peuvent eux aussi devenir un point sur la carte, et c'est là que ça devient vraiment intéressant : si deux textes sont des points, on peut mesurer la distance entre eux.

Alors comment une IA décide-t-elle que deux phrases qui n'ont presque aucun mot en commun parlent pourtant de la même chose ? On sort le mètre ruban dans le prochain post.

Faisons une petite expérience de recherche. Vous tapez sur un site immobilier : "appartement avec extérieur pour une famille près de Genève". Et quelque part dans la base dort cette annonce : "T4 lumineux avec grande terrasse, trois chambres, à Annemasse."

Pour un humain, c'est un match évident. La terrasse, c'est l'extérieur. Trois chambres, c'est pour une famille. Et Annemasse, c'est à dix minutes de Genève (quand les bouchons le permettent). Mais comptez les mots en commun entre les deux phrases : il n'y en a quasiment aucun.

Une recherche classique, par mots-clés, cherche justement des mots identiques. Elle passe donc complètement à côté de l'annonce, pendant que la famille continue à chercher.

C'est là que la carte du sens entre en jeu. On calcule l'embedding de la recherche, celui de l'annonce, et on obtient deux points. Si les deux phrases parlent de la même chose, les deux points sont proches, même sans aucun mot commun.

Reste à définir "proche". La méthode la plus répandue s'appelle la similarité cosinus, et le nom fait plus peur que l'idée. Imaginez que chaque embedding est une flèche qui part du centre de la carte. Deux flèches qui pointent quasiment dans la même direction : les textes parlent de la même chose. Deux flèches perpendiculaires : aucun rapport. On mesure donc l'angle entre les flèches, plutôt que la distance entre leurs pointes. Pour l'ordinateur, le calcul tient en quelques multiplications et additions, ce qui lui permet de comparer une recherche à des millions de textes en un clin d'oeil.

Le résultat est un score : proche de 1, les deux textes pointent dans la même direction ; proche de 0, ils n'ont rien à voir. (En théorie, le score peut descendre jusqu'à -1 pour des flèches opposées, mais avec les modèles d'embeddings courants, on voit surtout des valeurs positives.)

C'est ce qu'on appelle la recherche sémantique : on ne compare plus des mots, on compare des sens. Notre famille trouve son T4 à Annemasse, et le site n'a jamais eu besoin qu'on lui explique qu'une terrasse est un extérieur.

Mais cette mécanique permet bien plus que d'améliorer un moteur de recherche. Elle permet de demander à une IA d'aller fouiller dans vos propres documents avant de répondre. Et ça, c'est le fameux RAG, qu'on démonte dans le prochain post.

Posez à ChatGPT la question "Comment fonctionne notre authentification ?" et vous aurez droit à un joli cours général sur OAuth2, les tokens et les sessions. Très instructif, mais totalement inutile : il ne connaît pas votre système. Et il ne peut pas le connaître, puisque votre documentation interne n'a jamais fait partie de ce qu'il a lu pendant son entraînement.

Alors comment construit-on un assistant capable de répondre sur vos procédures, votre architecture ou vos incidents de l'an dernier ?

Première idée qui vient à l'esprit : réentraîner le modèle sur toute la documentation. C'est long, cher, et il faudrait recommencer à chaque modification d'une page. (On reviendra sur cette option dans quelques posts, elle a ses usages, mais pas celui-là.)

La solution qu'on retrouve presque partout s'appelle le RAG, pour Retrieval Augmented Generation. Derrière ce nom un peu pompeux se cache une idée toute simple : avant de répondre, on va chercher les bonnes pages, et on les donne au modèle avec la question.

Le trajet ressemble à ça :

Question
→ recherche dans vos documents
→ passages pertinents
→ question + passages envoyés au modèle
→ réponse

La recherche, c'est justement la similarité sémantique du post précédent : on compare la question aux documents, et on garde ceux qui pointent dans la même direction. Le modèle reçoit alors quelque chose comme "Voici trois extraits de la documentation interne. En t'appuyant dessus, réponds à : comment fonctionne notre authentification ?"

C'est un peu comme passer un examen à livre ouvert. L'étudiant n'a pas appris le manuel par coeur, mais il sait trouver la bonne page et la reformuler intelligemment.

Et c'est le point le plus souvent mal compris : avec un RAG, l'IA n'apprend pas vos documents. Rien n'est gravé dans le modèle. Elle les consulte au moment où elle en a besoin, puis les oublie. Conséquence très pratique : si vous mettez à jour une procédure, l'assistant utilisera la nouvelle version dès qu'elle aura été réindexée, sans toucher au modèle. Et on peut lui demander d'indiquer d'où vient chaque information.

Seulement voilà : si votre entreprise possède 100 000 documents, vous n'allez pas tous les coller dans la question. Alors comment choisit-on les quelques morceaux qui méritent d'être envoyés au modèle ? On découpe tout ça dans le prochain post.

Imaginez que vous cherchiez une recette de crêpes et qu'on vous tende toute la bibliothèque municipale en disant "c'est quelque part là-dedans". Techniquement, l'information est bien présente. En pratique, vous n'êtes pas plus avancé.

C'est exactement le problème qu'on rencontre avec un RAG sur 100 000 documents. On ne peut pas tout envoyer au modèle : ça ne rentrerait pas dans sa mémoire de travail, ça coûterait une fortune, et noyer la bonne information dans des milliers de pages inutiles dégrade la réponse.

Même à l'échelle d'un seul document, le problème reste entier. Un PDF de 80 pages qui parle d'architecture, de sécurité et de facturation, c'est un seul point sur la carte du sens, placé quelque part au milieu de tous ces sujets. Si la question porte sur la facturation, ce point "moyen" ne sera pas forcément le plus proche.

La solution : on découpe. Chaque document est coupé en morceaux, les fameux chunks, de quelques paragraphes chacun :

Document
├── chunk 1
├── chunk 2
├── chunk 3
└── ...

Chaque chunk reçoit son propre embedding, et tous ces vecteurs sont rangés dans une base vectorielle, une base de données spécialisée pour retrouver très vite les points les plus proches d'un point donné. Quand une question arrive, on calcule son embedding, on demande à la base les cinq ou dix chunks les plus proches, et seuls ceux-là partent vers le modèle.

Sur le papier, c'est simple. Dans la vraie vie, la façon de découper est l'un des réglages qui influencent le plus la qualité d'un RAG. Des chunks trop petits, et vous récupérez une phrase sans son contexte ("la valeur doit être inférieure à 30"... 30 quoi ? de quoi ?). Des chunks trop gros, et vous retombez sur le problème du PDF entier : beaucoup de bruit autour de l'information utile. Et un découpage aveugle, tous les 1 000 caractères par exemple, finira fatalement par couper un tableau en deux ou séparer un titre de son paragraphe.

C'est pour ça qu'on découpe de préférence en suivant la structure du document (titres, sections, paragraphes), souvent avec un léger chevauchement entre deux chunks. Et on ajoute des métadonnées à chaque morceau : document d'origine, date, auteur, projet, droits d'accès. Elles permettent de filtrer ("uniquement la doc du projet X, version actuelle") et de ne jamais montrer à quelqu'un un passage qu'il n'a pas le droit de lire.

Trouver les bons morceaux améliore énormément les réponses, mais ça ne garantit toujours pas que le modèle dira vrai. Pourquoi une IA peut-elle encore inventer quelque chose alors qu'on vient de lui donner les bons documents ? Pour répondre, il faut d'abord comprendre pourquoi elle hallucine, et c'est le sujet du prochain post.

Complétez cette phrase : "La capitale de la France est..." Vous avez répondu Paris sans réfléchir. Un modèle de langage aussi. Et pour comprendre pourquoi une IA hallucine, il faut regarder comment elle a trouvé cette réponse.

Un LLM ne va pas chercher "capitale de la France" dans une encyclopédie interne. Il fait quelque chose de plus modeste et de plus étonnant à la fois : il prédit la suite du texte, un petit morceau à la fois (un token, on y reviendra). À chaque étape, il calcule quels morceaux sont les plus probables compte tenu de tout ce qui précède. Après "La capitale de la France est", "Paris" écrase toute la concurrence, parce qu'il a vu cette association des milliers de fois pendant son entraînement.

Maintenant, changeons de question : "Quel est le titre du troisième roman publié par le physicien qui a découvert l'effet Byanistic ?" (N'allez pas chercher, cet effet n'existe pas.)

Le modèle va faire exactement la même chose : prédire la suite la plus plausible. Or la forme d'une bonne réponse, il la connaît parfaitement : un nom de physicien crédible, un titre de roman qui sonne juste, peut-être une date. Il n'y a pas de voyant rouge interne qui s'allume au moment où il passe d'un fait appris à une pure invention. Le mécanisme est le même, du début à la fin.

C'est pour ça que je n'aime pas dire que l'IA "ment". Mentir suppose de connaître la vérité et de choisir de la cacher. Ici, le modèle produit ce qui ressemble le plus à une bonne réponse, et un modèle entraîné sur des milliards de textes est devenu extraordinairement doué pour produire des choses qui ressemblent à de bonnes réponses. Tout tient en une phrase : plausible ne veut pas dire vrai.

Les modèles récents ont fait de gros progrès. On les entraîne à repérer les fausses prémisses et à dire qu'ils ne savent pas, et sur l'effet Byanistic, un bon modèle actuel vous répondra probablement qu'il ne connaît pas cet effet. Mais sur une question obscure, une référence bibliographique précise ou un chiffre pointu, le risque reste bien réel.

C'est justement pour ça qu'on leur donne des documents, des sources, parfois des outils : pour que la réponse plausible ait de bonnes chances d'être aussi la réponse vraie. Mais même avec un RAG bien construit, les hallucinations ne disparaissent pas complètement. Pourquoi ? C'est ce qu'on verra dans le prochain post.

On a vu dans le dernier post qu'un LLM produit la réponse la plus plausible, pas forcément la plus vraie. Et on avait vu avant qu'un RAG lui fournit les bons documents. Problème réglé, donc ? Pas tout à fait, parce qu'entre la question et la réponse, il y a toute une chaîne, et chaque maillon peut lâcher.

Reprenons notre assistant interne et suivons une question : "Quel est le délai de préavis pour une démission ?"

Premier maillon, la recherche. Elle peut ramener le mauvais document, par exemple la procédure de résiliation des contrats fournisseurs, qui parle beaucoup de "préavis" et de "délai". Ou ne pas ramener le bon, parce qu'il est rédigé avec d'autres mots et qu'il arrive onzième alors qu'on n'en garde que dix.

Deuxième maillon, le découpage. Le bon chunk est là, mais il s'arrête juste avant la phrase "sauf pour les cadres, où le délai est de trois mois". Le modèle répond juste... pour une partie des salariés seulement.

Troisième maillon, les documents eux-mêmes. La version 2022 et la version 2025 de la procédure sont toutes les deux dans la base, et elles ne disent pas la même chose. Laquelle croire ?

Quatrième maillon, l'interprétation. Tous les bons passages sont là, mais le modèle les combine mal, ou tire une conclusion que le texte ne dit pas vraiment.

Et enfin, le cas le plus traître : la réponse n'existe tout simplement pas dans les documents. On retombe alors sur le comportement du post précédent : si on ne lui a pas appris à s'arrêter, le modèle complète avec ce qui lui semble plausible.

Un RAG réduit donc fortement les hallucinations, mais ne les supprime pas. Ce qu'on appelle le grounding, c'est justement l'effort pour ancrer chaque réponse dans les sources fournies, et un bon système se reconnaît à trois comportements.

Il sait dire "je ne sais pas". C'est peut-être la réponse la plus précieuse qu'un assistant puisse donner, et elle se prépare : dans les instructions, dans le choix du modèle et dans les tests.

Il cite ses sources. Chaque affirmation renvoie au passage d'où elle vient, ce qui permet à l'utilisateur de vérifier en deux clics.

Il distingue ce qui est écrit de ce qu'il déduit. "La procédure indique trois mois" et "j'en conclus que votre cas relève probablement de cette règle", ce ne sont pas deux phrases du même niveau de confiance.

Jusqu'ici, notre IA cherche, lit et répond. Mais on peut aller plus loin et lui permettre d'agir : consulter une API, récupérer une donnée en temps réel, créer un ticket, déclencher une action. C'est là qu'on commence à parler d'agents, et c'est le sujet du prochain post.

Demandez à un modèle de langage sans aucun accès extérieur : "Quel temps fait-il en ce moment à Genève ?" Dans le meilleur des cas, il vous répondra honnêtement qu'il n'en sait rien. Dans le pire, il vous décrira un joli ciel dégagé avec 18 degrés, parce que c'est plausible pour la saison (vous connaissez maintenant la chanson).

Normal : la météo de ce matin ne faisait pas partie de ses données d'entraînement, et aucun document interne, aucun RAG ne la contiendra non plus. Il faut aller la chercher, maintenant, à la source.

C'est toute la différence entre un chatbot et un agent. Un chatbot, c'est un modèle qui parle. Un agent, c'est un modèle qui parle et qui dispose d'outils qu'il peut décider d'utiliser.

Voyons ce qui se passe avec notre question. L'agent commence par comprendre qu'il lui manque une donnée en temps réel. Il regarde les outils à sa disposition et repère un outil météo. Il ne l'exécute pas lui-même : il produit une demande structurée, quelque chose comme "appelle l'outil météo avec ville = Genève". Le programme qui l'entoure fait réellement l'appel à l'API, récupère le résultat ("pluie, 11 °C") et le renvoie au modèle. Et c'est seulement là que le modèle rédige sa réponse : "Il pleut à Genève, 11 degrés, prenez un parapluie."

C'est ce qu'on appelle le tool calling, et le plus important se cache dans la boucle : le modèle agit, observe le résultat, puis décide de la suite. Il peut s'arrêter là, ou appeler un autre outil si la réponse en a besoin. Pour "Dois-je prendre un parapluie pour mon rendez-vous de 15 h ?", il ira peut-être d'abord consulter l'agenda pour savoir où a lieu le rendez-vous, puis la météo de cet endroit, avant de répondre.

On entend souvent qu'un agent, c'est juste un chatbot avec un très gros prompt. C'est faux : le prompt le plus long du monde ne fera jamais apparaître la météo de ce matin. Ce qui fait l'agent, ce sont les outils, et la capacité à décider quand s'en servir.

Et c'est justement là que tout se complique. Si l'agent a accès à une météo, un agenda, un CRM et une messagerie, comment sait-il quel outil utiliser, avec quels paramètres et à quel moment ? On ouvre la boîte à outils dans le prochain post.