Les LLM interagissent différemment. Au lieu de simplement vérifier les données par rapport à un schéma, un LLM lit une description en langage clair de ce qu'un outil ou un autre système peut faire. En tant que développeur, je dois exposer les informations qu'un LLM appelant peut lire, consommer et finalement utiliser pour comprendre comment utiliser mon interface. Vous ne donnez pas au LLM un schéma strict. Au lieu de cela, vous fournissez une description comprenant l'objectif d'un outil, les entrées et les résultats attendus.
Le LLM utilise sa compréhension du langage pour déterminer comment utiliser l'outil sur la base de cette description. C'est comme si l'on passait de la vérification d'un formulaire rigide à la compréhension d'instructions verbales. C'est plus souple, surtout pour les tâches moins structurées, mais cela signifie que l'interaction dépend de l'interprétation, qui peut être moins prévisible que les formats stricts. Cette méthodologie est utilisée dans de nombreux domaines, du Model Context Protocol (MCP) au Google's open-source Agent Development Kit, comme je l'ai mentionné dans mon dernier blog.
Les messages-guides sont les nouveaux "documents de l'API".
Ainsi, pour les LLM, le "contrat API" ou la documentation est essentiellement l'invite que vous écrivez pour décrire l'outil ou la capacité. Au lieu d'écrire des annotations de code ou des fichiers de schéma, les développeurs rédigent désormais des descriptions claires et détaillées qui informent le LLM :
- Ce qu'il fait : La fonction principale de l'outil.
- Ce dont il a besoin : Les données requises, éventuellement accompagnées d'exemples ou d'indications de format.
- Ce qu'il donne en retour : Le résultat ou l'action attendu(e).
- Toute règle : Contraintes ou lignes directrices importantes.
Cela signifie que l'ingénierie rapide devient une compétence cruciale. Pour que ces systèmes fonctionnent, il est impératif que les équipes de développement puissent rédiger des instructions que les LLM peuvent comprendre et suivre de manière fiable.
Exemple simple : Un outil "d'aide à l'agenda" pour un LLM
Imaginons un outil plus dynamique, comme un assistant de calendrier, et décrivons-le pour un LLM :
Description générale de l'outil : "Il s'agit d'un outil d'assistant de calendrier. Il permet de programmer de nouvelles réunions et de trouver des plages horaires disponibles pour un groupe de personnes."
Fonction 1 : CreateMeeting Prompt : Nom de l'outil : CreateMeeting. Description : Permet de programmer une nouvelle réunion dans le calendrier. Données requises : attendees (une liste d'adresses électroniques), subject (texte du titre de la réunion), startTime (la date et l'heure auxquelles la réunion doit commencer ; essayez d'interpréter les heures relatives comme "demain à 15 heures" ou "lundi matin prochain"), et duration (texte décrivant la durée, par exemple "1 heure", "30 minutes"). Entrée facultative : lieu (texte, par exemple "Salle de conférence B" ou lien d'appel vidéo). Répond par un message de confirmation comprenant les détails définitifs de la réunion ou par une erreur si la programmation échoue (par exemple, conflit horaire, participants non valides). Si l'heure de début ou la durée est ambiguë, demandez à l'utilisateur des précisions avant de poursuivre. Sauf indication contraire, les heures sont supposées correspondre au fuseau horaire local de l'utilisateur.
Comment le LLM pourrait l'utiliser (après avoir interprété la demande de l'utilisateur) : CreateMeeting(attendees=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")
Fonction 2 : FindFreeTime Prompt : Nom de l'outil : FindFreeTime. Description : Recherche les créneaux horaires communs disponibles pour un groupe de personnes dans un laps de temps donné. Données requises : attendees (une liste d'adresses électroniques) et duration (texte décrivant la durée souhaitée de la réunion, par exemple "1 heure"). Entrée facultative : timeWindow (texte décrivant quand chercher, par exemple, "la semaine prochaine", "ce vendredi après-midi", "dans les 3 prochains jours" ; par défaut, la semaine de travail en cours est prise en compte si elle n'est pas spécifiée). Répond avec une liste des heures de début disponibles (date et heure) ou un message indiquant qu'aucun créneau commun n'a été trouvé. Précisez la plage de dates recherchée si une fenêtre relative telle que "la semaine prochaine" est utilisée. Sauf indication contraire, les heures sont supposées se situer dans le fuseau horaire local de l'utilisateur.
Comment le LLM pourrait l'utiliser (après avoir interprété la demande de l'utilisateur) : FindFreeTime(attendees=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")
Ici, les invites guident le LLM sur la manière de traiter les listes, d'interpréter les entrées potentiellement floues comme les dates et les durées, et même de demander des éclaircissements. Ceci est plus proche de la façon dont les interactions avec les outils LLM fonctionnent dans le monde réel.
Le défi : Ambiguïté et précision de la demande (préparation de la troisième partie de cette série)
La première fois que vous créez un tel outil en tant que développeur, vous vous dites : "C'est génial ! Écrire ces agents est un vrai jeu d'enfant". Et puis, comme souvent dans la vie d'un développeur, la réalité vous frappe de plein fouet...
Alors que les invites de l'assistant calendrier tentent de gérer un certain flou (comme "demain à 15 heures"), le fait de s'appuyer sur des descriptions en langage naturel peut permettre à votre logiciel de faire des choses nouvelles et intéressantes auxquelles vous ne vous attendiez vraiment pas.
Voici quelques exemples :
- Demande CreateMeeting contradictoire :
- Utilisateur : "Réservez une réunion de deux heures pour moi et Charlie ce vendredi après-midi, mais assurez-vous que ce soit avant 14 heures".
- Problème : "Vendredi après-midi" signifie généralement après 12 heures ou 13 heures. "Avant 14 heures" crée un conflit potentiel ou une fenêtre très étroite (par exemple, de 13 heures à 14 heures). L'invite n'indique pas explicitement au LLM comment gérer les contraintes conflictuelles au sein d'un paramètre unique tel que l'heure. Doit-il donner la priorité à "l'après-midi" ou à "avant 14 heures" ? Doit-il présenter le conflit à l'utilisateur ?
- Demande vague de temps libre :
- Utilisateur : "Trouvez le temps de discuter rapidement avec Dave la semaine prochaine".
- Problème : Qu'est-ce qu'une "discussion rapide" ? Le paramètre de durée doit être plus précis, par exemple "15 minutes" ou "30 minutes". L'invite actuelle exige une durée et ne précise pas de valeur par défaut ni comment traiter des termes vagues tels que "discussion rapide". Le LLM risque d'échouer ou de devoir deviner.
- Hypothèses implicites dans FindFreeTime :
- Utilisateur : "Trouvez une heure pour la réunion d'équipe de mercredi prochain".
- Problème : Qui est "l'équipe" ? Le LLM a besoin de la liste des participants (adresses électroniques). L'invite le demande, mais la demande de l'utilisateur repose sur le fait que le MLD connaît le contexte de "l'équipe". Un bon flux d'interaction pourrait impliquer que le LLM demande "Qui fait partie de l'équipe ?" si la liste des participants n'est pas fournie ou déduite de l'historique de la conversation. Dans ce cas, l'agent appelant pourrait être en mesure d'appeler un autre agent pour savoir qui fait partie de "l'équipe".
- Fuseaux horaires non précisés :
- Utilisateur (à Londres) : "Programmer une réunion avec Priya (à New York) à 9 heures demain matin".
- Problème : S'agit-il de 9 heures du matin, heure de Londres, ou de 9 heures du matin, heure de New York ? Les invites actuelles comprennent une hypothèse de base ("Supposons que les heures correspondent au fuseau horaire local de l'utilisateur, sauf indication contraire"), mais la gestion correcte des fuseaux horaires est complexe. Que se passe-t-il si l'utilisateur ne le précise pas et que les participants se trouvent dans des fuseaux horaires différents ? L'outil a besoin soit d'une logique sophistiquée pour gérer les fuseaux horaires, soit d'instructions beaucoup plus explicites dans l'invite sur la manière de demander et de confirmer les informations relatives au fuseau horaire si plusieurs lieux sont concernés. Une simple hypothèse peut entraîner des erreurs de programmation.
Ces exemples montrent que même avec des messages-guides convenables, l'ambiguïté des demandes des utilisateurs, des informations contradictoires ou des hypothèses non formulées (comme les fuseaux horaires) peuvent entraîner des erreurs, des actions incorrectes ou des boucles d'éclaircissement frustrantes. L'efficacité de l'interaction LLM-API dépend directement de la qualité et de l'exhaustivité de l'invite décrivant les capacités et les limites de l'outil. Elle doit couvrir non seulement le chemin heureux, mais aussi la manière de gérer les imprécisions, les informations manquantes, les conflits potentiels et les détails contextuels tels que les fuseaux horaires.
Devenir complexe : quand plusieurs agents d'intelligence artificielle se parlent (transition vers des questions plus profondes)
Décrire avec précision un seul outil est une chose, mais cela devient beaucoup plus délicat lorsque plusieurs agents d'intelligence artificielle tentent de travailler ensemble. Comment rédiger des messages-guides pour que l'agent A comprenne clairement ce que l'agent B peut et ne peut pas faire, y compris la manière dont l'agent B gère l'ambiguïté ? Comment se coordonnent-ils ? Comment s'assurer qu'ils travaillent ensemble de manière fiable, sans problèmes inattendus dus à la façon dont ils interprètent les instructions de l'autre ? Trouver comment définir ces interactions de manière claire et fiable à l'aide du langage est un défi majeur auquel nous sommes confrontés au fur et à mesure de l'évolution de ces systèmes.
Découvrez comment Akamai peut optimiser vos charges de travail d'IA à grande échelle. Contactez nos experts dès aujourd'hui.
Commentaires