Une carte hiérarchisée des concepts d’ingénierie de l’IA et du moment où ils sont importants
Découvrez quels concepts d’ingénierie de l’intelligence artificielle déterminent si un système fonctionne ou non, lesquels sont essentiels une fois que vous développez pour la production, et lesquels peuvent attendre.
Une liste de noms traite les vingt éléments comme équivalents, alors qu’ils ne le sont clairement pas. Six d’entre eux déterminent si votre système fonctionne même au départ. Sept autres deviennent pertinents une fois que vous commencez à développer quelque chose pour la production. Les sept derniers sont des concepts que vous devriez pouvoir reconnaître dans une conversation, mais dont vous pouvez sans risque reporter l’étude approfondie d’un an — et, malheureusement, ce sont généralement ceux que les gens choisissent d’étudier dans leur temps libre.
Ce qui suit aborde le même sujet, mais associe à chaque concept trois éléments : ce qu’il vous apporte réellement, le moment où il devient important, et une façon de vérifier si vous le comprenez vraiment plutôt que de simplement reconnaître le terme.
Ces vérifications sont ce qui mérite l’attention. La plupart des gens ne découvrent qu’ils ont suivi un sujet pendant des mois sans vraiment le comprendre que lorsqu’ils tentent de l’expliquer à voix haute pour la première fois.
Niveau 1 : Les six éléments qui déterminent si votre système fonctionne
1. Les embeddings et la recherche vectorielle
Ce que cela vous apporte : Presque tout ce qui concerne la récupération d’informations dépend de ce concept, et une erreur dans son application provoque des échecs sans générer d’erreur visible.
Vérification : Deux modèles d’embeddings produisent chacun des vecteurs de 1024 dimensions. Expliquez pourquoi un classificateur entraîné sur les résultats d’un de ces modèles générera encore des résultats erronés lorsqu’on lui fournit des vecteurs provenant de l’autre modèle.
Si le fait que les dimensions soient identiques semblait être un signe de compatibilité, c’est justement là une erreur de compréhension. Un modèle d’embeddings définit sa propre géométrie. Deux modèles différents placeront une même phrase en des endroits complètement différents au sein d’espaces qui se contentent de partager la même forme. Rien dans votre architecture ne vous avertira de cela.
2. La qualité de la récupération, qui n’est pas identique à RAG
Ce que cela vous offre : Presque toute la qualité des réponses dans un système basé sur la récupération d’informations — et presque aucune de cette qualité ne provient du modèle linguistique lui-même.
Vérification : Citez les trois points où un pipeline RAG peut échouer avant même que le modèle linguistique ne soit appelé.
Les éléments en question sont le découpage du texte, la génération d’encodages vectoriels et le classement des résultats. Si vous divisez un document au mauvais endroit, vous perdez la phrase exacte qui répond à la question. En utilisant un modèle d’encodage entraîné sur un domaine inadapté, votre jargon se retrouve dans une zone inappropriée de l’espace vectoriel. En omettant un étape de réclassement, votre outil de récupération affiche des résultats thématiquement proches mais factuellement irrelevants. Les équipes qui pensent avoir un problème de hallucinations ont généralement en réalité un problème de récupération d’informations, et elles passent souvent un mois à ajuster leurs prompts avant de vérifier cela.
3. Évaluation
Ce que cela vous offre : La capacité de déterminer si un changement a réellement amélioré quelque chose, ce qui distingue l’ingénierie des suppositions.
Vérification : Décrivez l’ensemble de référence que vous utilisez pour évaluer — le nombre d’exemples, leur origine, les critères de notation, ainsi que la personne chargée de vérifier ces scores.
Si vous ne pouvez pas répondre avec des chiffres concrets, ce n’est pas une évaluation, mais plutôt des impressions accompagnées d’une démonstration qui a justement fonctionné un mardi. Un point de départ raisonnable se situe entre deux cents et cinq cents paires d’entrée/sortie réelles tirées du trafic réel, notées selon quelques dimensions précises, avec une vérification manuelle d’une partie des résultats. Il est également utile de savoir que si vous utilisez un modèle comme juge, ce dernier a lui-même besoin d’une évaluation — un problème récursif délicat mais inévitable.
4. Sortie structurée et utilisation d’outils
Ce que cela vous offre : La liaison entre un système qui génère du texte et un système qui effectue réellement des actions.
Vérification : Le modèle renvoie du JSON qui échoue à la validation par rapport à votre schéma. Décrivez précisément ce que fait ensuite votre système.
Beaucoup s’arrêtent à l’affirmation « nous essayons à nouveau », mais c’est là que commencent les vraies questions. Combien d’essais, avec quelle stratégie de retardement, et l’essai de réessayage inclut-il l’erreur de validation afin que le modèle ait la possibilité de corriger sa propre erreur ? Que se passe-t-il après l’échec final — l’utilisateur voit-il un message d’erreur, ou une réponse dégradée mais utilisable ? Une appel à outil est essentiellement une invocation de fonction à travers une frontière qui peut produire des hallucinations, donc toutes les pratiques standard de validation des entrées non fiables s’appliquent ici avec la même rigueur.
5. Contrôle des coûts et de la latence
Ce que cela vous apporte : La différence entre une fonctionnalité réellement mise en production et une démo rejetée pour des raisons financières.
La vérification : Indiquez votre coût actuel par requête, puis énumérez cinq moyens de le réduire de moitié, classés selon l’impact potentiel de chacun.
Cinq approches méritent d’être prêtes à l’avance. Envoyez des demandes simples à un modèle moins cher et plus petit plutôt qu’au modèle par défaut. Mémorisez les réponses aux demandes qui sont sémantiquement proches de celles que vous avez déjà traitées, et non seulement identiques. Réduisez ou compressez tout ce que vous insérez dans le prompt. Groupez tout ce qui n’a pas besoin d’une réponse en temps réel en lots et exécutez-les hors ligne. Raccourcissez également les sorties du modèle, car les tokens qu’il génère coûtent généralement plus que ceux que vous envoyez. Selon certaines sources, Stripe aurait payé plus de 7 milliards de dollars pour OpenRouter ce mois-ci — une entreprise dont le produit principal automatise essentiellement les deux premières de ces solutions — ce qui montre que le secteur cesse de considérer le contrôle des coûts comme un détail secondaire.
6. Gestion du contexte
Avantages : un comportement prévisible lorsque les données d’entrée dépassent la fenêtre de contexte, ce qui se produit constamment en environnement de production et presque jamais lors des démonstrations.
Vérification : Lorsque la fenêtre de contexte est pleine, qu’est-ce qui est supprimé et qui a pris cette décision ?
Une réponse fiable mentionne une politique concrète : supprimer d’abord les messages les plus anciens, éliminer en premier les extraits obtenus ayant la note la plus basse, résumer la partie intermédiaire ou refuser directement la demande. Une réponse préoccupante indique que le framework s’en occupe, car cela signifie généralement que quelque chose d’important est discrètement éliminé sans que personne n’ait réellement vérifié de quoi il s’agit.
Niveau 2 : Les sept aspects que vous découvrez en développant un produit réel
Ces aspects deviennent pertinents une fois que le système est en ligne et que des utilisateurs réels interagissent avec lui. Il n’y a aucun inconvénient à les étudier plus tôt, mais les aborder avant le niveau 1 place les efforts dans le mauvais ordre.
7. Les prompts en tant qu’artefacts versionnés
L’art de rédiger des prompts reçoit bien plus d’attention qu’il ne le mérite, tandis que la discipline d’ingénierie liée aux prompts en reçoit beaucoup moins. Ce dont on a réellement besoin, c’est d’un registre, de versions fixées, de comparaisons côte à côte, ainsi que de la capacité de revenir en arrière, car un prompt est en fait du code qui passe en production sans jamais être traité par un compilateur.
8. Stratégie de segmentation
Diviser le texte en fenêtres de taille fixe, le découper selon des frontières sémantiques et ajouter une superposition entre les blocs représentent tous différents compromis entre la récurrence et la précision. Le choix approprié dépend de la structure des documents sous-jacents, et non du paramètre par défaut recommandé par un tutoriel.
9. Réclassement
La méthode habituelle consiste d’abord à obtenir une liste étendue et peu coûteuse, puis à effectuer une évaluation plus coûteuse sur cette liste. Omettre cette deuxième étape est probablement la raison la plus fréquente pour laquelle un pipeline de récupération produit des résultats qui semblent presque corrects, mais pas tout à fait.
10. Mesures de sécurité et injection de prompts
Cela exige des défenses en plusieurs niveaux : des filtres bon marché au point d’entrée, des vérifications plus coûteuses plus proches du modèle lui-même. Tout texte provenant d’un utilisateur ou d’un document récupéré par votre système doit être considéré comme une entrée potentiellement hostile, et jamais comme des instructions fiables.
11. Observabilité pour les systèmes non déterministes
Il s’agit ici de traces, et non de simples journaux. La question vraiment importante est de savoir quels fragments ont été récupérés et quelle version de l’instruction était en vigueur lorsque une réponse incorrecte spécifique est apparue il y a trois jours, et seuls les détails au niveau des traces peuvent y répondre.
12. Choix entre l’instruction, la récupération et le réglage fin
Cette décision a bien plus d’importance que la maîtrise d’une seule technique. La récupération fournit des connaissances, l’ajustement fin affine le comportement et le format de sortie, tandis que les prompts couvrent tout le reste que l’on peut gérer sans eux. Une erreur fréquente consiste à recourir à l’ajustement fin pour résoudre ce qui est en réalité un manque de capacités de récupération.
13. Boucles d’agent et sélection d’outils
Un seul agent équipé d’un ensemble d’outils bien choisis et d’une boucle d’exécution limitée permet de gérer une proportion surprenante grande des problèmes que les gens tentent de résoudre en recourant plutôt à des architectures multi-agents.
Niveau 3 : Les sept à reconnaître et à différer
Pour ce niveau, il suffit de connaître le vocabulaire suffisamment bien pour suivre une conversation à ce sujet. S’approfondir peut attendre que un problème concret force la question, et pour de nombreux praticiens ce moment ne vient jamais.
14. Orchestration multi-agents
C’est la entrée la plus surévaluée de cette liste. De nombreux articles ont analysé pourquoi ces systèmes échouent une fois déployés, et la conclusion récurrente est que les coûts de coordination ainsi que les taux d’erreur cumulatifs font qu’ils se comportent moins bien que un agent unique, bien défini, pour la plupart des cas d’usage. Connaissiez le terme, et n’utilisez ce modèle qu’en dernier recours.
15. Quantification et optimisation du service
Cela revêt une grande importance si vous hébergez vos propres poids de modèle, mais presque aucune importance si vous utilisez simplement une API.
16. Fonctionnement interne des Transformers
Les mécanismes d’attention, les encodages positionnels et le reste de l’architecture apparaissent bien plus souvent lors des entretiens que dans le travail quotidien. Il vaut la peine de les apprendre une fois, mais en comprendre profondément les principes ne change pas vraiment la manière dont vous construisez des systèmes.
17. Distillation
Cela devient utile une fois que vous disposez déjà d’un système fonctionnel mais coûteux et que vous devez réduire les dépenses, ce qui est un problème que vous créez plutôt qu’un problème de départ.
18. Mémorisation sémantique
Une technique puissante mais dangereuse : un accès au cache pour une requête quasi identique renvoie une réponse fausse avec une certitude absolue.
19. Graphes de connaissances et GraphRAG
Ces outils offrent des avantages réels lorsque les données de base sont véritablement relationnelles, mais ils exigent une complexité supplémentaire considérable pour en tirer parti.
20. Ajustement des préférences et famille RLHF
Cela concerne principalement les équipes qui entraînent réellement des modèles, plutôt que celles qui développent des applications sur la base de modèles existants.
La partie délicate
En examinant les trois niveaux, vous remarquerez quelque chose d’incongru.
L’orchestration multi-agents, l’intérieur des modèles de type transformer et la rédaction des prompts sont les sujets qui exigent le plus d’efforts d’apprentissage de la part des gens, et tous trois relèvent du niveau 2 ou 3. En revanche, l’évaluation, la qualité de la récupération des informations et le contrôle des coûts sont ce qui détermine réellement si un système fonctionne, mais ils reçoivent seulement une petite partie de l’attention, principalement parce qu’aucun d’eux ne permet de créer une démonstration convaincante.
Il existe une raison claire à cette différence, et il vaut mieux l’énoncer directement plutôt que de la présenter comme une critique. Les sujets de niveau 3 sont faciles à consommer : on peut en lire sur l’orchestration multi-agents pendant un trajet et partir en ayant l’impression d’avoir appris quelque chose. En revanche, l’évaluation oblige à créer un ensemble de données idéal, à débattre avec un collègue de ce que signifie réellement « bon », et parfois à accepter que son système n’était jamais aussi performant qu’il ne le semblait dans la démonstration. L’une de ces activités est agréable ; l’autre est celle qui aide réellement.
Comment vraiment apprendre ces concepts plutôt que de simplement les collecter
Le piège avec une telle liste est de la traiter comme un programme d’études à lire intégralement. La lecture ne mène qu’à la reconnaissance, et cette dernière s’effondre dès que quelqu’un pose une question complémentaire.
Deux habitudes fonctionnent bien mieux que la simple lecture.
Tout d’abord, construisez un petit système de bout en bout, puis brisez-le délibérément. Dirigez un pipeline de récupération vers des documents qui vous importent vraiment, et sabotez chaque étape intentionnellement. Divisez le texte de manière inadéquate et observez la dégradation de la qualité des réponses. Supprimez le module de reclassement et notez les changements. Faites subir au système une tentative d’injection de prompt et voyez ce qui est divulgué. Un week-end passé de cette façon enseigne plus qu’un mois de lecture, car ce qui reste, ce sont des souvenirs de faillites concrètes, et non des définitions abstraites.
Deuxièmement, mettez à l’épreuve ce vocabulaire avec des questions réalistes. Les vérifications décrites dans cet article sont basées sur le type de questions qui se posent réellement en pratique, et travailler sur des exercices concrets de conception de systèmes est le moyen le plus rapide de repérer les lacunes dans votre compréhension, surtout parce que les vraies questions comportent des suivi, et c’est précisément là que la simple reconnaissance superficielle devient insuffisante.
Où je pourrais me tromper
Cette classification est un jugement subjectif influencé par les systèmes spécifiques examinés ici, et non le résultat d’une enquête formelle ; il est donc plus honnête de la qualifier d’ordre défendable plutôt que de classement définitif.
Il y a deux positions qui méritent d’être discutées ouvertement. L’orchestration multi-agents se trouve au niveau 3 en partie parce que les données actuelles sur le comportement de ces systèmes en environnement de production ne sont pas flatteuses, et un cadre vraiment solide apparaissant dans un avenir proche pourrait facilement le faire monter en grade. Les mécanismes internes des Transformers occupent une place basse ici, car travailler avec des modèles d’IA est de plus en plus une discipline d’intégration plutôt que de modélisation, et quiconque travaille directement sur les modèles eux-mêmes devrait placer ce sujet bien plus haut.
La position qui mérite la défense la plus ferme est l’évaluation, classée en troisième position, et il existe de bonnes raisons de la placer plutôt en première. Sans elle, tous les autres éléments de cette liste deviennent des suppositions, car on ne peut améliorer ce que l’on ne peut pas mesurer, et très peu d’équipes qui développent sur la base de modèles aujourd’hui peuvent réellement dire si les changements de la semaine précédente ont amélioré ou détérioré les choses.
Si vous deviez réorganiser ce classement, les désaccords les plus intéressants se situent probablement à la frontière entre le niveau 1 et le niveau 2. Une discussion plus utile consisterait à indiquer quel élément vous aimeriez faire monter en grade et ce que ce changement vous a réellement apporté, plutôt que de créer encore une liste de vingt termes.
Lectures complémentaires
- Gérer LLM-as-a-Judge en tant que système de production dynamique — Découvrez comment le cycle de vie en quatre étapes de Netflix — données fiables, entraînement ajusté selon des critères précis, déploiement sécurisé et surveillance continue — permet à un système LLM-juge de rester précis à grande échelle.