7.6. Anatomie de predict

Model.predict(inputs, *, callback=None) est l’endroit où l’objet modèle chargé travaille réellement. Entre les entrées qui rentrent et le résultat qui ressort, trois étapes s’exécutent en séquence : pré-traitement, répartition vers le moteur, post-traitement. Deux des trois prennent des paramètres que le script contrôle directement ; le moteur au milieu est décidé par la caméra.

Les trois étapes de predict(). Le pré-traitement et le post-traitement prennent des paramètres que le script contrôle ; le moteur au milieu est fixé par la caméra.

7.6.1. Pré-traitement

L’étape de pré-traitement transforme chaque entrée en le tenseur dense que le réseau attend. L’entrée la plus courante est une image.Image, capturée en RGB565. L’étape la recadre et la redimensionne à la input_shape du réseau, convertit de RGB565 vers le format de canaux sur lequel le réseau a été entraîné (RGB888 pour la plupart des réseaux de vision), applique une échelle et un décalage par canal, et – lorsque le réseau attend une entrée entière – quantifie vers le input_dtype du modèle dans la même passe. Les réseaux entraînés pour une entrée flottante sautent l’étape de quantification et reçoivent directement le résultat de l’échelle et du décalage.

La ml.preprocessing.Normalization par défaut lit le dtype d’entrée du modèle et exécute automatiquement la bonne transformation. Une Normalization réglée à la main remplace les valeurs d’échelle, de moyenne et d’écart-type pour les modèles entraînés sur des statistiques de canaux personnalisées (les moyennes et écarts-types dérivés d’ImageNet sont un cas fréquent). Un simple appelable remplace entièrement l’étape – utile lorsque l’entrée n’est pas du tout une image ou lorsque l’application a déjà produit elle-même le tenseur dense.

7.6.2. Répartition vers le moteur

L’étape du moteur exécute le réseau. Le moteur vers lequel elle répartit est fixé par la caméra : le H7 et le RT1062 exécutent TFLM (l’interpréteur TensorFlow Lite for Microcontrollers, répartissant les noyaux CMSIS-NN optimisés pour ARM là où ils existent) ; l’AE3 exécute le même interpréteur TFLM avec son repli Cortex-M55 et le NPU Ethos-U prenant en charge tout opérateur que le compilateur Vela hors ligne a marqué pour l’accélérateur ; le N6 exécute STAI, le runtime de ST pour le NPU dédié du N6.

Le script ne choisit pas le moteur. Le moteur livré avec la caméra exécute tous les modèles que la caméra charge.

7.6.3. Post-traitement

L’étape de post-traitement reconvertit les tenseurs de sortie bruts du réseau en un résultat exploitable. Le comportement par défaut consiste à déquantifier chaque tenseur de sortie en virgule flottante (ou à le laisser passer inchangé pour les réseaux à sorties flottantes) et à les renvoyer sous forme de liste d’objets ndarray. La plupart des applications enregistrent un post-processeur – un appelable qui connaît la disposition de sortie du réseau – pour décoder les tenseurs en la forme de résultat sur laquelle l’application agit : une liste de boîtes englobantes, une liste de points clés, une liste de classes.

Le script contrôle cette étape de deux manières. Le mot-clé postprocess= du constructeur enregistre un post-processeur qui s’exécute à chaque appel. Le mot-clé callback= de predict() remplace le post-processeur enregistré pour un seul appel – utile pour basculer entre plusieurs décodeurs sans recharger le modèle. L’une ou l’autre forme reçoit (model, inputs, outputs) et renvoie ce que l’application attend.

7.6.4. Ce que le script contrôle

Le pré-traitement et le post-traitement sont les deux leviers du script. Le pré-processeur par défaut gère la plupart des modèles de vision ; le bon post-processeur pour une famille de réseaux donnée se choisit dans le catalogue sous ml.postprocessing. Le moteur au milieu est décidé par la compilation et fonctionne de la même manière quoi que demande le script.