Imaginons qu’une équipe de support souhaite résumer automatiquement les échanges avec ses clients. La première démonstration est simple : coller une conversation dans un prompt et lire le résultat. Le travail se précise quand ce résumé entre dans le quotidien de quelqu’un.
Je prendrais cet exemple pour examiner toute la fonctionnalité, du choix des données à la correction d’un mauvais résultat.
Définir une tâche précise
Pour un résumé de support, je définirais les informations utiles : le problème du client, les solutions déjà essayées et les points encore ouverts. Je conserverais des liens vers les messages d’origine pour permettre une vérification.
Un paragraphe bien écrit peut masquer une mauvaise date ou une promesse que personne n’a faite. L’agent doit pouvoir repérer et corriger cela rapidement. Je regarderais l’interface avec lui avant de consacrer trop de temps au choix du modèle.
Garder les autorisations dans le code
L’application doit sélectionner les conversations accessibles à l’utilisateur avant d’envoyer des données au modèle. Un échange peut contenir des consignes, des plaisanteries ou du texte copié ailleurs. Ces mots ne doivent pas modifier les droits de l’utilisateur.
Je séparerais aussi l’enregistrement du résumé de son envoi au client. Si la fonctionnalité finit par envoyer des messages, les destinataires et la confirmation devront avoir leurs propres contrôles dans le code. Écrire « sois prudent » dans le prompt ne suffit pas.
Conserver quelques exemples difficiles
Je garderais un jeu de tests avec une conversation ordinaire, une très longue, un dossier non résolu et des dates contradictoires. Les exemples synthétiques sont utiles ; les messages de production demandent des précautions avant de devenir des données de test.
Pour chaque cas, je noterais les faits à préserver et les questions auxquelles le résumé ne doit pas répondre. Je relancerais ces tests après une modification du prompt, du modèle ou de la recherche documentaire. Quelques réponses convaincantes peuvent facilement masquer une régression.
Prévoir l’échec d’une requête
Si le modèle ne répond pas à temps, l’agent doit conserver la conversation et ses notes. Je proposerais de réessayer sans repartir de zéro. Pour un résumé qui ne fait que lire des données, cette nouvelle tentative est généralement simple.
Une opération qui écrit des données demande plus d’attention. Le délai peut être dépassé alors que le serveur a déjà enregistré le résultat. L’application doit le vérifier avant de recommencer, sous peine de créer des doublons.
Calculer le coût de la tâche terminée
Je mesurerais le coût d’un résumé utilisable, en incluant les longues conversations et les nouvelles tentatives. Je regarderais aussi la fréquence des corrections. Un appel au modèle peu coûteux peut créer beaucoup de travail si chaque résultat doit être réécrit.
La mise en production demande un responsable, un moyen d’examiner les échecs et la possibilité de désactiver la fonctionnalité. Je commencerais avec un petit groupe d’utilisateurs et examinerais les problèmes avant d’élargir l’accès.