AI Engineering

1Le produit d'abord, le modèle ensuite

Le ML engineering classique partait des données pour entraîner SON modèle. L'AI engineering renverse l'ordre : on part d'un modèle existant, entraîné par quelqu'un d'autre, et tout le métier consiste à l'adapter, l'évaluer et le servir.

Ce renversement a trois conséquences qui structurent le livre :

• on ne touche plus aux poids du modèle (sauf finetuning tardif) ;
• les modèles sont si gros que l'optimisation de l'inférence devient un sujet à part entière ;
• les sorties sont ouvertes (du texte libre, pas une étiquette), donc l'évaluation devient le problème le plus dur.

La promesse de méthode tient en une phrase de la préface : « les outils se périment vite, les fondamentaux durent plus longtemps ». Huyen sait de quoi elle parle : elle enseignait TensorFlow en 2017, et en tire la leçon sur elle-même.

2L'anglais est la langue maternelle des modèles, et ça se paie

Dans Common Crawl, le corpus du web qui nourrit les modèles, l'anglais pèse 45,88 % ; le bengali, parlé par 272 millions de personnes, 0,093 % (ch. 2). Ce déséquilibre se paie de deux façons :

• la qualité baisse : GPT-4 résout trois fois plus de problèmes de maths en anglais qu'en arménien ou en farsi, et zéro sur six en birman ;
• la facture grimpe : le même contenu, tokenisé, est plus de quatre fois plus long en hindi qu'en anglais, dix fois plus long en birman. Sur une API facturée au token, une langue rare coûte dix fois plus cher pour un service moins bon.

Pour un développeur francophone, la leçon est concrète : testez vos prompts en français, mais sachez que le modèle « pense » dans une langue où votre marché est minoritaire.

3Les hallucinations ne sont pas des bugs, elles sont le produit

Un modèle de langage génère du probable, pas du vrai : « tout ce qui a une probabilité non nulle, aussi tiré par les cheveux ou faux soit-il, peut être généré par l'IA » (ch. 2). Huyen consacre au sampling (température, top-p) la section qu'elle dit avoir été la plus enthousiasmante à écrire : c'est là que naissent à la fois l'incohérence, les hallucinations et des gains spectaculaires. L'astuce Best-of-N en est l'exemple frappant :

# on génère N réponses (température > 0 → elles diffèrent),
# puis un petit évaluateur garde la meilleure
reponses = [llm(prompt) for _ in range(5)]
meilleure = max(reponses, key=noter)
# qualité ≈ celle d'un modèle 30× plus gros (OpenAI, 2021)

Sur l'origine des hallucinations, le livre pose deux hypothèses complémentaires :

• l'auto-illusion : le modèle traite ses propres tokens comme des faits, et fait boule de neige sur sa première erreur ;
• le désaccord de connaissances : pendant le finetuning supervisé, les annotateurs s'appuient sur des connaissances que le modèle n'a pas. On lui apprend littéralement à affirmer sans savoir.

Aucune des deux n'est résolue.

4L'évaluation est le goulot d'étranglement, pas le modèle

Quand Huyen demande aux équipes comment elles évaluent leurs applications, beaucoup répondent qu'elles regardent les résultats à l'œil (ch. 3). En face, les benchmarks publics rassurent pour de mauvaises raisons :

• OpenAI a trouvé 13 benchmarks dont au moins 40 % des données figuraient déjà dans le jeu d'entraînement de GPT-3 ;
• un doctorant de Stanford a fait scorer quasi parfaitement un modèle d'un million de paramètres en l'entraînant uniquement sur les données de test. Son papier satirique : « Pretraining on the Test Set Is All You Need ».

La réponse du livre : construire SA propre pipeline d'évaluation, calée sur des critères métier définis avant de coder. Et si vous vous outillez d'une IA juge, connaissez ses biais documentés : Claude-v1 se préfère lui-même avec 25 % d'écart, et les juges favorisent les réponses longues et la première position. La phrase de Greg Brockman que Huyen reprend : « les evals sont étonnamment souvent tout ce dont vous avez besoin ».

5Le contexte est le nouveau feature engineering

Un modèle se trompe d'abord quand il lui manque l'information : Huyen appelle la construction de contexte « le feature engineering des foundation models » (ch. 10). Le pattern RAG (Retrieval-Augmented Generation : aller chercher les documents pertinents dans une base externe et les injecter dans le prompt avant que le modèle réponde) est la réponse standard à ce manque, et le livre donne des repères chiffrés rares :

• commencez par la recherche par termes (BM25), que le PDG de Perplexity décrit comme difficile à véritablement améliorer ;
• les embeddings viennent après, et leur facture est réelle : il n'est pas rare qu'une base vectorielle coûte un cinquième, voire la moitié, de la facture d'API du modèle (ch. 6) ;
• l'encadré le plus contre-intuitif : si votre base de connaissances tient sous 200 000 tokens, environ 500 pages, mettez tout dans le contexte et oubliez le RAG (note Anthropic, ch. 6).

Le pipeline RAG, maillon par maillon, tient en quelques lignes :

question = "quelle est votre politique de retour ?"

# 1. on cherche les 3 documents les plus proches dans la base externe
docs = base_vectorielle.chercher(embed(question), top_k=3)

# 2. on les COLLE dans le prompt, avant la question
prompt = f"Réponds en t'appuyant SEULEMENT sur :\n{docs}\n\n{question}"

# 3. le modèle répond sur des faits fournis, pas sur sa mémoire floue
reponse = llm(prompt)

if contient_donnees_perso(entree):
    bloquer()                       # filtre d'ENTRÉE (PII, secrets, prompt injection)

reponse = llm(prompt)

if jugee_toxique(reponse):
    reponse = message_de_repli()    # filtre de SORTIE (un 2e modèle modérateur)

Trois choses que je ne savais pas avant de le lire

• Grok, le modèle de X, a été surpris à citer les politiques d'usage… d'OpenAI : le web est tellement plein de sorties ChatGPT que les nouveaux modèles s'entraînent dessus sans le vouloir (ch. 2).
• Répéter 0,1 % des données d'entraînement 100 fois suffit à faire chuter un modèle de 800 millions de paramètres au niveau d'un modèle deux fois plus petit (étude Anthropic, ch. 8).
• Demander à ChatGPT de répéter le mot « poem » à l'infini l'a fait dériver jusqu'à recracher des morceaux de ses données d'entraînement (ch. 5).

Toujours valable en 2026 ?

Les fondamentaux, oui : l'évaluation d'abord, le contexte avant le finetuning, les erreurs composées des agents, l'architecture progressive. Les noms propres, eux, tournent vite (détail dans l'avis) : prenez les principes, re-vérifiez les outils. Aucune deuxième édition annoncée ; le repo GitHub officiel de l'autrice maintient les ressources à jour.

Pour qui ?

Pour aller plus loin

Toute la section /apprendre/ de ce site est construite en codant avec l'IA, le repo officiel du livre (chiphuyen/aie-book) maintient les ressources par chapitre, et dans cette bibliothèque, Designing Data-Intensive Applications joue le même rôle pour les systèmes distribués.