Comment devenir ingénieur en IA appliquée

J'ai écrit ce guide tel que j'aurais aimé le trouver avant de faire la transition vers l'ingénierie IA appliquée.

Ce rôle recoupe largement celui d'ingénieur logiciel traditionnel, mais il ajoute quelques concepts importants que la plupart des ingénieurs logiciels doivent apprendre en effectuant cette transition. Je vous suggère d'utiliser ce document comme un plan des sujets clés à maîtriser, puis de suivre les ressources liées tout au long de l'article lorsque vous souhaitez approfondir.

À la fin, vous devriez avoir une compréhension beaucoup plus claire de ce qu'est l'ingénierie IA appliquée, ce que le poste exige réellement, et en quoi elle va au-delà de l'ingénierie logicielle traditionnelle.

Si vous êtes intéressé à travailler sur certains des problèmes les plus passionnants en IA appliquée avec une équipe d'ingénieurs très talentueuse, nous recrutons en permanence. Postulez sur notre site web à varickagents.com ou recommandez un candidat pour une prime de recommandation de 20 000 $.

Cela dit, la meilleure façon de comprendre l'ingénierie IA appliquée est de commencer par le changement dans votre façon de penser la construction de logiciels.

Ingénierie logicielle vs ingénierie IA

La plus grande différence entre être ingénieur logiciel et ingénieur IA est que l'ingénierie logicielle traditionnelle vous forme à penser de manière déterministe, tandis que l'IA appliquée vous oblige à penser de manière probabiliste.

Dans un logiciel normal, vous écrivez la logique, vous la faites fonctionner, et quand quelque chose casse, vous pouvez généralement en retrouver la trace – une entrée structurée donne de manière déterministe une sortie structurée.

L'IA appliquée ne fonctionne pas comme ça. Vous construisez autour d'un appel API non déterministe à l'intelligence, ce qui signifie que la même entrée peut revenir différente à chaque fois. Pour cette raison, le travail ne consiste plus seulement à construire le logiciel, mais à mesurer si le système se comporte réellement comme il le devrait.

La façon dont nous procédons est par le biais des évaluations, donc je vais détailler comment construire une suite d'évaluation qui garantit que l'agent que vous développez ne commet pas d'erreurs. J'ai appris que c'est l'une des compétences les plus importantes d'un développeur IA appliqué, compte tenu de la nature non déterministe du travail que nous effectuons.

La partie suivante de l'article couvre le développement de chaque partie d'un agent IA (sauf le modèle lui-même, bien sûr), car vous pouvez appeler une API vers un modèle mais vous devez construire tout le reste vous-même. C'est ce qu'on appelle l'ingénierie du harnais.

Et enfin, je vais couvrir comment passer d'un agent en production à plusieurs – et pourquoi c'est un problème de systèmes distribués. Si vous arrivez à la fin de cet article, il n'y a aucune raison pour que vous ne puissiez pas faire la transition pour devenir ingénieur IA appliqué.

Évaluations

Un ingénieur IA appliqué transforme l'incertitude en confiance mesurée à l'aide d'évaluations. Dans le développement logiciel traditionnel, vous faites confiance au système parce que vous avez écrit la logique et testé le code. En IA appliquée, vous ne pouvez pas faire confiance au système de cette façon car le modèle peut se comporter différemment d'une exécution à l'autre. L'ingénieur IA doit donc construire une couche de mesure autour de l'agent.

Une évaluation est le processus qui consiste à confier une tâche à un agent, à le laisser s'exécuter, et à noter ce qu'il a fait. L'objectif est de prouver deux choses : l'agent a terminé le travail correctement, et l'agent est resté dans les limites qui lui ont été fixées.

La première étape consiste à noter le résultat. C'est l'étape la plus simple du processus d'évaluation. Pour un agent de factures, ceux sur lesquels je travaille habituellement, cela signifie s'assurer que la facture arrive au bon endroit, ou que le doublon est signalé. Vous comparez simplement le résultat final à ce qui aurait dû se produire.

La deuxième étape consiste à noter la trajectoire. C'est le chemin que l'agent a emprunté pour arriver à ce résultat : les outils qu'il a appelés, les champs qu'il a touchés, les arguments qu'il a passés, et les actions qu'il a tentées en cours de route. Cela compte car un agent peut atteindre la bonne réponse finale tout en faisant quelque chose de dangereux dans le processus. Il peut classer une facture correctement tout en modifiant les coordonnées bancaires ou en envoyant un paiement avant approbation.

La trajectoire elle-même n'est qu'un journal : une liste ordonnée de chaque outil que l'agent a appelé et des arguments qu'il a passés – la noter signifie simplement écrire des vérifications sur ce journal.

Certaines vérifications sont déterministes – s'assurer que send_payment n'apparaît jamais avant un appel d'approbation, vérifier que les seuls champs modifiés étaient ceux que l'agent était autorisé à modifier. D'autres sont des appels de jugement – si une escalade était appropriée, si le raisonnement justifiait l'action. Ceux-ci vont à un second modèle avec une grille d'évaluation.

Le principe général à suivre est que les vérifications déterministes attrapent généralement les violations de sécurité, tandis que le modèle juge note la qualité.

Le résultat est deux notes par cas de test : l'agent a-t-il obtenu la bonne réponse, et s'est-il comporté correctement pour y parvenir. Ceux-ci doivent être rapportés séparément, car un agent qui classe correctement les factures 95 % du temps mais touche un champ interdit dans 4 % des exécutions semble excellent sur un score composite mais cause des complications commerciales majeures en production.

Cet article sert d'introduction aux évaluations et à tous les autres sujets abordés, j'ai donc lié d'autres ressources pour vous aider à approfondir. Certaines qui m'ont aidé à comprendre comment construire des évaluations efficaces sont :

• Le cours d'évaluation d'Anthropic
• Le guide complet de Lenny sur les évaluations
• La FAQ de Hamel sur les évaluations

Je recommanderais de parcourir chacun d'eux, mais en commençant par ceux de Lenny et Hamel avant de suivre le cours d'évaluation (qui est légèrement plus pratique).

Mais une évaluation a encore besoin d'un agent à tester, et tout ce qui entoure le modèle doit être construit par vous. Ce système environnant s'appelle un harnais – la section suivante couvre comment réfléchir à chaque partie du processus d'ingénierie du harnais, de l'appel d'outils à l'optimisation de la fenêtre de contexte.

Ingénierie du Harnais

Un modèle seul n'est pas un agent. Un modèle peut raisonner, classer, écrire et décider, mais il ne peut pas opérer seul au sein d'une entreprise. Il peut dire quelle action devrait avoir lieu, mais il ne peut pas prendre cette action en toute sécurité à moins que vous ne construisiez le système autour de lui – et ce système est le harnais.

Le harnais est tout ce qui entoure le modèle et transforme un appel API en un agent fonctionnel : les outils qu'il peut utiliser, le contexte qu'il voit, l'état dont il se souvient, les garde-fous qui le contraignent, et la boucle qui lui permet de continuer à travailler jusqu'à ce que la tâche soit terminée.

La première partie du harnais est l'exécution des outils.

Les modèles ne lisent et n'écrivent que du texte, donc lorsqu'un modèle décide de faire quelque chose, il ne l'exécute pas réellement. Il émet une demande structurée (une chaîne JSON) pour mettre à jour un enregistrement, ou envoyer un e-mail, ou rechercher dans une base de données.

Le harnais reçoit cette demande, la valide, exécute l'opération réelle et renvoie le résultat au modèle sous forme de texte.

La deuxième partie est la gestion du contexte. Chaque instruction, menu d'outils, résultat d'outil et message précédent prend de la place dans la fenêtre de contexte du modèle. Le harnais doit décider ce que le modèle a besoin de voir maintenant, ce qui doit être résumé et ce qui doit être supprimé. Sans cela, les agents se perdent dans un historique non pertinent.

J'écrirai un article plus complet qui approfondit chaque partie du processus de développement du harnais, mais pour l'instant, je recommanderais d'écouter cette conférence d'un ingénieur chez Arize, la plateforme d'apprentissage continu pour les agents, qui approfondit leur processus de réflexion sur la gestion du contexte.

Pour en savoir plus sur l'application d'une gestion de contexte efficace à vos agents en pratique, lisez ces blogs :

• L'article d'OpenAI sur la gestion du contexte
• Un guide pratique de la gestion du contexte
• Le guide d'ingénierie du contexte d'Anthropic

La troisième partie de l'ingénierie du harnais est l'état et la mémoire. Les modèles sont sans état entre les appels, donc tout ce dont l'agent a besoin de se souvenir doit vivre en dehors du modèle (généralement dans une base de données, un stockage de fichiers ou un enregistrement de tâche). Le contexte est ce que le modèle regarde en ce moment. L'état est tout ce que l'agent sait mais qu'il ne regarde pas actuellement.

La quatrième partie concerne les garde-fous. Étant donné que le modèle peut demander la mauvaise action avec la même confiance que la bonne, le harnais doit vérifier les autorisations, valider les entrées, bloquer les actions dangereuses et orienter les étapes à haut risque vers les humains.

Enfin, tout cela est réuni dans la boucle de l'agent : construire le contexte, appeler le modèle, inspecter sa réponse, exécuter l'outil si autorisé, stocker le résultat, mettre à jour le contexte, et répéter jusqu'à ce que la tâche soit terminée.

L'ingénierie du harnais constitue l'essentiel de ce que vous ferez en tant qu'ingénieur IA appliqué, alors prenez votre temps avec cette section. En tant qu'ingénieur IA appliqué, votre travail consiste à construire l'environnement d'exploitation qui permet à un système probabiliste de fonctionner au sein d'un logiciel déterministe.

Mais la production ne s'arrête généralement pas à un seul agent.

À mesure que le flux de travail s'agrandit, l'instinct naturel est de diviser le travail. Mais une fois que vous ajoutez ce deuxième agent, la conception du système change.

Avec un seul agent, la majeure partie de la complexité réside dans une seule boucle. Avec plusieurs agents, vous avez maintenant plusieurs boucles agissant sur le même environnement. Chaque agent peut lire un état qu'un autre agent vient de modifier, écrire dans une mémoire dont un autre agent dépend, ou appeler un outil dont le résultat affecte l'ensemble du flux de travail.

À ce stade, la partie difficile n'est plus seulement le prompting, les évaluations ou la conception du harnais. Cela devient un problème de systèmes distribués : qui possède quel état, qui peut écrire dans la mémoire, quels outils sont sûrs à réessayer, et que se passe-t-il lorsque deux agents raisonnables prennent des actions dans le mauvais ordre.

Les déploiements multi-agents sont un problème de systèmes distribués

Lorsque le premier agent fonctionne et que le flux de travail s'agrandit, un nouvel ingénieur IA appliqué a naturellement l'instinct de diviser le travail en rôles : un agent recherche, un planifie, un exécute, un révise.

Mais le deuxième agent change l'unité de conception de l'agent au système. Plusieurs boucles agissent maintenant dans le même environnement – un agent peut mettre à jour le statut client tandis qu'un autre est en train de planifier en écrivant sur un statut obsolète. Les deux ont pris des décisions raisonnables, mais le système a laissé ces décisions interagir dans le mauvais ordre.

C'est un problème de systèmes distribués. La bonne nouvelle est que les ingénieurs en systèmes distribués ont résolu ces défaillances il y a des décennies. Votre travail consiste à les appliquer à des boucles qui contiennent un LLM. Voici une liste de solutions issues des systèmes distribués qui s'appliquent à l'ingénierie IA :

Principe du rédacteur unique. Chaque élément d'état important a exactement un agent qui peut y écrire – les autres agents le lisent ou soumettent des demandes de modification. Appliquez cela au niveau de l'outil : si l'agent d'exécution est le seul qui peut écrire dans le CRM, l'agent de recherche ne peut pas corrompre le CRM, quelle que soit la qualité de son raisonnement.

Clés d'idempotence. Les agents réessayent les appels d'outils lorsque quelque chose échoue ou expire, mais les tentatives peuvent être dangereuses lorsque l'outil modifie quelque chose dans le monde réel. Vous ne voulez pas qu'un agent envoie le même paiement deux fois simplement parce que la première demande semblait avoir échoué. La solution consiste à attacher une clé unique à chaque appel d'outil modifiant l'état – c'est-à-dire toute action qui modifie des données dans un système externe. Si l'outil voit la même clé à nouveau, il doit renvoyer le résultat original au lieu d'exécuter l'action une seconde fois. L'API de Stripe fonctionne ainsi – et cela s'applique au développement d'agents lorsqu'il s'agit de paiements, d'e-mails, etc.

Conditions préalables sur les écritures. Les agents agissent souvent sur une vision obsolète du monde. Quelque chose peut avoir changé entre le moment où l'agent a fait son plan et le moment où il tente de mettre à jour un système externe. Pour éviter les écritures obsolètes, les outils modifiant l'état doivent exiger une condition avant d'effectuer le changement. Par exemple : « définir le statut sur Approuvé uniquement s'il est encore En attente ». Si le statut a déjà changé, l'outil doit échouer clairement au lieu de remplacer silencieusement l'état le plus récent.

Passages explicites. Transmettez le travail sous forme de messages avec un schéma défini, séquencés par un orchestrateur. Un agent doit recevoir sa tâche, pas la découvrir.

TLDR

Cet article sert d'aperçu des sujets les plus importants que j'ai appris en tant qu'ingénieur IA appliqué : les évaluations, l'ingénierie du harnais et la conception de systèmes multi-agents.

Si vous ne retenez qu'une chose, que ce soit celle-ci – le modèle fournit l'intelligence, mais tout ce qui le rend fiable (la couche de mesure, l'environnement d'exploitation, les règles de coordination) est conçu par vous. Comprenez ces éléments et la transition depuis l'ingénierie logicielle devient une extension des compétences que vous possédez déjà.

Si vous êtes intéressé par ce type de travail et que vous souhaitez vous attaquer à certains des problèmes les plus passionnants en IA appliquée avec une équipe d'ingénieurs très talentueuse, nous recrutons en permanence. Postulez sur notre site web à varickagents.com, et nous pourrions vous faire commencer dès que possible. D'autre part, si vous recommandez un candidat retenu, nous vous offrirons une prime de recommandation de 20 000 $.