Récemment, j'ai demandé à une IA de m'aider à peaufiner un article de blog.
Elle a écrit rapidement. La structure était complète et les idées étaient claires. Quand j'ai dit que je voulais que cela sonne plus professionnel, elle a ajouté une discussion technique. Quand j'ai demandé un appui académique, elle a trouvé des articles récents.
L'article est devenu plus sérieux, mais j'ai commencé à hésiter : fallait-il vraiment l'écrire de cette façon ?
Le contenu n'avait rien de manifestement erroné. Mais ce que j'avais voulu écrire, c'était un texte dans ma propre voix, un texte qui permettrait aux lecteurs de voir comment je réfléchissais à un problème. Après plusieurs cycles de révision, il devenait peu à peu une revue de recherche que j'aurais moi-même besoin de temps pour digérer.
Mes attentes évoluaient aussi en cours de route. Au départ, je n'avais pas pleinement déterminé ce que « professionnel » ou « approfondi » devait signifier pour cet article précis.
Cette expérience m'a amené à repenser ce qui fait un bon agent.
Si je vérifiais les exigences une par une, notre collaboration avait accompli pas mal de choses : l'article était écrit, la recherche était faite et les références étaient en place. Chaque demande individuelle avait un livrable correspondant.
Mais quand je les rassemblais, je devais encore me demander : est-ce l'article que je veux publier ?
Il est facile de vérifier ce qu'un agent a fait. Expliquer si ces actions ont rapproché l'utilisateur de son objectif demande plus de travail.
Dans ce cas, « ajouter un appui académique » était une demande explicite. Son but était de rendre l'argument plus crédible. Si l'ajout de recherche faisait perdre à l'article sa voix originale, il fallait reconsidérer comment utiliser ce matériau.
Une nouvelle demande de l'utilisateur n'est pas toujours quelque chose à simplement ajouter par-dessus. Elle peut être une correction de direction, ou même une raison de retirer un travail déjà accompli.
Pour un agent qui reste impliqué dans une tâche, comprendre ces changements affecte la qualité de toute la collaboration. Il doit réviser sa compréhension de la tâche au fur et à mesure des retours, plutôt que d'ajouter continuellement au résultat.
Cela complique aussi la notion de « terminé ». L'article peut avoir une fin, et la tâche peut être marquée comme accomplie, alors que l'utilisateur n'a toujours pas quelque chose qu'il peut utiliser.
Donc, avant de concevoir une évaluation, je veux clarifier autre chose : quel jugement cherchons-nous à porter à partir des résultats ?
Vérifier l'exactitude factuelle signifie vérifier les citations et les preuves à l'appui. Évaluer la capacité de révision signifie observer si l'agent comprend les retours et préserve le contenu qui fonctionne encore. Juger s'il peut prendre en charge une tâche du début à la fin signifie aussi regarder combien de travail il laisse à l'utilisateur.
Ces questions sont liées, mais « la qualité globale est bonne » ne permet guère de répondre à toutes.
Ce n'est que lorsque nous savons clairement ce que nous évaluons que nous pouvons savoir quelles preuves recueillir, et ce qu'un score peut nous dire.
Une évaluation doit aussi être équitable au regard des conditions du moment.
Dans ce processus d'écriture, certains objectifs ne sont devenus clairs qu'à travers la discussion. Les premières réponses devraient être jugées par rapport aux besoins déjà exprimés, plutôt qu'aux préférences apparues plus tard.
Si les exigences étaient déjà claires et que le résultat restait inadapté, nous devons identifier le problème plus précisément. L'agent a-t-il mal compris ? A-t-il oublié une contrainte antérieure ? Ou le fait de satisfaire une nouvelle demande a-t-il défait quelque chose qui fonctionnait déjà ?
Tout cela peut être décrit comme « une mauvaise écriture », mais cela appelle des améliorations très différentes. Fournir plus d'informations sur la tâche, ajuster le contexte ou changer l'approche d'exécution peuvent chacun aider. Mais d'abord, nous devons savoir où cela a mal tourné.
D'autres exigences ne devraient pas varier selon les préférences personnelles. Que les citations soient réelles, que les faits soient exacts et que les conclusions soient étayées doit être vérifié indépendamment. Qu'un utilisateur aime un résultat ne suffit pas à établir que ces exigences ont été satisfaites.
Je pense que cette distinction compte. Elle permet à l'évaluation de tenir compte de besoins spécifiques tout en conservant les normes de jugement nécessaires.
Même lorsque l'objectif est clair et que l'agent le saisit correctement cette fois-ci, il reste encore des choses à observer.
Peut-il bien accomplir la même tâche une seconde fois ? Si l'utilisateur formule la demande différemment, va-t-il mal interpréter l'intention ? Lorsque des informations manquent, peut-il reconnaître l'incertitude au lieu de combler les lacunes avec une prose fluide ?
Une étude sur la fiabilité des agents a examiné séparément la cohérence, la robustesse, la prévisibilité et la sécurité. À travers les modèles et les benchmarks testés, les gains de capacité n'ont apporté que des améliorations limitées de la fiabilité. C'est un rappel qu'après avoir appris ce qu'un agent peut accomplir, nous devons encore comprendre les conditions dans lesquelles nous pouvons compter sur lui. Recherche connexe
Alors, qui a le droit de définir ce qu'est un bon agent ?
Je crois que l'objectif réel de l'utilisateur devrait être le point de départ. Les équipes produit doivent être claires sur les besoins qu'elles entendent servir et sur la responsabilité qu'elles assumeront. L'ingénierie doit comprendre l'implémentation et les limites des capacités du système. L'évaluation traduit ces attentes en situations concrètes et vérifie si les résultats les confirment.
Quelqu'un doit être responsable des arbitrages finaux, et il doit y avoir des preuves sur lesquelles discuter de ces arbitrages.
Prenons la demande de rendre quelque chose « plus professionnel ». Une personne pense à la terminologie et aux références. Une autre pense à un raisonnement plus rigoureux. Quelqu'un d'autre s'attend à ce que l'auteur identifie le cœur du problème. Quand nous appliquons la demande à un article réel, il devient plus facile de voir que nous ne parlons pas tous de la même chose.
Je préfère construire un accord à travers des cas comme ceux-ci. Quels faits doivent être corrects ? Quelles parties déterminent si le résultat est utilisable ? Où y a-t-il de la place pour des choix différents ? Tout cela peut être discuté. Plus nos normes sont précises, plus nous avons de chances d'expliquer les désaccords plus tard.
Ces normes devraient aussi pouvoir être révisées. De nouvelles situations peuvent révéler des problèmes que nous n'avions pas envisagés, et les utilisateurs peuvent commencer à demander des choses différentes. Ce qui compte, c'est de consigner pourquoi nous avons fait un ajustement, afin que l'équipe puisse distinguer une amélioration du produit d'un changement dans la façon dont il est jugé.
La valeur de l'évaluation doit aussi se manifester dans les choix que nous faisons ensuite.
Si une évaluation nous laisse plus clairs sur ce qu'il faut prioriser, capables d'expliquer pourquoi une amélioration vaut l'investissement, et conscients des tests supplémentaires nécessaires lorsque les preuves sont insuffisantes, alors les scores ont une valeur pratique.
Avec le recul, l'IA m'a effectivement aidé à rendre l'article plus complet. Ce sont les cycles de discussion ultérieurs qui nous ont aidés à déterminer ce qu'il fallait garder et ce que nous pouvions retirer.
C'est aussi ce que j'espère que l'évaluation peut aider une équipe à faire : lorsqu'un résultat semble déjà bon, avoir encore un moyen de juger s'il est prêt à être mis entre les mains d'un utilisateur, et pourquoi nous pouvons avoir confiance en ce jugement.