Un porting di grandi promesse

Il mio Random Forest raggiungeva il 92% di accuracy su cerchi e croci. 

Sul telefonino, le prime versioni davano predizioni puramente casuali. 
Il problema non era il modello, ma tutto il resto! In Python scrivi  model.predict(X_test) e funziona. 

Su Android devi ricostruire l'intera pipeline da zero. 

Il modello è solo l'ultimo pezzo di un sistema che include acquisizione sensori, preprocessing, feature extraction e normalizzazione. 

Se uno di questi pezzi diverge anche minimamente dal training, il modello vede dati da un'altra distribuzione e le performance crollano.
Ho fatto convertire dall’IA il Random Forest in ONNX, un formato universale per modelli ML. 

La conversione preserva perfettamente gli alberi decisionali, e ONNX Runtime su Android gestisce l'inferenza in modo efficiente, ma questo risolve solo il problema di far girare il modello, non quello di dargli gli input giusti.
Le 122 feature del mio modello includevano statistiche temporali, trasformate di Fourier, correlazioni tra assi e metriche specifiche per distinguere movimenti circolari da lineari. In Python erano venti righe di NumPy e SciPy. In Kotlin l'IA ha dovuto reimplementare anche la DFT, perché Android non fornisce una libreria FFT standard integrata.
Il vero problema era garantire che ogni calcolo producesse esattamente lo stesso risultato. 

La media è facile, ma skewness e kurtosis hanno formule con correzioni per piccoli campioni che devono essere identiche.
L’IA ha tradotto riga per riga lo script Python originale, testando ogni feature individualmente per verificare che i valori combaciassero. Normalizzare le feature non è opzionale, è critico. 

Durante il training, StandardScaler calcola media e deviazione standard di ogni feature e le trasforma in distribuzioni a media zero e varianza uno. Sullo smartphone devi applicare la stessa trasformazione usando gli stessi parametri del training, non ricalcolandoli sui nuovi dati.
Ho esportato i parametri dello scaler in JSON caricandoli negli assets dell'app. Prima dell'inferenza, ogni feature passa attraverso (x - mean)/scale usando i valori del training. Sembra banale ma è fondamentale: usare parametri diversi equivale a dare al modello input completamente sballati.
ONNX Runtime restituisce le probabilità dei classificatori sklearn come dizionari wrapped in strutture custom. Il primo tentativo di parsing restituiva sempre 0.5 per entrambe le classi perché il cast falliva silenziosamente. Ho dovuto usare reflection per accedere ai valori corretti.

Questi bug sono subdoli perché il codice compila e gira, ma semplicemente produce risultati sbagliati!

Anche con tutto corretto, il modello prediceva prevalentemente una sola classe.
La causa probabile: lunghezza delle sequenze: feature statistiche sono sensibili al numero di campioni. 

Se il training usava cento timesteps e l'app ne raccoglie duecento, mean e std cambiano anche con gesti identici. Android campiona i sensori a frequenza variabile, rendendo il matching perfetto quasi impossibile senza controllare esattamente i parametri del training.
Deployment non è conversione di formato. È ricostruzione fedele di una pipeline. Ogni trasformazione applicata ai dati deve essere documentata e riproducibile. StandardScaler, window size, frequenza di campionamento, ordine delle feature: tutti questi dettagli invisibili nel notebook Jupyter diventano critici quando il modello esce dall'ambiente di sviluppo.
ONNX funziona bene per la portabilità del modello, ma non risolve il problema di portabilità della pipeline. La soluzione più robusta è probabilmente addestrare direttamente con dati dallo smartphone target, eliminando le discrepanze alla fonte. Altrimenti ogni step richiede test accurati per verificare la corrispondenza numerica tra ambienti.
Nonostante le difficoltà, vedere il modello rispondere in tempo reale sul proprio dispositivo ha un valore che va oltre i numeri di accuracy.