Agents IA : éliminez les informations superflues, gagnez en pertinence

Les modèles de raisonnement sont de plus en plus efficaces ; mais si les éléments transmis dans le contexte des modèles de langage sont de faible qualité, les réponses s'en ressentiront.

Mon hypothèse, c'est que, quelle que soit la capacité du modèle, si la qualité du contexte est faible (imprécis, faux ou à côté de la plaque...), alors la réponse ne sera pas satisfaisante.

C'est pourquoi travailler sur le prompt et utiliser un modèle de raisonnement puissant n'est que le début de l'histoire quand on veut améliorer la qualité des agents. Il faut bien évidemment ne laisser aucune marge d'erreur dans la récupération d'informations, que ce soit via des techniques de RAG ou, plus simplement, via les informations transmises par les outils.

Ce qu'on appelle les outils , ce sont des programmes que le modèle de langage demande à son programme hôte d'exécuter pour obtenir des informations, effectuer un calcul ou appliquer une modification.

Lorsqu'on construit un outil, la majorité d'entre nous (développeurs) se contentent, par exemple, d'envoyer aux agents le JSON brut des API en espérant que le modèle de langage devinera le sens de chaque champ. Ça fonctionne... jusqu'à ce que les imperfections qui ruinent l'expérience apparaissent.

Prenons un exemple : j'ai un outil qui me permet de récupérer le statut d'une commande depuis une API.

Une réponse typique de cette API est la suivante :

{
   "internal_id": "1234",
   "customer_reference": "#ORD-154-15",
   "status": "PAID",
   "delivery_date": "2025-07-15",
   "risk_refund": "HIGH"
}

Imaginons qu'une requête soit : Quand est-ce que mon colis va être livré ? et qu'on se serve de cette API pour répondre. Ça signifie qu'on va injecter cette réponse dans le modèle.

Premier problème : il y a des informations qu'on ne veut absolument pas montrer au client. Or tout ce qui est ajouté dans le contexte du modèle de langage est accessible par le client, y compris des informations sensibles comme risk_refund, et éventuellement le statut ou l'identifiant internal_id. Le champ risk_refund pose un problème de sécurité, et l'identifiant interne doit rester interne.

On peut commencer par supprimer ces informations pour obtenir une réponse qui ne transmet plus de données sensibles :

{
   "customer_reference": "#ORD-154-15",
   "status": "PAID",
   "delivery_date": "2025-07-15",
}

Maintenant, il faut garder à l'esprit qu'on échange avec un modèle de langage. Son interface, c'est du texte : ce texte sera utilisé pour former des tokens, lesquels serviront à générer la suite de la réponse. Pour mettre toutes les chances de mon côté, je vais donc reformater la sortie pour fournir une explication textuelle de la situation de la commande :

Commande #ORD-154-15, payée, sera livrée le 15 Juillet 2025.

Ce changement est important : transformer le document JSON en texte ajoute du contexte, du vocabulaire et un ton. Avec un template Jinja, il est assez simple de transformer la sortie JSON.

Exemple:

{# order_summary.j2 #}
{% set status_map = {
    "PENDING": "en attente de paiement",
    "PAID":    "payée",
    "CANCEL":  "annulée"
} %}

{% set date_parts = order.delivery_date.split('-') %}
{% set mois_fr = ["", "janvier", "février", "mars", "avril", "mai", "juin", "juillet", "août", "septembre", "octobre", "novembre", "décembre"] %}
Commande {{ order.customer_reference }}, {{ status_map.get(order.status, order.status) }}, sera livrée le {{ date_parts[2]|int }} {{ mois_fr[date_parts[1]|int] }} {{ date_parts[0] }}.

Arrive ensuite la spécialisation : en fonction du statut, je vais transmettre les informations de manière différente.

Quelques exemples :

*Commande #ORD-154--15, en attente de paiement.*Les informations de livraison seront fournies après réception du paiement. *Commande #ORD-154--15, payée.*Votre colis est en cours de préparation et sera expédié dans les 24 h. *Commande #ORD-154--15, annulée.*Aucun débit n'a été effectué et la commande est maintenant clôturée. *Commande #ORD-154--15, en attente de paiement.*Les informations de livraison seront fournies suite au paiement.

Avec cette méthode, le contexte est transmis sans information superflue, et on peut s'attendre à des réponses précises même avec les modèles de langage les moins performants. En revanche, cela demande plus d'énergie : il faut concevoir une couche de présentation des données textuelles spécialement pour les modèles de langage.

Si vous investissez massivement dans les agents, cette manière d'exposer vos données est certainement un aspect clé de votre investissement.