Travailler efficacement avec l’IA

La première partie de cette série défendait la redondance en IA : pour un travail important, il peut être utile qu’un modèle produise et qu’un autre examine indépendamment le résultat. Mais la redondance soulève immédiatement une autre question. Quels modèles faut-il intégrer au flux de travail ?

Cette question est plus importante qu’il n’y paraît. On parle souvent de l’IA comme si chaque modèle n’était qu’une marque différente d’un même produit. Dans la pratique, ce n’est pas ainsi que ces systèmes se comportent.

Certains systèmes sont des généralistes très larges. D’autres sont optimisés pour le code, la recherche, l’image, l’audio, la vidéo, l’automatisation ou des usages plus spécialisés. Certains peuvent utiliser des outils externes, d’autres non. Certains acceptent des types de fichiers particuliers ou de très grands contextes de travail. D’autres sont surtout performants lorsque la tâche reste dans un domaine précis.

Avant d’affirmer qu’une IA a échoué, l’utilisateur devrait d’abord se demander s’il a choisi la bonne IA.

Ce n’est pas un classement

Cet article n’est pas un classement permanent des entreprises ou des modèles d’IA. Un tel classement vieillirait rapidement, et notre propre usage est trop spécifique pour prétendre désigner un vainqueur universel.

Un système excellent dans un flux de travail peut être un mauvais choix dans un autre. Un modèle limité il y a six mois peut recevoir une mise à niveau majeure. Un outil qui dominait autrefois une catégorie peut ensuite être dépassé. Le niveau d’accès peut également modifier ce que l’utilisateur est réellement en train de tester.

La question utile n’est donc pas : « Quelle est la meilleure IA ? »

Elle est plutôt : « Quelle IA convient le mieux à cette tâche, avec ces contraintes, aujourd’hui ? »

Demander : « La meilleure pour quoi ? »

Si l’objectif est de monter une vidéo, un système dépourvu de capacités vidéo significatives ne devrait pas servir de référence pour juger l’IA vidéo. Si la tâche concerne un déploiement logiciel, un modèle incapable d’inspecter les fichiers ou les outils pertinents part immédiatement avec un désavantage. Si le travail dépend d’un domaine technique étroit, un système spécialisé peut dépasser un modèle plus général, même si ce dernier est globalement plus puissant.

Cela ne rend pas le modèle généraliste mauvais. Cela signifie que l’adéquation est mauvaise.

Les ingénieurs raisonnent déjà ainsi avec les outils physiques. Un multimètre, un oscilloscope, une clé dynamométrique et une caméra thermique peuvent tous être d’excellents outils. Aucun ne devient défectueux parce qu’il ne peut pas remplacer les autres.

L’IA devrait être évaluée avec la même discipline.

Une inadéquation de capacité n’est pas un échec de l’IA

Une inadéquation de capacité peut conduire à une conclusion trompeuse. L’utilisateur demande au système de distinguer, générer, inspecter ou manipuler quelque chose pour lequel il n’a pas été conçu ou équipé, puis considère le résultat médiocre comme la preuve que toute la technologie est médiocre.

“C’est comme demander à une personne daltonienne de choisir dans une palette de couleurs et de nommer chacune d’entre elles.”

— A. Remani

L’analogie est volontairement simple. Si la tâche dépend d’une capacité que l’évaluateur ne possède pas, insister davantage ne crée pas cette capacité manquante. De la même manière, répéter les prompts adressés à la mauvaise IA peut seulement produire des versions plus élaborées de la même inadéquation.

La première responsabilité de l’utilisateur est donc le choix.

Généralistes et spécialistes

L’IA généraliste possède une valeur immense parce qu’un seul système peut aider à écrire, analyser, programmer, planifier, traduire, rechercher et accomplir de nombreuses tâches courantes. Pour une petite entreprise, cette polyvalence peut être économiquement très puissante.

Mais la polyvalence a ses limites. Un outil spécialisé peut proposer des interfaces, un entraînement, des flux de travail, des intégrations ou des contrôles de sortie qu’un modèle généraliste ne fournit pas. Le meilleur flux de travail peut donc associer un généraliste performant à un ou plusieurs spécialistes, plutôt que de forcer un seul modèle à imiter toute une suite logicielle.

Ce n’est pas de la redondance pour la redondance. C’est une division du travail.

L’utilisateur doit décider si la tâche exige un généraliste, un spécialiste ou une combinaison des deux.

Comprendre l’IA avant de la juger

Choisir un modèle n’est qu’un début. L’utilisateur doit aussi comprendre le système qu’il teste.

Quels types de fichiers peut-il réellement inspecter ? Quels outils sont disponibles avec le forfait actuel ? Peut-il naviguer sur le Web, exécuter du code, travailler avec des images, générer des médias, conserver un long contexte ou se connecter à des services externes ? Ces capacités sont-elles disponibles dans l’interface utilisée, ou seulement dans un autre niveau d’abonnement ou un autre mode ?

L’utilisateur n’a pas besoin de mémoriser un manuel technique. Mais tester un système sans comprendre ses capacités de base peut rendre le test dépourvu de sens.

Parfois, ce qui ressemble à une limite du modèle est en réalité une limite de l’interface. Parfois, c’est une limite de l’abonnement. Parfois, la fonction existe mais n’a pas été activée dans le flux de travail. Et parfois, le modèle est réellement le mauvais outil.

Ce sont des conclusions différentes, qu’il ne faut pas confondre.

Accès gratuit, accès payant et évaluation équitable

Le coût compte, en particulier pour les startups et les utilisateurs individuels. Mais une évaluation équitable n’exige pas d’acheter tous les abonnements premium du marché.

Lorsqu’un niveau gratuit ou un essai utile existe, commencez par là. Confiez au système un travail représentatif plutôt que des démonstrations artificielles. Observez sa manière de répondre. Identifiez les limites qui affectent réellement la tâche.

Si un niveau payant débloque une capacité réellement importante, il peut être raisonnable de payer l’accès minimal approprié assez longtemps pour l’évaluer correctement. L’objectif n’est pas d’accumuler les abonnements. Il est d’éviter de rejeter un outil parce que la version testée n’a jamais été capable d’exécuter le flux de travail visé.

Le même principe fonctionne dans l’autre sens. Un abonnement premium ne prouve pas qu’un système est le bon choix. Si un outil moins cher ou gratuit accomplit la tâche requise de manière fiable, payer davantage ne rend pas le flux de travail plus intelligent.

La valeur vient de l’adéquation.

Tester le travail dont vous avez réellement besoin

Les benchmarks publics peuvent être utiles, mais ils ne connaissent pas votre travail exact.

Une startup qui travaille sur des sites multilingues, des documents techniques, des prototypes d’ingénierie, des modifications logicielles et de la recherche de terrain n’a pas le même problème d’évaluation qu’un studio vidéo, une équipe juridique, une classe ou un groupe de data science.

Le test le plus utile est donc un travail représentatif.

Donnez au modèle une tâche réelle mais contrôlée. Mesurez s’il respecte les contraintes. Vérifiez l’artefact livré plutôt que son explication. Notez le volume de corrections nécessaire. Comparez la vitesse, la fiabilité, l’ergonomie et la quantité de supervision humaine requise.

Un modèle qui produit une première réponse spectaculaire mais exige ensuite des heures de réparation peut avoir moins de valeur pratique qu’un modèle dont la première réponse paraît moins impressionnante mais résiste à la vérification.

Les capacités changent : les anciennes conclusions expirent

L’IA évolue assez vite pour que les utilisateurs se méfient des jugements définitifs.

« J’ai essayé cette IA et elle était mauvaise » est une phrase incomplète sans date, sans modèle, sans forfait, sans mode et sans tâche.

Le système peut avoir changé. Les fonctionnalités peuvent avoir changé. Le modèle qui alimente le produit peut avoir changé. Une capacité inexistante lors du premier test peut être devenue normale.

Cela ne signifie pas qu’il faut courir après chaque nouvelle version. Cela signifie que les décisions importantes concernant les outils doivent être réexaminées lorsque la technologie sous-jacente évolue de manière significative.

La meilleure IA pour une tâche est une cible mouvante.

Une seule IA n’a pas besoin de tout faire

Il existe autour de l’IA une attente étrange que l’on retrouve rarement avec les autres technologies : parce qu’un modèle peut faire beaucoup de choses, on attend de lui qu’il fasse tout.

Cette attente peut créer de la déception inutile et du risque inutile.

Un modèle généraliste peut aider à définir un concept vidéo pendant qu’un système spécialisé produit le média. Un modèle peut écrire du code pendant qu’un autre audite le déploiement. Un système orienté recherche peut rassembler des éléments de preuve tandis qu’un autre outil réalise l’analyse structurée. Des spécialistes humains peuvent intervenir partout où un jugement de domaine est nécessaire.

Le flux de travail doit être conçu autour de l’objectif, et non autour du besoin de prouver qu’un seul abonnement peut jouer tous les rôles.

Éviter le piège de l’uniformité

Il existe une autre raison pour laquelle le choix de l’outil compte. Si tout le monde choisit le même système généraliste, lui donne la même instruction vague et accepte la première réponse, l’IA peut produire une quantité surprenante d’uniformité.

Les mêmes structures apparaissent. Les mêmes formulations apparaissent. Les mêmes idées évidentes apparaissent. La technologie devient un égalisateur, mais elle peut aussi aplatir les différences entre les utilisateurs.

Ce n’est pas inévitable.

Deux personnes disposant de la même IA peuvent produire des travaux très différents parce que l’une comprend le domaine, choisit un outil plus adapté, combine intelligemment plusieurs systèmes, fournit de meilleures preuves, rejette les réponses génériques et applique un jugement indépendant.

L’accès à l’IA peut devenir courant. Savoir assembler le bon flux de travail d’IA est une compétence distincte.

Le choix relève de la responsabilité humaine

L’IA ne peut pas être entièrement responsable du fait d’avoir été ou non la bonne IA à choisir. Cette décision se situe un niveau au-dessus du modèle.

L’utilisateur définit l’objectif, évalue les outils disponibles, décide quelles capacités comptent, accepte le coût et détermine si le système a suffisamment bien fonctionné.

C’est pourquoi la maîtrise de l’IA devrait englober davantage que le prompting. Elle devrait inclure le choix des outils, la connaissance des capacités, les tests, la conscience des coûts et la volonté de changer d’outil lorsque le travail l’exige.

Partie trois : l’utilisateur pourrait être le problème

Choisir la bonne IA ne garantit toujours pas un bon résultat.

Un modèle performant peut recevoir un objectif vague. Un excellent système de programmation peut se voir demander trop de changements à la fois. Un modèle de recherche puissant peut être alimenté par de mauvaises hypothèses. Un premier résultat correct peut être détruit par une longue chaîne de corrections contradictoires.

Cela nous conduit à la dernière partie de cette série.

La première partie demande si le travail important réalisé avec l’IA devrait bénéficier d’une redondance indépendante. La deuxième demande si la bonne IA a été choisie. La troisième pose la question inconfortable qui demeure une fois ces deux conditions remplies :

Et si le problème venait de l’utilisateur ?