LLM: ce que personne m'avait dit
Pas un cours théorique. Ce que 6 mois de travail quotidien avec Claude m'ont appris sur comment ces trucs fonctionnent vraiment.
Quand j'ai commencé à bosser avec des LLMs, j'ai lu tous les articles "C'est quoi un LLM". Transformers, attention, tokens. J'ai tout compris sur le papier.
Et puis j'ai passé 6 mois à me faire avoir.
Voici ce que j'aurais aimé qu'on me dise dès le début.
Un LLM ne "sait" rien
Le truc qui m'a pris le plus de temps à intégrer : un LLM ne sait pas ce qu'il dit.
Il prédit le prochain mot. C'est tout. Andrej Karpathy l'explique bien : tout ce que fait un LLM, c'est deviner quel token vient après. Le reste (conversations, code, raisonnement) émerge de ça.
Concrètement, ça veut dire quoi ?
Quand Claude me répond "La fonction parseConfig() prend deux arguments", il ne "sait" pas que c'est vrai. Il prédit que cette phrase est statistiquement probable vu le contexte. Si c'est faux, il le dit avec la même confiance.
J'ai perdu des heures à débugger du code qui utilisait des méthodes inventées. Le LLM les avait générées parce qu'elles "sonnaient bien" dans le contexte.
La confiance n'est pas un signal
C'est le piège. Un LLM qui se trompe ne montre aucun signe d'hésitation.
Simon Willison utilise cette image : "un assistant trop confiant, ultra rapide, qui fait absolument des erreurs."
Au début, je faisais confiance aux réponses détaillées. Maintenant je sais que le niveau de détail ne veut rien dire. Un LLM peut inventer une documentation complète avec des URLs, des numéros de version, des exemples de code. Tout faux, mais très professionnel.
Ma règle maintenant : plus c'est spécifique (noms, dates, URLs, chiffres précis), plus je vérifie.
Le contexte, c'est tout
Un LLM n'a pas de mémoire. Chaque requête repart de zéro.
Ce qu'il "sait" à un instant T, c'est uniquement ce qui est dans le contexte : ton message, les messages précédents de la conversation, et les instructions système.
Ça paraît basique, mais les implications sont énormes.
Si tu lui demandes de modifier un fichier sans lui montrer le fichier, il va inventer un contenu plausible. Si tu lui parles d'un bug sans lui donner le code, il va supposer à quoi le code ressemble.
J'ai appris à tout donner explicitement. Le contexte, c'est pas "ce que le LLM devrait savoir", c'est "ce que le LLM sait".
Les limites sont invisibles
Les LLMs sont bons dans plein de trucs. Et nuls dans d'autres. Le problème : la frontière n'est pas évidente.
Ethan Mollick appelle ça la "frontière dentelée" (jagged frontier). Certaines tâches complexes sont triviales pour un LLM. Certaines tâches simples le font planter.
Exemples de mon quotidien :
- Facile : Générer 50 variantes d'un email marketing → impeccable
- Difficile : Compter le nombre de mots dans une phrase → se trompe souvent
- Facile : Refactorer du code complexe → généralement bon
- Difficile : Suivre des instructions avec 10 contraintes → en oublie toujours
Il n'y a pas de règle. Il faut tester.
Ce qui a changé ma façon de bosser
Après 6 mois, voici mes réflexes :
Je vérifie tout ce qui est spécifique. URLs, noms de fonctions, dates, statistiques. Le LLM invente ces trucs plus souvent qu'il ne les connaît.
Je donne le contexte explicitement. Jamais de "tu te souviens du fichier de config ?" Non, il ne se souvient pas. Je recolle le fichier.
Je découpe les tâches. Une grosse demande avec 10 contraintes = échec garanti. Dix petites demandes = ça marche.
J'utilise des fichiers de contexte. CLAUDE.md au début de chaque projet. Le LLM sait comment je veux bosser avant même qu'on commence.
Je teste sur des cas simples d'abord. Avant de lui confier un truc critique, je vérifie sur un exemple où je connais la réponse.
C'est pas de la magie. C'est un outil. Puissant, mais avec des angles morts.
Comprendre ça m'a fait passer de "je me fais avoir une fois sur deux" à "je sais quand lui faire confiance".
Sources :