7.6. Anatomia di predict

Model.predict(inputs, *, callback=None) è il punto in cui l’oggetto modello caricato svolge effettivamente il lavoro. Tra gli input che entrano e il risultato che esce, si susseguono in sequenza tre fasi: pre-elaborazione, dispatch del motore, post-elaborazione. Due delle tre accettano parametri che lo script controlla direttamente; il motore al centro è deciso dalla camera.

Le tre fasi di predict(). La pre-elaborazione e la post-elaborazione accettano parametri controllati dallo script; il motore al centro è fissato dalla camera.

7.6.1. Pre-elaborazione

La fase di pre-elaborazione trasforma ogni input nel tensore denso che la rete si aspetta. L’input più comune è un image.Image, catturato in RGB565. La fase lo ritaglia e lo ridimensiona alla input_shape della rete, lo converte da RGB565 al formato di canale su cui la rete è stata addestrata (RGB888 per la maggior parte delle reti di visione), applica scala e offset per canale e – quando la rete si aspetta input intero – lo quantizza al input_dtype del modello nella stessa passata. Le reti addestrate per input float saltano la fase di quantizzazione e ricevono direttamente il risultato di scala e offset.

Il ml.preprocessing.Normalization predefinito legge il dtype di input del modello ed esegue automaticamente la trasformazione corretta. Un Normalization regolato manualmente sovrascrive i valori di scala, media e deviazione standard per i modelli addestrati su statistiche di canale personalizzate (le medie e le deviazioni standard derivate da ImageNet sono un caso comune). Un semplice oggetto invocabile sovrascrive interamente la fase – utile quando l’input non è affatto un’immagine o quando l’applicazione ha già prodotto da sé il tensore denso.

7.6.2. Dispatch del motore

La fase del motore esegue la rete. A quale motore viene effettuato il dispatch è fissato dalla camera: l’H7 e l’RT1062 eseguono TFLM (l’interprete TensorFlow Lite for Microcontrollers, che effettua il dispatch verso i kernel CMSIS-NN ottimizzati per ARM dove esistono); l’AE3 esegue lo stesso interprete TFLM con il suo fallback Cortex-M55 e l’NPU Ethos-U che gestisce qualsiasi operatore che il compilatore offline Vela ha contrassegnato per l’acceleratore; l’N6 esegue STAI, il runtime di ST per l’NPU appositamente progettata dell’N6.

Lo script non sceglie il motore. Il motore fornito insieme alla camera esegue ogni modello che la camera carica.

7.6.3. Post-elaborazione

La fase di post-elaborazione trasforma i tensori di output grezzi della rete di nuovo in un risultato utilizzabile. Il comportamento predefinito è dequantizzare ogni tensore di output in virgola mobile (oppure lasciarlo passare invariato per le reti con output float) e restituirli come elenco di oggetti ndarray. La maggior parte delle applicazioni registra un post-processor – un oggetto invocabile che conosce il layout di output della rete – per decodificare i tensori nella forma di risultato su cui l’applicazione agisce: un elenco di bounding box, un elenco di keypoint, un elenco di classi.

Lo script controlla questa fase in due modi. La parola chiave postprocess= sul costruttore registra un post-processor che viene eseguito a ogni chiamata. La parola chiave callback= su predict() sovrascrive il post-processor registrato per una sola chiamata – utile per passare da un decodificatore all’altro senza ricaricare il modello. Entrambe le forme ricevono (model, inputs, outputs) e restituiscono ciò che l’applicazione si aspetta.

7.6.4. Cosa controlla lo script

La pre-elaborazione e la post-elaborazione sono le due leve dello script. Il pre-processor predefinito gestisce la maggior parte dei modelli di visione; il post-processor corretto per una determinata famiglia di reti viene scelto dal catalogo in ml.postprocessing. Il motore al centro è deciso dalla build e funziona allo stesso modo indipendentemente da ciò che lo script richiede.