Deployare Prodotti di Intelligenza Artificiale Conversazionale in Produzione con Jason Flaks

Deploying AI Conversational Products in Production with Jason Flaks

Questo articolo era originariamente un episodio di MLOps Live, una sessione interattiva di domande e risposte in cui i praticanti di ML rispondono alle domande degli altri praticanti di ML.

Ogni episodio è focalizzato su un argomento specifico di ML e durante questo episodio abbiamo parlato con Jason Falks di come distribuire prodotti di AI conversazionale in produzione.

Puoi guardarlo su YouTube:

O ascoltarlo come podcast su:

Spotify
Apple Podcasts

Ma se preferisci una versione scritta, eccola qui!

In questo episodio, imparerai:

1
Come sviluppare prodotti con l’AI conversazionale
2
I requisiti per la distribuzione di prodotti di AI conversazionale
3
Se è meglio costruire prodotti con dati proprietari interni o utilizzare quelli preconfezionati
4
Strategie di test per l’AI conversazionale
5
Come creare soluzioni di AI conversazionale per aziende su larga scala

Sabine: Ciao a tutti e bentornati a un altro episodio di MLOps Live. Sono Sabine, la vostra conduttrice, e come sempre sono accompagnata dal mio co-conduttore Stephen.

Oggi abbiamo con noi Jason Flaks e parleremo della distribuzione di prodotti di AI conversazionale in produzione. Ciao Jason e benvenuto.

Jason: Ciao Sabine, come va?

Sabine: Va molto bene e non vedo l’ora di iniziare la conversazione.

Jason, sei il co-fondatore e CTO di Xembly. È un capo di stato maggiore automatizzato che automatizza compiti conversazionali. Quindi è un po’ come un assistente esecutivo bot, è corretto?

Jason: Sì, è un ottimo modo per descriverlo. Quindi il CEO di molte aziende ha delle persone che lo assistono, magari un assistente esecutivo, magari un capo di stato maggiore. Questo avviene affinché il CEO possa concentrare il proprio tempo su compiti davvero importanti e significativi che alimentano l’azienda. Gli assistenti sono lì per aiutare a gestire alcuni degli altri compiti della loro giornata, come la pianificazione di riunioni o la presa di appunti durante le riunioni.

Noi puntiamo a automatizzare questa funzionalità in modo che ogni lavoratore di un’organizzazione possa avere accesso a quell’aiuto, proprio come farebbe un CEO o qualcun altro nell’azienda.

Sabine: Fantastico.

Ci addentreremo un po’ di più in questo argomento tra poco. Ma prima, vorrei chiederti qualcosa riguardo alla tua formazione. Hai un percorso abbastanza interessante.

Hai studiato composizione musicale, matematica e scienze prima di dedicarti maggiormente all’ingegneria del software, è corretto?

Jason: Sì, è corretto.

Come hai detto, all’inizio della mia vita ero un musicista. Avevo una passione per l’attrezzatura elettronica legata alla musica e anche per la matematica.

Ho iniziato il college come studente di composizione musicale e matematica e alla fine cercavo un modo per combinare queste due passioni. Sono finito in un programma di master che era un programma di ingegneria elettrica focalizzato esclusivamente sull’attrezzatura audio professionale, e questo mi ha portato a una carriera iniziale nel campo dell’elaborazione del segnale, facendo progettazione software.

Quello è stato il mio primo lavoro.

Sabine: Quindi ti trovi all’intersezione di diverse aree interessanti, suppongo.

Jason: Sì, è vero. Ho sempre cercato di rimanere un po’ vicino alla musica, all’audio e all’ingegneria, anche fino ad oggi.

Anche se mi sono allontanato un po’ dall’audio professionale, dalla musica, dal suono dal vivo, dalla lingua parlata e dal linguaggio naturale, è ancora strettamente legato al dominio audio, quindi è rimasto un pezzo delle mie competenze per tutta la mia carriera.

Sabine: Assolutamente. E parlando di attrezzatura, sei stato coinvolto nello sviluppo del Connect, giusto? (O della Xbox).

È stato il tuo primo approccio al riconoscimento vocale, a un’applicazione di machine learning?

Jason: È una domanda interessante. La cosa divertente sul riconoscimento vocale è che è davvero una pipeline a due fasi:

Il primo componente della maggior parte dei sistemi di riconoscimento vocale, almeno storicamente, è l’estrazione delle caratteristiche. Questo rientra molto nel dominio dell’elaborazione del segnale audio, una cosa in cui avevo molta esperienza in altre parti della mia carriera.

Anche se non stavo facendo riconoscimento vocale, ero solo familiare con le trasformate di Fourier veloci e molte delle componenti che vanno in quel front end, lo stack di riconoscimento vocale.

Ma hai ragione a dire che quando mi sono unito al team di Connect Camera, è stato un po’ la prima volta che il riconoscimento vocale è stato davvero inserito dalla mia parte. Mi sono naturalmente avvicinato ad esso perché capivo profondamente quella parte iniziale dello stack.

E ho scoperto che per me era davvero facile passare dal mondo dell’elaborazione del segnale audio, dove stavo cercando di creare effetti di distorsione per chitarra, a scomporre improvvisamente i componenti del linguaggio parlato per l’analisi. Aveva davvero senso per me, ed è lì che ho iniziato.

È stato un progetto molto interessante per iniziare perché Connect Camera era davvero il primo prodotto commerciale per consumatori che faceva riconoscimento vocale senza bisogno di premere un pulsante. In quel momento non c’erano prodotti sul mercato che ti consentivano di parlare con un dispositivo senza premere un pulsante.

Si doveva sempre premere qualcosa e poi parlare. Ora tutti abbiamo Alexa o Google Home. Sono comuni, ma prima che esistessero questi prodotti, c’era la Xbox Connect Camera.

Puoi consultare la letteratura dei brevetti e vedere come il dispositivo Alexa si riferisce a quei brevetti originali di Connect. Era davvero un prodotto innovativo.

Sabine: Sì, e ricordo che una volta avevo un docente che diceva che il linguaggio umano è il segnale più complesso nell’universo, quindi suppongo che non manchino sfide in quell’ambito in generale.

Jason: Sì, è davvero vero.

Cosa è l’IA conversazionale?

Sabine: Giusto, quindi, Jason, per scaldarti un po’, in un minuto, come spiegheresti l’IA conversazionale?

Jason: Wow, la sfida del minuto. Sono eccitato…

Quindi il dialogo umano o la conversazione è essenzialmente un dominio illimitato e infinito. L’IA conversazionale riguarda la costruzione di tecnologie e prodotti capaci di interagire con gli esseri umani in questo spazio di conversazione illimitato.

Quindi come costruiamo cose che possono capire di cosa stiamo parlando, partecipare alla conversazione e anche svolgere transazioni durante il dialogo.

Sabine: Fantastico. Ed è stato molto ben condensato. È stato come, beh, entro il minuto.

Jason: Sentivo molta pressione per andare così veloce che ho esagerato.

Su quali aspetti dell’IA conversazionale sta lavorando attualmente Xembly?

Sabine: Volevo chiedere un po’ su cosa sta lavorando attualmente il tuo team. Ci sono particolari aspetti dell’IA conversazionale su cui state lavorando?

Jason: Sì, è una domanda molto interessante. Quindi ci sono davvero due lati dello stack dell’IA conversazionale su cui lavoriamo.

Chatbot

Si tratta di consentire alle persone di interagire con il nostro prodotto tramite conversazioni vocali. Come abbiamo accennato all’inizio di questa conversazione, stiamo cercando di essere un assistente esecutivo automatizzato o un capo di stato maggiore.

Il modo in cui interagisci con qualcuno in quel ruolo è generalmente conversazionale, quindi la nostra capacità di rispondere ai dipendenti tramite conversazioni è estremamente utile.

Appunti automatici

La domanda diventa: come possiamo partecipare a una conversazione come questa su Zoom o Google Meet o qualsiasi altro fornitore di videoconferenze e generare appunti ben scritti che invieresti immediatamente alle persone presenti alla riunione per spiegare cosa è successo nella riunione?

Quindi non si tratta solo di una trascrizione. Si tratta di come estrarre gli elementi di azione e le decisioni e riassumere la riunione in un riassunto leggibile in modo tale che, se non eri presente, sapresti cosa è successo.

Questi sono probabilmente i due grandi elementi di ciò su cui stiamo lavorando nello spazio dell’IA conversazionale, e c’è molto di più su ciò che rende possibile tutto ciò, ma questi sono i due grandi settori di prodotto che stiamo coprendo oggi.

Sabine: Quindi, se potessi riassumerlo a grandi linee, come procedi nello sviluppo di questo prodotto?

Jason: Sì, parliamo di prendere appunti. Penso che sia interessante analizzarlo…

Il primo passo per noi è scomporre il problema.

Prendere appunti durante una riunione è effettivamente una cosa complicata a un certo livello. C’è una certa sfumatura nel modo in cui ogni essere umano prende appunti diversi, quindi ci ha richiesto di fare un passo indietro per capire…

Qual è il nucleo di ciò che rende preziosi gli appunti di una riunione e possiamo quantificarlo in qualcosa di strutturato che possiamo generare ripetutamente?

Le macchine non gestiscono bene l’ambiguità. Devi avere una definizione strutturata di ciò che stai cercando di fare in modo che i tuoi annotatori di dati possano etichettare le informazioni per te.

Se non puoi dare loro istruzioni molto chiare su ciò che stanno cercando di etichettare, otterrai risultati incerti.

Ma anche solo perché, in generale, se vuoi davvero costruire un sistema concreto che produca risultati ripetibili, devi definire il sistema, quindi dedichiamo molto tempo all’inizio per capire quale è la struttura di appunti di riunione adeguata.

Nei nostri primi giorni, abbiamo sicuramente stabilito che ci sono due elementi fondamentali in tutti gli appunti di una riunione.

1
Le azioni che derivano dalla riunione e che le persone devono seguire.
2
Un riassunto lineare che riassume ciò che è accaduto nella riunione, idealmente suddiviso per argomento in modo da coprire le sezioni della riunione come si sono svolte.

Una volta che hai questa struttura, devi fare il passo successivo per definire come saranno questi elementi individuali, in modo da capire quali modelli diversi nella pipeline devi costruire per realizzarli effettivamente.

Ambito delle dichiarazioni di problema dell’IA conversazionale

Sabine: C’era qualcos’altro che volevi aggiungere a questo?

Jason: Sì, quindi se pensiamo solo un po’ a qualcosa come gli elementi da azione, come si fa a definire uno spazio in modo che sia qualcosa di fattibile per una macchina da trovare?

Un buon esempio è che in quasi ogni riunione le persone dicono cose come “Vado a passeggiare il cane” perché stanno semplicemente conversando con le persone nella riunione riguardo a cose che faranno che non riguardano il lavoro.

Quindi hai cose in una riunione che non riguardano il lavoro, hai cose che stanno effettivamente accadendo in una riunione che vengono effettivamente transate in quel momento. Aggiorno quella riga nel foglio di calcolo, e poi hai acronimi veri, cose che sono effettivamente lavoro che devono essere avviate dopo che la riunione è finita e di cui qualcuno è responsabile.

Quindi come si definisce e si raffina tutto ciò in un dominio molto specifico che si può insegnare a una macchina a trovare?

Si scopre che è un problema estremamente difficile. Abbiamo dedicato molti sforzi a fare tutto questo e poi a iniziare il processo di raccolta dei dati in modo da poter iniziare a costruire questi modelli.

Inoltre, devi capire qual è la pipeline per costruire questi sistemi di IA conversazionale; in realtà è bifase.

1
C’è la comprensione del dialogo stesso – capire semplicemente il discorso, ma per transare su quei dati, in molti casi, è necessario normalizzare quei dati in qualcosa che una macchina può capire. Un buon esempio sono le date e gli orari.
2
La prima parte del sistema è capire che qualcuno ha detto “Lo farò la prossima settimana”, ma questo non è sufficiente per transare su di esso da solo. Se vuoi transare sulla prossima settimana, devi capire effettivamente in linguaggio informatico cosa significa “prossima settimana”.

Ciò significa che hai un riferimento a quale sia la data corrente. Devi essere abbastanza intelligente da sapere che “prossima settimana” significa effettivamente un intervallo di tempo, cioè la settimana successiva rispetto alla settimana corrente in cui ti trovi.

Ci sono molte complessità e modelli diversi che devi eseguire per poter fare tutto questo e avere successo.

Preparare un prodotto di intelligenza artificiale conversazionale

Stephen: Fantastico… Sto cercando di approfondire di più l’appunti che hai menzionato.

Sto cercando di affrontare l’angolo della produzione, ovviamente, per ottenere vantaggi per gli utenti, e l’ambiguità deriva da questo.

Prima di affrontare questa complessità, vorrei capire come si implementano tali prodotti. Voglio sapere se ci sono sfumature o requisiti specifici che vengono messi in atto, oppure se si tratta di una tipica implementazione di un flusso di lavoro di pipeline e basta.

Jason: Sì, è una buona domanda.

Direi che, prima di tutto, probabilmente una delle differenze più grandi tra le implementazioni di intelligenza artificiale conversazionale in questo stack per prendere appunti e lo spazio di apprendimento automatico tradizionale più ampio che esiste nel mondo, è legata a ciò di cui stavamo parlando prima, perché si tratta di un dominio illimitato.

Il labeling dei dati veloce e iterativo è assolutamente fondamentale per il nostro stack. E se pensi a come funziona una conversazione o un dialogo o semplicemente il linguaggio in generale, tu e io possiamo inventare una parola in questo momento, anche per il modello di linguaggio più grande del mondo – se prendiamo GPT-3 oggi – quella è un token non definito per loro.

Abbiamo appena creato una parola che non fa parte del vocabolario, loro non sanno cosa sia e non hanno un vettore per supportare quella parola. E quindi il linguaggio è una cosa viva. Sta costantemente cambiando. E quindi, se vuoi supportare l’intelligenza artificiale conversazionale, devi essere pronto ad affrontare la natura dinamica del linguaggio in modo costante.

Potrebbe non sembrare un vero problema (che le persone creino parole al volo tutto il tempo), ma lo è davvero. Non è solo un problema per due amici che chiacchierano in una stanza, ma è ancora più grande da un punto di vista aziendale.

Ogni giorno, qualcuno si sveglia e crea un nuovo prodotto con un marchio, e inventa una nuova parola, come Xembly, da mettere sopra alla loro cosa, è necessario assicurarsi di capire questo.

Quindi gran parte del nostro stack, prima di tutto, sta facendo in modo di avere un buon strumento per il labeling dei dati. Facciamo molta apprendimento semi-supervisionato, quindi dobbiamo essere in grado di raccogliere rapidamente i dati.

Dobbiamo essere in grado di etichettarli rapidamente. Dobbiamo essere in grado di produrre metriche sui dati che stiamo ottenendo solo dai feed di dati in tempo reale in modo che possiamo utilizzare dati non etichettati insieme ai nostri dati etichettati.

Penso che un altro componente enorme, come ho accennato in precedenza, sia che l’intelligenza artificiale conversazionale tende a richiedere pipeline di apprendimento automatico complesse. Di solito non puoi fare un’unica volta, “ecco un modello”, che gestisce tutto, indipendentemente da quello che stai leggendo oggi.

Nel mondo dei grandi modelli di linguaggio, di solito ci sono molte componenti per far funzionare uno stack end-to-end. E quindi abbiamo effettivamente bisogno di avere una pipeline completa di modelli. Dobbiamo essere in grado di aggiungere rapidamente pipeline a questo stack.

Significa che hai bisogno di un’architettura di pipeline solida in modo tale da poter inserire nuovi modelli ovunque in quella pipeline, se necessario, per far funzionare tutto come richiesto.

Risolvere diverse sfide nell’intelligenza artificiale conversazionale

Stephen: Se potessi guidarci attraverso il tuo stack end-to-end per i prodotti notevoli.

Vediamo quanto ogni sfida effettivamente rappresenta e magari come il tuo team le risolve.

Jason: Sì, lo stack è composto da diversi modelli.

Riconoscimento vocale

Inizia all’inizio con il convertire il parlato in testo; è come il componente fondamentale – quindi il riconoscimento vocale tradizionale.

Vogliamo rispondere alla domanda: “come prendiamo la registrazione audio che abbiamo qui e otteniamo un documento di testo da quella?”

Segmentazione degli interlocutori

Dato che stiamo affrontando dialoghi e conversazioni in cui non abbiamo canali audio distinti per ogni interlocutore, c’è un altro componente enorme nel nostro stack – la segmentazione degli interlocutori.

Ad esempio, potrei trovarmi in una situazione in cui ho una registrazione Zoom, in cui ci sono tre persone indipendenti su canali separati e poi ci sono sei persone in una stanza di conferenza che parlano su un singolo canale audio.

Per garantire che la trascrizione proveniente dal sistema di riconoscimento vocale si mappi correttamente al flusso di dialogo, dobbiamo effettivamente capire chi sta parlando distintamente.

Non basta dire, beh, quella era la sala conferenze B, e c’erano sei persone lì, ma capisco solo che è la sala conferenze B. Ho davvero bisogno di capire ogni singolo interlocutore perché parte della nostra soluzione richiede che capiamo effettivamente il dialogo – le interazioni reciproche.

Segmentazione dei parlanti non vedenti

Devo sapere che questa persona ha detto “no” a questa richiesta fatta da un’altra persona qui. Con il testo in parallelo, otteniamo una designazione del parlante che riteniamo stia parlando. Iniziamo un po’ con quello che chiamiamo “segmentazione dei parlanti non vedenti”.

Ciò significa che non sappiamo necessariamente chi è chi, ma sappiamo che ci sono persone diverse. Quindi successivamente cerchiamo di eseguire algoritmi di riconoscimento dell’impronta audio in modo da poter identificare effettivamente chi sono quelle persone se le abbiamo viste in passato. Anche dopo questo, abbiamo una sorta di ultima fase nella nostra pipeline. La chiamiamo la nostra “fase di formattazione”.

Fase di formattazione

Eseguiamo algoritmi di punteggiatura e una serie di altri piccoli pezzi di software in modo da ottenere una trascrizione ben strutturata, in cui siamo arrivati in questa fase ora, in cui sappiamo che Sabine stava parlando con Stephen che stava parlando con Jason. Abbiamo il testo che si assegna a quei confini. È ragionevolmente ben punteggiato. E ora abbiamo qualcosa che speriamo sia una trascrizione leggibile.

Divisione della pipeline di apprendimento automatico

Da lì, biforchiamo la nostra pipeline. Eseguiamo due percorsi paralleli:

1
Generazione di azioni da compiere.
2
Generazione di riepiloghi.

Per le azioni da compiere, eseguiamo modelli proprietari interni che cercano essenzialmente azioni parlate in quella trascrizione. Ma ciò si rivela insufficiente perché molte volte in una riunione, quello che le persone dicono è “posso farlo”. Se ti dessi le note della riunione alla fine della riunione e ottenessi qualcosa che dicesse azione, “Stephen ha detto, posso farlo”, non sarebbe molto utile per te, giusto?

Ci sono un sacco di cose che devono accadere una volta che ho trovato quella frase per trasformarla in pros ben scritti, come ho detto prima:

dobbiamo dereferenziare i pronomi.
dobbiamo tornare indietro nella trascrizione e capire cosa fosse.
lo riformattiamo.

Cerchiamo di riformulare quella frase in qualcosa di ben scritto. È come iniziare con il verbo, sostituire tutti quei pronomi, quindi “posso farlo” diventa “Stephen può aggiornare la presentazione con la nuova slide dell’architettura”.

Le altre cose che facciamo in quella pipeline sono eseguire componenti per l’estrazione del proprietario e l’estrazione della data di scadenza. L’estrazione del proprietario consiste nel capire a chi si riferisce una dichiarazione quando dico “io”, e quindi sapere a chi mi riferisco in quella trascrizione nel dialogo e assegnare correttamente il proprietario.

La rilevazione della data di scadenza, come abbiamo detto, è come trovo le date in quel sistema? Come le normalizziamo in modo da poterle presentare a tutti nella riunione?

Non che fosse semplicemente dovuto il martedì, ma il martedì in realtà significa il 3 gennaio 2023, in modo da poter mettere qualcosa nel tuo calendario in modo che tu possa farlo. Questa è la parte degli elementi di azione della nostra pila, e poi abbiamo la parte di riepilogo della nostra pila.

In quella parte della nostra pila [parte di riepilogo], cerchiamo effettivamente di fare due cose.

In primo luogo, cerchiamo di fare una segmentazione degli argomenti non vista, “come disegniamo le linee in questo dialogo che corrispondono approssimativamente a sezioni della conversazione?”

Quando abbiamo finito qui, qualcuno probabilmente tornerebbe indietro e ascolterebbe questa riunione o questo podcast e sarebbe in grado di raggrupparlo in sezioni che sembrano essere in linea con qualche tipo di argomento. Dobbiamo farlo, ma non sappiamo realmente quali siano quegli argomenti, quindi usiamo alcuni algoritmi.

A queste chiamiamo algoritmi di rilevamento del punto di cambiamento. Cerchiamo un cambiamento sistematico nel flusso della natura del linguaggio che ci dice che c’è stato una pausa.

Una volta che facciamo questo, essenzialmente eseguiamo una sintesi astrattiva. Quindi usiamo alcuni dei moderni modelli di linguaggio di grandi dimensioni per generare riepiloghi ben scritti di quei segmenti della conversazione in modo che quando quella parte della pila è finita, si ottengono due sezioni o azioni da compiere e ora sono riepiloghi ben scritti, tutti con dichiarazioni ben scritte che si possono sperabilmente inviare immediatamente alle persone subito dopo la riunione.

Build vs. open-source: quale modello di intelligenza artificiale conversazionale dovresti scegliere?

Stephen: Sembra che ci siano molti modelli e sequenze. Sembra un po’ complesso e ci sono molti oneri, il che è eccitante per noi perché possiamo superare la maggior parte di queste cose.

Hai menzionato che la maggior parte di questi modelli sono proprietari interni.

Solo per curiosità, dove utilizzi quelle strategie all’avanguardia o modelli preconfezionati e dove pensi che questi problemi siano già stati risolti rispetto alle cose che pensi possano essere risolte internamente?

Jason: Cerchiamo di evitare il problema del “non inventato qui”. Siamo più che felici di utilizzare modelli disponibili pubblicamente se esistono e ci aiutano a raggiungere i nostri obiettivi.

Di solito c’è un problema principale nella conversazione vocale che tende a richiedere la creazione di modelli personalizzati anziché l’utilizzo di modelli preconfezionati. Questo perché il dominio di cui abbiamo parlato in precedenza è così ampio: in realtà, è possibile ottenere risultati opposti utilizzando modelli molto grandi.

E statisticamente, il linguaggio su larga scala potrebbe non riflettere il linguaggio del tuo dominio, nel qual caso l’utilizzo di un modello grande potrebbe non fornire i risultati desiderati.

Vediamo ciò molto spesso nel riconoscimento vocale; un buon esempio potrebbe essere un sistema proprietario di riconoscimento vocale di, diciamo, Google, ad esempio.

Uno dei problemi che incontriamo è che Google ha dovuto addestrare i propri sistemi per gestire la trascrizione di tutto YouTube. Il linguaggio di YouTube non si adatta bene al linguaggio delle riunioni aziendali.

Questo non significa che non siano adatti per il contesto generale, lo sono. Quello che intendo è che YouTube rappresenta probabilmente meglio il linguaggio nello spazio del macro-dominio.

Noi ci occupiamo del sotto-dominio del linguaggio aziendale. Questo significa che se, in modo probabilistico, come fanno la maggior parte dei modelli di apprendimento automatico, si cercano di prevedere le parole in base all’insieme generale del linguaggio rispetto al tipo di dominio ristretto con cui abbiamo a che fare nel nostro mondo, spesso si prevederà la parola sbagliata.

In questi casi, abbiamo scoperto che è meglio costruire qualcosa, se non di proprietà, almeno addestrato sui nostri dati proprietari, internamente anziché utilizzare sistemi preconfezionati.

<pDetto questo, ci sono sicuramente casi di riassunto che ho menzionato in cui facciamo il riassunto delle informazioni. Penso che siamo arrivati a un punto in cui sarebbe folle non utilizzare un grande modello di linguaggio come GPT-3 per farlo.

Deve essere sintonizzato, ma penso che sarebbe folle non utilizzarlo come sistema di base perché i risultati superano ciò che si può ottenere in altro modo.

Riassumere il testo è difficile in modo tale che sia estremamente leggibile e la quantità di dati di testo che servirebbe acquisire per addestrare qualcosa che lo faccia bene, come una piccola azienda, non è più concepibile.

Ora abbiamo queste grandi aziende come OpenAI che lo hanno fatto per noi. Si sono impegnati e hanno speso somme ridicole per addestrare grandi modelli su quantità di dati che sarebbero difficili da ottenere per qualsiasi organizzazione più piccola.

Possiamo semplicemente sfruttarlo ora e ottenere alcuni dei vantaggi di questi riassunti molto ben scritti. Tutto quello che dobbiamo fare è adattarli e sintonizzarli per ottenere i risultati di cui abbiamo bisogno.

Le sfide nell’esecuzione di sistemi complessi di intelligenza artificiale conversazionale

Stephen: Sì, è molto interessante e mi piacerebbe approfondire le sfide che affronti nell’esecuzione di un sistema complesso perché gestire un sistema complesso può comportare problemi che vanno dalla configurazione del team ai problemi di calcolo, e poi si parla di dati di qualità.

Nella tua esperienza, quali sono le sfide che “interrompono il sistema” e che devi affrontare per farlo ripartire?

Jason: Sì, ci sono molti problemi nell’esecuzione di questo tipo di sistemi. Cercherò di coprirne alcuni.

Prima di entrare nel vivo della produzione di inferenze dal vivo, uno dei problemi più grandi è quello che chiamiamo “debito tecnico dell’apprendimento automatico” quando si eseguono questi sistemi a cascata.

Abbiamo una serie di modelli dipendenti o che possono diventare dipendenti l’uno dall’altro, e ciò può diventare problematico.

Questo accade perché quando addestri gli algoritmi successivi a gestire gli errori provenienti dagli algoritmi precedenti, l’introduzione di un nuovo sistema può causare il caos.

Ad esempio, diciamo che il mio motore di trascrizione commette molti errori nella trascrizione delle parole. Ho un membro del mio team il cui nome viene sempre trascritto in modo errato (non è un nome tradizionale in inglese).

Se costruiamo i nostri modelli di linguaggio successivi per cercare di mascherare ciò e compensarlo, cosa succede quando improvvisamente cambio il mio sistema di trascrizione o ne introduco uno nuovo che può gestirlo? Ora tutto crolla e si rompe.

Una delle cose che cerchiamo di fare è non incorporare l’errore dei nostri sistemi precedenti nei nostri sistemi successivi. Cerchiamo sempre di assumere che i nostri modelli più in fondo alla pipeline operino con dati puri in modo che non siano accoppiati, e ciò ci consente di aggiornare in modo indipendente tutti i nostri modelli e tutto il nostro sistema senza pagare idealmente quella penalità.

Ora, non siamo perfetti. Cerchiamo di farlo, ma a volte ci si trova in un angolo in cui non si ha altra scelta se si desiderano davvero risultati di qualità.

Ma idealmente, cerchiamo l’indipendenza completa dei modelli nel nostro sistema in modo che possiamo aggiornarli senza dover poi aggiornare ogni altro modello nella pipeline – questo è un pericolo in cui si può incorrere.

All’improvviso, quando ho aggiornato il mio sistema di trascrizione, non stavo più ottenendo quella parola che non stavo trascrivendo, ma ora devo aggiornare il mio sistema di punteggiatura perché è cambiato il modo in cui funziona la punteggiatura. Devo aggiornare il mio sistema di rilevamento delle azioni. Il mio algoritmo di sintesi non funziona più. Devo sistemare tutte queste cose.

Si può davvero cadere in un pericoloso baratro in cui il costo di apportare modifiche diventa estremo. Questo è un componente di esso.

L’altra cosa che abbiamo scoperto è che quando si esegue una catena di stack di algoritmi di apprendimento automatico, è necessario essere in grado di eseguire rapidamente nuovamente i sistemi attraverso la pipeline in qualsiasi componente della pipeline.

Fondamentalmente, per arrivare alla radice della tua domanda, tutti sappiamo che i sistemi di produzione si rompono. Succede tutto il tempo. Vorrei che non succedesse, ma succede.

Quando si eseguono algoritmi di apprendimento automatico in catena, se non si è estremamente attenti, si può incorrere in sistemi in cui i dati iniziano ad accumularsi e si ha una grande latenza se non si dispone di una capacità di archiviazione sufficiente e ovunque si conservino quei dati lungo la pipeline, le cose possono iniziare a implodere. Si possono perdere dati. Possono accadere tutte sorta di cose negative.

Se si mantiene correttamente i dati attraverso i vari stati del sistema e si costruisce un buon strumento in modo da poter costantemente eseguire rapidamente nuovamente le pipeline, allora si può scoprire che è possibile uscire dai guai.

Abbiamo costruito molti sistemi internamente in modo che se abbiamo un reclamo di un cliente o se non ha ricevuto qualcosa che si aspettava di ricevere, possiamo rapidamente individuare dove ha fallito la nostra pipeline e riavviarlo rapidamente da precisamente quel passaggio nella pipeline.

Dopo aver risolto qualsiasi problema che abbiamo scoperto, magari abbiamo avuto un piccolo bug che abbiamo distribuito accidentalmente, magari è stato solo un’anomalia, o abbiamo avuto un picco di memoria strano o qualcosa che ha causato il blocco del contenitore a metà pipeline.

Possiamo rapidamente colpire quel passaggio, farlo passare attraverso il resto del sistema e farlo uscire alla fine del cliente senza che i sistemi si bloccano ovunque e senza che si verifichi un fallimento catastrofico.

Stephen: Giusto, e queste pipeline vengono eseguite come servizi indipendenti, o ci sono diverse architetture per il modo in cui vengono eseguite?

Jason: Sì, quasi tutti i nostri modelli di sistema vengono eseguiti come servizi individuali, indipendenti. Utilizziamo:

Kubernetes e Containers: per la scalabilità.
Kafka: nostra soluzione di pipelining per passare messaggi tra tutti i sistemi.
Robin Hood Faust: ci aiuta a orchestrare i diversi modelli di apprendimento automatico lungo la pipeline. E abbiamo sfruttato anche quel sistema.

Come ha impostato Xembly il team di apprendimento automatico?

Stephen: Sì, è un ottimo punto.

Per quanto riguarda l’organizzazione del team, il team sfrutta esperti di linguaggio in qualche modo, o come sfrutta esperti di linguaggio? E anche dal lato delle operazioni, c’è un team separato per le operazioni, e poi ci sono i ricercatori o gli ingegneri ml che fanno queste pipeline e così via?

Fondamentalmente, come è organizzato il tuo team?

Jason: Per quanto riguarda il lato dell’apprendimento automatico della nostra squadra, ci sono tre componenti principali nel nostro team di machine learning:

Team di ricerca applicata: sono responsabili della costruzione dei modelli, della ricerca su “quali modelli abbiamo bisogno”, “quali tipi di modelli”, “come addestrarli e testarli”. Generalmente costruiscono i modelli, misurando costantemente la precisione e la completezza e apportando modifiche per cercare di migliorare l’accuratezza nel tempo.
Team di annotazione dei dati: il loro ruolo è di etichettare continuamente alcuni insiemi dei nostri dati.
Team del flusso di apprendimento automatico: questo team è responsabile dello sviluppo del software per ospitare tutti questi modelli, comprendere come i dati appaiano in input e in output, come devono essere scambiati tra i diversi modelli e l’intero stack.

Ad esempio, in tutte queste parti abbiamo parlato di Kafka, Faust, database MongoDB. Si preoccupano di come far interagire tutte queste cose insieme.

Sfide di calcolo e modelli di linguaggio estesi (LLM) in produzione

Stephen: Ottimo. Grazie per aver condiviso questo. Quindi penso che un’altra sfida principale che associamo al deployment di modelli di linguaggio estesi riguardi la potenza di calcolo quando si passa alla produzione, giusto? E questa è la sfida con GPT, come Sam Altman tweeterebbe sempre.

Sono solo curioso, come affronti questa sfida della potenza di calcolo in produzione?

Jason: Abbiamo effettivamente delle sfide di calcolo. Il riconoscimento vocale, in generale, richiede molta potenza di calcolo. La segmentazione degli altoparlanti, tutto ciò che riguarda principalmente il lato audio grezzo, tende a richiedere molta potenza di calcolo, quindi questi sistemi di solito richiedono GPU per farlo.

Prima di tutto, diciamo che abbiamo alcune parti del nostro stack, specialmente i componenti audio, che tendono a richiedere macchine GPU potenti per gestire il lato puramente linguistico, come il modello di elaborazione del linguaggio naturale. Alcuni di questi possono essere gestiti solo tramite elaborazione CPU. Non tutti, ma alcuni.

Per noi, una delle cose fondamentali è capire i diversi modelli nel nostro stack. Dobbiamo sapere quali modelli devono essere eseguiti su macchine diverse e assicurarci di poter ottenere questi diversi set di macchine.

Sfruttiamo Kubernetes e Amazon (AWS) per garantire che il nostro flusso di apprendimento automatico abbia diversi set di macchine su cui operare, a seconda dei tipi di modelli. Quindi abbiamo le nostre macchine GPU potenti e poi abbiamo le nostre macchine più tradizionali orientate alla CPU su cui possiamo eseguire le cose.

Per quanto riguarda il costo di tutto ciò e la sua gestione, tendiamo a cercare di fare due cose:

1. Ridimensionare in modo indipendente le nostre pod all’interno di Kubernetes
2. Ridimensionare anche gli host EC2 sottostanti.

Ci sono molte complessità nel farlo, e farlo bene. Ancora una volta, parlando di alcune delle cose menzionate in precedenza nel nostro sistema riguardo ai dati del flusso di lavoro e alle copie di backup e ai crash, si può incorrere in fallimenti catastrofici.

Non puoi permetterti di ridimensionare eccessivamente o insufficientemente le tue macchine. Devi assicurarti di essere efficace nel creare e spegnere macchine e farlo idealmente proprio prima che arrivino i dati di traffico.

Fondamentalmente, devi capire come fluiscono i tuoi dati di traffico. Devi assicurarti di impostare le metriche corrette, che sia in base al carico della CPU o alle richieste generali.

Idealemente, devi avviare le macchine al momento giusto in modo tale da essere sufficientemente in anticipo rispetto al traffico in entrata. Ma è assolutamente fondamentale per la maggior parte delle persone nel nostro settore che si faccia qualche tipo di scalabilità automatica.

In vari punti della mia carriera nel riconoscimento vocale, abbiamo dovuto far funzionare centinaia e centinaia di server per operare su larga scala. Può essere molto, molto costoso. Far funzionare quei server alle 03:00 del mattino, se il traffico è prevalentemente domestico negli Stati Uniti, significa solo sprecare soldi.

Se puoi ridurre il carico delle macchine durante quel periodo di notte, puoi risparmiare un sacco di soldi.

Come garantisce la qualità dei dati durante la creazione di prodotti di elaborazione del linguaggio naturale?

Stephen: Fantastico. Penso che saltiamo subito alle domande della comunità.

Giusto, quindi la prima domanda che questa persona pone, dati di qualità sono un requisito fondamentale per la creazione e l’utilizzo di AI conversazionali e prodotti NLP generali, giusto?

Come ti assicureresti che i tuoi dati siano di alta qualità durante l’intero ciclo di vita del prodotto?

Jason: Praticamente sì, è una domanda fantastica. La qualità dei dati è fondamentale.

Innanzitutto, direi che cerchiamo effettivamente di raccogliere i nostri dati. Abbiamo scoperto che in generale molti dei dataset pubblici disponibili non sono sufficienti per le nostre esigenze. Questo è particolarmente un grande problema nel campo del discorso conversazionale.

Ci sono molte ragioni per questo. Una. Solo per tornare alla dimensione dei dati, una volta ho fatto una stima approssimativa di quale fosse la dimensione approssimativa del discorso conversazionale, e ho ottenuto un numero, tipo 1,25 quintilioni di affermazioni che sarebbe necessario coprire approssimativamente l’intera dimensione del discorso conversazionale.

Questo perché il discorso soffre – oltre a un gran numero di parole, possono essere unite all’infinito. Possono essere unite all’infinito perché, come probabilmente scoprirete quando modificherete questo podcast, parliamo in modo incoerente. Va bene, siamo in grado di capirci nonostante ciò.

Non c’è molta struttura grammaticale effettiva nel discorso parlato. Cerchiamo, ma in realtà generalmente non segue regole grammaticali come facciamo per il discorso scritto. Quindi il dominio del discorso scritto è grande.

Il dominio del discorso conversazionale è veramente infinito. Le persone balbettano. Ripetono le parole. Se stai operando su trigrammi, ad esempio, devi accettare “I I I,” la parola “I” tre volte di seguito balbettata come un’affermazione valida, perché succede tutto il tempo.

Ora espandi tutto questo al mondo di tutte le parole e tutte le combinazioni, e ti trovi letteralmente in un set di dati infinito. Quindi hai il problema della scala in cui non ci sono dati sufficienti disponibili in primo luogo.

Ma hai anche altri problemi legati alla privacy, alla legalità, ci sono tutti tipi di questioni. Perché non ci sono grandi set di dati conversazionali disponibili? Molte aziende non sono disposte a mettere online tutte le registrazioni delle loro riunioni per farle ascoltare al mondo.

Questo non succede proprio. C’è un limite alla quantità di dati, se cerchi set di dati conversazionali che sono disponibili, come registrazioni audio dal vivo effettive, alcuni di essi sono stati creati artificialmente, alcuni di essi sono come dati di conferenza, non sono realmente collegati al mondo reale.

A volte puoi trovare riunioni governative, ma ancora una volta, queste non sono collegate al mondo con cui stai lavorando. In generale, finisci per dover raccogliere i tuoi dati anziché sfruttare i dati disponibili su Internet.

E quindi la domanda successiva è, una volta che hai i tuoi dati, come ti assicuri che la qualità di quei dati sia effettivamente sufficiente? Ed è un problema molto difficile.

Hai bisogno di una buona squadra di annotazione dei dati per iniziare e di strumenti molto, molto buoni. Abbiamo fatto uso di Label Studio, che è un software open source. Credo ci sia anche una versione a pagamento – facciamo un buon uso di questo strumento per etichettare rapidamente molti dati, è necessario fornire ai tuoi annotatori di dati strumenti adeguati.

Credo che le persone sottovalutino quanto sia importante effettivamente l’attrezzatura per l’etichettatura dei dati. Cerchiamo anche di applicare alcune metriche ai nostri dati in modo da poter analizzare la qualità del set di dati nel tempo.

Eseguiamo costantemente quello che chiamiamo il nostro “file di incoerenza”. Qui prendiamo ciò che i nostri annotatori hanno etichettato e lo facciamo passare attraverso il nostro modello, e verifichiamo dove ci sono differenze.

Quando tutto è finito, facciamo una valutazione manuale per verificare se i dati sono stati etichettati correttamente, e ripetiamo quel processo nel tempo.

In sostanza, controlliamo costantemente la nuova etichettatura dei dati rispetto alle previsioni del nostro modello nel tempo, in modo da essere sicuri che il nostro set di dati rimanga di alta qualità.

In quali domini lavora il team di machine learning?

Stephen: Sì, penso che abbiamo dimenticato di chiedere la prima parte dell’episodio, ero curioso, in quali domini lavora il team? È un dominio aziendale o solo un dominio generale?

Jason: Sì, in generale è il dominio aziendale. In generale, nelle riunioni aziendali, quel dominio è ancora abbastanza ampio nel senso che non siamo particolarmente focalizzati su un determinato settore.

Ci sono molti tipi di attività commerciali nel mondo, ma principalmente sono aziende. Non si tratta di consumatore-consumatore. Non è come se chiamassi mia madre, sono dipendenti di un’azienda che parlano tra loro.

Testare prodotti di intelligenza artificiale conversazionale

Stephen: Sì, e sono curioso, questa prossima domanda, a proposito, proviene da alcune aziende che vogliono sapere qual è la tua strategia di test per l’intelligenza artificiale conversazionale e in generale per i prodotti di NLU?

Jason: Abbiamo scoperto che testare il linguaggio naturale è davvero difficile in termini di costruzione del modello. Ovviamente abbiamo un set di dati di addestramento e test. Seguiamo le regole tradizionali della costruzione del modello di machine learning per assicurarci di avere un buon set di test che valuti i dati.

A volte abbiamo cercato di assegnare dei set di dati “d’oro”, riunioni “d’oro” per il nostro flusso di annotazione delle note, in modo da poter controllare almeno per avere una valutazione generale, “hey, questo nuovo sistema sta facendo le cose giuste in generale”.

Ma poiché il sistema è così grande, spesso abbiamo scoperto che quei test non sono altro che un controllo generale. Non sono davvero validi per una valutazione reale su larga scala, quindi di solito testiamo in tempo reale: è l’unico modo che abbiamo trovato per farlo in un dominio illimitato.

Funziona in due modi diversi a seconda della fase di sviluppo in cui ci troviamo. A volte implementiamo i modelli e li eseguiamo con dati in tempo reale senza utilizzare effettivamente i risultati per i clienti.

Abbiamo strutturato tutti i nostri sistemi perché abbiamo un sistema di apprendimento automatico a catena molto ben costruito in cui possiamo inserire passaggi di apprendimento automatico ovunque nel flusso di lavoro e eseguire passaggi paralleli che ci consentono di dire a volte, “hey, eseguiremo un modello in modalità silenziosa”.

Abbiamo un nuovo modello per prevedere gli elementi d’azione, lo eseguiremo e scriveremo i risultati. Ma il resto del flusso di lavoro funzionerà con il vecchio modello, ma almeno ora possiamo fare un test pubblicitario e osservare cosa hanno prodotto entrambi i modelli e vedere se sembra che stiamo ottenendo risultati migliori o peggiori.

Ma anche dopo questo, molto spesso, mettiamo in produzione un nuovo modello solo su una percentuale del traffico e poi valutiamo alcune euristiche o metriche di alto livello per vedere se stiamo ottenendo risultati migliori.

Un buon esempio nel nostro mondo sarebbe che speriamo che i clienti condividano i riassunti delle riunioni che inviamo loro. Ed è molto facile per noi, ad esempio, cambiare un algoritmo nel flusso di lavoro e poi andare a vedere, “hey, i nostri clienti condividono i nostri appunti di riunione più spesso?”

Perché la condivisione degli appunti di riunione tende a essere un buon indicatore della qualità di ciò che abbiamo consegnato al cliente. E quindi c’è un’ottima euristica che possiamo monitorare per dire, “hey, abbiamo migliorato o peggiorato con questo?”

In generale, è così che testiamo. Molto test in tempo reale. Di nuovo, principalmente a causa della natura del dominio. Se stai operando in un dominio quasi infinito, non c’è un set di test che probabilmente quantificherà se stai migliorando o meno.

Mantenere l’equilibrio tra monitoraggio ML e test

Stephen: E qual è il confine tra il monitoraggio in produzione e il vero e proprio testing?

Jason: Voglio dire, stiamo sempre monitorando tutte le parti della nostra infrastruttura. Stiamo costantemente cercando euristiche semplici sugli output del nostro modello che potrebbero indicarci se qualcosa è andato storto.

Ci sono metriche come la perplessità, che è qualcosa che usiamo per il linguaggio per capire se stiamo producendo del nonsense.

Possiamo fare cose semplici come contare il numero di elementi d’azione che prevediamo in una riunione e che monitoriamo costantemente per capire se stiamo andando fuori strada, insieme a tutti i tipi di monitoraggio che facciamo per la salute generale del sistema.

Per esempio:

Tutti i contenitori Docker sono in esecuzione?
Stiamo consumando troppa CPU o troppa memoria?

Questo è un lato dell’infrastruttura che penso sia un po’ diverso dal lato della costruzione del modello, dove stiamo costantemente costruendo e poi eseguendo i nostri dati di addestramento che produciamo e inviamo come parte di una build giornaliera per i nostri modelli.

Vediamo costantemente le nostre metriche di precisione-recall mentre etichettiamo i dati in tempo reale e acquisiamo nuovi dati. Possiamo costantemente testare le costruzioni del modello per vedere se le nostre metriche di precisione-recall stanno forse andando fuori controllo in una direzione o nell’altra.

Strumenti open-source per l’IA conversazionale

Stephen: Sì, è interessante. Bene, passiamo subito alla domanda successiva che questa persona ha posto: Puoi consigliare degli strumenti open-source per l’IA conversazionale?

Jason: Sì, certo. Nello spazio del riconoscimento vocale, ci sono sistemi di riconoscimento vocale come Kaldi – lo consiglio vivamente; È stato uno dei pilastri del riconoscimento vocale per un po’ di tempo.

Ci sono sicuramente sistemi più recenti, ma si possono fare cose incredibili con Kaldi per avviare e far funzionare i sistemi di riconoscimento vocale.

Chiaramente, sistemi come GPT-3, li consiglierei vivamente alle persone. È un ottimo strumento. Penso che debba essere adattato. Si otterranno risultati migliori se si affina, ma hanno fatto un ottimo lavoro nel fornire API e rendere facile aggiornarle quando necessario.

Facciamo molto uso di sistemi come SpaCy per la rilevazione delle entità. Se stai cercando di avviarti nel processing del linguaggio naturale in qualsiasi modo, ti consiglio vivamente di conoscere bene SpaCy. È un ottimo sistema. Funziona fantasticamente già di base. Ci sono tutti i tipi di modelli. Migliora costantemente nel corso degli anni.

E ho già accennato, solo per l’etichettatura dei dati, utilizziamo Label Studio, che è uno strumento open-source per l’etichettatura dei dati che supporta l’etichettatura di tutti i tipi di contenuti audio, testo e video. Sono davvero facili da avviare e iniziare rapidamente ad etichettare i dati. Lo consiglio vivamente a chiunque stia cercando di iniziare.

Come costruire prodotti di IA conversazionale per grandi aziende su larga scala

Stephen: Bene, grazie per la condivisione. Prossima domanda.

La persona chiede: “Come costruire prodotti di IA conversazionale per grandi aziende su larga scala?” Quali fattori considereresti quando inizi il progetto?

Jason: Sì, direi che con organizzazioni su larga scala in cui si gestiscono carichi di traffico molto elevati, penso che il problema più grande sia il costo e la scala.

Finirai per aver bisogno di molta, molta capacità di server per gestire quel tipo di scala in un’organizzazione di grandi dimensioni. E quindi, il mio consiglio è di pensare davvero all’aspetto operativo vero e proprio di quella stack. Che tu stia usando Kubernetes o Amazon, devi pensare a quei componenti di autoscaling:

Quali sono le metriche che attiveranno l’autoscaling?
Come fai a farlo funzionare?

Scala i pod e Kubernetes su host EC2 con autoscaling è effettivamente non banale da far funzionare rapidamente. Abbiamo già parlato anche della complessità legata a alcuni tipi di modelli che tendono generalmente a necessitare di GPU per il calcolo, altri no.

Quindi come distribuisci i tuoi sistemi sui tipi corretti di nodi e li scala in modo indipendente? E penso che finisca anche per essere una considerazione su come allocare quelle macchine.

Quali macchine acquisti in base al traffico? Quali macchine riservi? Acquisti istanze spot per ridurre i costi? Queste sono tutte considerazioni in un’azienda su larga scala che devi valutare quando avvii e fai funzionare queste cose se vuoi avere successo su larga scala.

Deploy di prodotti di IA conversazionale su dispositivi edge

Stephen: Fantastico. Grazie per aver condiviso questo.

Quindi passiamo subito alla prossima. Come affronti la distribuzione e le sfide generali di produzione con prodotti di IA conversazionale su dispositivi on-device?

Jason: Quando diciamo on-device, intendiamo su server o su dispositivi più limitati?

Stephen: Oh sì, dispositivi limitati. Quindi dispositivi edge e dispositivi che non hanno quella potenza di calcolo.

Jason: Sì, in generale, non ho avuto a che fare con il deploy di modelli su piccoli dispositivi di calcolo da alcuni anni. Posso solo condividere la mia esperienza storica per cose come la telecamera connessa. Quando ci ho lavorato, ad esempio.

Abbiamo distribuito parte del carico tra il dispositivo e il cloud. Per le cose che richiedono una risposta veloce e una bassa latenza, eseguiamo componenti a piccola scala nel dispositivo, ma poi trasferiamo i componenti più complessi al cloud.

Non so quanto sia pertinente per rispondere alla domanda di questo utente, ma è qualcosa con cui mi sono occupato in passato, dove di base si esegue un sistema di riconoscimento vocale molto leggero sul dispositivo per rilevare una parola di attivazione o semplicemente far partire il sistema.

Ma una volta avviato, tutte le richieste su larga scala vengono inviate a un’istanza cloud perché in generale non si può gestire il calcolo di alcuni di questi sistemi su un dispositivo piccolo e limitato.

Dibattito su ChatGPT

Stephen: Credo che sarebbe un peccato se non discutessimo di ChatGPT in questo episodio. E sono solo curioso, questa è una domanda comune, tra l’altro.

Cosa ne pensi di ChatGPT e di come le persone lo stanno usando oggi?

Jason: Sì, oh mio Dio, dovresti avermelo chiesto all’inizio perché probabilmente potrei parlarne per un’ora e mezza.

ChatGPT e GPT, in generale, sono incredibili. Ne abbiamo già parlato molto, ma grazie al fatto che è stato addestrato su così tanto linguaggio, può fare cose davvero straordinarie e scrivere testi bellissimi con poche informazioni di input.

Ma ci sono sicuramente alcune avvertenze nell’uso di questi sistemi.

Una è, come abbiamo già detto, che è ancora un set di addestramento fisso. Non viene aggiornato dinamicamente, quindi una cosa da considerare è se può effettivamente mantenere uno stato all’interno di una sessione. Se inventi una nuova parola durante un dialogo, in genere sarà in grado di usare quella parola successivamente nella conversazione.

Ma se termini la sessione e ci ritorni, non avrà più conoscenza di quella parola. Altre cose di cui preoccuparsi, sempre perché è fisso, è che conosce solo cose fino al 2021 e prima.

La versione originale di GPT3 risale al 2018 e prima, quindi non è a conoscenza degli eventi moderni. Ma penso che forse la cosa più importante che abbiamo scoperto usando questo sistema, è che è un grande modello di linguaggio, funzionalmente sta prevedendo la parola successiva. Non è intelligente, non è intelligente in alcun modo.

Prende l’encoding umano dei dati, che abbiamo codificato come linguaggio, e poi impara a prevedere la parola successiva, il che si rivela essere un buon indicatore di intelligenza ma non è intelligenza stessa. Ciò che succede a causa di ciò è che GPT3 o ChatGPT inventeranno dei dati perché stanno solo prevedendo la parola più probabile successiva.

Ciò che è un po’ spaventoso di ChatGPT è che scrive così bene che può dire falsità in modo molto convincente che, se non prestate molta attenzione ai dettagli, potreste anche non accorgervene. Questa è forse la cosa più spaventosa.

Può trattarsi di una sottilità come una negazione. Se non state davvero leggendo ciò che restituisce, potrebbe aver fatto qualcosa di semplice come una negazione, che avrebbe dovuto essere una dichiarazione positiva. Potrebbe aver trasformato una risposta affermativa in una negativa o potrebbe aver aggiunto un apostrofo alla fine di qualcosa.

Se leggete rapidamente, i vostri occhi lo scorreranno solo e non lo noteranno, ma potrebbe essere completamente sbagliato dal punto di vista dei fatti. In qualche modo, stiamo soffrendo di un eccesso di grandezza. È diventato così bravo, è così sorprendente a scrivere che ora abbiamo il rischio che il problema sia che l’umano che lo valuta potrebbe effettivamente non accorgersi che ciò che ha scritto è factualmente incorretto, solo perché legge molto bene.

Penso che questi sistemi siano incredibili; penso che cambieranno fondamentalmente il modo in cui molte persone lavorano nell’apprendimento automatico e nell’elaborazione del linguaggio naturale, e cambieranno semplicemente il modo in cui le persone interagiscono.

Riguardo ai computer in generale, penso che tutti dovremmo essere consapevoli del fatto che non è una cosa magica che funziona solo al momento. È pericoloso presumere che lo sia. Se vuoi usarlo per te stesso, ti suggerisco vivamente di personalizzarlo.

Se stai cercando di usarlo così com’è e generare contenuti per le persone o qualcosa del genere, ti suggerisco vivamente di consigliare ai tuoi clienti di rivedere e leggere. E non condividere ciecamente ciò che ottengono da esso, perché c’è una possibilità ragionevole che ciò che c’è dentro potrebbe non essere corretto al 100%.

Conclusione

Stephen: Fantastico. Grazie, Jason. Quindi questo è tutto da parte mia.

Sabine: Sì, grazie per i commenti extra bonus su ciò che, suppongo, è ancora convincente, ma è solo una fabbricazione per ora. Vediamo dove va. Ma sì, grazie, Jason, per essere venuto e per aver condiviso la tua esperienza e i tuoi consigli.

È stato bello averti qui.

Jason: Sì, grazie Stephen è stato davvero fantastico. Mi è piaciuta molto la conversazione.

Sabine: Prima di lasciarti, come possono le persone seguire ciò che stai facendo online? Forse mettersi in contatto con te?

Jason: Sì, puoi seguire Xembly online su www.xembly.com. Puoi contattarmi. Basta il mio nome, [email protected]. Se hai domande, sarò felice di rispondere. Sì, dai un’occhiata al nostro sito web, vedi cosa sta succedendo. Cerchiamo di tenere le persone aggiornate regolarmente.

Sabine: Fantastico. Grazie mille. E qui a mlops Live, torneremo tra due settimane, come sempre. E la prossima volta, avremo con noi Silas Bempong e Abhijit Ramesh, parleremo di come fare MLOps per studi di ricerca clinica.

Nel frattempo, ci vediamo sui social e nella community di MLOps slack. Ci vediamo molto presto. Grazie e stai bene.

MLOps,Natural Language Processing

Gli modelli come GPT-4 si comportano in modo sicuro quando viene loro data la capacità di agire? Questo articolo sull’IA introduce il benchmark MACHIAVELLI per migliorare l’etica delle macchine e costruire agenti adattivi più sicuri