Tôt ou tard, tout agent IA reçoit une demande avec un trou dedans. Le client n'a pas dit quelle gamme de matériaux il a choisie. Le mandat ne précise pas s'il faut des puces ou des paragraphes. La demande de soutien ne nomme pas le compte. L'agent a alors deux options : combler le trou avec une valeur par défaut et poursuivre, ou s'arrêter et poser la question. Beaucoup d'agents sont construits pour faire toujours l'une des deux, par réflexe. Les uns devinent et livrent avec aplomb un travail faux. Les autres posent des questions sur tout et transforment une tâche de cinq minutes en une conversation dont personne ne voulait. Les deux réflexes ont un prix, et il existe une meilleure règle que l'un ou l'autre.
Deux options, souvent choisies par réflexe.
L'article pose le choix simplement : devant une demande incomplète, « the system can commit early and risk being wrong, or it can acquire more context first » (en anglais dans l'original), c'est-à-dire que le système peut s'engager tôt au risque de se tromper, ou d'abord aller chercher plus de contexte.[1] Acquérir du contexte, c'est plus large que poser une question à une personne. Cela couvre une question de clarification, une recherche dans un fichier ou une base de données, un appel d'outil, ou un essai rapide avant l'exécution réelle. Chacune a un coût : des jetons (tokens), du temps et, quand la question va à une personne, l'attention de cette personne.
Les réflexes viennent de la façon dont les agents sont construits. Un prototype qui devine fait bonne figure en démonstration, parce que la demande de la démo était complète. Une équipe qui s'est fait prendre par une réponse fausse livrée avec aplomb ajoute alors « en cas de doute, demande à l'utilisateur » dans les instructions, et l'agent se met à tout demander, parce que presque tout est un peu flou. Ni l'une ni l'autre version n'a rien décidé. Un agent bien conçu tranche donnée par donnée, chaque fois qu'il en manque une.
Quand un agent IA doit-il demander ? Quand la réponse vaut la question.
Le résultat central de l'article, dépouillé de sa notation, tient en une règle de décision : ne dépenser pour plus de contexte que si ce que la réponse devrait vous apprendre vaut plus que ce qu'il en coûte de l'obtenir.[1] La théorie de la décision a un nom pour ce test : la valeur de l'information. Les auteurs mesurent ce que la réponse apporte par la baisse d'incertitude qu'elle produit chez l'agent à propos de la tâche, et le coût en jetons. Dans votre entreprise, vous pouvez faire le même test sur n'importe quelle donnée manquante avec trois questions simples : quelle est la probabilité que la valeur par défaut soit mauvaise, combien coûte la correction d'une mauvaise supposition, et combien coûte la question ?
Un agent IA ne devrait poser une question de clarification que si la probabilité que sa valeur par défaut soit mauvaise, multipliée par le coût de correction d'une mauvaise supposition, dépasse le coût de la question. Si la valeur par défaut est presque toujours bonne, ne demandez pas. Si une mauvaise supposition se corrige à peu de frais, ne demandez pas. Si un fichier ou un système détient déjà la réponse, allez la chercher, parce qu'une recherche coûte quelques jetons sans mobiliser qui que ce soit. Mettre un humain dans la boucle coûte plus cher que toute autre source de contexte : la question posée à une personne est le dernier recours, pas le premier réflexe.
Pondérez selon ce qui est vérifié.
La façon évidente de choisir quoi demander, c'est de poser des questions sur ce dont l'agent est le moins sûr. L'article ajoute une variante qui pondère chaque question possible selon l'attention que la vérification finale porte réellement à ce détail, et rapporte qu'elle a fait monter le taux de réussite par rapport à ne rien demander ou à demander au hasard, pour un coût modeste en jetons.[1] Le résumé des auteurs eux-mêmes : poser quelques questions bien choisies peut valoir la peine, « but only when those questions buy information the final output will actually be judged on » (en anglais dans l'original), c'est-à-dire seulement quand ces questions achètent une information sur laquelle le résultat final sera réellement jugé.[1]
Dans leur tâche de rédaction, les préférences cachées étaient le ton, la longueur et le format, et la vérification automatisée notait la longueur et le format, mais jamais le ton. Un agent également incertain sur les trois dépenserait volontiers une question sur le ton, et cette question n'achèterait rien que la vérification puisse voir. Le détail pour lequel le réviseur, le client ou le système en aval rejettera le travail est celui qui mérite une question ; le détail que personne ne regardera jamais est celui à régler par défaut avant de passer à autre chose.
Le modèle ne peut pas le déduire seul : l'agent ne sait pas ce que votre réviseur vérifie, à moins que quelqu'un ne l'écrive. Le premier travail est donc le vôtre : dresser la liste de ce sur quoi le travail fini est jugé. C'est cette liste qui indique à l'agent quelles lacunes méritent une question.
Un exemple chiffré : l'agent de soumissions.
Prenons un petit entrepreneur en rénovation dont l'agent rédige des soumissions à partir des notes de visite de chantier, environ 100 par mois. Le propriétaire de l'entreprise révise chaque soumission avant son envoi, à l'aide d'une courte liste de contrôle interne : les lignes de prix correspondent à la gamme de matériaux choisie par le client, une durée de validité est indiquée, l'adresse du client est exacte. Personne ne vérifie le ton du mot d'accompagnement. Les chiffres ci-dessous sont illustratifs, les nôtres, dimensionnés pour une entreprise de cette taille.
Dans une demande typique, quatre éléments peuvent manquer : la gamme de matériaux, la durée de validité, l'adresse du client et le ton du mot d'accompagnement. Passez chacun dans le schéma et les réponses diffèrent. Le ton n'est jamais vérifié : il reçoit le ton par défaut de l'entreprise. L'adresse se trouve dans le dossier client : l'agent la cherche. La durée de validité est vérifiée, mais la norme de l'entreprise, 30 jours, ne change presque jamais : l'agent l'applique et le mentionne. La gamme de matériaux est vérifiée, souvent absente des notes, et une mauvaise supposition oblige à refaire chaque ligne de prix. C'est celle qui vaut une question, et seulement si les notes ne la précisent pas déjà.
Lisez le graphique de gauche à droite. Ne rien demander est le moins cher par soumission et le plus coûteux en reprises : 55 brouillons sur 100 reviennent pour être refaits. Tout demander donne le meilleur taux de réussite du premier coup, avec deux points d'avance, et le paie de quatre fois plus de jetons supplémentaires et 400 interruptions par mois, surtout pour répondre à des questions dont la réponse était la valeur par défaut ou se trouvait déjà dans le dossier. L'approche ciblée obtient environ 95 % du gain pour le quart des jetons supplémentaires. L'écart en jetons représente peu d'argent pour une entreprise de cette taille. Les interruptions, non : 400 par mois, c'est environ vingt par jour ouvrable, le propriétaire qui répond à l'agent censé lui alléger la tâche.
Notre note sur le coût comme métrique prioritaire plaide pour consigner le coût de chaque étape d'agent. Les questions posées à une personne devraient aussi figurer dans ce journal, chiffrées en minutes, car pour une petite équipe, c'est souvent le coût le plus élevé.
Ne comptez pas sur le modèle pour y arriver seul.
Il est tentant de tout laisser au modèle : lui donner une bonne consigne système, lui dire de demander au besoin et lui faire confiance pour trouver les questions efficaces. L'article est une raison de ne pas le faire. Il a soumis des modèles de pointe actuels, de plusieurs fournisseurs, à son jeu de vingt questions, où la meilleure stratégie de questionnement se calcule exactement et où chaque réponse est vraie. Les modèles ont cerné la réponse de façon constante, et pourtant ils sont restés moins économes en questions que la meilleure stratégie.[1] Ce n'est pas un classement de modèles et il ne faut pas le lire comme tel. La conclusion, c'est qu'aucun n'était économe en questions d'emblée, sur une tâche conçue pour rendre l'efficacité facile à voir.
Une vraie demande est plus difficile que ce jeu : les réponses sont vagues, la personne change d'idée et les faits sont répartis dans des fichiers que le modèle ne voit pas. Les auteurs le disent eux-mêmes de leur banc d'essai.[1] Si les modèles posent trop de questions dans la version facile, partez du principe que le vôtre en posera trop (ou trop peu) dans la vraie, et fixez vous-même la politique de questions. Un objectif qui bouge en pleine conversation est un échec en soi, traité dans notre note sur le changement d'idée ; une question posée tôt, au bon endroit, est l'un des moyens les moins coûteux de l'éviter.
Mettez-le dans les instructions de l'agent.
En pratique, tout cela devient un court tableau dans les instructions de l'agent : chaque donnée qui peut manquer à la tâche, si le travail fini est vérifié sur ce point, où se trouve la réponse, la valeur par défaut et ce que fait l'agent. Pour l'agent de soumissions, il ressemble à ceci.
| donnée manquante | vérifiée ? | où se trouve la réponse | valeur par défaut | action de l'agent |
|---|---|---|---|---|
| ton du mot d'accompagnement | non | aucune source requise | ton de l'entreprise | poursuivre ne demande jamais |
| adresse du client | oui | le dossier client | aucune | chercher ne demande que si le dossier est vide |
| durée de validité | oui | norme de l'entreprise | 30 jours | poursuivre indique la valeur par défaut sur la soumission |
| gamme de matériaux | oui | les notes de visite, parfois | standard | demander quand les notes ne la précisent pas, une seule question |
Quatre habitudes font fonctionner le tableau en pratique :
- Écrivez ce sur quoi le travail est jugé.
La liste de contrôle du réviseur, les champs obligatoires du système en aval, les règles permanentes du client. C'est la pondération dont parle l'article, et vous seul pouvez la fournir.
- Donnez à l'agent ses recherches avant ses questions.
Branchez le dossier client, la liste de prix, la soumission du mois dernier. Chaque réponse que l'agent peut chercher est une question à laquelle personne n'a à répondre. Quand il dispose d'un outil, exigez qu'il réclame une valeur obligatoire manquante plutôt que d'en inventer une : un argument inventé pour un outil est une supposition qui a l'air d'une donnée.
- Regroupez les questions et proposez la valeur par défaut.
Un seul message avec une ou deux questions qui comptent, chacune accompagnée de la réponse que l'agent retiendra si personne ne répond, vaut mieux qu'une série de questions au compte-gouttes. La personne peut répondre en un mot, ou ne pas répondre du tout.
cible : une interruption par tâche, au plus - Comptez les questions, puis ajustez.
Consignez chaque question posée par l'agent et notez si la réponse a changé le résultat. Une question dont la réponse est toujours la valeur par défaut devrait devenir une valeur par défaut. Une valeur par défaut qui fait constamment renvoyer le travail devrait devenir une question.
L'autre moitié de cette décision, c'est le moment d'arrêter de recueillir de l'information pour passer à l'action, ce que l'article traite comme faisant partie de la même boucle. Notre note sur un planificateur qui sait s'arrêter couvre ce volet.
Ce que cette note ne prétend pas.
Aucun chiffre de l'article. L'article rapporte des résultats de petits tests synthétiques, avec réponses simulées et outils désactivés exprès. Nous ne reprenons pas ses chiffres. Chaque chiffre de cette note provient de notre exemple illustratif d'agent de soumissions.
Ce que le banc d'essai permet et ne permet pas de démontrer. Le jeu de vingt questions est volontairement simple : des réponses exactes lues directement dans un tableau, une liste de questions fixe, aucun vrai outil. C'est ce qui rend son résultat net, et aussi pourquoi il dit peu de choses sur un produit précis. Nous l'employons pour la règle et pour une direction (les modèles posent plus de questions qu'il n'en faut), pas pour des ordres de grandeur.
Aucun classement de modèles. L'article nomme les modèles testés. Pas nous, parce que le propos est une règle de conception pour votre agent, pas un verdict sur un fournisseur, et que les modèles hébergés changent assez souvent pour rendre caduc tout résultat de ce genre.
Un mot sur l'autre usage. Les auteurs soulignent que la même technique qui aide un assistant à poser moins de questions, mais de meilleures, pourrait aider quelqu'un à soutirer des renseignements sensibles à une personne. Si votre agent s'adresse au public, limitez ce sur quoi il a le droit de poser des questions.
Si votre équipe construit un agent qui pose sans cesse des questions, ou un agent qui n'en pose jamais, le formulaire de contact est la façon la plus rapide de nous joindre. Dites-nous ce que fait l'agent et qui révise son travail, et nous vous enverrons gratuitement un avis écrit sur celles de ses questions qui valent la peine d'être gardées. Rédiger des règles comme celles-ci dans les instructions d'un agent fait partie de notre travail en assistants et agents.