Come costruire un tool per il tracciamento degli esperimenti [Apprendimenti dagli ingegneri dietro Neptune]

'Costruzione tool tracciamento esperimenti [Apprendimenti dagli ingegneri dietro Neptune]'

Come ingegnere MLOps nel tuo team, spesso ti viene richiesto di migliorare il flusso di lavoro dei tuoi data scientist aggiungendo funzionalità alla tua piattaforma di Machine Learning o creando strumenti autonomi per il loro utilizzo.

Il tracciamento degli esperimenti è una di queste funzionalità. E siccome stai leggendo questo articolo, è probabile che i data scientist che supporti abbiano chiesto il tuo aiuto. Gli esperimenti che eseguono stanno aumentando di scala e diventando sempre più complessi; tenere traccia dei loro esperimenti e assicurarsi che siano riproducibili sta diventando più difficile.

Creare uno strumento per la gestione degli esperimenti può aiutare i tuoi data scientist;

1
Tenere traccia degli esperimenti in diversi progetti,
2
Salvare i metadati relativi agli esperimenti,
3
Riprodurre e confrontare i risultati nel tempo,
4
Condividere i risultati con i membri del team,
5
O inviare gli output degli esperimenti ai sistemi downstream.

Questo articolo è un riassunto di ciò che abbiamo imparato costruendo e mantenendo uno dei tracciatori di esperimenti più popolari degli ultimi cinque anni.

Basandoci sulle esperienze del nostro Piotr Łusakowski (architetto), Adam Nieżurawski (responsabile tecnico del backend) e altri ingegneri di neptune.ai, imparerai:

Come sviluppare i requisiti per il tuo strumento di tracciamento degli esperimenti,
Quali sono i componenti di uno strumento di tracciamento degli esperimenti ideale e come soddisfano i requisiti,
Come progettare il layer di backend di uno strumento di tracciamento degli esperimenti.
Considerazioni tecniche da tenere in considerazione per la costruzione di uno strumento di tracciamento degli esperimenti.

Il focus di questa guida è fornirti i blocchi di costruzione necessari per creare uno strumento che funzioni per il tuo team. Questo articolo non copre le considerazioni tecnologiche per la costruzione di uno strumento di tracciamento degli esperimenti o la scrittura del codice per costruirne uno.

Ci concentreremo sui blocchi di costruzione perché qualsiasi codice scritto non sarebbe importante dopo una settimana e qualsiasi strumento probabilmente sarebbe dimenticato dopo sei mesi.

Sviluppo dei requisiti per uno strumento di tracciamento degli esperimenti

Sul lato dello sviluppo, ci sono tre problemi principali che risolvi quando costruisci uno strumento di tracciamento degli esperimenti, che includono:

Aiutare i tuoi data scientist a gestire i metadati e la genealogia degli artefatti da origini dati e modelli.
Fornire ai tuoi data scientist un’interfaccia per monitorare ed valutare le prestazioni degli esperimenti per prendere decisioni efficaci e risolvere problemi di debug.
Fornire ai tuoi data scientist una piattaforma per monitorare il progresso dei loro progetti di Machine Learning.

Tre motivi per cui è necessario costruire uno strumento di tracciamento degli esperimenti

Gestione dei metadati e genealogia degli artefatti da origini dati e modelli

Uno strumento di tracciamento degli esperimenti può aiutare i tuoi data scientist a tracciare la genealogia degli artefatti degli esperimenti dalle loro origini dati e modelli, a memorizzare i metadati risultanti e a gestirli. Dovrebbe essere possibile individuare da dove provengono i dati e i modelli di un esperimento, in modo che i tuoi data scientist possano esplorare gli eventi dell’esperimento e i processi che li hanno portati.

Ciò permette di ottenere due benefici significativi:

Riproducibilità: Assicurarsi che ogni esperimento eseguito dai tuoi data scientist sia riproducibile.
Spiegabilità: Garantire che possano spiegare i risultati dei loro esperimenti.

Assicurare la riproducibilità dei risultati degli esperimenti

I risultati di un esperimento dovrebbero essere facilmente riproducibili in modo che i tuoi data scientist possano collaborare meglio tra loro e con altre squadre e ottimizzare il flusso di lavoro. La riproducibilità significa eseguire lo stesso codice con la stessa configurazione dell’ambiente e sugli stessi dati per ottenere risultati simili o identici.

Per rendere la riproducibilità possibile, è necessario creare componenti che tengano traccia dei metadati degli esperimenti (come i parametri, i risultati, i file di configurazione, le versioni di modelli e dati, ecc.), dei cambiamenti del codice e della configurazione dell’ambiente di allenamento dei data scientist (o dell’infrastruttura).

Senza tracciabilità end-to-end e senza la tracciatura della genealogia dei dati, è quasi impossibile per i data scientist riprodurre modelli e risolvere errori e pipeline.

I tuoi utenti dovrebbero essere in grado di tracciare le modifiche al codice di sviluppo del modello (codice di elaborazione dati, codice di pipeline, script di utilità, eccetera) che influenzano direttamente come eseguono gli esperimenti e i relativi risultati.

Assicurarsi che i data scientist possano spiegare i risultati degli esperimenti

Quando i data scientist eseguono esperimenti e costruiscono modelli che soddisfano i requisiti di prestazione previsti, devono anche comprendere i risultati per valutare perché il loro modello fa determinate previsioni. Questo, naturalmente, non è vero in tutte le situazioni, ma in circostanze in cui devono capire come e perché il tuo modello fa previsioni, “spiegabilità” diventa cruciale.

Non puoi aggiungere spiegabilità al loro flusso di lavoro se non puoi tracciare da dove provengono i dati dell’esperimento (la loro genealogia), come sono stati elaborati, quali parametri hanno utilizzato per eseguire gli esperimenti e, ovviamente, quali sono stati i risultati di quegli esperimenti.

Uno strumento di tracciamento degli esperimenti dovrebbe consentire ai tuoi data scientist di:

Esaminare gli esperimenti di altre persone e condividere facilmente i propri.
Confrontare il comportamento di qualsiasi esperimento creato.
Tracciare e verificare ogni esperimento per eventuali bias indesiderati e altri problemi.
Debuggare e confrontare gli esperimenti per i quali mancano i dati di addestramento, il codice o i parametri.

La conformità legale è un’altra ragione per cui la spiegabilità è essenziale. Ad esempio, il GDPR richiede alla tua organizzazione di raccogliere e tenere traccia dei metadati sui set di dati e di documentare e segnalare il funzionamento del/i modello/i risultante/i dagli esperimenti.

Monitorare e valutare le prestazioni degli esperimenti per prendere decisioni efficaci

Nella maggior parte dei casi, ha senso confrontare i risultati degli esperimenti effettuati con diverse versioni dei set di dati e dei parametri. Una soluzione di tracciamento degli esperimenti aiuta i tuoi data scientist a misurare l’impatto della modifica dei parametri del modello sugli esperimenti. Vedranno come le prestazioni di un modello cambiano con diverse versioni dei dati.

Certo, ciò sarebbe utile per loro per costruire modelli di apprendimento automatico robusti e ad alte prestazioni. Non possono essere certi che un modello addestrato (o modelli) si generalizzerà a dati non visti senza monitorare e valutare i propri esperimenti. Il team di data science può utilizzare queste informazioni per scegliere il miglior modello, i migliori parametri e le migliori metriche di prestazione.

Tracciare il progresso di un progetto di apprendimento automatico

Utilizzando una soluzione di tracciamento degli esperimenti, il team di data science e altre parti interessate possono verificare il progresso di un progetto e vedere se sta procedendo verso i requisiti di prestazione previsti.

Requisiti funzionali e non funzionali

Sarebbe ridondante dire che per lo sviluppo di un efficace strumento software è necessario dedicare molta attenzione alla definizione dei requisiti. Innanzitutto, dovresti scoprire quali sono i requisiti legati all’attività e all’uso del prodotto. Successivamente, devi specificarli, analizzarli, testarli e gestirli durante tutto il ciclo di sviluppo del software.

La creazione di storie utente, la loro analisi e la convalida dei requisiti sono tutte parti dello sviluppo dei requisiti che meritano un articolo a parte. Questa sezione fornirà una panoramica delle esigenze più importanti funzionali e non funzionali per uno strumento ideale per il tracciamento degli esperimenti.

Comprendere i tuoi utenti

In base alla struttura del team e all’organizzazione aziendale, potresti avere diversi utenti che richiedono uno strumento di tracciamento degli esperimenti. Ma idealmente, i data scientist sarebbero gli utenti del tuo strumento di tracciamento degli esperimenti. A un livello più generale, ecco i compiti che i tuoi data scientist vorrebbero svolgere con uno strumento di tracciamento degli esperimenti:

Vedere l’esecuzione del training del modello in tempo reale: Quando addestrano modelli su server remoti o lontano dal proprio computer, vogliono vedere l’esecuzione del training del modello in tempo reale in modo da poter reagire rapidamente in caso di fallimenti o analizzare i risultati quando sono completati.
Vedere tutti i metadati di addestramento del modello in un unico luogo: Quando lavorano su un progetto in team o da soli, vogliono avere tutti i metadati di costruzione del modello in un unico luogo in modo da poter trovare rapidamente i migliori metadati del modello ogni volta che ne hanno bisogno e avere la certezza che saranno sempre disponibili.
Confrontare le esecuzioni di addestramento del modello: Quando hanno diverse versioni di modelli addestrati, vogliono confrontare i modelli e vedere quali hanno ottenuto le migliori prestazioni, quali parametri hanno funzionato e quali input/output erano diversi.

Requisiti funzionali

Nella sezione precedente, hai appreso i problemi che puoi risolvere con uno strumento di tracciamento degli esperimenti; questi sono anche i compiti da svolgere per costruire uno strumento di tracciamento degli esperimenti funzionale.

Per iniziare a progettare un software di tracciamento degli esperimenti, devi sviluppare requisiti funzionali che rappresentino ciò che uno strumento ideale di tracciamento degli esperimenti dovrebbe fare. Ho categorizzato i requisiti funzionali nella tabella qui sotto, mostrando la necessità in base ai compiti che i tuoi utenti devono svolgere e a come dovrebbe apparire la relativa funzionalità.

Necessità	Funzionalità
Integrazione senza soluzione di continuità con gli strumenti nell’ecosistema.	Integrarsi con i framework di ML che si utilizzano per sperimentazione (addestramento del modello e strumenti per i dati).
	Integrarsi con orchestratori di flusso di lavoro e strumenti CI/CD (se il vostro stack è a questo livello).
Supporto per diversi tipi di dati per il logging dei metadati.	Registrare tipi di dati semplici come interi, float, stringhe, eccetera.
	Registrare tipi di dati complessi come serie di float, stringhe, immagini, file e directory di file.
Consumare i metadati registrati (sia in modo programmabile che tramite interfaccia utente).	Visualizzare un elenco di esecuzioni e dettagli dell’esecuzione, come la versione dei dati su cui è stato addestrato, i parametri del modello, le metriche di performance, gli artefatti, il proprietario, la durata e l’ora di creazione.
	Ordinare e filtrare gli esperimenti per attributi. Ad esempio, potreste voler mostrare solo le esecuzioni addestrate sulla versione X del dataset Y con un’accuratezza superiore a 0,93, raggrupparle per gli utenti che le hanno create e ordinare per tempo di creazione.
	Confrontare diversi esperimenti per vedere come diversi parametri, architetture di modelli e dataset influenzano l’accuratezza del modello, il costo dell’addestramento e l’utilizzo dell’hardware.

Requisiti non funzionali

I requisiti non funzionali per uno strumento di tracciamento degli esperimenti dovrebbero includere:

Qualità	Descrizione
Affidabilità	Non si vuole che lo strumento di tracciamento degli esperimenti faccia esplodere i lavori di addestramento, potrebbe essere costoso e ovviamente dovrebbe essere un punto di rottura.
Performance	Le API e le integrazioni devono avere bassa latenza in modo da non rallentare i lavori di addestramento e i flussi di lavoro di ML (che costano denaro).
Efficienza	L’architettura e le tecnologie dovrebbero essere ottimizzate in termini di costo-efficienza perché gli utenti possono eseguire e tracciare molti esperimenti e i costi possono aumentare rapidamente.
Scalabilità	ML crescerà solo di importanza all’interno della vostra organizzazione. Non si vuole trovarsi in una situazione in cui è necessario riscrivere un sistema a causa di alcuni shortcut presi all’inizio quando solo un data scientist lo stava utilizzando.
Robustezza	È necessario un modello di dati elastico per supportare:Dimensioni e strutture del team variabili (un unico data scientist o magari un team composto da un data scientist, 4 ingegneri di machine learning, 2 ingegneri DevOps, ecc.).Flussi di lavoro variabili in modo che gli utenti possano decidere cosa vogliono tracciare. Alcuni tracceranno solo la fase post-addestramento. Altri vorranno tracciare interi flussi di lavoro di trasformazione dei dati, mentre altri monitoreranno i modelli in produzione.Paesaggio in continua evoluzione – il modello di dati deve essere in grado di supportare ogni nuovo framework e strumento di ML nell’ecosistema. Senza di ciò, le integrazioni potrebbero diventare rapidamente approssimative e non manutenibili.

Requisiti per l’integrazione esterna: L’integrazione dovrebbe essere configurata in modo che il software possa raccogliere metadati sui dataset che gli utenti utilizzeranno per gli esperimenti.

Architettura del sistema di tracciamento degli esperimenti

Un sistema di tracciamento degli esperimenti ideale avrà tre (3) livelli:

1
Frontend/UI.
2
Backend.
3
Libreria client (API / integrazione nell’ecosistema).

Una volta compreso cosa fanno questi componenti e perché ne abbiamo bisogno, sarai in grado di costruire un sistema personalizzato per le tue esigenze di tracciamento degli esperimenti.

Interazioni tra diversi strati del software di tracciamento degli esperimenti

Costruire lo strato frontend del sistema di esperimenti

Lo strato frontend intercetta la maggior parte delle richieste degli utenti e le invia ai server backend per eseguire qualsiasi logica di tracciamento degli esperimenti. Poiché la maggior parte delle tue richieste e risposte deve passare attraverso lo strato frontend, avrà molto traffico e dovrà essere in grado di gestire il più alto livello di concorrenza.

Lo strato frontend è anche il modo in cui puoi visualizzare e interagire con gli esperimenti che esegui. Quali sono le parti più importanti del frontend di un sistema per il tracciamento degli esperimenti?

Visualizzare i metadati degli esperimenti

Molte sperimentazioni in data science riguardano le visualizzazioni, dalla visualizzazione dei dati al monitoraggio in tempo reale dei modelli addestrati e delle loro prestazioni. Lo strato frontend deve essere in grado di visualizzare tutti i tipi di metadati degli esperimenti, dalle semplici stringhe ai quaderni Jupyter incorporati, al codice sorgente, ai video e ai report personalizzati.

Visualizzare centinaia di esecuzioni con i loro attributi

Desideri essere in grado di visualizzare i dettagli degli esperimenti in qualsiasi momento, durante e dopo una esecuzione, inclusi le proprietà correlate e i metadati registrati. Tali metadati includono:

Algoritmi utilizzati.
Metriche di prestazione e risultati.
Durata dell’esperimento.
Insieme di dati di input.
Ora di inizio dell’esperimento.
Identificatore univoco per l’esecuzione.
Altre proprietà che ritieni necessarie.

Dovresti anche essere in grado di confrontare le esecuzioni in base ai loro risultati e potenzialmente tra esperimenti diversi.

Se è essenziale per il tuo caso d’uso, potresti voler aggiungere funzionalità di spiegabilità e attributi al tuo esperimento utilizzando questi attributi. E, naturalmente, potresti anche voler promuovere o scaricare i tuoi modelli da questa visualizzazione.

Tabella delle esecuzioni in neptune.ai | Vedi nell’app

Gestire lo stato e ottimizzare le prestazioni sono due delle parti più complesse nella costruzione del componente UI. Confrontare, ad esempio, dieci esecuzioni con migliaia di attributi ciascuna, molti dei quali devono essere visualizzati su grafici dinamici, può causare molti problemi. Anche i progetti di dimensioni VoAGI possono sperimentare blocchi del browser costanti se vengono effettuati in modo ingenuo.

Oltre alle prestazioni, ci sono altre personalizzazioni dell’UI che ti consentono di mostrare solo un sottoinsieme degli attributi di un progetto, raggruppare le esecuzioni in base a attributi specifici, ordinare in base ad altri, utilizzare un editor di query di filtro con suggerimenti e completamento, e così via.

Backend del sistema

Il backend del sistema supporta la logica della soluzione di tracciamento degli esperimenti. Questo strato è dove si codificano le regole del dominio di tracciamento degli esperimenti e si determina come i dati vengono creati, memorizzati e modificati.

Il frontend è uno dei client per questo strato. Puoi avere altri client, come integrazioni con un registro dei modelli, componenti di monitoraggio della qualità dei dati, ecc. Ciò che sarebbe efficace, come con la maggior parte dei software tradizionali, sarebbe creare servizi in questo strato e nel layer API, che imparerai nella sezione seguente.

Per uno strumento di tracciamento degli esperimenti di base, è necessario implementare due componenti principali del backend del sistema che si desidera costruire:

1
Registro utenti, progetti e spazi di lavoro.
2
Componente di tracciamento effettivo.

Registro utenti, progetti e spazi di lavoro

Questo componente ti aiuta a gestire gli utenti dello strumento di tracciamento degli esperimenti e a tenere traccia delle loro attività con gli esperimenti che eseguono. Le principali cose che questo componente deve fare sono:

Gestire l’autenticazione e l’autorizzazione,
Amministrazione e autorizzazioni del progetto,
Quote (numero di richieste al secondo, quantità di archiviazione) per progetto o spazio di lavoro.

Qual è il livello di dettaglio delle autorizzazioni che desideri implementare? Puoi scegliere tra autorizzazioni specifiche, ruoli personalizzati e ruoli predefiniti grossolani.

Componente di tracciamento

Il componente di tracciamento è la logica effettiva di tracciamento degli esperimenti che devi implementare. Ecco alcune parti che dovresti considerare di implementare:

Archiviazione degli attributi.
Archiviazione di blob e file.
Archiviazione di serie.
Motore di interrogazione.

Archiviazione degli attributi

Le tue esecuzioni hanno attributi (parametri, metriche, campioni di dati, ecc.), e hai bisogno di un modo per associare tali dati alle esecuzioni. Qui entra in gioco l’archiviazione degli attributi e l’organizzazione generale dei dati in una tabella, in modo che le ricerche dei dati siano facili per gli utenti. Naturalmente, in questo caso sarebbe utile un database relazionale.

Qual è il livello di coerenza che desideri? Puoi accettare una coerenza eventuale? Oppure preferiresti una forte coerenza a discapito di una latenza più elevata al livello dell’API?

Archiviazione di blob e file

Alcuni attributi non si adattano facilmente a un campo di database e avresti bisogno di un modello di dati per gestirli. L’archiviazione di blob è una soluzione molto conveniente. Il principale vantaggio è che puoi archiviare una vasta quantità di dati non strutturati. I tuoi utenti potrebbero voler archiviare codice sorgente, campioni di dati (CSV, immagini, DataFrame pickled, ecc.), pesi del modello, file di configurazione, ecc. Questa soluzione è molto utile.

La considerazione chiave da fare qui è la convenienza a lungo termine del servizio di archiviazione e l’accesso a bassa latenza.

Archiviazione di serie

Hai bisogno di determinare un modo per archiviare le serie, in particolare le serie numeriche, che sono attributi che richiedono una particolare attenzione. A seconda del tuo caso d’uso, potrebbero avere decine o milioni di elementi. Potrebbe essere difficile archiviarli in modo che l’utente possa accedere ai dati nell’interfaccia utente. Puoi anche limitare il numero di serie che supporti, ad esempio a 1.000 elementi, che è sufficiente per molti casi d’uso.

Le considerazioni chiave sono:

1
Convenienza a lungo termine dell’archiviazione.
2
Il compromesso tra funzionalità.
3
E relativa semplicità di implementazione.

Motore di interrogazione

Hai anche bisogno di aggiungere la funzionalità di filtrare le esecuzioni con strutture molto diverse, il che significa che hai bisogno di un robusto motore di database che possa gestire questi tipi di interrogazioni. Questo è qualcosa che un semplice database relazionale non può fare in modo efficace quando la quantità di dati non è trascurabile. Un’alternativa è limitare drasticamente il numero di attributi di esperimento che è possibile filtrare o raggruppare. Se scendi a un livello più basso, alcuni trucchi e hack di database saranno sufficienti per lavorare in questo modo.

La considerazione chiave qui è il compromesso tra il numero di attributi che un utente può filtrare, ordinare o raggruppare e la semplicità di implementazione.

Libreria del client (API e integrazione nell’ecosistema)

A livello elevato, il livello dell’API viene utilizzato per proteggere i client dall’essere a conoscenza della struttura, dell’organizzazione o persino del servizio che espone una specifica operazione, il che è molto utile. Non dovrebbe cambiare nulla o eseguire logica come fa il livello del backend. Invece, dovrebbe offrire un’interfaccia proxy standard che espone gli endpoint del servizio e le operazioni dell’API che si configura per esporre.

Quando si costruisce uno strumento di tracciamento degli esperimenti, un’API grezza (nativa) di solito non è sufficiente. Affinché la soluzione sia utilizzabile dagli utenti, è necessario integrarla in modo trasparente con il loro codice. Se si definisce prima il livello dell’API, i client avranno modifiche minime, se del caso, da apportare in risposta alla rifattorizzazione sottostante del codice sorgente, purché il contratto dell’API non cambi.

Ciò significa, nella pratica, che è possibile utilizzare una libreria (preferibilmente Python) per gestire la comunicazione con i server di backend per il logging e l’interrogazione dei dati. Gestisce i tentativi di riprova e di ritardo; probabilmente si desidera implementare una coda persistente e asincrona fin dall’inizio: persistente per garantire la durabilità dei dati e asincrona in modo che non rallenti il processo di addestramento del modello per gli utenti.

Dal momento che lo strumento di tracciamento degli esperimenti dovrà anche lavorare con i tuoi strumenti di dati, addestramento e promozione del modello, tra gli altri, il livello dell’API deve integrarsi con gli strumenti nell’ecosistema ML e dati.

L’ecosistema ML e dati evolve, quindi la creazione di un’integrazione non è la fine. Deve essere testato con le nuove versioni degli strumenti con cui funziona e aggiornato quando le API diventano obsolete o, più spesso, quando cambiano senza preavviso. È anche possibile risolvere questo indirizzando gli utenti alle versioni precedenti dell’integrazione senza obbligarli a apportare modifiche al proprio codice di sperimentazione.

Considerazioni per l’architettura del software di tracciamento degli esperimenti (backend)

Valutare la fattibilità è una parte significativa nella costruzione della struttura del sistema di tracciamento degli esperimenti e nell’valutare se lo stai costruendo correttamente. Ciò significa sviluppare un’architettura ad alto livello basata sui requisiti che hai stabilito.

Il design architetturale dovrebbe mostrare come i livelli e i componenti che hai analizzato dovrebbero integrarsi in un’architettura a strati. Con “architettura a strati” intendo distinguere l’architettura del frontend da quella del backend. Questo articolo si focalizza sulle considerazioni per l’architettura del backend, dove viene codificata la logica per il tracciamento degli esperimenti.

Una volta compresa l’architettura del backend, puoi anche seguire i principi del design orientato al dominio per costruire un’architettura del frontend.

Strato di architettura del backend

Per costruire l’architettura del sistema, segui alcuni principi architetturali del software che aiutano a rendere la struttura il più semplice ed efficiente possibile. Uno di questi principi descrive la modularità. Vuoi che il software sia modulare e ben strutturato in modo da poter comprendere rapidamente il codice sorgente, risparmiare tempo nella costruzione del sistema e ridurre eventualmente il debito tecnico.

Lo strumento per tenere traccia degli esperimenti quasi certamente si evolverà, quindi quando sviluppi la prima architettura, sarà approssimativa e qualcosa che funziona. Poiché la tua architettura cambierà nel tempo, sarà necessario seguire pattern di design coerenti per risparmiare tempo nella manutenzione e nell’aggiunta di nuove funzionalità.

Ecco come appare lo strato di architettura del backend per una soluzione di base per il tracciamento degli esperimenti, tenendo conto dei requisiti e dei componenti elencati in precedenza:

Architettura del backend di uno strumento ideale per il tracciamento degli esperimenti

Utilizzando le parti spiegate in precedenza, è possibile individuare i diversi moduli nell’architettura e vedere come lavorano insieme.

Considerazione architetturale: separare l’autenticazione dall’autorizzazione

Potresti aver notato nell’architettura che l’autenticazione è separata dall’autorizzazione. Poiché potresti avere diversi utenti, vorresti che convalidassero le proprie credenziali attraverso il componente di autenticazione.

Attraverso il componente di autorizzazione, l’amministratore del software può gestire le autorizzazioni e i livelli di accesso per ogni utente. Puoi leggere di più sulla differenza tra autenticazione e autorizzazione in questo articolo.

La parte di gestione delle quote del componente di gestione degli utenti aiuterebbe a gestire il limite di archiviazione disponibile per gli utenti.

Considerazioni da fare prima di costruire uno strumento per il tracciamento degli esperimenti

Per quanto valga, hai imparato a livello più alto cosa serve per costruire un software di tracciamento degli esperimenti. La domanda successiva naturale diventa quindi: “Quali considerazioni devo fare prima di costruire uno strumento per il tracciamento degli esperimenti?”

Bene, forse è una domanda sciocca e non una che faresti se il software strategico della tua organizzazione, l’offerta principale del prodotto, fosse uno strumento per il tracciamento degli esperimenti. Se non lo è, dovresti continuare a leggere!

Probabilmente sei già familiare con il dilemma dello sviluppo del software: costruire o acquistare. Se lo strumento per il tracciamento degli esperimenti è il software operativo della tua organizzazione (per supportare le operazioni regolari dei team di dati e intelligenza artificiale), la considerazione importante successiva da fare per rispondere a questa domanda sarebbe il livello di maturità della tua organizzazione in termini di:

Esperienza,
Talento,
E risorse (tempo e denaro).

Considerazioni nella decisione se costruire o acquistare uno strumento per il tracciamento degli esperimenti

Analizziamo alcune delle domande che dovrai porgerti quando cercherai di prendere questa decisione.

La tua organizzazione ha mai sviluppato uno strumento per il tracciamento degli esperimenti?

Ad esempio, se la tua organizzazione non ha mai sviluppato uno strumento per il tracciamento degli esperimenti, ci vorrà più tempo, tentativi ed errori per adeguarsi agli standard del settore, alle migliori pratiche, alla sicurezza e alla conformità. Se non esiste una “base” su cui costruire, soprattutto dal punto di vista del team di ingegneria, le soluzioni approssimative potrebbero non essere all’altezza degli standard del settore e delle aspettative aziendali.

Tu e gli altri interessati dovete valutare se un’azienda può permettersi tentativi ed errori o se è necessaria una soluzione preconfezionata, efficace, più sicura e affidabile.

Quali talenti sono disponibili per la costruzione?

Se sei un’azienda produttrice di software, c’è la possibilità che tu abbia già sviluppatori software che lavorano sulla tua offerta strategica. Devi considerare il costo opportunità di utilizzare le competenze dei tuoi sviluppatori interni per costruire uno strumento per il tracciamento degli esperimenti invece di utilizzare le loro competenze per migliorare il tuo prodotto principale.

Sviluppare un tracciatore di esperimenti in-house potrebbe migliorare significativamente il tuo prodotto o l’efficienza del flusso di lavoro del tuo team di ML. Tuttavia, potrebbe anche richiedere le competenze e il tempo dei tuoi sviluppatori per costruire altre cose che sarebbero differenziazioni più significative o finire per sprecare tempo ed efforti.

Quanto ci costerebbe costruirlo?

I costi di costruzione di un tracciatore di esperimenti in-house sono principalmente costi di manutenzione. L’organizzazione può sopportare il costo di mantenere il software aggiornato, risolvere bug e aggiungere nuove funzionalità?

Il budget copre l’infrastruttura necessaria per far funzionare lo strumento e assumere nuove persone nel caso in cui gli sviluppatori originali se ne vadano. Pensa agli effetti a lungo termine di un progetto di sviluppo software costoso e che richiede tempo, non solo ai risparmi a breve termine.

Una grande parte della riduzione dei costi di manutenzione consiste nel ridurre la possibilità di spese elevate e impreviste che si presentano tutte in una volta sola. In altre parole, come con i costi di manutenzione in generale, il momento migliore per gestire il rischio è all’inizio del ciclo di vita del software quando si determina se qualcosa deve essere costruito o esternalizzato.

Quanto tempo ci vorrebbe per costruire lo strumento di tracciamento degli esperimenti?

Devi considerare i costi opportunità. Ad esempio, se ci vogliono due mesi per creare uno strumento personalizzato, cosa altro sarai in grado di costruire in quel tempo? Ci vorrebbe più tempo di due mesi per implementare il componente di tracciamento? Quanti cicli di sviluppo ci vorrebbero per costruire lo strumento da un POC a una versione finale e stabile?

Se fai parte di un’azienda più grande e hai abbastanza cicli di sviluppo per costruire un tracciatore di esperimenti, potrebbe non essere un problema. E quando non lo è, in particolare un problema unico al tuo caso d’uso? Ottenere una soluzione preconfezionata che si integra con il tuo stack in modo da poterti concentrare sulla costruzione del tuo software strategico potrebbe funzionare meglio.

È improbabile che tu abbia abbastanza cicli per raggiungere il livello di sofisticazione e ricchezza di funzionalità di cui hai bisogno da uno strumento di gestione degli esperimenti standard, quindi potrebbe non valere la pena dedicare i tuoi cicli di sviluppo ad esso.

Ad esempio, su neptune.ai, abbiamo dedicato gli ultimi cinque anni a concentrarci esclusivamente sulla costruzione di un robusto archivio dei metadati per gestire tutti i metadati relativi alla costruzione dei modelli per i tuoi utenti e tracciare i loro esperimenti. Abbiamo imparato dai clienti e dalla comunità di ML e migliorato continuamente il prodotto per essere robusto in diversi casi d’uso e carichi di lavoro.

Codifica più veloce a scapito del design e dell’architettura è quasi sempre la scelta sbagliata. Questo è particolarmente vero se il software è operativo perché hai meno tempo per concentrarti su una buona architettura e costruire le funzionalità che deve avere. Dopotutto, non è un software strategico che influisce direttamente o definisce la tua organizzazione.

Pensieri finali

Abbiamo coperto parecchio in questo articolo; facciamo un breve riepilogo di alcuni punti chiave:

Il tracciamento degli esperimenti è un’attività intensa. Utilizzare gli strumenti giusti e l’automazione lo rende user-friendly ed efficiente.
Sviluppare requisiti efficaci per uno strumento di tracciamento degli esperimenti dovrebbe richiedere: considerare quali utenti utilizzeranno il software e come si integrerà con il tuo stack di dati e i tuoi servizi downstream. Fondamentalmente, pensare ai requisiti minimi necessari per iniziare – senza coinvolgere la sofisticazione.
Il layer backend del software di tracciamento degli esperimenti è il layer più essenziale da implementare. Devi assicurarti di implementare il componente di tracciamento e il registro dello spazio di lavoro per gestire le sessioni degli utenti in modo fluido.

Il tuo obiettivo per la costruzione di un tracciatore di esperimenti è assicurarti di fornire il componente per i tuoi utenti per registrare i dati degli esperimenti, tracciare quegli esperimenti e collaborare su di essi in modo sicuro. Se riescono a farlo con poco o nessun onere, allora hai probabilmente costruito ciò che funziona per il tuo team.

Nella maggior parte dei casi, vediamo che la costruzione della prima versione è solo il primo passo – specialmente se non è un componente software principale per la tua organizzazione. Potresti trovare difficile aggiungere nuove funzionalità man mano che aumenta l’elenco dei requisiti degli utenti a causa di nuovi problemi.

Tu e gli stakeholder pertinenti coinvolti dovreste considerare il valore di dedicare risorse per stare al passo con le esigenze dei tuoi utenti e, potenzialmente, gli standard del settore.

Prossimi passi

Quindi, da dove vai da qui? Sei entusiasta di costruire? O pensi che una soluzione preconfezionata possa fare al caso tuo?

La maggior parte delle piattaforme di registro dei modelli che abbiamo considerato assumeva una forma specifica per archiviare i modelli. Questa assumeva la forma di esperimenti – ogni modello era quello successivo in una serie. Nel caso di Stitch Fix, i nostri modelli non seguono un pattern di targeting lineare.

Potrebbero essere applicabili a regioni specifiche, linee di business, esperimenti, ecc. e tutti essere in qualche modo interscambiabili tra loro. La gestione facile di queste dimensioni era fondamentale per come i data scientist avevano bisogno di accedere ai loro modelli.

– Elijah Ben Izzy e Stefan Krawczyk in Deployment for Free;
A Machine Learning Platform for Stitch Fix’s Data Scientists

Questo era Stefan Krawczyk che parlava del motivo per cui hanno deciso di costruire un registro dei modelli invece di utilizzare soluzioni esistenti. Nello stesso contesto, a meno che non si abbiano requisiti utente speciali che le soluzioni open source o a pagamento esistenti non soddisfano, costruire e mantenere uno strumento di tracciamento degli esperimenti potrebbe non essere l’uso più efficiente del tempo e dello sforzo dello sviluppatore.

Desideri approfondire o semplicemente parlare della costruzione di un tracciatore di esperimenti? Contattaci; saremmo lieti di scambiare esperienze.

Naturalmente, se decidi di saltare la fase di costruzione e utilizzare invece Neptune, sentiti libero di iscriverti e provarlo per primo. Mettiti in contatto con noi se hai domande!

Riferimenti e risorse

Sviluppo di modelli di apprendimento automatico esplicabili e riproducibili con DALEX e Neptune – neptune.ai
Dovresti comprare o costruire il software? – YouTube

ML Experiment Tracking