🖥️ Diapositives du cours — Séance 03 (lun. 5 oct.)
Cette page vous donne le vocabulaire de travail du reste du chapitre : ce que calcule réellement un grand modèle de langage (LLM), comment il devient un « agent », et quels modes d’échec viennent de quelle partie de la machinerie. Savoir par où entrent les erreurs est ce qui permet de les chercher.
Ce que calcule un LLM¶
Un grand modèle de langage est un transformer — l’architecture fondée sur l’attention dont nous avons vu les mécanismes avec les modèles de séquences au chapitre 4.4 — entraîné à prédire le token suivant dans un texte. L’attention permet à chaque token de se conditionner sur tous ceux qui le précèdent (la génération va de gauche à droite, l’attention est donc masquée causalement : aucun token ne voit son propre futur), d’où la capacité de ces modèles à traiter des structures à longue portée (une variable définie 200 lignes plus haut, une affirmation faite trois paragraphes avant) que les modèles de séquences plus anciens perdaient. Passée à des milliards de paramètres et entraînée sur une large fraction de l’internet public, la prédiction du token suivant produit en fin de compte un moteur généraliste texte-vers-texte : résumé, traduction, code et réponse à des questions deviennent tous « continuez ce texte de façon plausible ».
Trois étapes d’entraînement transforment ce moteur en assistant :
- Pré-entraînement : prédire le token suivant sur un immense corpus. C’est de là que viennent la connaissance de la langue, du code et (imparfaitement, jusqu’à une date de coupure) du monde.
- Affinage par instructions (instruction tuning) : entraînement complémentaire sur des paires (instruction, bonne réponse) sélectionnées, pour que le modèle réponde aux questions au lieu de simplement les prolonger.
- Apprentissage par renforcement à partir de retours humains (RLHF) et ses successeurs : on entraîne un modèle de préférence sur des classements humains de réponses, puis on optimise le LLM contre lui. Cela rend les modèles serviables et polis. Cela les rend aussi complaisants — un biais que vous mesurerez en 6.2, car un modèle réglé pour plaire à des évaluateurs tend à vous plaire, y compris quand vous avez tort sharma2023sycophancy.
Deux faits mécaniques à garder en tête :
Fenêtres de contexte. Le modèle voit une fenêtre finie de tokens — des centaines de pages dans les modèles actuels, mais finie, et l’attention sur de très longs contextes se dégrade : un élément situé au milieu d’un long contexte est restitué moins fiablement qu’un élément proche de ses extrémités liu2024lost. Conséquence pratique pour un usage de recherche : un agent qui « lit » votre dépôt de 40 fichiers l’échantillonne et le résume, et peut répondre avec assurance à partir des seules parties auxquelles il a prêté attention.
Tokenisation, et pourquoi les LLM sont de mauvais calculateurs. Le texte est découpé en tokens — des fragments de sous-mots, ni caractères ni mots. Les nombres sont fragmentés arbitrairement : 13.847 peut devenir 13, ., 847. Le modèle n’a pas de type numérique ; les chiffres ne sont que du vocabulaire. L’arithmétique est donc une complétion de motifs sur des chaînes de chiffres, ce qui fonctionne pour les motifs courants et échoue silencieusement ailleurs. Cela vaut avec plus de force encore pour les séries numériques : coller 3 650 déplacements GNSS journaliers dans un prompt (une consigne) et demander la tendance revient à confier un problème de régression à un moteur de complétion de texte. Il répondra, avec aisance, et le nombre sera à peu près plausible. Le remède n’est pas un meilleur prompt ; c’est de donner une calculatrice au modèle — ce qui est tout l’objet de l’usage d’outils, ci-dessous. Un agent bien construit à qui l’on demande une vitesse GNSS doit écrire et exécuter du code numpy, pas « lire » les nombres.
Génération augmentée par recherche documentaire (RAG)¶
La connaissance issue du pré-entraînement est figée à une date de coupure et floue au niveau des détails. Le RAG y greffe une mémoire : les documents sont découpés en fragments puis plongés dans un espace vectoriel (les idées de représentation du chapitre 3), la question de l’utilisateur en extrait les fragments les plus similaires, et le texte retrouvé est placé dans la fenêtre de contexte avec la consigne « répondez à partir de ces documents ». Le modèle cite désormais des éléments sur lesquels il n’a jamais été entraîné.
Exemple géoscientifique : un système RAG sur le corpus de métadonnées de stations de votre réseau (réponses instrumentales, journaux de déploiement, rapports d’incident sur les données). « Quelles stations large bande proches de la marge de Cascadia présentaient des problèmes de datation connus en 2021 ? » devient une question retrouvable et répondable avec ses sources. Le mode d’échec se déplace lui aussi : une réponse RAG ne vaut que ce que vaut sa recherche documentaire, et le modèle synthétisera volontiers une réponse à partir des mauvais fragments. Quand vous évaluez un système RAG, évaluez les sources retrouvées, pas seulement la prose.
Usage d’outils : ce qui fait un agent¶
L’appel de fonction (function calling) permet au modèle d’émettre, au lieu de prose, une requête structurée — query_catalog(min_magnitude=5, region="Cascadia", since="2020-01-01") — que votre code exécute, le résultat repartant dans le contexte du modèle. Un agent n’est rien de plus exotique que :
un LLM + un ensemble d’outils + une boucle sur les observations.
Le modèle propose une action, le harnais l’exécute, l’observation revient dans le contexte, et le modèle propose l’action suivante, jusqu’à ce qu’il juge la tâche terminée. Lire des fichiers, exécuter du Python, chercher sur le web et interroger un catalogue de séismes FDSN ne sont que des outils dans la boucle. Un agent à qui l’on demande « le taux de sismicité a-t-il changé après le séisme de M 6,4 de 2022 ? » peut interroger le catalogue, écrire le test de changement de taux, l’exécuter, regarder les nombres et réviser — une véritable tâche scientifique en plusieurs étapes.
Cette architecture déplace la confiance. L’arithmétique est désormais faite par numpy, qui est fiable. Ce qui reste peu fiable, c’est tout ce que le modèle décide encore : quelles données interroger, quel test exécuter, si la magnitude de complétude a été traitée, si un résultat de requête vide signifie « aucun séisme » ou « mauvaise requête ». Les erreurs d’agent ne sont généralement pas des erreurs de calcul ; ce sont des erreurs de spécification et de jugement. C’est pourquoi 6.3 évalue les agents de bout en bout contre une vérité terrain au lieu de relire leur code ligne à ligne.
Un paragraphe sur les modèles de raisonnement et le calcul au moment de l’inférence : les modèles actuels peuvent être exécutés de manière à produire de longues chaînes internes de travail intermédiaire — brouillonner, vérifier, revenir en arrière — avant de répondre, dépensant plus de calcul par requête en échange de meilleures performances en mathématiques, en code et sur les problèmes à plusieurs étapes. Cela aide de façon fiable, et cela change le modèle de coût (une question difficile coûte plus cher qu’une question facile). Cela ne change rien à vos obligations : une réponse fausse après dix mille tokens de délibération reste fausse, et un long « raisonnement » visible peut rendre les erreurs plus persuasives, non moins fréquentes.
Modèles à poids ouverts et modèles par API¶
Vous pouvez appeler un modèle de pointe hébergé via une API, ou exécuter localement un modèle à poids ouverts (poids téléchargeables, exécution sur votre propre matériel). Les compromis sont génériques et méritent d’être raisonnés projet par projet plutôt que par effet de mode :
| Modèle de pointe par API | Poids ouverts, auto-hébergé | |
|---|---|---|
| Capacité | La plus élevée disponible | Les modèles plus petits ont comblé une grande part de l’écart ; encore généralement derrière la pointe |
| Structure de coût | Au token ; croît avec l’usage | Matériel et installation en amont ; coût marginal quasi nul |
| Latence | Aller-retour réseau ; limites de débit | Local ; vous maîtrisez le débit |
| Confidentialité | Les données quittent votre machine — vérifiez les conditions avant d’envoyer des données non publiées ou des éléments soumis au contrôle des exportations | Les données restent locales ; souvent le facteur décisif pour des données cliniques, propriétaires ou pré-publication |
| Reproductibilité | Les modèles hébergés changent sous vos pieds ; épinglez la version quand le fournisseur le permet | Vous maîtrisez les poids exacts pour toujours — épinglez-les comme n’importe quelle dépendance (chapitre 5) |
Pour des chaînes scientifiques par lots — extraction structurée sur dix mille résumés, disons — un petit modèle à poids ouverts doté d’un jeu d’évaluation bien conçu bat souvent un modèle de pointe coûteux qui n’en a aucun.
Hallucination : un mode d’échec distinct de l’erreur¶
Une erreur ordinaire est une réponse fausse produite par un processus traçable — un bogue, une hypothèse fausse, du bruit. L’hallucination est une fabrication fluide : le modèle produit un contenu précis, assuré, bien mis en forme, sans aucune source, parce que générer du texte plausible est exactement ce pour quoi il est optimisé. La distinction compte parce que vos réflexes de détection d’erreur sont calibrés sur les erreurs ordinaires, qui ont généralement l’air fausses par quelque endroit. Le contenu halluciné, lui, est sélectionné pour avoir l’air juste.
Le cas scientifique canonique est la citation fabriquée : des auteurs qui sonnent vrai, un titre plausible, une revue réelle, un DOI bien formé qui ne résout vers rien. L’extraction structurée en a une version plus subtile : demandez à un modèle d’extraire magnitudes, profondeurs et localisations de cinquante résumés vers un tableau, et la plupart des lignes seront justes tandis que quelques-unes contiendront des valeurs qui n’apparaissent nulle part dans le texte source, mises en forme exactement comme les bonnes. Rien ne les signale.
Les conséquences, que les deux carnets suivants transforment en pratique :
- Toute citation est vérifiée — résoudre le DOI, confirmer que l’article existe, confirmer qu’il dit bien ce pour quoi il est cité. Sans exception ; le contrôle coûte quelques minutes, et 6.2 vous fait concevoir la procédure.
- Toute affirmation quantitative est vérifiée contre les données, pas contre la plausibilité. La plausibilité est le seul test que les hallucinations réussissent à coup sûr.
- L’assurance et la mise en forme ne sont pas des preuves. Un tableau n’a pas plus de chances d’être juste parce que c’est un tableau bien rangé.
Traitez la sortie d’un LLM comme une mesure issue d’un instrument non étalonné : possiblement excellente, inutilisable tant que vous n’avez pas fait votre propre calibration. Construire cette calibration est l’objet des deux carnets suivants.