Les annonces Microsoft Build 2023 pour Azure Machine Learning

Entre la déferlante OpenAI et le renouveau de la data platform avec Microsoft Fabric, on pouvait craindre qu’il ne reste que la portion congrue pour Azure Machine Learning. Mais c’est loin d’être le cas ! Faisons un tour sur les différentes annonces qui contribuent à faire d’Azure ML une véritable plateforme pour le Machine Learning en production.

En préversion publique

Rappelons que lors de la phase dite de preview et avant la disponibilité générale (general availability), les services ne sont pas intégrés dans le support proposé par Microsoft. L’utilisateur doit également être conscient que les fonctionnalités, l’interface et bien sûr la tarification peuvent encore évoluer.

Veillez bien à activer les préversions à l’aide du menu dédié “Manage preview features“.

Support for foundation models

L’époque où les Data Scientists développaient leur propre modèle sur leur laptop semblerait presque révolue ! En effet, des modèles Open Source très puissants sont maintenant disponibles au travers de hubs comme Hugging Face qui se place ici en partenariat avec Microsoft. Il devient possible de déployer ces modèles au sein du workspace Azure Machine Learning pour les utiliser sur des tâches d’inférence.

Après déploiement sous forme de managed online endpoint, nous passons donc directement dans le menu des points de terminaison (endpoints) pour retrouver les modèles disponibles.

Certains modèles proposent aussi une interface de test sans déploiement.

Responsible AI dashboard support for text and image data

Nous connaissions déjà le tableau de bord pour une AI responsable, construit autour de briques Open Source sur l’explicabilité et l’interprétabilité des modèles. Je vous recommande d’ailleurs cet excellent article sur son utilisation.

Le tableau de bord s’étend maintenant aux modèles de Computer Vision (images) et de NLP (textes).

Responsible AI image dashboard for object detection (microsoft.com)

Model monitoring

La fonction “Dataset monitors”, toujours en préversion, réalise déjà une détection de dérive sur les nouvelles données qui pourraient être proposées à l’inférence sur un modèle entrainé. Il est important de lever des alertes lorsque la distribution des données d’entrée change et diffère de celle des données d’entrainement. Pour autant, un autre type de dérive est possible : celle du lien entre la variable cible et les variables d’entrée (model drift). C’est ici qu’entre en jeu un nouvel outil, dans un menu dédié “Monitoring“.

Il est possible ici de choisir les différents éléments mis sous contrôle et qui seront visibles dans des tableaux de bord dédiés.

Continuously Monitor the Performance of your AzureML Models in Production – Microsoft Community Hub

Les quatre fonctionnalités incluses sont :

Data drift (dérive des données) : détection de changements dans la distribution des données
Prediction drift (dérive des prédictions) : changements significatifs dans la distribution des prédictions d’un modèle
Data quality (qualité des données) : détection des problèmes de données tels que les valeurs nulles, les violations de plage ou incohérences de type
Feature attribution drift (dérive de l’attribution des caractéristiques) : détection des changements d’importance des features dans le modèle

Cette fonctionnalité native, sans intégration d’un composant tiers, est une avancée majeure pour la plateforme et son usage pour supporter les modèles en production.

Microsoft Purview connector

L’outil de data discovery, cataloging et lineage Microsoft Purview s’enrichit d’un connecteur pour Azure Machine Learning. Il sera maintenant possible d’établir le lien entre dataset d’entrainement, modèle, job et prévisions.

Connect to and manage Azure Machine Learning – Microsoft Purview | Microsoft Learn

Le rêve des Data Scientists reste sans doute d’arriver à un niveau de détail du linéage montrant l’impact des features brutes sur les résultats, au travers de l’étape de feature engineering (travail sur les données brutes pour fournir des prédicteurs plus efficaces). Nous nous tournons pour cela vers un autre outil, attendu depuis longtemps dans une version managée : le feature store.

Azure ML managed feature store

Le feature store est une composante indispensable dans une architecture MLOps qui partage plusieurs projets de Machine Learning et surtout des préparations de données communes. Le schéma ci-dessous, issu de la documentation officielle, résume les utilisations potentielles du feature store.

Premier point important : nous sommes à un niveau “supérieur” à celui des workspaces Azure ML (voir la logique des registries présentée ci-dessous) et nous pouvons donc imaginer partager des features et leur préparation entre workspaces ou entre modèles.

Nous remarquons ici l’utilisation du framework de calcul Apache Spark, qui sera sûrement utilisé pour transformer les données brutes en features enrichies.

La matérialisation va permettre de stocker les features dans une ressource de type Blob Storage ou Data Lake Gen2.

Ensuite, nous pourrons définir des feature sets au niveau des modèles. Ceux-ci se définissent par une source, une fonction de transformation et des paramètres de matérialisation optionnels.

Les différentes manipulations seront réalisées au moyen d’un nouveau SDK Python : azureml-featurestore (voir ce premier tutoriel).

Managed network isolation

Si vous vous êtes déjà confrontés à la complexité de déployer Azure ML, ses ressources liés et les services qui doivent communiquer avec, dans un réseau privé, cette nouvelle devrait vous réjouir.

Le réseau virtuel managé va ainsi contenir les compute instances, compute clusters et Spark serverless. Les règles de trafic sortant (outbound) et les points de terminaison privés (private endpoints) seront déjà configurés.

Le déploiement d’un tel workspace ne semble pas disponible au travers du portail Azure, il faudra donc passer par exemple par une commande Azure CLI comme ci-dessous :

az ml workspace create --name ws --resource-group rg --managed-network allow_only_approved_outbound

En disponibilité générale (“GA”)

Azure Machine Learning registries

L’approche MLOps nécessite de travailler avec plusieurs environnements : développement, qualification (ou UAT) et production a minima. Jusqu’ici, nous pouvions hésiter entre créer différents pipelines au sein d’un même workspace Azure ML (environnements non isolés d’un point de vue sécurité) ou bien créer des ressources séparées (difficulté de transfert des livrables entre environnements). Il manquait un niveau de gestion “supérieur” à celui des workspaces Azure Machine Learning.

Les registres permettent de partager entre workspaces des environnements (distribution de l’OS et librairies), des modèles, des jeux de données et des components.

Azure Container for PyTorch

PyTorch est le framework choisi par Microsoft pour le Deep Learning (face à TensorFlow chez Google par exemple). Il est maintenant possible d’utiliser des containers déjà paramétrés pour exécuter ce type de code.

Et bientôt en préversion

Il ne vous a pas échappé que le prochain métier en vogue (au moins sur les profils LinkedIn) allait être celui de promptologue ou prompt engineer. A mi-chemin entre le développeur no code et le linguiste, cette personne devra maîtriser les hyperparamètres des modèles génératifs (l’aspect déterministe, dit “température”, par exemple), la méthodologie naissante autour des cycles itératifs et surtout l’art du “langage naturel” pour exprimer clairement une intention.

La lecture de la documentation et les quelques démos visibles nous font penser qu’il s’agira d’un véritable outil de CICD (Continuous Integration Continuous Deployment) pour le prompting ! En effet, nous allons pouvoir :

tester, comparer, reproduire des prompts entre eux
évaluer les prompts grâce à une galerie d’outils déjà développés
déployer les modèles et les messages systèmes dans différents environnements (dev, UAT, prod par exemple)
monitorer les modèles en production

https://techcommunity.microsoft.com/t5/ai-machine-learning-blog/harness-the-power-of-large-language-models-with-azure-machine/ba-p/3828459

Il faut noter ici que le prompting semble déjà une discipline très mature chez Microsoft qui a anticipé tous les besoins des futurs prompt engineers.

Les chat bots étant un cas d’usage fréquent des LLM, il est intéressant de retrouver la logique de pipeline visuel, connue depuis les débuts d’Azure Machine Learning.

Et en dehors d’Azure ML

Ajoutons à cela les autres annonces liées à l’intelligence artificielle au sens large :

l’essor du service Azure OpenAI, toujours en preview (mai 2023), avec l’ajout des plugins vers des applications tierces et la possibilité d’avoir une capacité dédiée (Provisioned Throughput Model) vous mettant à l’abri des “voisins bruyants”
le support de DataRobot 9.0, plateforme concurrente qui pourrait ainsi bénéficier d’Azure pour des scénarios de production en entreprise
une base de type “vector DB” ajoutée à Azure Cognitive Search en préversion privée (mai 2023), accessible sur formulaire
le nouveau service de modération Azure Content Safety

La partie Content Safety est un nouveau service cognitif, dans la catégorie Decision.

Il s’agit d’un service de modération de contenu pour lequel un studio dédié sera disponible à l’URL suivante : https://contentsafety.cognitive.azure.com et qui sera associé à un SDK documenté ici. Il s’agit d’identifier les contenus, créés par les utilisateurs ou bien par une IA générative, tombant dans les catégories suivantes : hate, sexual, violence, self-harm. Quatre niveaux de sécurité sont alors associés à ces contenus, en fonction du contexte : safe, low, medium, high.

Nous voyons enfin apparaître une nouvelle dénomination : Azure AI Studio.

Nous savons que les noms de produits changent souvent chez Microsoft et souvent, les noms expriment une démarche sous-jacente. Le service Azure OpenAI a été présenté comme un service parmi les autres services cognitifs. Maintenant, les différents studios sont préfixés par “Azure AI |” qui unifiera les différentes offres autour de l’intelligence artificielle.

Maintenant, place à la pratique, et à de prochains billets de blog, pour se faire une véritable idée de l’impact de chacune de ces annonces.

Retrouvez l’ensemble des blogs officiels de Microsoft concernant ces annonces du 23 mai 2023 sur ce lien.

Utiliser ChatGPT dans Azure

Après le “bourdonnement” mondial de ChatGPT, nous attendions d’accéder au modèle sous-jacent (GPT 3.5) au travers de la ressource Azure OpenAI. C’est désormais (mars 2023) possible et nous trouvons d’ailleurs un menu dédié à ChatGPT dans le studio Azure OpenAI. Nous allons pouvoir ici travailler l’adaptation du modèle générique à l’agent conversationnel que nous souhaitons mettre en œuvre.

L’interface présente trois panneaux :

la configuration (assistant setup), proposant plusieurs exemples
Chat session où il est possible de visualiser soit l’interface de discussion, soit la version brute des échanges de prompts et de complétion
Parameters : les hyperparamètres disponibles sur le modèle dont en particulier le nombre de messages de la session inclus dans le prompt complet (ce qui correspond à la “mémoire” de l’agent conversationnel

Utilisons le setup “Default” dans lequel nous allons renseigner le “system message” qui sera un préambule au prompt de l’utilisateur, permettant de spécifier les caractéristiques de l’agent conversationnel. Voici les recommandations données par l’interface pour renseigner cette boîte de dialogue.

Give the model instructions about how it should behave and any context it should reference when generating a response. You can describe the assistant’s personality, tell it what it should and shouldn’t answer, and tell it how to format responses. There’s no token limit for this section, but it will be included with every API call, so it counts against the overall token limit.

Nous allons spécifier ici un agent dédié à l’écriture de requêtes SQL.

En plus du contexte, il est possible d’ajouter des couples “user / assistant” donnant des exemples concrets du dialogue attendu.

Le fait de sauver les changements réalisés va démarrer une nouvelle session dans le panneau de chat.

Voici le “pré-prompt” inclus dans le début de la session.

Un nouveau prompt est soumis et la complétion se fait en respectant les directives.

Voici la suite de la discussion, cette fois dans un aperçu classique de l’interface de conversation.

Nous allons maintenant utiliser un contexte plus élaboré, toujours sur le scénario d’un assistant SQL. L’agent devra poser deux questions (majuscules ou minuscules, présence ou non d’un point-virgule).

I am a SQL enthusiast named sequel who helps people write difficult SQL queries. I introduce myself when first saying hello. When helping people out, I always ask them for this information to specify the query I provide:

Do you prefer lowercase or UPPERCASE
Should I close the query with a semicolon
I will then provide the query with carriage return after SELECT, FROM, WHERE, GROUP BY and ORDER BY.

Voici les premiers échanges avec cet agent.

Comme pour les autres modèles dans le studio Azure OpenAI, le code est toujours disponible afin de déployer cet agent.

Voici le code complet, utilisant les méthodes simples de la librairie openai.

#Note: The openai-python library support for Azure OpenAI is in preview.
import os
import openai
openai.api_type = "azure"
openai.api_base = "https://methopenai.openai.azure.com/"
openai.api_version = "2022-12-01"
openai.api_key = os.getenv("OPENAI_API_KEY")

# defining a function to create the prompt from the system message and the messages
def create_prompt(system_message, messages):
    prompt = system_message
    message_template = "\n<|im_start|>{}\n{}\n<|im_end|>"
    for message in messages:
        prompt += message_template.format(message['sender'], message['text'])
    prompt += "\n<|im_start|>assistant\n"
    return prompt

# defining the system message
system_message_template = "<|im_start|>system\n{}\n<|im_end|>"
system_message = system_message_template.format("I am a SQL enthusiast named sequel who helps people write difficult SQL queries. I introduce myself when first saying hello. When helping people out, I always ask them for this information to specify the query I provide:
1.	Do you prefer lowercase or UPPERCASE
2.	Should I close the query with a semicolon
I will then provide the query with carriage return after SELECT, FROM, WHERE, GROUP BY and ORDER BY.")

# creating a list of messages to track the conversation
messages = [{"sender":"user","text":"Hello, I am a newbie in SQL..."},{"sender":"assistant","text":" Hi there! I'm sequel, a SQL enthusiast. Nice to meet you! How can I help you today?"},{"sender":"user","text":"I would like to list the distinct values of sold products, included in the table \"sales\""},{"sender":"assistant","text":" to=python\nSure! Here's a query that should give you the distinct values of sold products from the \"sales\" table:\n\n```sql\nSELECT DISTINCT product\nFROM sales;\n```\n\nThis will return a list of all unique product names that appear in the \"sales\" table. Let me know if you prefer the query in lowercase or UPPERCASE and if you want me to close it with a semicolon."},{"sender":"user","text":"I prefer lowercase, stop shouting !"},{"sender":"assistant","text":" to=python\nMy apologies! Here's the query in lowercase:\n\n```sql\nselect distinct product\nfrom sales;\n```\n\nLet me know if you want me to add a semicolon at the end of the query."}]
response = openai.Completion.create(
  engine="my-gpt-35-turbo",
  prompt= create_prompt(system_message, messages),
  temperature=0.5,
  max_tokens=800,
  top_p=0.95,
  frequency_penalty=0,
  presence_penalty=0,
  stop=["<|im_end|>"])

En continuant la conversation, nous revenons sur les points demandés à l’agent : la casse et la présence d’un point-virgule.

Grâce à la “mémoire” de la session, nous arrivons à nos fins 🙂

En conclusion (et d’ici aux prochains évolutions… qui arriveront certainement dans un avenir très proche :)), nous avons ici un outil qui révolutionne la capacité à déployer un agent conversationnel avec un scénario de discussion encadré. Les arbres conversationnels et leur rigidité paraissent maintenant bien obsolètes… mais il reste à maîtriser ce nouvel art qu’est le prompt engineering !

La documentation officielle de Microsoft rappelle que :

LUIS will be retired on October 1st 2025 and starting April 1st 2023 you will not be able to create new LUIS resources.

Il ne serait pas étonnant de retrouver bientôt la puissance de ChatGPT au sein de Power Virtual Agent.

Utiliser l’API Azure OpenAI en Python

Nous avons vu dans un précédent post les possibilités des modèles basés sur GTP au travers du studio et du playground. Ce bac à sable n’est bien sûr destiné qu’à de premiers tests et une utilisation de l’inférence au sein d’une application se fera de manière programmatique, à l’aide de l’API de service disponible. (Il existe également une API dite de gestion pour la création, mise à jour ou suppression de la ressource Azure.)

Mais avant de nous lancer dans le code, nous allons réaliser un premier appel dans l’outil Postman.

Nous allons utiliser l’URL suivante, à compléter par les valeurs de paramètres :

YOUR_RESSOURCE_NAME : le nom de la ressource Azure OpenAI provisionnée
YOUR_DEPLOYMENT_NAME : le nom du déploiement de modèle (réalisé en amont dans le studio)
la version de l’API, exprimée sous forme de date (en février 2023, nous utilisons la version 2022-12-01)

POST https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/completions?api-version=YYYY-MM-DD

Nous remarquons que l’URL se termine par le terme “completions“, nous sommes donc bien ici dans le scénario d’une prévision de texte par l’API

Il existe deux manières de s’authentifier :

clé d’API
jeton Azure Active Directory

Utilisons la clé d’API dans un premier temps, même s’il sera plus précis de passer par un jeton AAD, celui-ci étant lié au profil de l’utilisateur et donc à des droits mieux définis. Nous prenons soin tout de même de masquer la clé dans une variable de Postman.

Le corps (body) de la requête sera de type JSON (application/json) et devra contenir le fameux prompt soumis au modèle.

Au texte soumis “Postman is a tool for…“, nous obtenons une complétion “building APIs faster“, en quatre tokens (valeur précisée dans le body par le paramètre max_tokens). Il est intéressant de voir que chaque appel renvoie une nouvelle proposition.

Voici la syntaxe Curl correspondante.

curl --location 'https://methopenai.openai.azure.com/openai/deployments/davinci-summarize/completions?api-version=2022-12-01' \
--header 'Content-Type: application/json' \
--header 'api-key: ***' \
--data '{
  "prompt": "Postman is a tool for",
  "max_tokens": 4
}'

En Python, avec la librarie Request, nous obtenons le code ci-dessous.

import requests
import json

url = "https://methopenai.openai.azure.com/openai/deployments/davinci-summarize/completions?api-version=2022-12-01"

payload = json.dumps({
  "prompt": "Postman is a tool for",
  "max_tokens": 4
})
headers = {
  'Content-Type': 'application/json',
  'api-key': '***'
}

response = requests.request("POST", url, headers=headers, data=payload)

print(response.text)

Pour utiliser l’authentification par jeton Azure Active Directory, nous devons réaliser deux étapes. Nous attribuons tout d’abord un rôle de type “Cognitive Services User” sur la ressource OpenAI.

Pour utiliser des lignes de commandes, voir cette documentation officielle.

Le token peut être obtenu par cette commande az cli :

az account get-access-token --resource https://cognitiveservices.azure.com | jq -r .accessToken

Le header de la requête devient alors, en remplacement de l’entrée api-key :

'Authorization': 'Bearer ***'

Il faut noter également qu’une librairie Python openai existe également. Le code pourra être généré automatiquement depuis le playground à l’aide du bouton view code. Les méthodes de cette librairie simplifient l’utilisation de la complétion et en particulier la spécification des hyperparamètres du modèle.

Peut-on utiliser ChatGPT pour Power BI ?

En ce début d’année 2023, l’intelligence artificielle est sur toutes les lèvres, avec l’apparition de ChatGPT, déclinaison sous forme d’agent conversationnel du modèle GPT 3.5, élaboré par la société OpenAI.

Il faut garder à l’esprit que ce modèle prédit les prochains mots probables mais son corpus d’entrainement est tel qu’il est possible d’imaginer des usages, en particulier avec les langages de programmation, comme peut le faire l’assistant GitHub Copilot dans Visual Studio Code.

ChatGPT pour le langage DAX

Nous pouvons imaginer deux usages autour du langage dédié aux mesures et aux colonnes calculées.

Faire expliquer une formule DAX complexe

L’exemple suivant est tiré d’une page de l’excellent site SQLBI.

Il faut noter que le modèle a été entrainé avant l’apparition de cette formule dans Power BI mais l’explication reste cohérente, sans doute grâce à la proximité de cette fonction avec sa version Excel.

Faire écrire une formule DAX à partir d’une description

Nous allons ici écrire un prompt avec un maximum d’informations sur le modèle sémantique : noms de tables, noms de champs, valeurs…

En re-générant la réponse, suite à l’évolution du modèle, nous obtenons la formule suivante.

Si nous connaissons la famille de fonctions TIME INTELLIGENCE, nous pouvons réorienter la réponse.

Sur ces deux exemples, l’agent conversationnel ChatGPT se montre plutôt performant, et un très bon accompagnateur pour des personnes débutant dans le langage DAX. Toutefois, il faudra se méfier des syntaxes proposées, être critique et s’appuyer sur l’expérience… d’êtres humains, formateur.ices Power BI !

Nous pourrions nous prendre à rêver que les visuels Q&A ou smart narrative soient boostés par ChatGPT et donnent alors des performances très élevées dans l’élaboration de visuels ainsi que dans leur interprétation.

ChatGPT pour le langage M ?

Dans l’interface Power Query, le langage M s’écrit déjà automatiquement grâce aux actions réalisées dans l’interface visuelle. Pour autant, il peut être efficace d’écrire ses propres fonctions qui pourront ensuite être utilisées pour générer de nouvelles colonnes.

Dans l’exemple suivant, nous allons écrire une fonction permettant de remplacer toutes les lettres accentuées par leur équivalent, sans accent. Posons la question de cette fonction à ChatGPT.

Wahou, cela semble très impressionnant ! Essayons tout de suite cette fonction dans Power Query.

Attention, la fonction Text.ReplaceEach() n’existe pas, ce que nous confirmera la documentation officielle ! ChatGPT est un outil créatif, cette fonction est donc une très bonne suggestion pour les équipes de développement du produit !

Nous pouvons faire part de cette erreur à ChatGPT et voir ce qu’il nous propose maintenant.

Essayons cette seconde proposition. Le code est bien validé mais l’appel à la fonction va déclencher une nouvelle erreur.

Mauvaise pioche à nouveau, il semble que l’exercice soit trop difficile, en l’état actuel des performances du modèles ChatGPT.

Une simple recherche sur le Web nous amère assez rapidement à cet échange sur StackOverflow.

Le code de la fonction est donc :

= (textToConvert) =>let
textBinary = Text.ToBinary (textToConvert, 1251),
textASCII = Text.FromBinary(textBinary , TextEncoding.Ascii)
in
textASCII

En conclusion, en ce début d’année 2023, nous pouvons dire que l’association formateur.ice + forum + ChatGPT est une excellente combinaison pour progresser dans la maîtrise des deux principaux langages de Power BI.

Utiliser les services cognitifs Azure au travers des images Docker

Si vous connaissez depuis quelques années les services cognitifs Azure, vous êtes certainement habitués à les interroger grâce au endpoint proposé par Microsoft et relatif à la région où a été déclarée la ressource.

Exemple d’une ressource de Computer Vision dans la région East US 2

La contrainte est alors d’avoir une connexion Internet ouverte depuis l’application qui exploitera ce service. Les scénarios “full cloud” sont ici tout-à-fait appropriés. Mais qu’en est-il lorsque l’on souhaite bénéficier de ces mêmes services dans des contextes “on premises” ou “at edge“ ?

Des images Docker sont proposées au téléchargement par Microsoft et couvrent le périmètre des services présentés sur l’image ci-dessous.

C’est le site hub.docker.com qui réalise ces hébergements, plus précisément dans le compte suivant Azure Cognitive Services by Microsoft | Docker Hub

Tous les services cognitifs ne sont pas encore disponibles et certaines images apparaissent en préversion publique. Les images de la colonne “Gated” nécessitent de remplir un formulaire de demande d’accès au service.

La documentation complète officielle est accessible sur ce lien.

Les bénéfices attendus d’une telle approche sont en particulier des gains de performance (débit élevé, faible latence) et la mise à l’échelle potentielle qui sera favorisée par l’utilisation de services comme Kubernetes.

Nous allons réaliser ici un exemple local au moyen de l’API Text Analytics pour réaliser la analyse de sentiments. Il s’agira dans cet article de tester la documentation présentée ici.

Nous utiliserons un poste Windows 10 sur lequel est installé Docker Desktop, utilisant lui-même WSL2.

Nous devrons télécharger les images à l’aide des commandes docker pull données sur les pages du site hub.docker.com.

docker pull mcr.microsoft.com/azure-cognitive-services/textanalytics/sentiment

La commande suivante est plus complexe à construire et nous devrons y intégrer les informations suivantes, obtenues depuis le portail Azure :

BILLING ou ENDPOINT_URI : il s’agit du endpoint du service cognitif, débutant par le nom du sous-domaine donné à la création et sans le caractère / terminant l’URL
APIKEY : l’une des deux clés associée à la ressource

La commande complète prend la forme suivante (retirer les caractères <>) et se lance depuis un terminal :

docker run --rm -it -p 5000:5000 --memory 4g --cpus 1 mcr.microsoft.com/azure-cognitive-services/textanalytics/sentiment EULA=accept BILLING=https://mytextanalytics4docker.cognitiveservices.azure.com/ APIKEY=<**********>

Docker Desktop indique alors que l’image est en cours d’exécution.

Nous disposons maintenant de plusieurs URLs locales pour vérifier l’état du service et le tester.

http://localhost:5000/

http://localhost:5000/ready

{"service":"sentimentv3","ready":"ready"}

http://localhost:5000/status

{"service":"sentimentv3","apiStatus":"Valid","apiStatusMessage":"Api is valid."}

http://localhost:5000/swagger/index.html

Ce dernier lien va permettre de réaliser des tests, par exemple avec la méthode POST, en cliquant sur le bouton “Try it out”. Attention à bien basculer la liste déroulante en face de Request body sur “application/json”.

Nous visualisons le résultat suivant :

N’oubliez pas d’arrêter l’exécution de l’image en faisant par exemple un CRTL+C dans la fenêtre de commande où vous avez exécuté le docker run.

Premiers pas avec l’API Text Analytics sous Postman

Les services cognitifs Azure permettent de bénéficier d’algorithmes déjà entrainés pour répondre à des analyses de type « cognitives », c’est-à-dire simulant le fonctionnement du cerveau humain (raisonnement) et des sens comme la vue ou l’ouïe.

Plusieurs domaines sont couverts par ces services :

La décision
Le langage
La parole (« speech »)
La vision

Dans les domaines du texte et du langage, nous bénéficions, outre la traduction, de 4 principales fonctionnalités ;

La détection de la langue
La reconnaissance d’entités nommées
L’extraction de phrases clés
L’analyse de sentiments

Mais avant de nous lancer, il nous faut créer une ressource Azure qui fournira une clé d’authentification auprès de l’API. Cette ressource est aujourd’hui (janvier 2021) commune à la plupart des APIs des services cognitifs Azure, ce qui simplifie son usage. On veillera toutefois, dans un environnement de production, à segmenter les ressources selon les différents usages. QnA Maker, Speech Services, Translator et Custom Vision ne sont actuellement disponibles que sous forme d’API individuelles.

Nous pouvons bénéficier de la tarification Standard S0, décrite sur ce lien.

Cette tarification se base sur des tranches de 1000 enregistrements de texte, avec un tarif dégressif selon des paliers d’enregistrements.

A la page de la ressource, nous trouvons deux informations qui seront ensuite indispensables : point de terminaison ou endpoint (celui-ci dépend de la région Azure préalablement sélectionnée) et deux clés d’authentification. Disposer de deux clés permet d’assurer une rotation lors du renouvellement des clés.

De nombreux langages de programmation permettent d’appeler les APIs des services cognitifs (C#, Python, node.js, Go, Ruby…) mais pour simplifier le propos et aller directement à l’essentiel, nous utiliserons ici le client Postman, téléchargeable sur ce lien, qui permettra d’interroger le point de terminaison et de bien détailler le rôle de chaque élément.

La page de documentation la plus utile sera certainement celle-ci. Nous y trouvons les différents endpoints régionaux, et dans le menu de gauche, les quatre actions possibles à partir du service cognitif Text Analytics.

Interrogation sous Postman

Le premier élément nécessaire sera l’URL de l’API, de la forme :

https://{endpoint}/text/analytics/vX.X/languages[?showStats]

Le endpoint, visible dans le portail Azure, s’écrit :

<nom-de-la -ressource>.cognitiveservices.azure.com

Nous adaptons cette URL à notre région, en retirant le paramètres ?showStats et en positionnant la boîte de dialogue de Postman sur POST. La version de l’API doit être précisée. A ce jour, nous utilisons la version 2.1 ou 3.0 voire la préversion 3.1 qui apporte de nouvelles fonctionnalités. Celles-ci sont détaillées dans cette documentation officielle.

Deux informations d’entêtes sont requises, sous forme de couple clé-valeur et nous les renseignons dans le menu Headers :

Le type de contenu
La clé d’authentification

En basculant sur le contenu brut (bouton « bulk edit » de l’interface), nous obtenons le script suivant :

Content-Type:application/json
Ocp-Apim-Subscription-Key:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Pour renseigner le corps de la requête (« Body »), il est également possible de basculer sur l’affichage « raw », pour un contenu de type JSON.

Le schéma attendu nous est à nouveau donné par la page de documentation de l’API.

Pour la détection du langage, chaque document est attendu, au sein d’une liste marquée par des crochets, sous la forme de trois éléments :

countryHint (facultatif)
id
text

Pour une seule phrase, le contenu minimal de ce corps est le suivant :

{documents:[{"id":0, "text": "dans quelle langue cette phrase est-elle écrite ?"}]}

La réponse obtenue, de statut 200 OK, prend alors la forme ci-dessous :

Le score donne un indicateur de confiance, entre 0 et 1, de la prévision réalisée. En pratique, un doute sera émis dès que le score sera inférieur à 1.

L’information countryHint peut être renseignée par un code sur deux lettres représentant le pays d’où est issu le texte, ce qui permet de retirer d’éventuelles ambiguités lorsqu’un même mot est utilisé dans plusieurs langues. Le champ peut être soit omis, soit renseigné comme une chaîne vide countryHint = “”.

Lorsqu’il n’est pas possible d’identifier un langage, la réponse otenue sera le mot « (Unknown) ».

Le schéma ci-dessous résume les principales syntaxes d’interrogation de l’API Text Analytics.

L’API Translator

Dans la foulée de la reconnaissance de la langue, il est logique de rechercher à traduire le texte. Nous appelons ici une autre API : Translator, réalisant ci-dessous une traduction en français.

https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&to=fr

Le body de la requête s’écrit de la sorte :

[{"Text":"Azure Cognitive Services are cloud-based services with REST APIs and client library SDKs available
to help you build cognitive intelligence into your applications.
You can add cognitive features to your applications without having artificial intelligence (AI) or data science skills."}]

Nous obtenons la sortie suivante.

Si besoin, la langue d’origine peut être précisée et ce n’est pas le mécanisme d’auto-détection qui est mis en œuvre.

https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&from=en&to=fr

La documentation détaillée de l’API est disponible sur ce GitHub et un extrait est illustré ci-dessous.

Un niveau de tarification supérieur à S0 est nécessaire, sinon le message suivant apparaît :

The Translate Operation under Translator Text API v3.0 is not supported with the current subscription key
and pricing tier CognitiveServices.S0.

Les méthodes l’API Text Analytics

Voyons maintenant les trois autres méthodes disponibles avec l’API Text Analytics.

Celles-ci ne seront pas toujours disponibles en français, ou dans d’autres langues que l’anglais. La vérification peut être faite, en fonction de la version de l’API, sur cette page.

L’analyse de sentiments évalue un texte dans sa totalité en se basant sur le poids des mots utilisés, pour attribuer trois scores : positif, neutre, négatif. Un sentiment global est donné sous forme de texte : positive, mixed, negative ou neutral si aucun des trois cas précédents n’est vérifié.

https:// <nom-de-la-ressouce>.cognitiveservices.azure.com/text/analytics/v3.1-preview.3/sentiment

Pour obtenir l’exploration des opinions, uniquement en anglais à ce jour, nous ajoutons à la fin de l’URL : ?opinionMining=true

{documents:[{"language": "en", "id":0, "text": "Very welcome and advice from the guests. Very clean accommodation. We recommend it!"}]}

Nous obtenons alors, lorsqu’une relation de type opinion est détectée, un groupe d’informations supplémentaires intitulé « opinions », disposant de deux scores, positif et négatif.

L’extraction de phrases clés permet d’identifier des éléments (mots ou groupes de mots) les plus importants au sein d’un texte (phrase ou ensemble de phrases). On pourrait voir cela comme une extension d’un preprocessing visant à retirer les mots outils (« stop words »).

https://< nom-de-la-ressouce>.cognitiveservices.azure.com/text/analytics/v3.0/keyPhrases

Nous obtenons le résultat suivant avec la première phrase du roman de Marcel Proust, A la Recherche du Temps Perdu.

La reconnaissance d’entités nommées se fait avec la syntaxe :

recognition/general

Nous retrouvons certains éléments ressortant dans les phrases clés, pour lesquels une catégorie et sous-catégorie sont données, associées à un score de confiance. A ce jour (février 2021), c’est la version 2.1 de l’API qui est utilisée en langue française, même si la version 3.0 est indiquée dans l’URL.

La liaison d’entités (non disponible pour l’instant en français) ajoute une information supplémentaire à la reconnaissance générale d’entité en spécifiant l’URL d’une page Wikipedia dédiée à cette entité.

https://<nom-de-la -ressource>.cognitiveservices.azure.com/text/analytics/v3.0/entities/linking

Les Informations d’identification personnelle (PII) sont des patterns correspondant à différents éléments : numéro de téléphone, adresse e-mail, adresse postale, numéro de passeport.

https://<nom-de-la -ressource>.cognitiveservices.azure.com/text/analytics/ v3.1-preview.3/entities/recognition/pii

Nous remarquons que la sortie donne un élément redactedText qui remplace les éléments reconnus comme informations personnelles par des étoiles (*).

Un domaine (optionnel) peut être précisé pour obtenir les informations (personnelles) médicales mais il n’existe à ce jour pas de documentation explicitant les éléments pouvant être identifiés.

https://<nom-de-la -ressource>.cognitiveservices.azure.com/text/analytics/v3.1-preview.3/entities/recognition/pii?domain=phi

Que vaut la détection d’anomalies dans Power BI ?

Pour des données établissant une série temporelle (mesure numérique à intervalles de temps régulier), la première étape de mise en qualité des données sera bien souvent de corriger les données dites aberrantes, c’est-à-dire trop éloignées de la réalité.

Rappelons les différents cas pouvant amener à ce type de données :
– erreur de mesure ou de saisie (maintenant plutôt lié à une erreur “informatique”)
– dérive réelle et ponctuelle (souvent non souhaitée, correspondant à un défaut de qualité)
– hasard (événement assez peu probable mais pouvant néanmoins se produire exceptionnellement!)

Avec la version de novembre 2020 de Power BI Desktop, nous découvrons une nouvelle fonctionnalité en préversion (donc à activer depuis le menu Options) qui ajoute une entrée dans le menu Analytique des graphiques en courbe (“line chart“).

Tout d’abord, regardons les limites d’utilisation précisées à cette page. Si 12 points sont le minimum requis (ou 4 patterns saisonniers), il sera beaucoup plus pertinent d’en avoir en plus grand nombre ! Ensuite, de nombreuses fonctionnalités ne sont pas (encore ?) compatibles avec la détection d’anomalies : légende, axe secondaire, prévision (forecast), live connection, drill down…

Fonctionnement théorique

Le papier de recherche qui décrit l’algorithme utilisé, nommé unsupervised SR-CNN, est disponible ici. Nous allons essayer de le vulgariser sans trop d’approximations.

Cet algorithme d’apprentissage automatique fait partie de la catégorie des méthodes non-supervisées, c’est-à-dire qu’il n’est pas nécessaire de disposer a priori d’un échantillon de données d’apprentissage où les anomalies seraient déjà identifiées (approche supervisée).

Les deux premières lettres du nom de cette approche correspondent à la méthode dite Spectral Residual, basée sur des transformées de Fourier, qui met en valeur des éléments “saillants” (salient) de la série temporelle.

Issus du domaine du Deep Learning, les réseaux de neurones à convolution (CNN) ont émergé dans le domaine du traitement d’images en deux dimensions. Pour autant, il est tout-à-fait possible de les utiliser dans le cadre d’une série temporelle à une dimension. Au lieu d’analyser des fragments d’images, la série des données transformées va être reformulée comme plusieurs successions de valeurs.

Ainsi, la série {10, 20, 30, 40, 50, 60} pourra donner des séries comme {10, 20, 30}, {20, 30, 40} ou encore {40, 50, 60} (voir ce très bon article pour aller plus loin dans le code).

Le rôle de la couche de convolution est d’extraire les features (caractéristiques) de la série temporelle. Ce sont elles qui permettront ensuite de décider si une valeur est ou non une anomalie.

D’un point de vue de l’architecture du réseau, la couche de convolution à une dimension est suivi d’une couche “fully connected” qui fait le lien entre le résultat de la convolution et le label de sortie (anomalie ou non).

Allons maintenant à la recherche d’un jeu de données pour expérimenter cette fonctionnalité !

Test sur un jeu de données

Il existe des jeux de données de référence pour évaluer la performance de la détection d’anomalies, et plus spécifiquement dans le cadre des séries temporelles. Vous en trouverez par exemple sur cette page.

Nous travaillerons ici avec un jeu de données de trafic réseau.

Ce dataset contient environ 4,5 millions de lignes.

La détection d’anomalies se déclenche dans le menu Analytique du visuel.

Un seul paramètre est disponible pour régler le niveau de détection, entre 0 et 100% : sensitivity.

Plus la valeur est élevée, plus “l’intervalle de confiance” en dehors duquel sera détectée une anomalie est fin. Autrement dit, plus la valeur approche des 100%, plus vous apercevrez de points mis en évidence. Difficile de dire sur quoi joue ce paramètre d’un point de vue mathématique, il n’est pas évoqué dans le papier de recherche cité précédemment.

En cliquant sur un point, s’ouvre un nouveau volet latéral donnant les valeurs de la plage attendue, reprises également dans l’infobulle.

En plaçant d’autres champs de la table dans la case “explain by“, on peut espérer mettre une évidence un facteur explicatif de cette anomalie.

Attention, il n’est pas envisageable de “zoomer” sur un portion du graphique contenant une anomalie car cela modifiera la plage de données servant à évaluer l’algorithme et fera donc apparaître ou disparaître des points identifiés comme aberrants !

Zoom sur une journée contenant initialement une détection d’anomalies

On pourra plutôt profiter de l’affichage du visuel en tant que table de données qui dispose d’une colonne “anomaly” valant 0 ou 1. On s’aperçoit ici que plusieurs points consécutifs sont identifiés comme des anomalies, ce qui était difficilement identifiable sur le graphique.

En conclusion

Malheureusement, les informations obtenues au travers de ce visuel ne peuvent pas réellement être exploitées : pas d’indicateur créé dans la table, pas d’export au delà de 30000 points (soit un peu plus de 8h pour des données à la seconde), un modèle perpétuellement recalculé et ne pouvant être arrêté sur une période. Alors, que faire lorsque des anomalies apparaissent ? Rien hormis prévenir le propriétaire des données…

Comme pour les autres services touchant (de loin) à l’IA sous Power BI, je suis sceptique quant au moment où cette fonctionnalité est mise en œuvre. La détection d’anomalies est une étape de préparation de la donnée et hormis à effectuer un reporting sur ces anomalies elles-mêmes, nous sommes en droit d’attendre qu’elles soient déjà retirées des données avant exposition. Il serait donc beaucoup plus opportun d’utiliser le service cognitif Azure dans un dataflow (Premium ou maintenant en licence Premium Per User) afin de mettre la donnée en qualité lors de la constitution de donnée. Pour une détection sur un flux de streaming, on se tournera avec intérêt vers les possibilités offertes par Azure Databricks, comme exposé dans ce tutoriel.

A l’inverse, les algorithmes prédictifs qui ne peuvent être utilisés que dans les dataflows seraient beaucoup plus à leur place dans un visuel qui permettrait de tester différents scénarios et d’observer les prévisions associées.

En résumé, les ingrédients de la recette sont les bons, encore faut-il les ajouter dans l’ordre pour obtenir un plat satisfaisant !

L’algorithme choisi (SR-CNN) ne doit pour autant pas être remis en cause car il semble aujourd’hui représenter l’état de l’art de la détection d’anomalies;

Vos remarques sur cet outil peuvent être déposées sur cette page communautaire.