IA générative : du monitoring au LLMOps, une transition (déjà) nécessaire

Contrôler les coûts et les usages de l’IA générative

Dans le cadre de l’intégration de sa plateforme avec Azure OpenAI et les API d’OpenAI, Datadog entend suivre le nombre de requêtes envoyées aux API, leur temps de réponse, le nombre de tokens (la longueur des requêtes) sollicité afin d’anticiper les coûts. L’outil de l’éditeur peut afficher le volume d’appels aux interfaces associées à différents modèles ainsi que leurs temps de réponse.

De surcroît, Datadog prétend pouvoir identifier des patterns d’usage en « découpant » les informations des requêtes API par modèle, service dans l’entreprise, par ID d’organisations ou d’utilisateurs et par clés API.

« Nous pouvons également voir les erreurs de fonctionnement des API, l’atteinte des quotas, mais aussi suivre les traces, à savoir inspecter le contenu des prompts et des complétions », précise Yrieix Garnier.

La demande vient-elle de Microsoft ? Oui, annonce clairement Yrieix Garnier. « Mais les requêtes des clients sont par ailleurs de plus en plus nombreuses. Beaucoup d’entreprises testent les capacités de l’IA générative ».

« [Les développeurs] veulent savoir comment le composant OpenAI intégré dans leurs applications se comporte en matière de performance, de coût, et quels sont les usages », poursuit-il. « C’est basique, mais très utile, car la popularité de ces modèles peut rapidement coûter cher ».

Le suivi des traces peut servir dans le cadre d’un travail de fine-tuning (d’affinage) ou pour optimiser des embeddings (des vectorisations), mais aussi pour obtenir la température sélectionnée pour une tâche (une valeur comprise entre 0 et 2 qui détermine la précision du résultat). « C’est aux clients d’échantillonner les données pour juger de la qualité des questions-réponses, mais nous explorons des moyens pour peaufiner le contenu en entrée et en sortie des modèles ». Par défaut, 10 % des requêtes tracées émettent des logs contenant ces informations, précise la documentation de l’éditeur.

À l’avenir, Datadog imagine pouvoir observer d’autres modèles (par exemple, Claude d’Anthropic, Amazon Bedrock, etc.), les infrastructures qui hébergent des LLM privés, les bases de données de vectorisation (embeddings) ou encore la combinaison de plusieurs modèles. Bref, proposer une solution de LLMOps.

Les éditeurs se projettent dans l’approche LLMOps

En la matière, l’éditeur d’outils MLOps Weight and Biases semble déjà plus avancé. Son module de traçage permet d’identifier les problèmes dans les chaînes LLM, de l’exécution d’un prompt à l’obtention d’un résultat. Il est également possible de stocker les prompts et les configurations des modèles ayant permis d’obtenir les meilleurs résultats.

De son côté, Databricks pousse le projet open source Mlflow, qui permet, depuis la version 2.3 lancée en mars, de surveiller certains paramètres, métriques, prédictions et artefacts (résultats stockés dans un format donné) des LLM open source et propriétaires. Comme celui de Weight & Biases, l’outil dispose d’intégration avec les API d’OpenAI et celles de LangChain, un framework pour bâtir des applications basées sur des modèles de langage.

Serait-il possible d’aller plus loin ? Les outils cités ci-dessus mesurent généralement les événements en périphérie d’un LLM. Or les entreprises semblent préoccupées par la protection de leurs données et de leur capacité à expliquer le fonctionnement de leurs modèles.

« Nos clients ont beaucoup de choses à observer, qu’ils utilisent un LLM sur étagère ou qu’ils décident de l’entraîner eux-mêmes. Nous rencontrons également des clients qui ont des contraintes de confidentialité, de protection de la propriété intellectuelle », avance Yrieix Garnier.

En la matière, OpenAI, Microsoft et les autres prennent petit à petit conscience que les entreprises veulent avoir le contrôle sur leurs données et contenir les résultats (les complétions) qu’ils pourraient obtenir. Dans le cadre de l’AI Act, cela deviendra probablement une obligation légale dans l’Union européenne.

Or, il ne parait pas possible d’observer de près le comportement des poids des modèles propriétaires. De fait, Google, OpenAI, Anthropic et même LightOn protègent leurs propriétés intellectuelles : les poids, les features et d’autres caractéristiques ne sont pas exposés. Ce n’est pas forcément le cas avec les modèles open source qui peuvent être plus facilement auscultés.

Une gouvernance périphérique naissante

Pour autant, cette analyse en profondeur « serait très complexe à faire », estime Alan Trefler, CEO de Pegasytems, un éditeur d’une plateforme qui mêle low-code/no-code et IA générative. Le nombre de dimensions et de paramètres qui agissent lors d’une prédiction réalisée par un grand modèle de langage est considérable.

Le dirigeant pense qu’il faut déjà surveiller l’usage des données privées et confidentielles et, en sus des mesures de chiffrement et de cybersécurité, utiliser des embeddings. Ces représentations vectorielles de textes peuvent remplacer les informations critiques à envoyer aux modèles. De la sorte, l’API d’un éditeur de LLM ne recevrait qu’une liste de nombres à virgule flottante. De son côté, Nvidia propose sa bibliothèque NeMo Guardrails pour apposer des garde-fous aux applications NLG, et filtrer les complétions.

Yrieix Garnier considère que la plateforme de Datadog permet de détecter les informations personnelles (ou confidentielles) dans les logs d’un système. Cette technique pourrait être appliquée aux applications d’IA générative.

En attendant, OpenAI et Microsoft, les porteurs des modèles les plus populaires, proposent une rustine. Dans le cadre d’appels aux API d’OpenAI ou d’AzureOpenAI, « par défaut, les données envoyées ne sont pas utilisées pour entraîner ou améliorer le modèle, à moins que [le client] décide de partager ces données à cette fin ». Les données des utilisateurs peuvent tout de même être conservées pendant 30 jours afin de détecter « des abus » dans les messages envoyés via API.