Apprentissage automatique et grands modèles de langage pour les architectes

Pourquoi les architectes doivent comprendre le modèle

Tous les composants des chapitres précédents de ce cours étaient déterministes : pour une même entrée et un même état, un service renvoyait la même sortie, et un test pouvait l’affirmer. Un composant fondé sur l’apprentissage automatique est d’une nature différente. Il n’a pas été écrit sous forme de règles ; il a été ajusté à des exemples, et ce qu’il renvoie est une meilleure estimation statistique. Un modèle de fraude renvoie un score, pas un verdict. Un grand modèle de langage (LLM) renvoie un texte fluide, généralement juste et parfois faux, avec aplomb.

Un architecte n’a pas besoin d’entraîner des modèles, pas plus qu’il n’a besoin d’écrire un moteur de base de données. Il doit en revanche connaître les propriétés d’un modèle assez bien pour concevoir en fonction d’elles, de la même façon que le chapitre 7 demandait de savoir ce que garantit réellement un niveau d’isolation. Ces propriétés sont : comment les modèles sont fabriqués et ce que cela implique pour leurs connaissances ; comment ils échouent ; d’où viennent leur coût et leur latence ; et pourquoi on ne peut jamais se fier à leur sortie comme on se fie à une ligne de base de données. Tout le reste de ce chapitre, de la récupération aux garde-fous, en découle.

L’apprentissage automatique en une page

L’apprentissage automatique construit une fonction à partir de données plutôt qu’à partir de règles écrites à la main. Il existe trois familles classiques. En apprentissage supervisé, les données d’entraînement contiennent les bonnes réponses (les étiquettes) : des paiements passés marqués comme frauduleux ou authentiques, des livraisons passées avec leur durée réelle. Le modèle apprend à associer les entrées aux étiquettes. Prédire une catégorie relève de la classification (fraude ou non) ; prédire un nombre relève de la régression (minutes avant l’arrivée du repas). En apprentissage non supervisé, il n’y a pas d’étiquettes, et le modèle trouve une structure par lui-même : des groupes de clients similaires, des transactions inhabituelles qui ne correspondent à aucun motif, des représentations numériques compactes de textes. En apprentissage par renforcement, un agent effectue des actions dans un environnement et apprend à partir d’un signal de récompense plutôt que de bonnes réponses, par exemple une politique d’affectation des livreurs récompensée pour des délais de livraison courts.

Les grands modèles de langage proviennent surtout d’une quatrième variante, l’apprentissage auto-supervisé, dans laquelle les étiquettes sont tirées des données elles-mêmes : on masque le mot suivant d’une phrase et on entraîne le modèle à le prédire. Comme n’importe quel texte fournit ses propres étiquettes, on peut entraîner les modèles sur bien plus de données que quiconque ne pourrait en étiqueter à la main.

Deux phases comptent pour l’architecture. L’entraînement ajuste les nombres internes du modèle (ses paramètres ou poids) pour réduire l’erreur sur les données d’entraînement. C’est une lourde charge de travail par lots : de grands jeux de données, de nombreux accélérateurs (des GPU ou des puces similaires), des heures à des mois de calcul, et un pipeline qui doit être reproductible. L’inférence consiste à utiliser le modèle entraîné pour produire des sorties à partir de nouvelles entrées. C’est une charge de travail de service, avec des objectifs de latence, des débits de requêtes et un coût par appel, comme n’importe quel autre service du chapitre 9. La plupart des équipes qui construisent des fonctionnalités d’IA n’entraînent jamais de grand modèle ; elles consomment l’inférence d’un fournisseur ou font tourner des poids entraînés par d’autres.

Le modèle mental le plus utile consiste à voir un modèle entraîné comme une fonction probabiliste. Pour une entrée, il produit des scores ou une distribution de probabilités sur les sorties possibles. Quelqu’un, en général l’application, transforme ensuite cette distribution en décision : bloquer le paiement si le score de fraude dépasse 0,8, ou choisir le mot suivant par échantillonnage. Cette dernière étape est une décision de conception aux conséquences métier, et elle relève de l’architecture, pas du modèle.

Les bases de l’évaluation : précision, rappel et surapprentissage

Comme un modèle est ajusté plutôt que spécifié, la seule façon de savoir s’il est bon est de le mesurer sur des exemples qu’il n’a pas vus. Les données sont réparties entre un jeu d’entraînement (pour ajuster le modèle), un jeu de validation (pour régler des choix comme les seuils) et un jeu de test mis de côté pour la mesure finale et honnête. Un modèle qui obtient de bons scores sur ses données d’entraînement mais de mauvais sur de nouvelles données fait du surapprentissage : il a mémorisé les particularités des exemples au lieu d’apprendre le motif général. La fuite de données, où une information sur la réponse se glisse dans les entrées (par exemple un indicateur de remboursement qui n’est positionné qu’une fois la fraude confirmée), produit des modèles qui semblent excellents en test et échouent en production.

Pour la classification, l’exactitude seule est trompeuse dès qu’une classe est rare. Comptez quatre issues : les vrais positifs (fraude signalée), les faux positifs (paiement authentique signalé), les faux négatifs (fraude manquée) et les vrais négatifs. La précision est la part des éléments signalés qui sont réellement positifs, TP / (TP + FP). Le rappel est la part des positifs réels qui ont été détectés, TP / (TP + FN). Relever le seuil de décision augmente généralement la précision et réduit le rappel, et le bon équilibre dépend de ce que coûte chaque type d’erreur. Le score F1, moyenne harmonique des deux, les résume en un seul nombre lorsque les coûts sont comparables.

Les modèles se dégradent aussi après leur déploiement. Lorsque les entrées que voit le modèle s’éloignent des données d’entraînement (nouveaux restaurants, nouveau moyen de paiement, pandémie qui modifie les habitudes de commande), son exactitude baisse sans bruit. La supervision de ce phénomène fait partie de l’évaluation des systèmes d’IA, traitée plus loin dans ce chapitre.

L’apprentissage profond et le transformer

Un réseau de neurones est un empilement de couches, chacune calculant des sommes pondérées de ses entrées, suivies d’une fonction non linéaire simple. L’entraînement ajuste par petites touches des millions ou des milliards de poids, par descente de gradient et rétropropagation, afin que les sorties du réseau se rapprochent des cibles. L’apprentissage profond désigne les réseaux à nombreuses couches, qui apprennent leurs propres représentations internes de l’entrée au lieu de s’appuyer sur des caractéristiques conçues à la main. Il a transformé la reconnaissance d’images à partir de 2012 environ, puis la parole et la traduction peu après.

Le langage était plus difficile, car le sens dépend du contexte : dans le livreur a laissé le sac parce qu’il était déchiré, il renvoie au sac. Les réseaux récurrents antérieurs traitaient le texte un mot à la fois, ce qui rendait l’entraînement lent et le contexte à longue distance fragile. En 2017, Ashish Vaswani et ses collègues de Google ont publié Attention Is All You Need, qui introduisait le transformer. Son mécanisme central, l’auto-attention, permet à chaque position du texte de calculer un mélange pondéré d’informations provenant de toutes les autres positions, si bien que il peut porter fortement son attention sur sac. Comme toutes les positions sont traitées en parallèle pendant l’entraînement, les transformers utilisent efficacement les accélérateurs modernes, et leur qualité n’a cessé de progresser à mesure qu’on augmentait la taille des modèles, des données et du calcul.

Deux conséquences concernent l’architecte. D’abord, le calcul de l’attention croît à peu près avec le carré de la longueur de la séquence, ce qui explique en partie pourquoi la longueur du contexte est limitée et pourquoi les longs prompts coûtent plus de temps et d’argent (les progrès de l’ingénierie ont atténué ce coût, sans le supprimer). Ensuite, il existe différentes formes de transformers pour différentes tâches : les modèles décodeur seul génèrent du texte et sont à la base des modèles de chat actuels, tandis que les modèles encodeurs dans la lignée de BERT (2018) lisent du texte pour le classer ou le représenter, et font fonctionner de nombreux modèles d’embedding et de re-ranking utilisés pour la récupération. Beaucoup de grands modèles utilisent aussi une conception à mélange d’experts, dans laquelle seule une partie du réseau est active pour chaque token, ce qui réduit le coût d’inférence pour une taille totale donnée.

Comment un grand modèle de langage produit du texte

Un modèle ne lit ni des caractères ni des mots ; il lit des tokens, des fragments de texte issus d’un vocabulaire fixe de dizaines ou de centaines de milliers d’entrées, produits par un tokeniseur. Les mots courants forment un seul token ; les mots rares, les noms et les nombres se découpent en plusieurs. Pour un texte en anglais, une règle empirique courante est d’environ quatre caractères, soit les trois quarts d’un mot, par token. Les autres langues et le code source nécessitent souvent davantage de tokens pour le même contenu, ce qui compte car les prix, les limites et la latence se calculent tous en tokens.

La fenêtre de contexte est le nombre maximal de tokens que le modèle peut prendre en compte lors d’un appel, en comptant les instructions, la conversation jusque-là, les documents fournis et la réponse qu’il rédige. En 2026, les fenêtres vont de quelques milliers de tokens pour les petits modèles embarqués sur l’appareil à environ un million, voire plus, pour certains modèles hébergés. Une grande fenêtre n’implique pas qu’on en fasse bon usage : Liu et ses collègues (Lost in the Middle, 2023) ont montré que les modèles exploitent les informations situées au début et à la fin d’un long contexte de manière plus fiable que celles enfouies au milieu, et chaque token supplémentaire ajoute du coût et de la latence.

La génération est une prédiction du token suivant en boucle. Le modèle lit toute l’entrée (la phase de prefill) et produit une probabilité pour chaque token de son vocabulaire d’être le suivant. Un token est choisi, ajouté à l’entrée, et le processus recommence (la phase de décodage) jusqu’à ce que le modèle émette un marqueur de fin ou atteigne une longueur maximale. Le modèle met en cache les résultats internes des tokens déjà traités (le cache KV), si bien que chaque étape ne calcule que le nouveau token, mais la sortie est toujours produite un token à la fois. C’est pourquoi les tokens de sortie sont plus lents et généralement plusieurs fois plus chers que les tokens d’entrée, et pourquoi les réponses sont diffusées en streaming aux utilisateurs au fur et à mesure de leur production.

La façon dont le token suivant est choisi s’appelle l’échantillonnage. Le décodage glouton prend toujours le token le plus probable. La température commence par remettre les probabilités à l’échelle : en dessous de 1, elle les accentue en faveur du favori ; au-dessus de 1, elle les aplatit, de sorte que les tokens moins probables apparaissent plus souvent. L’échantillonnage top-p (nucleus) ne garde que les tokens les plus probables dont les probabilités totalisent p, et le top-k ne garde que les k plus probables. Une température basse convient à l’extraction, à la classification et à la notation ; une température plus élevée convient au remue-méninges et à la variété des formulations.

Enfin, le modèle est sans état. Une API de modèle ne se souvient de rien d’un appel à l’autre : une conversation ne paraît continue que parce que l’application envoie tout l’historique pertinent à chaque requête. L’état de la conversation se trouve donc dans votre système, sa taille détermine le coût à chaque tour, et décider de ce qu’il faut garder, résumer ou abandonner est une tâche de conception (voir mémoire et état à la section 12.4).

import math

# raw scores the model gives three candidate next tokens after
# "The capital of Portugal is"
logits = {"Lisbon": 9.0, "Porto": 6.5, "Madrid": 5.0}

def probabilities(logits, temperature):
    scaled = {t: v / temperature for t, v in logits.items()}
    total = sum(math.exp(v) for v in scaled.values())
    return {t: round(math.exp(v) / total, 4) for t, v in scaled.items()}

print(probabilities(logits, 1.0))  # Lisbon 0.9088, Porto 0.0746, Madrid 0.0166
print(probabilities(logits, 0.5))  # Lisbon 0.9930, Porto 0.0067, Madrid 0.0003
print(probabilities(logits, 2.0))  # Lisbon 0.7033, Porto 0.2015, Madrid 0.0952

Les embeddings : le sens sous forme de nombres

Un embedding est une liste de nombres (un vecteur, généralement long de quelques centaines à quelques milliers de nombres) qui représente le sens d’un texte, d’une image ou d’un produit, produite par un modèle d’embedding. Le modèle est entraîné de sorte que les éléments de sens proche se retrouvent proches les uns des autres : mon repas est arrivé froid et la commande n’était pas chaude à la livraison produisent des vecteurs voisins alors qu’ils n’ont presque aucun mot en commun. La proximité se mesure généralement par la similarité cosinus, l’angle entre deux vecteurs.

Les embeddings servent à la recherche sémantique, aux recommandations, à la déduplication, au regroupement (clustering) et à la classification, et ils sont au cœur de la plupart des systèmes de génération augmentée par récupération. Deux faits architecturaux en découlent. Les modèles d’embedding sont distincts, plus petits et bien moins chers que les modèles de génération, et peuvent facilement tourner sur votre propre infrastructure. Et les vecteurs issus de modèles d’embedding différents (ou de versions différentes d’un même modèle) ne sont pas comparables : changer de modèle d’embedding implique donc de recalculer les embeddings de tout le corpus, une décision peu coûteuse à prendre tôt et coûteuse à inverser plus tard.

Du pré-entraînement à un assistant utile

Un modèle de chat moderne se construit par étapes. Le pré-entraînement applique la prédiction auto-supervisée du token suivant à un énorme corpus de texte et de code, souvent des milliers de milliards de tokens. C’est de loin l’étape la plus coûteuse, à la portée de quelques organisations seulement, et elle produit un modèle de base : un puissant continuateur de texte qui a assimilé la grammaire, des faits, des styles et des schémas de raisonnement, mais qui ne suit pas les instructions de manière fiable. Tout ce que le modèle sait de son pré-entraînement est figé à une date de fin d’entraînement.

Le fine-tuning poursuit l’entraînement sur un jeu de données bien plus petit et ciblé. Le fine-tuning sur instructions s’appuie sur des exemples d’instructions associées à de bonnes réponses, ce qui transforme le modèle de base en assistant. L’apprentissage par renforcement à partir de retours humains (RLHF) demande ensuite à des personnes de comparer des paires de réponses, entraîne un modèle de récompense à prédire leurs préférences, et optimise l’assistant pour qu’il obtienne un bon score selon ce modèle. L’approche a été décrite par Christiano et ses collègues en 2017 et appliquée au suivi d’instructions dans les travaux InstructGPT d’OpenAI (Ouyang et ses collègues, 2022). Des variantes remplacent certaines parties du pipeline : l’optimisation directe des préférences (direct preference optimisation, 2023) apprend à partir des comparaisons sans modèle de récompense distinct, et les retours peuvent venir d’un autre modèle suivant des principes écrits plutôt que de personnes.

Les organisations peuvent aussi faire du fine-tuning, souvent avec des méthodes économes en paramètres comme LoRA (Hu et ses collègues, 2021), qui entraînent un petit module complémentaire plutôt que tous les poids. Le fine-tuning est efficace pour enseigner un format, un ton, une tâche ciblée ou le vocabulaire d’un domaine. C’est un mauvais moyen d’enseigner des faits qui changent, comme des prix ou des règles, car ces faits se retrouvent alors figés dans des poids qui ne peuvent pas citer leur source, ne peuvent pas être mis à jour sans réentraînement et ignorent les droits d’accès. Pour des connaissances qui évoluent, la récupération est généralement le meilleur outil ; l’ordre habituel des tentatives est : de meilleurs prompts, puis la récupération, puis le fine-tuning.

Hallucination et non-déterminisme

Une hallucination est une sortie fluide et assurée mais fausse ou non étayée : une citation inventée, une fonction qui n’existe pas dans une bibliothèque, une politique de remboursement que l’entreprise n’a jamais eue. C’est une conséquence directe du fonctionnement du modèle. L’entraînement récompense des suites plausibles, pas des suites vérifiées, et le modèle n’a aucun moyen intégré de distinguer ce qu’il sait de ce qui sonne simplement juste. Les taux d’hallucination varient beaucoup selon le modèle et la tâche, et ils baissent lorsque le modèle reçoit les faits pertinents (ancrage), lorsqu’il est autorisé et encouragé à dire qu’il ne sait pas, ou lorsqu’il doit citer des sources que l’application peut vérifier. Ils ne tombent jamais à zéro.

Les sorties sont aussi non déterministes. Avec l’échantillonnage, le même prompt donne par construction des réponses différentes. Même à température 0, les modèles hébergés ne sont pas garantis reproductibles : l’arithmétique en virgule flottante sur les accélérateurs n’est pas parfaitement associative, et la façon dont un serveur regroupe votre requête avec d’autres peut changer l’ordre des opérations et donc, à l’occasion, un token. Les fournisseurs mettent aussi à jour des modèles sous des noms inchangés. De petites modifications de la formulation du prompt, de l’ordre des exemples ou du contexte environnant peuvent changer sensiblement les résultats.

Pour un architecte, ces deux propriétés signifient qu’un test qui vérifie une sortie exacte unique ne prouve pas grand-chose, que la version du modèle et le prompt doivent être enregistrés avec chaque résultat, et que toute sortie importante doit être vérifiée par quelque chose de plus fiable que le modèle lui-même.

Concevoir autour d’un composant probabiliste

L’idée architecturale la plus importante de ce chapitre est le confinement. Un modèle est un composant puissant mais peu fiable : c’est donc le code déterministe qui l’entoure qui décide de ce que le modèle a le droit de voir, de ce qu’il a le droit de faire et de ce qu’il advient de sa sortie. En termes d’architecture hexagonale, le modèle se trouve derrière un port : le domaine demande un brouillon de réponse, une classification ou une extraction, et l’adaptateur qui appelle le modèle fait aussi respecter le contrat de sortie. Les règles du domaine (plafonds de remboursement, horaires d’ouverture, qui peut voir quelle commande) restent dans du code ordinaire et testable.

Un test utile pour toute fonctionnalité d’IA proposée consiste à se demander ce qui se passe quand le modèle se trompe de la manière la plus plausible. Si la réponse est un client voit une phrase un peu maladroite, peu de contrôle est nécessaire. Si c’est un remboursement est versé sur le mauvais compte ou on indique la mauvaise dose à un patient, la conception doit rendre cette issue impossible par la validation, les permissions et la confirmation humaine, quelle que soit la qualité du modèle. Les modèles continueront de s’améliorer ; ce principe de conception, lui, ne changera pas.