Blog.

TensorFlow Extended (TFX) | Production Machine Learning Pipeline


Autore
Andrea Provino
Data
Tempo di lettura
6 minuti
Categoria
machine-learning

tensorflow-extended-tfx-deploy-machine-learning-guide-machine-learning-pipelines

TensorFlow Extended (TFX) è una piattaforma end-to-end (i.e. Completa di software e hardware) per il rilascio (deploy) in produzione di ML pipeline. L’idea di TensorFlow Extended (TFX) è quindi quella di fornirti una soluzione per passare dalla sperimentazione, o ricerca, alla gestione di una production pipeine in modo agevole.

In questo post ho raccolto per te alcune indicazioni sull’utilizzo di TensorFlow Extended TFX per farti risparmiare tempo, evitando la lettura di noiose documentazioni.

In pratica, ho fatto il lavoro di ricerca al tuo posto!

Chiaramente ho configurato il post in modo che possa essere letto anche da chi non ha alcuna esperienza o conoscenza pregressa.

Hai comunque la piena libertà di saltare da un paragrafo all’altro: ho cercato di gestirli come piccoli compartimenti stagni in modo che la comprensione dell’uno non richieda la lettura degli altri.

In questo modo dovresti guadagnare tempo e trovare rapidamente risposta alle tue domande.

Infine, non considerare le ripetizioni in inglese e italiano di alcuni termini, o la specificazione del loro significato: so che molti suonano a te familiari, ma le strategie di ottimizzazione SEO richiedono questi stratagemmi.

Iniziamo!

Cos’è TensorFlow Extended (TFX)?

TFX è una piattaforma per la creazione e l’hosting di Machine Learning Pipelines che fornisce:

  • un toolkit per la creazione delle pipeline, con cui orchestrare i workflow su diverse piattaforme (e.g Apache Airflow, Apache Beam, KubeFlow Pipelines)
  • standard components per assemblare le pipeline, o come parte di uno script di training per il modello.
  • libraries per le funzionalità base di molti componenti. Le librerie possono essere usate per estendere le funzionalità attraverso custom components, o per usarle in modo separato.

Partorito negli uffici Google, e oggi da loro impiegato in quasi ogni modello di produzione.

Questo perché TFX è un machine learning toolkit basato su Tensorflow, con cui definire, rilasciare e monitorare un sistema di machine learning.

La preparazione delle pipeline per la pulizia dei dati, l’allenamento del modello e il rilascio in produzione si base sulla configurazione del framework.

TFX è poi un sistema modulare, flessibile e collaborativo volto ad agevolare tutte quelle operazioni complesse e tediose legate al rilascio di un modello in produzione.

Partiamo da una considerazione fondamentale che legittima l’esistenza di TensorFlow Extended (TFX).

Secondo una ricerca di DeepLearning.ai, solamente il 22% delle aziende che lavorano con tecnologie di machine learning ha rilasciato sistemi in produzione.

Il tuo progetto di Machine Learning, che vorresti abbia vita longeva, potrebbe diventare un vero incubo senza un efficace ambiente di produzione che ne permetta l’affidabile funzionamento.

Un incubo che in termini economici potremmo rappresentare come una grave perdita e che ha origine nella gestione di MLOps e nella riduzione del debito tecnico.

Cosa sono le MLOps?

Le MLOps sono un insieme di attività con l’obiettivo di rilasciare e gestire un sistema di Machine Learning in produzione in modo affidabile ed efficiente. Possiamo intenderle come l’intersezione di:

  • DevOps
  • Data Engineering
  • Machine Learning

La soluzione proposta da Google per agevolare il MLOps è allora TensorFlow Extended (TFX), uno strumento per rilasciare in produzioni robusti e trasparenti (i.e. Interpretabili) sistemi di Machine Learning.

Usato correttamente, Tensorflow Extended (TFX) consente di raggiungere prestazioni all’avanguardia riducendo il debito tecnico delle MLOps.

Ti spiego ora cosa intendo per debito tecnico.

Machine Learning Technical Debt | TLDR

Ho raccolto per te 3 grandi considerazioni sul debito tecnico collegato al rilascio in produzione di un sistema di Machine Learning.

Orchestrazione dei componenti (e versioni) del modello

Tra i compiti più complessi di un Machine Learning Engineer vi è il tener traccia e la gestione dei componenti e versioni del modello.

Ogni stadio di MLOps (sampling, training, evaluation e serving) richiede una sua profonda considerazione.

Devi poi ricordare una cosa fondamentale.

La complessità aumenta quando i dati cambiano nel tempo.

L’aggiornamento dei modelli, se eseguito con poco ordine e visione di lungo termine, crea presto un debito tecnico difficilmente recuperabile che riduce la vita del progetto, e certamente la sua manutenibilità.

La creazione di custom script e glue code per “hotfix problema x” può funzionare per mettere il sorriso al cliente il giorno A ma verosimilmente è una valvola del gas aperta, pronta a far esplodere tutto il giorno B.

Stiamo creando un codice fragile, ricco di ridondanze, che complica inutilmente implementazioni future.

Per un’azienda di piccole dimensioni, o una startup, questo si traduce in un bagno di sangue che crea friction nella creazione di business value.

Abbiamo bisogno di un sistema che tracci le modifiche, e ci permetta un agile rollback se necessario, in modo da creare una pipeline robusta e affidabile, oggi come domani.

Chiaramente, non può mancare la necessità di evitare a tutti costi interruzioni di sistema (system outage): dobbiamo anche considerare i necessari fallback per i casi peggiori (worst case scenario).

Cambiamenti veloci e controllati per soddisfare le esigenze di business

Senti la tranquillità nell’aria?

Il Project Manager deve essere in ferie.

Poco dopo, la pace è interrotta dal brusio di una discussione su una funzionalità apparentemente inutile che complica quel tuo perfetto ambiente che eri riuscito a creare.

Aspri sorrisi a parte, gli sforzi dei Machine Learning Engineers sono critici per il business.

A volte è difficile, ma dobbiamo ricordare che ogni nostra azione è finalizzata a produrre valore in mondo di continui cambiamenti.

Un’evoluzione inarrestabile che si traduce in piccoli cambiamenti che devono essere implementati rapidamente.

Questo richiede un sistema trasparente, che tenga traccia con ordine dei cambiamenti sul codice e sul risultato dei modelli.

Non è un compito semplice: persino Amazon fallì, con il suo sistema di dynamic pricing che produsse sconti folli, e prezzi senza senso durante uno dei suoi Prime Days.

In quel caso i fattori di evoluzione erano:

  • nuove promozioni
  • prezzi base e limite (price flooring / ceiling)
  • competizione tra merchants

Più in generale i diversi fattori esterni possono richiedere complesse modifiche ai sistemi, causando bug dagli risultati spiacevoli.

Ogni modifica costituisce un livello di complessità aggiuntivo: così tenerne traccia è fondamentale e necessario.

Metriche: Business KPI

Ogni progetto è finalizzato a un ritorno d’investimento (ROI).

In quest’ottica è chiara l’esigenza di un opportuno sistema di monitoraggio per garantire il raggiungimento delle KPI definite in fase iniziale di progettazione.

Tutt’al più è bene che il nostro sistema non causi perdite nascoste dietro black boxes e risultati ambigui.

L’ideale sarebbe quindi avere una dashboard che mostri le perfomance del modello su dati reali.

La parola chiave qui è integration testing.

Google, ad esempio, ha sempre tre ambienti con relativi modelli di:

  • sperimentazione o testing (experimentation), con mock tests per la validazione
  • debugging, per valutare le prestazioni del modello con traffico limitato ed effettuare il fine tuning del modello.
  • produzione (production), in cui monitoriamo le richieste di business (precision, recall, risultati economici) e le metriche di produzione (latenza, scalabilità e affidabilità)

I test e la valutazione delle performance sono elementi critici fondamentali per assicurare sistemi di Machine Learning di produzione affidabili e di altà qualità.

Parliamoci francamente: è improbabile avere degli ambienti come Google, per’altro nelle realtà italiane che già difficilmente comprendono cosa significhi applicare un modello di Machine Learning.

Possiamo comunque trarre ispirazione, e gettare le basi per quello che speriamo essere un progetto di lungo termine!

Benissimo!

Come si collega tutto questo discorso con Tensorflow Extended (TFX)?

Nel prossimo post ti spiego come funziona TensorFlow Extended.

TensorFlow Extended Dependencies 

Tensorflow Extended ha 5 librerie principali. Potrebbe tornare utile ricordare i loro nomi, dato che nella documentazione è tutto abbreviato…

  1. TensorFlow Model Analysis (TFMA)
  2. TensoFlow Data Validation (TFDV)
  3. TensorFlow Transform (TFT)
  4. TFX Basic Shared Libraries (TFX-BSL)
  5. ML Metadata (MLMD)

Non ti preoccupare molto, li ho lasciati qui solo come riferimento.

Nel prossimo post, quello in cui ti spiego come funziona TFX, analizziamo nello specifico ciascuna libreria.

In ultima analisi, ti lascio a questo breve video di presentazione:

Per il momento è tutto.

Per aspera, ad astra.

Un caldo abbraccio, Andrea

https://andreaprovino.it/tensorflow-extended-tfx/(si apre in una nuova scheda)

Taggedmachine learningMachine Learning in productiontensorflow


Ultimi post

Patricia Merkle Trie

Il Practical Algorithm To Retrieve Information Coded In Alphanumeric Merkle Trie, o Patricia Merkle Trie è una struttura dati chiave-valore usatada Ethereum e particolarmente efficiente per il salvataggio e la verifica dell’integrità dell’informazione. In questo post ne studieremo le caratteristiche. Prima di procedere, ci conviene ripassare l’introduzione al Merkle Tree nella quale abbiamo chiarito il […]

Andrea Provino
ethereum-patricia-merkle-tree
Tree Data Structure: cos’è un Merkle Tree

Un Merkle Tree è una struttura dati efficiente per verificare che un dato appartenga a un insieme esteso di elementi. È comunemente impiegato nelle Peer to Peer network in cui la generazione efficiente di prove (proof) contribuisce alla scalabilità della rete. Capire i vantaggi di questa struttura ci tornerà utile nel nostro percorso di esplorazione […]

Andrea Provino
merkle-tree-cover
UTXO: come funziona il modello Unspent Transaction Outputs

Per tenere traccia dei bilanci utente, la blockchain di Bitcoin sfrutta un modello di contabilità definito UTXO o Unspent Transaction Outputs. In questo articolo ne esaminiamo le caratteristiche. Ogni blockchain è dotata di un sistema di contabilità, un meccanismo attraverso cui tenere traccia dei bilanci di ciascun utente. I due grandi modelli di riferimento nel […]

Andrea Provino
bitcoin-utxo
Cos’è Ethereum

Possiamo definire Ethereum come una macchina a stati distribuita che traccia le transizioni di un archivio dati general-purpose (i.e. una memoria in grado di registrare qualsiasi dato esprimibile come coppia di chiave e valore o key-value) all’interno della Ethereum Blockchain. È arrivato il momento di esplorare uno dei progetti tecnologici più innovativi e interessanti degli […]

Andrea Provino
ethereum