J’ai publié 42 shorts sur les termes de l’IA en 42 jours

Si vous lisez ceci, c’est soit parce que vous utilisez trop d’outils d’IA comme ChatGPT, Gemini ou Claude pour diverses choses, soit parce que la personne qui vous a envoyé ce message le pense.

Dans tous les cas, vous avez probablement vécu la même expérience que la plupart des gens avec ces outils. Vous posez une question simple, vous obtenez une réponse, et quelque chose cloche. Parfois c’est vague. Parfois c’est lent. Parfois ça sonne confiant, soigné et autoritaire, puis vous réalisez que c’est tout simplement faux.

La partie frustrante, ce n’est pas qu’ils échouent. C’est qu’ils échouent de manière incohérente.

Vous pouvez poser presque la même question deux fois et obtenir deux niveaux de qualité complètement différents, comme si l’outil était brillant une minute, puis confus la suivante.

Quand ça arrive, le conseil standard revient. Mieux prompter. Reformuler. Être plus spécifique. Ajouter des contraintes. Réessayer.

Une communication claire aide, mais le prompting n’est pas le vrai problème ici. Nous sommes tous des prompt engineers. Ce n’est que la surface. Le problème plus profond, c’est que la plupart des gens utilisent des systèmes qu’ils ne comprennent pas. Essayez d’utiliser un vélo correctement sans comprendre que pédaler fait tourner les roues.

Ces outils donnent l’impression d’être conversationnels, donc nous les traitons instinctivement comme des partenaires de conversation. Mais leur intelligence n’est pas façonnée comme la nôtre. Elle est inégale. Dentelée. Elle excelle dans certains domaines et s’effondre dans d’autres. Un modèle peut écrire une très belle explication, aider à brainstormer une stratégie ou rédiger quelque chose qui ressemble à un travail fini, puis échouer avec assurance sur une étape logique très simple. Il peut expliquer un sujet complexe en langage clair, puis quelques lignes plus tard inventer des détails qui n’ont jamais existé.

Si vous ne comprenez pas avec quel type de système vous interagissez, vous ne pouvez pas prédire quand il sera fiable et quand il vous surprendra. Et c’est le problème que je voulais résoudre, parce qu’il concerne tout le monde, pas seulement les ingénieurs. Ces outils font déjà partie du travail quotidien d’un nombre énorme de personnes, et ils deviennent rapidement une partie par défaut du workflow de la plupart des métiers intellectuels.

Alors j’ai construit quelque chose qui paraît presque trop simple pour être important.

Un vocabulaire.

J’ai publié un cours YouTube gratuit intitulé « Introduction à l’IA en 42 termes ». Il s’agit de 42 shorts, chacun couvrant un concept qui revient constamment dès que quelqu’un essaie d’expliquer les LLMs et l’IA générative. La série complète est déjà en ligne. Le but n’est pas de vous faire mémoriser des définitions. Le but est de vous donner un modèle mental de la façon dont ces systèmes fonctionnent, afin que vous puissiez les utiliser de manière délibérée plutôt que d’avancer à l’aveugle.

p.s. Si vous voulez soutenir mon travail de la meilleure manière possible, pensez à partager cette édition ou la chaîne YouTube avec un ou deux amis, pour aider à diffuser la connaissance.

Commencez le mini-cours ici :

Parce qu’une fois que vous avez ce modèle mental, tout change. Le comportement étrange cesse de sembler aléatoire. Les forces cessent de paraître magiques. Les échecs cessent d’être personnels. Et surtout, vous savez quoi faire ensuite.

La plupart de la confusion autour de l’IA vient d’un manque de vocabulaire. Les gens parlent de tokens, d’embeddings, de paramètres, d’hallucinations, de fine-tuning, de retrieval, d’agents, d’alignement et de garde-fous comme si tout le monde savait déjà ce que ces mots signifient. Si ces termes sont flous, tout ce qui est construit dessus reste flou aussi. Vous ne pouvez pas dire pourquoi une réponse a échoué. Vous ne pouvez pas dire pourquoi un modèle semble meilleur qu’un autre. Vous ne pouvez pas dire pourquoi ajouter un document rend soudainement la sortie plus précise. Vous ne pouvez pas dire si un produit alimenté par l’IA est réellement solide ou simplement un habillage malin autour d’une fenêtre de chat.

Quand les gens n’ont pas de vocabulaire, ils finissent avec de la superstition. Ils développent des rituels. Ils collectionnent des templates de prompts. Ils copient la formulation qui a fonctionné pour quelqu’un d’autre dans un outil différent, avec des règles cachées différentes. Et ensuite, ils sont surpris que ça ne fonctionne pas ailleurs.

Spoiler : 99,9 % des « prompt templates » sont inutiles.

C’est pour ça que je ne m’intéresse pas à l’enseignement de techniques de prompting, et que ça n’a jamais été le cas. Les techniques de prompting changent sans cesse à mesure que les modèles évoluent. Les fondations, elles, ne changent pas. Les modèles s’améliorent chaque année, mais ils reposent toujours sur les mêmes idées fondamentales, sont entraînés de manière similaire, et sont limités par les mêmes contraintes sous-jacentes qui ne vont pas changer de sitôt. Si vous comprenez ces contraintes, vous continuerez d’en tirer profit même lorsque les interfaces et les fonctionnalités évolueront.

Au cœur de tout cela se trouve une vérité simple que la plupart des gens n’ont toujours pas intégrée.

Un grand modèle de langage est un système qui prédit ce qui vient ensuite.

Quand vous tapez une question dans ChatGPT, il ne va pas chercher une réponse dans une base de données. Il ne « sait » pas les choses au sens humain. Il prend le texte que vous lui avez donné et pose, encore et encore, une seule question : étant donné tout ce que j’ai vu jusqu’ici, quel est le prochain token le plus probable ? Ce token peut être un mot, une partie de mot, un nombre ou un signe de ponctuation. Il en prédit un, l’ajoute à la séquence, puis prédit le suivant, et ainsi de suite jusqu’à ce qu’une réponse apparaisse. Vous êtes en train de regarder une machine de prédiction du prochain token fonctionner en temps réel.

Cela explique pourquoi reformuler compte. Un petit changement au début modifie le paysage des probabilités de ce qui vient ensuite, et peut pousser le modèle dans une direction complètement différente. Cela explique aussi pourquoi ces systèmes peuvent sembler corrects alors qu’ils ne le sont pas. La fluidité et la vérité ne sont pas la même chose. Le modèle est optimisé pour produire du texte plausible, pas pour vérifier des faits.

Une fois que vous comprenez cela, les autres concepts s’imbriquent naturellement. Les tokens comptent parce que tout est mesuré en tokens, y compris les limites, la vitesse et le coût. Les embeddings comptent parce que le modèle ne peut pas traiter les mots comme des symboles, il traite des nombres qui représentent des schémas d’usage. La fenêtre de contexte compte parce que le modèle ne « se souvient » que de ce qui tient à l’intérieur à un instant donné. Si quelque chose sort de cette fenêtre, ça n’existe plus pour le modèle, peu importe son importance pour vous. C’est pour ça que les conversations se dégradent, que les contraintes dérivent, et que vous avez parfois l’impression que le modèle a « oublié » quelque chose d’évident. Il n’a pas oublié. Il n’y a simplement plus accès. (Tout cela est défini dans le cours gratuit !)

À partir de là, le cours explique pourquoi les assistants se comportent comme ils le font. Un modèle de base est entraîné à continuer du texte. C’est tout. Pour obtenir quelque chose comme ChatGPT, on l’entraîne davantage afin qu’il suive des instructions et réponde d’une manière que les humains préfèrent. C’est là qu’interviennent l’instruction tuning et des techniques comme le RLHF. Elles ne rendent pas le modèle capable de comprendre la vérité par magie. Elles façonnent le comportement, le ton et l’utilité. Elles lui apprennent ce que les humains ont tendance à valoriser dans une réponse.

Ensuite, on arrive à la réalité pratique qui compte pour toute personne utilisant ces outils dans le monde réel : les modèles échouent, et il faut des moyens de réduire ces échecs. Les hallucinations ne sont pas un bug que l’on corrige avec un meilleur prompt. C’est une conséquence du fonctionnement du système. Et nous ne pouvons pas changer cela. Si le modèle n’a pas d’information fiable dans son contexte, il produira quand même quelque chose, parce que c’est ce pour quoi il est conçu. La solution n’est donc souvent pas de « demander plus gentiment ». La solution est de l’ancrer dans une source de vérité. C’est là qu’intervient la génération augmentée par la recherche (RAG). Vous récupérez des informations pertinentes depuis des documents ou le web, vous les injectez dans le prompt, et vous forcez le modèle à générer une réponse basée sur ces preuves plutôt que sur ses seuls schémas internes.

C’est aussi là que les systèmes d’agents apparaissent, et que les choses deviennent rapidement dangereuses si vous ne savez pas ce que vous faites. Plus vous laissez un modèle naviguer, récupérer des informations et agir (en votre nom), plus vous devez considérer tout ce qu’il lit comme une entrée non fiable. L’injection de prompt est essentiellement de l’ingénierie sociale pour machines, et si vous construisez des systèmes qui ingèrent du texte externe, vous avez besoin de vraies défenses, pas de vibes.

Et puis il y a la partie que presque tout le monde ignore jusqu’à ce que quelque chose casse : l’évaluation. Les gens adorent les scores de modèles et les classements. Mais les benchmarks ne disent pas si votre application va bien se comporter. C’est pour ça que les builders mesurent des métriques comme la fidélité et la pertinence, et utilisent de plus en plus des techniques comme le LLM-as-judge pour évaluer les sorties à grande échelle. Quand la fiabilité compte, on ne se contente pas d’espérer que le modèle se comporte bien. On mesure. On empile des mécanismes d’atténuation. On conçoit en tenant compte des modes d’échec.

C’est l’idée centrale de toute la série. L’IA ne devient pas fiable par magie. Elle devient fiable par conception.

Si vous êtes un utilisateur et non un builder, cette mentalité de conception reste importante, parce qu’elle change la façon dont vous déléguez des tâches. Vous commencez à voir où les LLMs excellent et où ils ne devraient pas être impliqués du tout. Vous apprenez quand demander de la créativité et quand exiger de l’ancrage. Vous apprenez quand utiliser un modèle, quand utiliser un outil comme une calculatrice, et quand la décision la plus sûre est de ne pas utiliser d’IA du tout dans la boucle.

C’est ce que je veux que les gens retiennent après avoir terminé les 42 termes (environ 1 à 1,5 heure). Pas de l’excitation. Pas de la peur. Du discernement.

Le meilleur résultat n’est pas d’obtenir de meilleures réponses de ChatGPT. Le meilleur résultat est de comprendre la différence entre son intelligence et la vôtre, et d’arrêter de lui confier des tâches pour lesquelles il n’a jamais été conçu.

L’effet secondaire sera de meilleures réponses, une confiance accrue et moins de peurs autour de l’AGI.

Donc oui, la série est un cours YouTube gratuit. Mais l’objectif plus profond est de faire en sorte que l’IA ressemble moins à un raccourci risqué et davantage à un outil que vous pouvez utiliser de manière délibérée et confiante.

Si vous voulez la parcourir, vous pouvez commencer n’importe où dans la liste des 42 shorts ici, mais je recommande de commencer par le début, car les premiers concepts dissipent le plus de confusion.

Une dernière chose.

Si vous gravitez autour de l’IA depuis assez longtemps, vous vous souvenez probablement d’un terme que vous entendiez sans cesse et que personne n’expliquait clairement. Un mot utilisé comme s’il allait de soi, alors que ce n’était pas le cas.

Quel était ce terme pour vous, afin que je puisse l’ajouter au cours ?

Découvrez gratuitement les 42 vidéos ici :

https://www.youtube.com/playlist?list=PLRaQqpZCtdyNkUd8QlKGnwWBtD-opK6Vt