Observabilité des agents IA en R : ce qu'ellmer et vitals rendent possible

Tant qu'un chatbot ou un agent IA reste un prototype de démo, personne ne se soucie de savoir pourquoi il répond mal un jour sur dix, ni combien de tokens il a consommés pour y arriver. Dès qu'il passe en production dans une app Shiny ou un pipeline métier, ces deux questions deviennent centrales : on doit pouvoir diagnostiquer un incident et prouver que le système fait ce qu'on attend de lui. C'est précisément le trou que comblent deux évolutions récentes de l'écosystème ellmer et vitals.

ellmer embarque désormais une instrumentation OpenTelemetry native. Chaque appel à chat(), chat_async(), stream() ou stream_async() génère un span invoke_agent qui englobe les appels au fournisseur et les exécutions d'outils, avec le nom du modèle, les identifiants de réponse et la consommation de tokens en entrée et sortie. Les appels HTTP de httr2 viennent s'imbriquer automatiquement dans ces spans. Pour une équipe qui utilise déjà un collecteur de traces en interne, c'est un gain direct : on voit où le temps part, quel modèle a répondu, quel outil a échoué, sans instrumenter soi-même le code.

Ce traçage répond à la question du comment, mais pas à celle du bien ou mal. C'est le rôle de vitals, le package d'évaluation de modèles conçu pour R. Il permet de construire des jeux de tests (des tâches avec une réponse attendue), de les faire passer à un modèle, puis de noter les réponses, par exemple via un modèle juge avec model_graded_qa(). La nouveauté generate_structured() permet d'extraire des données structurées des réponses, ce qui ouvre la porte à des évaluations plus fines que le simple jugement textuel : on peut vérifier qu'un champ attendu est bien rempli, qu'une catégorie correspond, qu'un format est respecté.

Concrètement, cela change la façon dont on construit un agent IA en R. Avant de le déployer, on écrit un jeu de cas de test représentatif des usages réels, on le fait tourner avec vitals pour obtenir un score de référence, et on rejoue cette évaluation à chaque changement de prompt ou de modèle pour détecter les régressions. Une fois en production, on branche OpenTelemetry pour observer la latence, le coût en tokens et les erreurs d'outils en conditions réelles. Les deux approches sont complémentaires : l'évaluation offline garantit la qualité avant le déploiement, le traçage en ligne surveille le comportement réel.

Les limites sont réelles. L'évaluation par un modèle juge reste un modèle qui évalue un autre modèle, avec ses propres biais ; vitals réduit ce risque en encourageant des instructions de notation plus courtes, mais ne l'élimine pas. Le traçage OpenTelemetry suppose une infrastructure de collecte déjà en place côté entreprise, ce qui n'est pas toujours le cas des équipes data qui travaillent surtout en R. Capturer le contenu des conversations dans les traces est en plus une fonctionnalité opt-in, pour de bonnes raisons de confidentialité, mais cela veut dire qu'il faut l'activer explicitement et réfléchir à ce qu'on journalise.

Le signal le plus important, au fond, est culturel : l'écosystème R autour de l'IA générative ne se limite plus à appeler une API de chat. Il s'outille pour les exigences classiques du logiciel en production, test automatisé et observabilité, appliquées à des systèmes dont le comportement n'est pas déterministe.

Plutôt que d'écrire x[length(x)], on peut utiliser tail(x, 1), plus lisible et qui fonctionne aussi bien sur un vecteur, une liste ou un data.frame.