L'appel à manifestation d'intérêt en tant que livre de règles - Guider les agents LLM au-delà des instructions de base

Dans le cadre de l'intégration des grands modèles de langage (LLM) aux API traditionnelles, nous avons vu comment les invites deviennent les nouvelles "docs API", décrivant ce qu'un outil peut faire. À première vue, tout cela semble merveilleusement simple. Vous donnez au LLM l'accès à certains outils, vous les décrivez et voilà, vous avez un agent intelligent ! Mais comme beaucoup d'entre nous le découvrent, il y a une différence cruciale entre un LLM qui peut utiliser un outil et un LLM qui utilise un outil de manière judicieuse ou efficace dans un contexte plus large. Cela répond directement aux défis que nous avons rencontrés avec notre simple assistant de calendrier.

C'est là que nous rencontrons souvent ce que j'appelle le syndrome du "stagiaire enthousiaste". Votre agent LLM, tout comme un stagiaire enthousiaste mais inexpérimenté, suit avec diligence les instructions explicites relatives à ses outils. Cependant, il peut manquer le jugement expérimenté d'un employé expérimenté qui prend intuitivement en compte les règles non formulées, les facteurs humains subtils ou le "meilleur résultat global". Les stagiaires actuels en droit sont exceptionnellement doués pour comprendre et exécuter le texte qu'on leur donne, mais ils ne saisissent pas intrinsèquement le contexte tacite ou le "pourquoi" nuancé d'une tâche qui dicte souvent le véritable succès.

Cela signifie qu'en tant que développeurs, notre rôle évolue. Nous ne nous contentons plus de décrire les fonctions de l'outil ; nous élaborons méticuleusement des manuels de règles dans nos messages-guides, en guidant le LLM dans des processus décisionnels complexes.

Étude de cas : L'assistant calendrier "attentionné

Revenons sur notre outil "Assistant calendrier" de la partie 2. Imaginons que notre agent principal LLM ait accès aux deux fonctions principales que nous avons définies :

1. CreateMeeting(attendees, subject, startTime, duration, location): Planifie une réunion.
2. FindFreeTime(attendees, duration, timeWindow): Recherche les emplacements disponibles.

Nos invites initiales pour ces outils gèrent l'interprétation de base et sont configurées pour respecter les heures de travail standard de l'entreprise, par exemple du lundi au vendredi, de 8h00 à 18h00, heure locale, pour chaque employé.

Un utilisateur, qui est un chef d'équipe basé à Londres, fait la demande suivante : "Nous avons besoin d'une séance stratégique d'une heure pour le projet Atlas au début de la semaine prochaine. Les participants seront moi-même, Maria (également basée à Londres) et Ben (basé à Édimbourg). Cela nécessite une préparation importante de la part de tous les participants. Merci de programmer cette réunion à notre siège de Londres".

L'agent "stagiaire enthousiaste" se met au travail. Il interroge les calendriers à l'aide de FindFreeTime et constate que le lundi à 8h30 GMT est techniquement "libre" pour tout le monde dans le cadre des heures de travail standard définies.

• Il procède à l'appel : CreateMeeting(attendees=["lead@example.com", "maria@example.com", "ben@example.com"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

Techniquement, une réunion est prévue. Mais est-ce un bon résultat ? Réfléchissez aux implications :

1. Prise en compte des déplacements ignorée : Pour Ben, qui vit à Édimbourg, une réunion en personne à Londres à 8 h 30 est très problématique. Il faudrait qu'il se déplace très tôt le lundi matin ou, plus probablement, qu'il se déplace le dimanche soir. L'agent, en ne tenant compte que des "heures de travail disponibles de 8 à 6" sur le calendrier, n'a absolument pas pris en considération les difficultés logistiques et l'impact personnel d'une réunion matinale nécessitant un déplacement important. Il n'a pas fait la différence entre un créneau de 8h30 pour un participant local et un créneau pour un participant éloigné devant être physiquement présent.
2. Temps de préparation négligé : L'utilisateur a explicitement indiqué qu'il s'agissait d'une "session stratégique critique" nécessitant une "préparation importante". Le fait de la programmer le lundi matin à la première heure (8h30) pousse implicitement les participants à utiliser leur temps personnel du week-end pour se préparer s'ils veulent être prêts à commencer si tôt.

C'est le moment où, en tant que développeur, vous réalisez que l'agent a exécuté sa tâche en fonction de la disponibilité explicite du calendrier, mais qu'il n'a pas tenu compte de facteurs humains implicites et de considérations pratiques cruciales. Il n'a pas eu le jugement nécessaire pour garantir un résultat véritablement efficace et attentionné.

Encodage de l'"expérience" et de la "considération" dans les messages-guides

Pour que notre "stagiaire" devienne un "assistant expérimenté", nous devons intégrer une logique plus sophistiquée dans le système de gestion de l'information. guide de l'agent principal (ou les instructions générales qu'il suit lors de l'orchestration des outils). Cela va au-delà de la simple description des FindFreeTime ou CreateMeeting eux-mêmes. Nous devons dire à l'agent comment se comporter avec plus de considération.

Cela implique souvent de demander à l'agent de rechercher et d'utiliser ce que l'on peut appeler un "troisième outil" ou une couche supplémentaire d'informations et de logique. Dans le cas présent, il s'agit de le lieu où se trouvent les participants, le contexte du voyage et la nature de la réunion. Notre agent pourrait devoir implicitement (ou explicitement par le biais d'un autre outil comme GetUserProfile(email)) accéder ou déduire :

• Le lieu de travail principal de chaque participant.
• Le type de réunion (par exemple, en personne ou virtuelle).
• Les implications de l'importance et du moment de la réunion (par exemple, "réunion critique du lundi matin").

Avec l'accès à ces "données contextuelles", nous devons ensuite ajouter une liste d'instructions du type "si... alors..." à l'invite principale de l'agent :

Extrait de la logique d'invitation à l'agent révisée (conceptuelle) :

"...Lorsqu'il s'agit de programmer une réunion :

1. Rassembler un contexte amélioré : Pour chaque participant, déterminez sa localisation probable (par exemple, à l'aide de GetUserProfile(attendee_email)). Notez si la réunion est spécifiée comme étant "en personne" et si les participants sont distants.
2. Tenir compte des frais de déplacement pour les réunions en personne :
   • Si la réunion se déroule en personne, et un participant est éloigné, et un créneau proposé tôt le matin (par exemple, avant 10 heures, heure locale du lieu de la réunion) est identifié :
     • Ensuite, signalez-le au demandeur. Par exemple : "Ben viendra d'Édimbourg pour cette réunion en personne. Pour lui permettre de voyager confortablement le lundi, préférez-vous que la réunion commence à 10h30 ou plus tard, ou dois-je explorer les options virtuelles ?
3. Prévoir un temps de préparation pour les réunions importantes :
   • Si une réunion est décrite comme "critique", "importante" ou nécessitant une "préparation significative", - une réunion est décrite comme "critique", "importante" ou nécessitant une "préparation significative". et il est programmé tôt un lundi (ou immédiatement après un jour férié) :
     • Demandez ensuite à l'auteur de la demande de confirmer son choix. Par exemple : "Pour cette session critique du lundi qui nécessite une préparation, un début à 8h30 permettrait-il à tout le monde d'avoir suffisamment de temps le lundi matin même, ou un créneau autour de 10h00 serait-il plus approprié pour permettre une préparation le jour même ?
4. Traiter les conflits généraux de fuseau horaire et d'heures de travail (comme nous l'avons vu précédemment) :
   • (Incorporer une logique pour donner la priorité aux "fenêtres sociales principales", gérer les créneaux horaires en dehors de celles-ci et demander une confirmation pour les heures peu pratiques dans différents fuseaux horaires, le cas échéant, même pour les réunions virtuelles).
5. Respecter les dérogations explicites de l'utilisateur :
   • Si l'utilisateur confirme explicitement un arrangement qui ne lui convient pas (par exemple, "Oui, Ben est au courant et voyagera dimanche"), procédez alors, éventuellement avec une confirmation finale : "Compris. Programmation confirmée".

Invitations : Des descriptions simples aux algorithmes complexes

Comme vous pouvez le constater, l'invite de notre agent principal a considérablement évolué. Il ne s'agit plus d'une simple liste d'outils disponibles. C'est un arbre de décision détaillé et conditionnel. C'est un algorithme miniature exprimé en langage naturel. Ces énoncés "si...alors..." deviennent l'épine dorsale du processus de "raisonnement" de l'agent, le guidant non seulement vers une solution, mais aussi vers une meilleure solution.

Le défi - et la compétence émergente des développeurs - consiste à prévoir ces pièges potentiels et à encoder de manière préventive l'"expérience", la "politique de l'entreprise" ou la "courtoisie" directement dans les instructions du MLD. Cela prouve que si les LLM apportent un pouvoir incroyable, le travail d'un développeur pour guider ce pouvoir vers des applications réellement utiles et attentionnées est plus crucial que jamais. Il s'agit de transformer ce "stagiaire enthousiaste" en un collègue numérique fiable et expérimenté, un message soigneusement rédigé à la fois.

À l'avenir, ces agents devraient évoluer au-delà des manuels de règles les plus détaillés, en leur permettant de véritablement "apprendre" des résultats de leurs actions. Alors qu'aujourd'hui nous codons méticuleusement l'expérience, la prochaine frontière concerne les agents capables d'affiner leurs stratégies de manière autonome. Imaginez qu'un agent ait accès non seulement aux outils et aux données nécessaires à l'accomplissement de sa tâche, mais aussi à un retour d'information continu sur la réussite ou l'échec de ces actions pour atteindre les résultats commerciaux souhaités. Notre assistant calendrier, par exemple, s'il observe régulièrement que des invitations à des réunions à 12 heures sont rejetées par un utilisateur particulier au motif qu'il est "sorti déjeuner", pourrait apprendre au fil du temps à déprioriser ou même à éviter de suggérer ce créneau à cette personne, sans qu'un développeur n'ait à programmer explicitement une règle "pas de réunions à midi pour l'utilisateur X".

Maintenant, extrapolons cette capacité d'apprentissage à des processus commerciaux plus complexes. Un agent initialement programmé avec un ensemble de procédures pour, par exemple, l'accueil des clients ou la logistique de la chaîne d'approvisionnement, pourrait, en mesurant les indicateurs de performance clés et en observant les résultats réels, commencer à identifier les inefficacités ou à découvrir des voies plus optimales. Au fil du temps, il pourrait ajuster subtilement son approche, redéfinir les priorités des étapes, voire suggérer des modifications aux processus fondamentaux que les développeurs ont d'abord conçus. À l'avenir, les développeurs pourraient donc être non seulement les architectes initiaux de ces comportements d'agents, mais aussi les cultivateurs de systèmes dans lesquels les agents affinent et optimisent progressivement leurs propres "algorithmes" opérationnels, devenant ainsi de véritables partenaires dynamiques et apprenants dans la réalisation des objectifs de l'entreprise.

Découvrez comment Akamai peut optimiser vos charges de travail d'IA à grande échelle. Contactez nos experts dès aujourd'hui.