De l'ingénieur logiciel à l'ingénieur en IA : 8 leçons tirées des coulisses de Skai

• Pour devenir ingénieur en IA, il ne suffit pas d'apprendre à utiliser de nouveaux outils. Il est essentiel de comprendre le fonctionnement des modèles d'IA pour développer des applications fiables et efficaces.
• Les modèles d'IA présentent des limites dont les ingénieurs doivent tenir compte. Les biais dans les données, la tokenisation et la surcharge contextuelle peuvent tous avoir une incidence sur la qualité des résultats générés par l'IA.
• Des choix techniques mûrement réfléchis permettent d'améliorer les performances et l'efficacité. Une mise en cache rapide, une bonne gestion de la mémoire et une sélection judicieuse des modèles peuvent réduire considérablement les coûts et la latence.
• La transition vers l'ingénierie de l'IA est un processus d'apprentissage continu. Chez Skai, l'expérimentation pratique et le partage des connaissances aident les ingénieurs à acquérir les compétences nécessaires au développement basé sur l'IA.

Tous ceux qui se sont déjà engagés à aller à la salle de sport pendant quelques mois connaissent ce sentiment. Pendant des semaines, vous y allez, vous enchaînez les séries et vous suivez vos progrès. Mais quand vous vous regardez dans le miroir, vous avez l’impression que rien ne change. Puis, un matin, vous réalisez que votre corps s’est complètement transformé. C’est un peu comme Peter Parker, incarné par Tobey Maguire, qui se réveille après la morsure d’araignée dans le film original de 2002 et découvre soudain qu’il a des abdos bien dessinés.

Mais comme le savent tous les sportifs et tous les ingénieurs, la transformation du jour au lendemain n'est qu'un mythe.

Chez Skai, nous avons été nombreux à vivre une expérience similaire. En levant les yeux de nos IDE, nous avons pris conscience que, du jour au lendemain, pour ainsi dire, nous étions passés du statut d’ingénieurs logiciels traditionnels à celui d’ingénieurs en IA. Bien sûr, cela ne s’est pas fait du jour au lendemain. Nous avons passé des mois à tester différents types de modèles de langage à grande échelle (LLM), tout en apprenant aux côtés de nos « champions de l’IA » et de nos collègues, à mesure que nous découvrions ce qui fonctionnait.

Et maintenant que nous disposons de ces puissantes capacités, les célèbres paroles de l’oncle Ben (paix à son âme) prennent tout leur sens : « Un grand pouvoir implique de grandes responsabilités. » Car devenir ingénieur en IA ne se résume pas à savoir comment donner des instructions à un modèle. Cela implique de comprendre ce qui se passe en coulisses.

Cette réflexion a donné naissance à une initiative de formation interne que j'ai lancée avec ma responsable, Noa Weiss, intitulée « Under the Hood ». Au cours de brèves sessions mensuelles, les ingénieurs partagent des concepts pratiques liés à l'IA, remettent en question les idées reçues et explorent comment ces technologies s'appliquent à notre travail quotidien.

Lors de notre première session, j'ai abordé huit concepts fondamentaux que, selon moi, tout ingénieur travaillant dans le domaine de l'IA devrait maîtriser.

1. Biais dans les données : le paradoxe des gauchers

Voici une expérience amusante. Demandez à un modèle de génération d'images de créer une image représentant une personne gauchère en train d'écrire dans un cahier à côté d'un verre de vin plein. Vous pourriez bien obtenir à la place une personne droitière et un verre à moitié vide.

Pourquoi ? Les modèles d'IA apprennent des schémas à partir de leurs données d'entraînement. Lorsqu'un élément est moins courant, comme un écrivain gaucher, les modèles ont tendance à se tourner vers l'alternative qui leur est la plus familière. J'appelle cela la « résistance de distribution »: la tendance des résultats de l'IA à privilégier les schémas courants.

Le même problème peut se poser lors de la génération de code. Si vous demandez à un modèle de résoudre un cas limite particulier lié à votre logique métier spécifique, il aura tendance à se tourner vers une solution familière qui ne sera peut-être pas tout à fait adaptée.

Leçon d'ingénierie : lorsque vous travaillez avec des exigences inhabituelles ou des cas limites, fournissez des contraintes explicites et des exemples plutôt que de partir du principe que le modèle comprendra ce qui rend la situation différente.

2. La tokenisation : le problème de la fraise

Demandez à un modèle d'IA combien de fois la lettre « r » apparaît dans le mot « strawberry ». Aujourd'hui, vous obtiendrez probablement la bonne réponse : trois. Mais il y a quelques mois à peine, ces modèles avaient encore du mal à répondre à ce genre de questions.

En effet, les modèles linguistiques ne traitent pas les mots comme le font les humains. Ils décomposent le texte en unités plus petites appelées « tokens », qui ne correspondent jamais à des lettres individuelles. Lorsqu'un assistant IA répond correctement à cette question, il se peut qu'il utilise un outil d'exécution de code pour compter les lettres plutôt que de s'appuyer sur la génération de langage.

Cette distinction est importante lors du développement d'applications qui exigent de la précision.

Leçon d'ingénierie : utilisez du code déterministe pour des tâches telles que le comptage de caractères, la manipulation de chaînes de caractères et la mise en forme précise. L'IA peut aider à générer le code, mais elle ne devrait pas toujours être chargée d'exécuter la logique elle-même.

3. Température : La Roue de la Fortune

Les développeurs décrivent souvent la « température » comme le « paramètre de créativité » d’un modèle d’IA. C’est une façon pratique de voir les choses, mais voici une meilleure manière d’aborder la question.

Imaginez une « Roue de la fortune » où chaque segment représente un mot susceptible de venir ensuite. À des températures plus basses, le modèle privilégie nettement les options les plus probables. À des températures plus élevées, les options moins probables ont davantage de chances d’être sélectionnées.

Mais voici le hic : une température plus basse ne garantit pas une réponse correcte. Un modèle peut donner une réponse erronée, même lorsque ses résultats sont très prévisibles.

Leçon d'ingénierie : utilisez des températures plus basses lorsque la cohérence est importante ou lorsque vous visez des résultats structurés ou prévisibles, mais ne confondez pas cohérence et absence d'hallucinations. Une température basse ne peut pas éliminer les hallucinations ; la validation du résultat reste donc indispensable.

4. Gestion du contexte : la salle de réunion calme contre le stade

Imaginez que vous essayez d'avoir une conversation constructive dans une salle de réunion calme avec cinq personnes. Imaginez maintenant que vous ayez cette même conversation dans un stade rempli de 100 000 supporters en délire.

C'est là toute la différence entre fournir à un modèle d'IA un contexte ciblé et pertinent, et le submerger d'informations superflues.

Chaque modèle Transformer fonctionne avec un budget d'attention fixe dont la somme mathématique est égale à 1,0 (100 %). À mesure que vous ajoutez des tokens dans la fenêtre de contexte, le poids d'attention relatif disponible pour chaque token diminue, car chaque token réclame une part de l'attention.

Au cours de nos travaux d'ingénierie chez Skai, j'ai découvert que plus de 40 % des lignes de l'une de nos bases de code étaient des fichiers de documentation au format Markdown. Cela représente une quantité considérable de « bruit » potentiel à traiter pour un agent de codage basé sur l'IA.

Lorsque les développeurs fournissent une documentation obsolète, des notes provisoires et des journaux volumineux, le modèle peut avoir plus de mal à identifier les instructions importantes. Nous étudions actuellement des moyens de clarifier ce contexte, notamment grâce à un agent conçu pour faciliter la mise à jour de notre documentation.

La leçon d'ingénierie : considérez le contexte comme une ressource limitée. Maintenez la documentation à jour, supprimez les fichiers et commentaires superflus, et fournissez aux agents IA uniquement les informations dont ils ont réellement besoin.

5. Résultats structurés : résoudre des problèmes de calcul différentiel et intégral en vers

Les ingénieurs apprécient les sorties structurées, car elles facilitent l'intégration des réponses générées par l'IA dans les applications. Par exemple, exiger d'un modèle d'IA qu'il renvoie un JSON valide permet de s'assurer qu'un autre système pourra traiter sa réponse.

Mais imaginez qu’on vous demande de résoudre un problème de calcul différentiel complexe tout en exprimant chaque étape sous forme de vers parfaitement rimés. Ça vous donne le tournis ? Tant mieux.

Selon le modèle et la mise en œuvre, imposer trop tôt des contraintes de mise en forme strictes peut compliquer les tâches complexes.

En imposant une mise en forme stricte dès le premier token, vous l'empêchez de générer de manière autorégressive des tokens de réflexion (chaîne de pensée) qui l'aident à raisonner pour résoudre le problème.

Leçon d'ingénierie : pour les tâches de raisonnement complexes, vérifiez si le fait de séparer les étapes de raisonnement et de mise en forme permet d'améliorer les résultats. Une approche consiste à résoudre d'abord le problème, puis à convertir la réponse dans la structure requise.

6. Mise en cache rapide : comment un petit changement a permis de réduire les coûts

C'était l'un des enseignements les plus concrets tirés de notre expérience chez Skai.

De nombreux fournisseurs d'IA proposent la mise en cache des prompts, ce qui permet aux systèmes de réutiliser des parties d'un prompt déjà traitées plutôt que de traiter les mêmes informations à plusieurs reprises. Cependant, la mise en cache ne fonctionne que lorsque le contenu réutilisable présent dans le cache nécessite une correspondance exacte de préfixe, au niveau des caractères.

Dans l'une de nos premières implémentations, nous avions placé des informations dynamiques au début des messages d'invite de notre système. Cette petite décision a perturbé la mise en cache et augmenté les coûts de traitement.

Après avoir modifié la manière dont nous organisions ces requêtes, une seule pull request a permis de réduire notre coût par requête LLM de plus de 90 %. Pas mal pour un changement relativement mineur !

Leçon d'ingénierie : placez les instructions stables et les informations réutilisables au début des invites. Faites évoluer les données d'entrée vers la fin afin d'optimiser les possibilités de mise en cache.

7. La mémoire des agents IA : au-delà de l'historique des conversations

Lorsque les développeurs envisagent pour la première fois de doter un agent IA d'une mémoire, la solution qui vient immédiatement à l'esprit consiste à enregistrer les conversations précédentes et à les réinjecter dans le modèle. Malheureusement, cette approche devient rapidement compliquée.

Les historiques de conversation trop longs épuisent le budget de contexte, augmentent la latence et compliquent la tâche de l'agent lorsqu'il s'agit d'identifier les informations pertinentes. Une meilleure approche consiste à mettre en place un pipeline de mémoire active afin d'extraire les faits utiles, de les stocker efficacement et de ne récupérer que ce qui est nécessaire à la tâche en cours.

Par exemple, au lieu de stocker l'intégralité d'une conversation, un agent pourrait retenir une préférence utile : « L'utilisateur préfère Python à Java. » Des techniques telles que la recherche hybride (alliant la correspondance sémantique et la correspondance par mots-clés) et la déduplication vectorielle peuvent contribuer à rendre cette mémoire plus utile au fil du temps.

Leçon d'ingénierie : concevoir la mémoire des agents en s'appuyant sur des pipelines d'extraction et de récupération actifs plutôt que sur l'historique brut des conversations.

8. Sélection du modèle : choisir l'outil adapté à la tâche

Toutes les tâches d'IA ne nécessitent pas forcément le modèle le plus volumineux et le plus puissant. Prenons l'exemple de la génération d'un titre de conversation par rapport au débogage d'un problème complexe en production. La première tâche est relativement simple. La seconde peut nécessiter un raisonnement plus approfondi, plusieurs étapes et davantage de ressources informatiques.

Le recours à un modèle de raisonnement coûteux pour chaque tâche peut accroître la latence et les coûts sans apporter d'avantages significatifs.

Il est essentiel de comprendre la différence entre les modèles « fast-path » standard et les « modèles de réflexion » (calcul en temps d’inférence) qui allouent des jetons d’exécution supplémentaires pour s’autocorriger avant de fournir une réponse.

Leçon d'ingénierie : adaptez le modèle à la tâche. Utilisez des modèles légers pour les opérations d'orchestration simples et réservez les capacités de raisonnement plus avancées aux nœuds de décision complexes.

Mettre nos connaissances à l'épreuve

Bien sûr, nous ne pouvions pas clôturer notre première session « Under the Hood » sans un petit concours amical. Nous avons lancé Kahoot, une plateforme de quiz interactive où les participants répondent aux questions en temps réel, et nous avons mis tout le monde au défi de répondre à un quiz de 20 questions portant sur ce que nous avions appris.

L'ambiance était incroyable, et je suis sûr que le prix que j'avais promis au gagnant n'y était absolument pour rien. Mais surtout, voir ces ingénieurs débattre des raisons pour lesquelles une requête avait échoué ou pourquoi un cache n'avait pas fonctionné montrait bien que ces concepts commençaient à faire tilt.

Quelle est la prochaine étape pour l'ingénierie de l'IA chez Skai ?

Devenir ingénieur en IA ne consiste pas à mémoriser les derniers mots à la mode ni à copier des prompts trouvés sur Internet. Il s'agit de comprendre pourquoi les modèles se comportent ainsi, d'identifier leurs limites et d'utiliser ces connaissances pour créer de meilleurs systèmes.

Notre première session « Under the Hood » n'était qu'un début. Nous continuons à explorer ces concepts ensemble, et de plus en plus d'ingénieurs prennent la parole pour partager ce qu'ils apprennent, sous ma supervision.

Car même si la transition vers l'ingénierie de l'IA peut donner l'impression de s'être faite du jour au lendemain, la véritable transformation passe par une expérimentation, une collaboration et un apprentissage continus. Et personnellement, j'ai hâte de découvrir ce qui se cache sous le capot.

---

Questions fréquemment posées