Una prospettiva (filosofica) sulle lacune di competenze nell’intelligenza artificiale |  di Mathieu Lemay |  Settembre 2023

 | Intelligenza-Artificiale

Recentemente, alcuni dei nostri progetti hanno avuto clienti che chiedevano informazioni sul trasferimento dei progetti a team interni non ancora esistenti. “Come formiamo il nostro team affinché possieda la soluzione che hai creato?” “Come possiamo garantire che il nostro team sia a prova di futuro grazie ai cambiamenti nell’intelligenza artificiale?” Le variazioni su queste domande hanno ricevuto, per la maggior parte, risposta con raccomandazioni o piani di gestione del cambiamento, ma rimaneva un tema chiave: “Come possiamo assumere i giusti membri del team nel settore dell’intelligenza artificiale?”

Questa domanda, soprattutto per una società di consulenza aziendale sull’intelligenza artificiale come la nostra, è fondamentale. La capacità di identificare, reclutare, formare (e monetizzare) i dipendenti in un settore altamente dinamico richiede uno sforzo enorme. Ancora più rischiosa è la mancanza di competenze accessorie necessarie per la realizzazione di un progetto di successo, come la gestione dei requisiti, la comunicazione con il cliente e il monitoraggio del progetto.

Ciò che spesso consideriamo il più grande ostacolo nei nostri dipendenti e clienti è la mancanza di competenze molto discrete e specifiche, che di solito coprono solo due o tre aree di competenza mancanti, ma sufficienti a bloccare l’intero progetto. Questo articolo chiede come ciò si manifesta.

Per illustrare come le competenze mancanti possano causare l’improvvisa interruzione del progetto e come affrontarle, esistono due semplici quadri che aiutano a orientarsi nella questione. Sono:

  • Modelli mentali, che sono un’astrazione di un sistema, concetto o modello; E
  • Abilità a forma di T, che rappresentano la capacità di un individuo di possedere competenze generali in più ambiti pur essendo altamente specializzato in uno o alcuni di essi.

Modelli mentali

I modelli mentali sono rappresentazioni indipendenti intese a aiutare a interagire con costrutti, concetti e sistemi, di cui non mancano nell’apprendimento automatico. Semplicemente, aiutano a compartimentare le idee.

Dal documento di ricerca “Modelli mentali: una sintesi interdisciplinare di teoria e metodi“, Natalie Jones e la sua squadra spingere ulteriormente la spiegazione:

I modelli mentali sono rappresentazioni personali e interne della realtà esterna che le persone utilizzano per interagire con il mondo che le circonda. Sono costruiti da individui in base alle loro esperienze di vita, percezioni e comprensioni del mondo uniche. I modelli mentali vengono utilizzati per ragionare e prendere decisioni e possono essere la base dei comportamenti individuali. Forniscono il meccanismo attraverso il quale le nuove informazioni vengono filtrate e archiviate.

Ecco come sai che stai lavorando con un modello mentale adeguato:

  • È finito.
  • Sebbene finito, è completo anche nel suo obiettivo rappresentativo.
  • Consente costrutti di scatola nera per semplificare le idee al corretto livello di astrazione.

Tuttavia, i modelli mentali (e, soprattutto, l’impilamento dei modelli mentali) presentano dei limiti. Da N. Jones Ancora:

La capacità delle persone di rappresentare il mondo in modo accurato, tuttavia, è sempre limitata e unica per ciascun individuo. I modelli mentali si caratterizzano quindi come rappresentazioni incomplete della realtà. Sono anche considerate rappresentazioni incoerenti perché dipendono dal contesto e possono cambiare a seconda della situazione in cui vengono utilizzate. In sostanza, i modelli mentali devono essere modelli altamente dinamici per adattarsi a circostanze in continuo cambiamento e per evolversi nel tempo attraverso l’apprendimento. Concettualizzare le rappresentazioni cognitive come modelli dinamici e imprecisi di sistemi complessi riconosce i limiti nella capacità delle persone di concepire tali sistemi complessi.

Pertanto, la nostra capacità di concettualizzare, comprendere, analizzare, investigare, prototipare, costruire e implementare qualsiasi livello di automazione basata sull’apprendimento automatico richiede fluidità concettuale in molti domini di conoscenza, sia sul lato tecnico che su quello amministrativo del progetto.

Abilità a forma di T

Nella società moderna, il termine “competenze a T” è un po’ improprio; utili sono individui su più fronti con una profondità di specializzazione in più domini.

Un individuo con competenze a forma di T avrà tipicamente una conoscenza generale in più domini di conoscenza correlati pur avendo una profondità di specializzazione in un dato argomento o funzione.

Con l’avvento dell’ingegneria dell’apprendimento automatico (ovvero l’applicazione nel mondo reale e consapevole dei rischi dei principi scientifici dell’apprendimento automatico), è evidente la necessità di capacità multidisciplinari concorrenti.

Un altro modo per descrivere un individuo a forma di T è qualcuno che, nel contesto di un progetto o di una serie di responsabilità, è in grado di affrontare con successo molteplici funzioni richieste ed è un esperto in alcune di esse. Pericoloso in tutto il lavoro e mortale in alcuni di essi.

Il modo in cui questi individui spesso si manifestano è avere una comprensione generale dell’intero ambito del loro lavoro. Anche se potrebbero non essere esperti in alcuni aspetti dei compiti loro assegnati, sanno almeno come compartimentare questi compiti meno confortevoli in elementi di lavoro con chiari confini di input e output per il resto del sistema; hanno quindi visibilità e capacità sull’intero progetto.

Anche se non hanno mai interagito con un’anatra prima, sanno come dovrebbe apparire l’anatra e come dovrebbe starnazzare, il che è sufficiente per non essere bloccati.

Rispetto a un progetto di migrazione al cloud o a un SaaS, l’apprendimento automatico tende ad avere molti concetti impilati in sequenza (in contrapposizione a quelli simultanei o ad albero), nonché una combinazione di considerazioni aggiuntive specifiche per le implementazioni di apprendimento automatico a livello di produzione. Le distribuzioni dipendono dai tipi di modello, i tipi di modello dipendono dalla scienza dei dati e l’analisi esplorativa dei dati dipende dai requisiti del progetto.

Nel giornale “Sfide di garanzia della qualità per le applicazioni software di machine learning durante le fasi del ciclo di vita dello sviluppo software” (Alamin2021), l’autore spiega una chiara differenza tra lo sviluppo di software tradizionale e le applicazioni software di apprendimento automatico. Dal giornale:

Nello sviluppo software tradizionale, per prima cosa raccogliamo i requisiti. Quindi progettiamo, sviluppiamo, testiamo, distribuiamo e manteniamo l’applicazione. Per i sistemi ML, dobbiamo ancora definire l’obiettivo dell’applicazione, ma invece di progettare l’algoritmo lasciamo che il modello ML apprenda la logica desiderata dai dati (1). Tali osservazioni portano alla domanda se e come i modelli ML possano essere adottati senza interrompere il ciclo di vita dello sviluppo software (SDLC) delle (applicazioni software di apprendimento automatico). Idealmente, le fasi del flusso di lavoro/pipeline ML e dell’SDLC dovrebbero andare di pari passo per garantire un’adeguata garanzia della qualità. Tuttavia, come notato in precedenza, tali aspettative possono essere irrealistiche a causa delle differenze intrinseche nel modo in cui vengono progettati i modelli ML e nel modo in cui vengono sviluppate le applicazioni software tradizionali.

(Lwakatare 2019), nel suo articolo “Una tassonomia delle sfide dell’ingegneria del software per i sistemi di apprendimento automatico: un’indagine empirica”va ancora oltre:

(…) Sebbene nel mondo accademico venga data molta attenzione alle scoperte teoriche degli algoritmi di apprendimento, gli studi empirici mostrano che essi costituiscono solo una piccola parte del sistema operativo ML (20).

Di conseguenza, nella pratica si incontrano diverse sfide durante lo sviluppo e la manutenzione dei sistemi ML (6). Per affrontare il problema, le prove emergenti evidenziano la necessità di prendere in considerazione ed estendere i principi, gli approcci e gli strumenti consolidati dell’ingegneria del software (SE) nello sviluppo di sistemi ML (11,19).

Quindi, possiamo descrivere un progetto di intelligenza artificiale come se richiedesse un po’ più di modelli mentali per completare un progetto di dimensioni simili. ma i software di intelligenza artificiale richiedono in genere un accumulo più sequenziale di questi principi, mentre Cloud e SaaS sembrano avere una maggiore concorrenza nelle loro idee, il che porta a interdipendenze meno critiche tra loro.

Prendiamo un semplice modello di progetto, in cui devono svolgersi una serie di attività in 9 ipotetici domini. Questi domini possono rappresentare un mix di competenze di gestione dei progetti, ingegneria dei requisiti, scienza dei dati, apprendimento automatico, cloud e MLOps. Anche se abbastanza semplificati, la maggior parte dei progetti che incontriamo presentano un simile cambiamento sequenziale di competenze.

Illustrazione dell’autore.

Tuttavia, con l’emergere di nuove tecnologie, a volte ci sono nuove tecnologie che ti verrà richiesto di utilizzare. A volte si tratta di piccole modifiche (ad esempio, la sostituzione di Git LFS con DVC) e a volte sono molto, molto più grandi (come l’impegno a Kubernetes da un approccio VM monolitico). Idealmente, tu e il tuo team sareste completamente competenti per svolgere tutti questi compiti; realisticamente, con il tasso di cambiamento in questo settore, probabilmente hai familiarità con la maggior parte di essi e alcuni sono nuovi o non completamente padroneggiati.

In questo caso, c’è un unico punto di conoscenza mancante.

Illustrazione dell’autore.

Questa è, direi, una condizione operativa molto normale. Un cliente vuole provare una nuova libreria; qualcuno ha suggerito un database diverso. Succede tutte le volte. Il modulo che richiede una modifica può essere sostituito mentalmente a caldo senza conseguenze importanti se non la lettura di alcune API o l’apprendimento di un diverso approccio di gestione del progetto.

Il punto in cui ci sono problemi all’interno di MLOps è che spesso due o più aree problematiche causano una mancanza di conoscenza percepita molto più ampia all’interno di un progetto.

Illustrazione dell’autore.

Sebbene esistano solo due aree problematiche, la mancanza di efficacia percepita riguarda la maggior parte delle attività assegnate.

Una manciata di concetti mancanti si manifesterà come una frustrante incapacità di fornire risultati o di essere efficaci all’interno di un progetto.

Per essere chiari, tutto il nostro team (me compreso) apprende continuamente e in modo proattivo nuovi concetti e tecnologie per garantire che non ci siano argomenti o aree di conoscenza inaspettati di cui siamo completamente ciechi. Di solito seguiamo la seguente sequenza per scoprirli:

  • Identificare. Non appena senti parlare di una nuova tecnologia o approccio che verrà utilizzato, prendi nota del suo nome, della sua descrizione e del suo contesto.
  • Isolato. Sebbene sia difficile identificare le “incognite sconosciute” nella conoscenza mancante, poniamo semplici domande per risolverle: qual è il contesto di questo concetto? In cosa assomiglia a ciò che già so? In cosa è diverso da quello che già so?
  • Inizia in piccolo. “Ciao mondo” gli esempi sono ancora un modo valido per assicurarsi di avere una certa efficacia nell’utilizzo di un particolare strumento.

Invece di concentrarti sulla totalità delle tue capacità come misura del progresso, dovresti considerare la combinazione delle tue capacità e il modo in cui le applichi insieme per fornire valore e successo al progetto.

Fonte: towardsdatascience.com

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *