Questo post è co-autore con Jan Paul Assendorp, Thomas Lietzow, Christopher Masch, Alexander Meinert, Dr. Lars Palzer, Jan Schillemans di SIGNAL IDUNA.
In SIGNAL IDUNA, un grande assicuratore tedesco, ci stiamo attualmente reinventando con il nostro programma di trasformazione VISION2023 per diventare ancora più orientati al cliente. Due aspetti sono centrali in questa trasformazione: la riorganizzazione di ampie parti della forza lavoro in team agili e interfunzionali e diventare un'azienda realmente basata sui dati. Qui, il motto "Lo costruisci, lo esegui" è un requisito importante per un team interfunzionale che crea un prodotto di dati o di machine learning (ML). Ciò pone stretti vincoli su quanto il team di lavoro può spendere per produrre e gestire un prodotto.
Questo post mostra come SIGNAL IDUNA affronta questa sfida e utilizza il AWS Cloud per consentire ai team interfunzionali di creare e rendere operativi i propri prodotti ML. A tal fine, introduciamo innanzitutto la struttura organizzativa dei team agili, che stabilisce i requisiti centrali per l'infrastruttura cloud utilizzata per sviluppare ed eseguire un prodotto. Successivamente, mostriamo come tre team centrali di SIGNAL IDUNA consentono ai team interfunzionali di creare prodotti di dati nel cloud AWS con un'assistenza minima, fornendo un flusso di lavoro adeguato e soluzioni infrastrutturali che possono essere facilmente utilizzate e adattate. Infine, esaminiamo il nostro approccio e lo confrontiamo con un approccio più classico in cui sviluppo e funzionamento sono separati in modo più rigoroso.
Agile@SI – la Fondazione del Cambiamento Organizzativo
Dall'inizio del 2021, SIGNAL IDUNA ha iniziato a mettere in atto la sua strategia Agile@SI e a stabilire metodi agili per lo sviluppo di soluzioni orientate al cliente in tutta l'azienda [1]. I compiti e gli obiettivi precedenti sono ora svolti da team interfunzionali, chiamati squadre. Queste squadre utilizzano metodi agili (come il framework Scrum), prendono le proprie decisioni e creano prodotti orientati al cliente. In genere, le squadre si trovano in divisioni aziendali, come il marketing, e molte hanno una forte enfasi sulla creazione di prodotti basati sui dati e basati su ML. Ad esempio, i casi d'uso tipici nel settore assicurativo sono la previsione dell'abbandono dei clienti e la raccomandazione del prodotto.
A causa della complessità del ML, la creazione di una soluzione ML da parte di una singola squadra è impegnativa e pertanto richiede la collaborazione di squadre diverse.
SIGNAL IDUNA ha tre team essenziali che supportano la creazione di soluzioni ML. Circondato da queste tre squadre c'è il team responsabile dello sviluppo e delle operazioni a lungo termine e della soluzione ML. Questo approccio segue il modello di responsabilità condivisa di AWS [2].
Nell'immagine sopra, tutte le squadre sono rappresentate in una panoramica.
Abilitazione al cloud
L'infrastruttura cloud sottostante per l'intera organizzazione è fornita dalla squadra Cloud Enablement. È loro compito consentire ai team di creare autonomamente prodotti su tecnologie cloud. Ciò migliora il tempo di commercializzazione costruendo nuovi prodotti come ML e segue il principio "Lo costruisci, lo gestisci".
Ufficio dati/Data Lake
Lo spostamento dei dati nel cloud, oltre a trovare il set di dati corretto, è supportato dalla squadra Data Office/Data Lake. Hanno impostato un catalogo di dati che può essere utilizzato per cercare e selezionare i set di dati richiesti. Il loro scopo è stabilire la trasparenza e la governance dei dati. Inoltre, sono responsabili della creazione e della gestione di un Data Lake che aiuti i team ad accedere ed elaborare i dati rilevanti.
Piattaforma di analisi dei dati
La nostra squadra Data Analytics Platform (DAP) è un team focalizzato su cloud e ML presso SIGNAL IDUNA che è esperto in ingegneria ML, ingegneria dei dati e scienza dei dati. Consentiamo ai team interni di utilizzare il cloud pubblico per il machine learning fornendo componenti e conoscenze dell'infrastruttura. I nostri prodotti e servizi sono presentati in dettaglio nella sezione seguente.
Consentire ai team interfunzionali di creare soluzioni ML
Per consentire ai team interfunzionali di SIGNAL IDUNA di creare soluzioni ML, abbiamo bisogno di un modo rapido e versatile per fornire un'infrastruttura cloud riutilizzabile, nonché un flusso di lavoro efficiente per consentire ai team di onboarding di utilizzare le funzionalità cloud.
A tal fine, abbiamo creato un processo di onboarding e supporto standardizzato e fornito modelli di infrastruttura modulari come Infrastructure as Code (IaC). Questi modelli contengono componenti dell'infrastruttura progettati per casi d'uso comuni di ML che possono essere facilmente adattati ai requisiti di un caso d'uso specifico.
Il flusso di lavoro della creazione di soluzioni ML
Esistono tre ruoli tecnici principali coinvolti nella creazione e nel funzionamento di soluzioni ML: il data scientist, l'ingegnere ML e un ingegnere dei dati. Ogni ruolo fa parte della squadra interfunzionale e ha responsabilità diverse. Il data scientist ha la conoscenza di dominio richiesta dei requisiti funzionali e tecnici del caso d'uso. L'ingegnere ML è specializzato nella creazione di soluzioni ML automatizzate e nella distribuzione di modelli. E l'ingegnere dei dati si assicura che i dati fluiscano da locale e all'interno del cloud.
Il processo di fornitura della piattaforma è il seguente:
L'infrastruttura del caso d'uso specifico è definita in IaC e sottoposta a versionamento in un repository centrale del progetto. Ciò include anche pipeline per l'addestramento e la distribuzione del modello, nonché altri artefatti del codice relativi alla scienza dei dati. Data scientist, ingegneri ML e ingegneri dei dati hanno accesso al repository del progetto e possono configurare e aggiornare tutto il codice dell'infrastruttura in modo autonomo. Ciò consente al team di modificare rapidamente l'infrastruttura, se necessario. Tuttavia, l'ingegnere ML può sempre supportare lo sviluppo e l'aggiornamento dell'infrastruttura o dei modelli ML.
Componenti dell'infrastruttura riutilizzabili e modulari
Le risorse IaC gerarchiche e modulari sono implementate in Terraform e include l'infrastruttura per la scienza dei dati comune e i casi d'uso ETL. Questo ci consente di riutilizzare il codice dell'infrastruttura e di applicare le policy di sicurezza e conformità richieste, come l'utilizzo Servizio di gestione delle chiavi AWS (KMS) crittografia per i dati, nonché incapsulamento dell'infrastruttura in Cloud privato virtuale Amazon (VPC) ambienti privi di accesso diretto a Internet.
La struttura gerarchica IaC è la seguente:
- moduli incapsula i servizi AWS di base con la configurazione richiesta per la sicurezza e la gestione degli accessi. Ciò include le configurazioni delle migliori pratiche come la prevenzione dell'accesso pubblico a Servizio di archiviazione semplice Amazon (S3) bucket o applicando la crittografia per tutti i file archiviati.
- In alcuni casi, è necessaria una varietà di servizi per automatizzare i processi, ad esempio per distribuire modelli ML in fasi diverse. Pertanto, abbiamo definito Soluzioni come un insieme di diversi moduli in una configurazione congiunta per diversi tipi di attività.
- Inoltre, offriamo completo Progetti che combinano soluzioni in ambienti diversi per soddisfare le molteplici esigenze potenziali di un progetto. Nel nostro progetto MLOps, definiamo un'infrastruttura distribuibile per la formazione, il provisioning e il monitoraggio dei modelli ML integrati e distribuiti negli account AWS. Discutiamo ulteriori dettagli nella prossima sezione.
Questi prodotti hanno la versione in un repository centrale dalla squadra DAP. Questo ci consente di migliorare continuamente il nostro IaC e prendere in considerazione le nuove funzionalità di AWS, come Amazon Sage Maker Registro modello. Ogni squadra può fare riferimento a queste risorse, parametrizzarle secondo necessità e infine distribuirle nei propri account AWS.
Architettura MLOps
Forniamo un progetto pronto all'uso con soluzioni specifiche per coprire l'intero processo MLOps. Il progetto contiene un'infrastruttura distribuita su quattro account AWS per la creazione e la distribuzione di modelli ML. Questo ci consente di isolare risorse e flussi di lavoro per i diversi passaggi del processo MLOps. La figura seguente mostra l'architettura multi-account e descriviamo come la responsabilità su fasi specifiche del processo sia suddivisa tra i diversi ruoli tecnici.
I modellismo account include servizi per lo sviluppo di modelli ML. In primo luogo, l'ingegnere dei dati utilizza un processo ETL per fornire dati rilevanti dal data lake SIGNAL IDUNA, il gateway centralizzato per i flussi di lavoro basati sui dati nel cloud AWS. Successivamente, il set di dati può essere utilizzato dal data scientist per addestrare e valutare i candidati modello. Una volta pronto per esperimenti estesi, un modello candidato viene integrato in una pipeline di formazione automatizzata dall'ingegnere ML. Utilizziamo Amazon SageMaker Pipelines per automatizzare la formazione, l'ottimizzazione degli iperparametri e la valutazione del modello su larga scala. Ciò include anche il lignaggio del modello e un meccanismo di approvazione standardizzato per i modelli da mettere in scena per l'implementazione in produzione. Gli unit test automatizzati e l'analisi del codice garantiscono la qualità e l'affidabilità del codice per ogni fase della pipeline, come la preelaborazione dei dati, l'addestramento del modello e la valutazione. Una volta che un modello è stato valutato e approvato, utilizziamo Amazon SageMaker ModelPackages come interfaccia per il modello addestrato e i metadati pertinenti.
I utensili account contiene pipeline CI/CD automatizzate con diverse fasi per il test e la distribuzione di modelli addestrati. Nella fase di test, i modelli vengono distribuiti nel servire-non prod account. Sebbene la qualità del modello venga valutata nella pipeline di addestramento prima che il modello venga messo in scena per la produzione, qui eseguiamo test di prestazioni e integrazione in un ambiente di test isolato. Dopo aver superato la fase di test, i modelli vengono distribuiti nel serve-prod conto da integrare nei flussi di lavoro di produzione.
Separare le fasi del flusso di lavoro MLOps in diversi account AWS ci consente di isolare lo sviluppo e il test dalla produzione. Pertanto, possiamo applicare una rigorosa politica di accesso e sicurezza. Inoltre, i ruoli IAM personalizzati assicurano che servizi specifici possano accedere solo ai dati e ad altri servizi richiesti per il suo ambito, a seguito del principio di minimo privilegio. I servizi all'interno degli ambienti di servizio possono inoltre essere resi accessibili ai processi aziendali esterni. Ad esempio, un processo aziendale può interrogare un endpoint all'interno dell'ambiente serving-prod per le previsioni del modello.
Vantaggi del nostro approccio
Questo processo presenta molti vantaggi rispetto a una rigida separazione tra sviluppo e funzionamento sia per i modelli ML, sia per l'infrastruttura richiesta:
- Isolamento: ogni team riceve il proprio set di account AWS completamente isolati dagli ambienti degli altri team. Ciò semplifica la gestione dei diritti di accesso e la riservatezza dei dati per coloro che sono autorizzati a lavorarci.
- Abilitazione cloud: I membri del team con poca esperienza precedente nel cloud DevOps (come molti data scientist) possono facilmente osservare l'intero processo di progettazione e gestione dell'infrastruttura poiché (quasi) nulla è loro nascosto dietro un servizio centrale. Ciò crea una migliore comprensione dell'infrastruttura, che a sua volta può aiutarli a creare prodotti di data science in modo più efficiente.
- Proprietà del prodotto: L'utilizzo di soluzioni infrastrutturali preconfigurate e servizi gestiti mantiene molto basse le barriere alla gestione di un prodotto ML in produzione. Pertanto, un data scientist può facilmente assumere la proprietà di un modello che viene messo in produzione. Ciò riduce al minimo il noto rischio di non riuscire a mettere in produzione un modello dopo lo sviluppo.
- Innovazione: poiché gli ingegneri ML vengono coinvolti molto prima che un modello sia pronto per essere messo in produzione, possono creare soluzioni infrastrutturali adatte a nuovi casi d'uso mentre i data scientist sviluppano un modello ML.
- Adattabilità: Poiché le soluzioni IaC sviluppate da DAP sono disponibili gratuitamente, qualsiasi team può adattarle facilmente per soddisfare un'esigenza specifica per il proprio caso d'uso.
- Open source: tutte le nuove soluzioni infrastrutturali possono essere facilmente rese disponibili tramite il repository di codici DAP centrale per essere utilizzate da altri team. Nel tempo, ciò creerà una ricca base di codice con componenti dell'infrastruttura adattati ai diversi casi d'uso.
Sommario
In questo post, abbiamo illustrato come i team interfunzionali di SIGNAL IDUNA vengono abilitati a creare ed eseguire prodotti ML su AWS. Al centro del nostro approccio c'è l'utilizzo di un set dedicato di account AWS per ogni team in combinazione con progetti e soluzioni IaC su misura. Questi due componenti consentono a un team interfunzionale di creare e gestire un'infrastruttura di qualità della produzione. A loro volta, possono assumere la piena proprietà end-to-end dei loro prodotti ML.
Fare riferimento a Pipeline per la costruzione di modelli Amazon SageMaker – Amazon SageMaker per saperne di più.
Ulteriori informazioni su ML su AWS sulla nostra pagina ufficiale.
Riferimenti
[1] https://www.handelsblatt.com/finanzen/versicherungsbranche-vorbild-spotify-signal-iduna-wird-von-einer-handwerker-versicherung-zum-agilen-konzern/27381902.html
[2] https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
[3] https://aws.amazon.com/compliance/shared-responsibility-model/
Informazioni sugli autori
Jan Paul Assendorp è un ingegnere ML con un forte focus sulla scienza dei dati. Crea modelli ML e automatizza l'addestramento dei modelli e l'implementazione negli ambienti di produzione.
Thomas Lietzow è lo Scrum Master della squadra Data Analytics Platform.
Cristoforo Masch è il Product Owner della piattaforma di analisi dei dati della squadra con conoscenze in ingegneria dei dati, scienza dei dati e ingegneria ML.
Alessandro Meinert fa parte del team Data Analytics Platform e lavora come ingegnere ML. Ha iniziato con le statistiche, è cresciuto su progetti di data science, ha trovato passione per i metodi e l'architettura ML.
Dott. Lars Palzer è un data scientist e fa parte del team della piattaforma di analisi dei dati. Dopo aver aiutato a creare i componenti dell'architettura MLOps, ora li sta utilizzando per creare prodotti ML.
Jan Schillemans è un ingegnere ML con un background di ingegneria del software. Si concentra sull'applicazione delle migliori pratiche di ingegneria del software agli ambienti ML (MLOps).
- Coinsmart. Il miglior scambio di bitcoin e criptovalute d'Europa.
- Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. ACCESSO LIBERO.
- Criptofalco. Radar Altcoin. Prova gratuita.
- Fonte: https://aws.amazon.com/blogs/machine-learning/how-signal-iduna-operationalizes-machine-learning-projects-on-aws/
- "
- 100
- 2021
- accesso
- Il mio account
- operanti in
- Action
- vantaggi
- agile
- Tutti
- Sebbene il
- Amazon
- .
- analitica
- AMMISSIONE
- approccio
- architettura
- Automatizzata
- disponibile
- AWS
- essendo
- MIGLIORE
- best practice
- costruire
- Costruzione
- impacchettare
- affari
- funzionalità
- casi
- Challenge
- Cloud
- infrastruttura cloud
- codice
- collaborazione
- combinazione
- Uncommon
- azienda
- rispetto
- conformità
- Configurazione
- contiene
- Creazione
- dati
- Dati Analytics
- scienza dei dati
- scienziato di dati
- dedicato
- schierare
- distribuzione
- deployment
- progettazione
- dettaglio
- sviluppare
- sviluppato
- in via di sviluppo
- Mercato
- diverso
- discutere
- distribuito
- dominio
- facilmente
- crittografia
- endpoint
- ingegnere
- Ingegneria
- Ingegneri
- Ambiente
- essential
- stabilire
- esempio
- esperienza
- FAST
- Caratteristiche
- figura
- Infine
- Nome
- Focus
- concentrato
- i seguenti
- essere trovato
- Fondazione
- Contesto
- pieno
- Obiettivi
- la governance
- Aiuto
- aiuta
- qui
- Come
- HTTPS
- Immagine
- implementato
- importante
- competenze
- includere
- informazioni
- Infrastruttura
- assicurazione
- integrato
- integrazione
- Interfaccia
- Internet
- coinvolto
- IT
- Le
- conoscenze
- grandi
- IMPARARE
- apprendimento
- piccolo
- Lunghi
- macchina
- machine learning
- gestione
- gestione
- Rappresentanza
- Marketing
- partita
- Utenti
- Meta
- ML
- modello
- modelli
- componibile
- monitoraggio
- Nuove funzionalità
- prodotti nuovi
- offrire
- ufficiale
- Procedura di Onboarding
- operativo
- organizzazione
- Altro
- proprietario
- performance
- piattaforma
- Termini e Condizioni
- politica
- predizione
- Previsioni
- Frodi
- un bagno
- processi
- i processi
- Prodotto
- Produzione
- Prodotti
- Programma
- progetto
- progetti
- fornire
- la percezione
- cloud pubblico
- qualità
- deposito
- necessario
- Requisiti
- Risorse
- responsabile
- recensioni
- Rischio
- Correre
- Scala
- Scienze
- Scienziato
- scienziati
- Cerca
- problemi di
- servizio
- Servizi
- servizio
- set
- condiviso
- Un'espansione
- Software
- Ingegneria del software
- Soluzioni
- specializzata
- spendere
- Stage
- inizia a
- iniziato
- statistica
- conservazione
- Strategia
- forte
- Successivamente
- supporto
- supportato
- circondato
- task
- team
- Consulenza
- Tecnologie
- test
- Testing
- test
- tempo
- Training
- Trasformazione
- Trasparenza
- Aggiornanento
- us
- uso
- utilizzare
- virtuale
- Orologio
- OMS
- entro
- senza
- Lavora
- Forza lavoro
- lavori