Dove gli agenti di programmazione sono utili e dove falliscono

Pedro Alves lavora intensamente con l'AI da 25 anni. Attualmente è CTO di Thoth AI e il creatore di Last Week in AI.

Abbiamo parlato con Pedro degli agenti di programmazione e del perché sia così importante sapere cosa possono e non possono fare. Ecco cosa ci ha raccontato.

Prima che l'“AI” diventasse qualcosa che le persone mettevano nelle presentazioni

Sono Pedro, CTO di Thoth AI. Lavoravo con l'AI prima che diventasse qualcosa che le persone mettevano nelle presentazioni: nel 2001, quando studiavo informatica all'università, ho costruito un piccolo mondo pieno di agenti simulati e li ho lasciati imparare a superarsi a vicenda, una sorta di gioco della vita digitale il cui obiettivo era osservare i loro progressi. Sono passati 25 anni e continuo ancora a inseguire la stessa domanda: come si fa a far migliorare un sistema?

Quando è arrivato il momento della scuola di specializzazione, tutti davano per scontato che avrei conseguito un dottorato in apprendimento automatico. Non l'ho fatto. Mi sembrava un campo troppo ristretto e troppo teorico. Volevo imparare il mestiere confrontandomi con i dati più ricchi e disordinati che riuscissi a trovare, così sono passato alla biologia computazionale: proteomica per la laurea magistrale e genomica per il dottorato. Ho acquisito competenze in apprendimento automatico, statistica e scienza dei dati applicandole — alle reti di interazione gene-gene, all'ingegneria delle caratteristiche, alle reti neurali e ai metodi d'insieme — a problemi in cui sbagliare aveva un costo.

È lì che ho imparato la lezione che da allora ha plasmato tutto ciò che faccio. In medicina, ho costruito modelli di progressione delle malattie e il parametro di valutazione standard — l'accuratezza complessiva — era inutile. Un modello "buono" secondo quella misura si limitava a riconfermare i casi che i medici già conoscevano, mentre l'intero valore risiedeva nei casi che avrebbero mancato. Così, invece di ottimizzare l'accuratezza, ho ottimizzato la AUC parziale — essenzialmente la capacità del modello nei casi che contavano. Il parametro che qualcuno ti consegna è quasi mai il vero obiettivo.

Da lì, ho esplorato diversi settori: quei modelli medici, un periodo di consulenza per una squadra di calcio professionistica, poi la Silicon Valley e anni nella visione artificiale, quando per far funzionare il rilevamento e la classificazione dovevi ancora innovare sul modo in cui addestravi e persino inizializzavi i pesi di una rete. Ho lavorato con dati provenienti da social network, commercio al dettaglio, moda e video. Ho trascorso un anno a costruire algoritmi di trading con algoritmi genetici e ottimizzazione a sciame di particelle, metodi di ottimizzazione non parametrica sui quali avevo scritto articoli durante la scuola di specializzazione. Alla fine, ho fondato la mia azienda, costruendo strumenti di AI per persone che non erano data scientist.

È l'ampiezza a collegare tutto. Dopo una dozzina di settori, continuo a vedere lo stesso problema in forme diverse: un trucco ovvio nella genomica si rivela essere la chiave nella visione artificiale. Mi interessa più il modo in cui un problema viene inquadrato che il modo in cui viene risolto, perché è nell'inquadramento che si nasconde il maggiore potenziale.

È questo che mi ha portato a Thoth. Sulla carta, siamo un'azienda di annotazione dei dati. Ma penso che il problema che l'intero settore cerca di risolvere sia quello sbagliato. Nessuno vuole dati annotati: i dati sono solo il passaggio intermedio. Le persone vogliono un modello migliore. Perciò sto spingendo verso un futuro in cui un sistema individui di quali dati il tuo modello ha bisogno per migliorare e gestisca questa parte al posto tuo, così puoi concentrarti sul modello invece che sull'etichettatura.

I due aspetti dell'azienda

Strutturalmente, Thoth AI ha due aspetti. Da una parte c'è il motore per le operazioni sui dati, che opera a livello internazionale e su larga scala. È più grande di una tipica startup, ma comunque molto più piccola dei colossi del settore, quindi la definirei di medie dimensioni. Dall'altra c'è la parte che sto costruendo: un team di ricerca e innovazione completamente nuovo qui nella Bay Area, attualmente composto da cinque persone, con altri ingressi previsti nei prossimi mesi. Lì, perseguiamo il resto del miglioramento del modello: tutto ciò che va oltre l'etichettatura.

La nostra ricerca si concentra principalmente su due direzioni. La prima è la robotica: generare dati incarnati, valutarli e usare l'apprendimento attivo per generare automaticamente i migliori dati di addestramento possibili, affinché i robot possano imparare i loro compiti con la minor quantità di dati possibile. La maggior parte del lavoro utilizza dati egocentrici (essenzialmente riprese in prima persona) e ci concentriamo soprattutto sulla produzione dei dati egocentrici della massima qualità possibile. La seconda riguarda l'affidabilità e l'efficienza dei modelli linguistici: comprendere cosa causa le allucinazioni e come si manifestano e, sul fronte dell'efficienza, riconoscere quando un modello più piccolo può gestire una richiesta, quindi riformularla o suddividerla in parti affinché un modello più semplice ed economico possa rispondere. Oggi tutto questo è ancora ricerca, con l'obiettivo di trasformarlo in prodotti che lanceremo da questo team.

Per quanto riguarda fase e dimensioni: la divisione dati è un'attività internazionale consolidata di medie dimensioni, mentre il team di ricerca statunitense è volutamente ancora agli inizi. Attualmente siamo in cinque nel nostro ufficio di San Mateo, con una o due nuove assunzioni previste nei prossimi mesi. Questa è la nostra situazione attuale.

Come test approfonditi producono risultati affidabili

Pedro condivide

La preparazione ora procede quasi da sola. Ma questo non è il vero vantaggio. Il miglioramento più importante riguarda la qualità: la riunione è più incisiva e mirata, e le questioni giuste arrivano in modo affidabile al CEO.

Molti si affrettano ad automatizzare con l'IA ogni attività e funzione, ma io sono prudente. L'IA rende banale creare una demo. Costruire qualcosa di affidabile per l'uso quotidiano è un'altra cosa. Quando si utilizzano davvero questi strumenti, ci si imbatte in casi limite e situazioni particolari in cui l'automazione funziona quasi, ma non del tutto. Perciò testo approfonditamente qualsiasi soluzione prima di affidarle un flusso di lavoro reale.

Quest'anno ho sviluppato strumenti basati sull'IA per la nostra riunione settimanale di revisione con il CEO, abbastanza solidi da superare questo livello. Inviano email ai responsabili delle varie aree per raccogliere gli aggiornamenti, compilano automaticamente le risposte, preparano report, riepiloghi e l'ordine del giorno, e tengono traccia dei risultati nel tempo.

Prima, tutto questo veniva fatto manualmente. Qualcuno sollecitava le persone per ottenere gli aggiornamenti, riuniva manualmente le risposte, scriveva i riepiloghi e l'ordine del giorno, e monitorava i risultati di settimana in settimana. Funzionava, ma era lento, e l'ordine del giorno tendeva facilmente a concentrarsi su ciò che era più recente invece che su ciò che contava di più.

Ora la preparazione procede quasi da sola. Ma questo non è il vero vantaggio. Il miglioramento più importante riguarda la qualità: la riunione è più incisiva e mirata, e le questioni giuste arrivano in modo affidabile al CEO. Quindi non si tratta tanto del tempo risparmiato, quanto di indirizzare l'attenzione del CEO verso le decisioni che contano davvero.

Perché il giudizio rimane umano mentre l'IA accelera la programmazione

Oggi l'IA alimenta la programmazione stessa, praticamente ovunque. I miei ricercatori, gli ingegneri che portano il nostro lavoro in produzione e io utilizziamo tutti strumenti di programmazione basati sull'IA. È il giudizio umano, non una specifica categoria di attività, a determinare come viene costruito il codice, e questo standard cambia in base alla posta in gioco.

Dal punto di vista della ricerca, l'obiettivo è solitamente far funzionare qualcosa, spesso configurando un repository GitHub per testare la validità di un'idea. Nulla arriva in produzione, quindi sono tollerante riguardo alla sua scrittura. Se funziona e risponde alla domanda, è sufficiente.

La produzione è diversa. Il modo in cui costruiamo qualcosa è importante quanto il fatto che funzioni, quindi utilizziamo l'IA con maggiore cautela. Gli ingegneri senior sono responsabili dell'architettura, della qualità e delle revisioni. L'IA li accelera, ma non prende queste decisioni. Questo confine rimane umano.

L'esperienza del team è un elemento di supporto. I suoi membri utilizzano l'IA in modo diverso rispetto alle persone meno esperte. Sanno già riconoscere un buon risultato, quindi il modello amplifica il loro giudizio invece di sostituirsi al giudizio che stanno ancora sviluppando. Li rende più veloci senza sostituire l'elemento essenziale.

Come utilizzare efficacemente gli agenti di programmazione

Nel complesso, l'efficacia degli agenti di programmazione deriva dalla disciplina con cui gestisco i punti di forza e le debolezze della tecnologia.

Ci penso come se stessi dipingendo una tela. L'obiettivo è sempre lo stesso: chiarire l'immagine che ho in mente, poi usare l'IA per tradurre quell'intento in codice funzionante il più velocemente possibile. Il suo successo dipende da una variabile: quanto lavoro creativo conservo e quanto ne affido ad altri.

L'IA dà il meglio di sé al primo livello. Riesco a vedere l'intero dipinto e a tracciare pennellate ampie, mentre l'IA completa i dettagli. So esattamente cosa deve essere costruito, e tradurre l'intento in codice è essenzialmente un processo basato su formule. È qui che l'IA moltiplica davvero la produttività, e in questa categoria rientra la maggior parte del mio lavoro quotidiano.

Il secondo livello è utile, ma presenta una maggiore variabilità. È simile, ma lascio intenzionalmente aperte alcune aree della tela e dico al modello di dipingere qualcosa al loro interno. Richiede una certa creatività, ma la mia direzione continua a delimitarne i confini. Considero quell'output una bozza, non una risposta.

Metto in guardia le persone dal terzo livello. Consiste nell'affidare all'IA il nucleo creativo: la definizione del progetto o le decisioni progettuali fondamentali. Può sembrare impressionante a chi non conosce a fondo il settore, ma spesso rende molto meno di quanto riesca perché il modello colma una lacuna che avrei dovuto colmare io.

Quella lacuna è proprio il punto. Quasi ogni progetto ha bisogno di una cosa unica: un'intuizione o una decisione non ovvia richiesta dal problema. Per impostazione predefinita, il modello fornisce la soluzione media, il modello più comune derivato dal suo addestramento. La parte che fa funzionare un progetto di solito non è nella media, e l'IA non può arrivarci da sola. Quella parte spetta a me trovarla. Dopodiché, l'IA costruisce tutto ciò che viene dopo più velocemente e meglio di quanto potrei fare da solo.

Come gli agenti di programmazione creano bug difficili da trovare

Pedro condivide

Il risultato positivo più evidente degli agenti di programmazione è la velocità. La programmazione è più rapida, il che aumenta la frequenza delle nostre distribuzioni, e non si tratta solo di velocità pura. Le attività che erano complicate da configurare ora sono molto più semplici. Questa parte è reale e conta.

Il risultato positivo più evidente degli agenti di programmazione è la velocità. La programmazione è più rapida, il che aumenta la frequenza delle nostre distribuzioni, e non si tratta solo di velocità pura. Le attività che erano complicate da configurare ora sono molto più semplici. Questa parte è reale e conta.

Un risultato più interessante riguarda il modo in cui sono cambiati i nostri bug. Il tasso di difetti non è aumentato, ma sono cambiati i tipi di difetti. L'IA garantisce che il codice venga eseguito. Quasi sempre verifica questo aspetto prima di restituirtelo. Di conseguenza, i bug più semplici — quelli che generano soltanto un errore o impediscono l'esecuzione — si presentano molto meno spesso. Ciò che rimane sono bug logici, casi che il modello non ha esaminato fino in fondo, e sono più difficili da individuare proprio perché il codice viene eseguito senza problemi.

È qui che si trova il lato negativo. Questi bug si nascondono meglio. Se una persona non ha esperienza o si affida troppo allo strumento, vede il codice in esecuzione e presume che sia corretto, quando non lo è. Il pericolo non consiste in un numero maggiore di bug, ma nella falsa sicurezza. Serve qualcuno che sappia cosa cercare per individuare le cose che superano il test "funziona", ma sono comunque sbagliate.

Perché l'IA dovrebbe essere usata per amplificare le capacità delle persone esperte invece di migliorare quelle meno capaci

Ciò che mi ha sorpreso di più è stato capire da dove derivi il vantaggio. Intuitivamente, si potrebbe pensare che l'IA abbassi la soglia di esperienza, permettendo di assumere team più economici e junior e di lasciare che gli strumenti li portino a un livello superiore. È vero il contrario. L'esperienza ora conta di più, non di meno.

Si tratta di affidabilità. Usare l'IA per trasformare un ingegnere senior in cinque ingegneri senior è molto più affidabile che trasformare un ingegnere junior in uno senior. L'IA moltiplica il buon giudizio che già possiedi; non crea il giudizio che ti manca.

Perciò valorizzo le mie persone più forti; non cerco di far crescere quelle più deboli. Alcune persone esperte, ciascuna capace di produrre diverse volte più di prima, superano ogni volta un team misto più numeroso.

Perché la creatività deve venire dagli esseri umani, non dall'IA

È evidente che l'IA non ha mantenuto le promesse sugli aspetti creativi e di connessione della ricerca. Quando svolgo attività tecniche con l'assistenza dell'IA, una persona deve comunque collegare i punti: capire come estendere il lavoro di qualcun altro, collegare due articoli in modo sensato e compiere quei salti logici che daresti per scontati. Questa parte richiede ancora una persona.

Non sorprende, se si ricorda cosa sono questi modelli. Sono macchine probabilistiche. Producono il testo che ha maggiori probabilità di soddisfare il lettore. Stiamo migliorando nell'addestrarli ad altri tipi di attività, ma diventa davvero difficile quando si cerca di insegnare la creatività in sé, perché costruire il segnale di addestramento è complesso.

Prendiamo i set di dati. Un set di dati che descriva l'aspetto di un cane è semplice. Si raccolgono molte immagini di cani. Un set di dati sulla creatività nel disegnare cani presenta un problema diverso. Consideriamo, per esempio, qualcuno che aggiunge delle ali a un cane. Il punto dell'esempio non sono le ali. È il gesto astratto che vi sta dietro: prendere qualcosa che non c'entra e inserirlo in un luogo in cui non ci si aspetta di trovarlo. Per far comprendere questo a un modello, servono un numero enorme di esempi, così impara che non sono le ali a contare, ma il gesto creativo.

Anche se ci arriva, si incontra il problema successivo. Ora prendiamo la stessa creatività e applichiamola a un'equazione matematica o a un frammento di codice tratto da un articolo, usandola per estendere l'algoritmo di qualcun altro. È in questo tipo di trasferimento che il modello crolla.

Le persone si affidano alle macchine proprio per la parte in cui sono più deboli. L'ironia è che la soluzione costa poco. Un pizzico di creatività umana porta lontano. Non affidarti troppo alla macchina per quella parte e puoi ottenere risultati notevoli.

Perché i CTO devono riprogettare il modo in cui le capacità dell'IA si diffondono nelle organizzazioni

Questo non sarà il consiglio più popolare del momento, ma penso che sia quello più prudente e con maggiori probabilità di dare risultati: siate più ponderati di quanto il momento vi spinga a essere.

In questo momento, le aziende stanno spendendo enormi quantità di denaro sulla base di una semplice supposizione: chiunque può automatizzare una parte del proprio lavoro con l'IA. Quindi la direttiva viene rivolta a tutti. Ingegneri, esperti di dati, vendite, marketing, l'intera azienda. Create un account, automatizzate qualcosa, costruite i vostri strumenti e partite. Il risultato è un'enorme quantità di sforzi sprecati: lavoro duplicato, progetti che non portano da nessuna parte, strumenti che nessuno usa. Le aziende bruciano molti soldi in attività, tempo e token che non producono nulla di duraturo.

Costruiteci intorno un processo reale. Centralizzatelo. Create un piccolo team centrale il cui compito sia rendere ogni altro team più efficace con l'IA. Sviluppano flussi di lavoro, contesto riutilizzabile, standard e modelli efficaci, poi li distribuiscono affinché i singoli ingegneri non debbano sostenere ciascuno il costo della scoperta. Questa è la versione strutturale di ciò che ho detto prima sul concentrare la leva sulle persone più forti: pochi ingegneri esperti di IA che migliorano l'intera organizzazione.

Questo produce simultaneamente due risultati. L'utilizzo aumenta perché i team applicano modelli già collaudati invece di procedere per tentativi. E recuperate una grande quantità di tempo che si perde silenziosamente in sperimentazioni che non era necessario ripetere più di una volta.

Segui gli aggiornamenti

Potete seguire il lavoro di Pedro Alves su LinkedIn o iscrivervi alla sua newsletter, La scorsa settimana nell'IA. E date un'occhiata a Thoth AI.

Su The CTO Club arriveranno altre interviste a esperti!