Strategie di prodotto dal machine learning classico per adattarsi (o abbandonare) al mondo dell’intelligenza artificiale generativa
Anni fa, il primo consiglio che mi diede il mio capo di Opendoor fu conciso: “Investire nel backtesting. I team di prodotto AI riescono o falliscono in base alla qualità dei loro backtesting”. A quel tempo, questo consiglio era provato e vero; era stato imparato nel modo più duro dai team di ricerca, raccomandazioni, scienze della vita, finanza e altri prodotti ad alto rischio. È un consiglio che mi è stato caro per gran parte di un decennio.
Ma sono arrivato a credere che non sia assiomatico per la costruzione generativo Prodotti di intelligenza artificiale. Un anno fa sono passato dai classici prodotti ML (che producono output semplici: numeri, categorie, elenchi ordinati) a prodotti di intelligenza artificiale generativa. Lungo il percorso, ho scoperto che molti principi del machine learning classico non servono più a me e ai miei team.
Attraverso il mio lavoro presso Tome, dove sono responsabile del prodotto, e le conversazioni con i leader delle startup di intelligenza artificiale generativa, ho riconosciuto 3 comportamenti che distinguono i team che forniscono le funzionalità di intelligenza artificiale generativa più potenti e utili. Queste squadre:
- Lavora contemporaneamente all’indietro (dai problemi degli utenti) e in avanti (dalle opportunità tecnologiche)
- Progettare circuiti di feedback a basso attrito fin dall’inizio
- Riconsiderare gli strumenti di ricerca e sviluppo del machine learning classico
Questi comportamenti richiedono il “disimparare” numerose cose che rimangono le migliori pratiche per il machine learning classico. All’inizio alcuni potrebbero sembrare controintuitivi. Tuttavia, si applicano alle applicazioni di intelligenza artificiale generativa in generale, spaziando dal software orizzontale a quello verticale, dalle startup agli operatori storici. Immergiamoci!
(Ti chiedi perché il backtest automatizzato non è più un principio per i team che si occupano di applicazioni di intelligenza artificiale generativa? E con cosa sostituirlo? Continua a leggere il Principio 3)
(Più interessato alle tattiche, piuttosto che ai processi, per quanto l’interfaccia utente/UX delle app di intelligenza artificiale generativa dovrebbe differire dai classici prodotti ML? Dai un’occhiata a questo post del blog.)
“Lavorare a ritroso” partendo dai problemi degli utenti è un credo in molti ambienti di prodotto e design, reso famoso da Amazon. Studia gli utenti, valuta i loro punti critici, scrivi i requisiti UX per mitigare quello principale, identifica la migliore tecnologia da implementare, quindi risciacqua e ripeti. In altre parole, capire “Questo è il chiodo più importante da colpire, quindi quale martello usare”.
Questo approccio ha meno senso quando le tecnologie abilitanti avanzano molto rapidamente. ChatGPT non è stato creato lavorando a ritroso a partire da un punto critico dell’utente. È decollato perché ha offerto una tecnologia nuova e potente attraverso un’interfaccia utente semplice e aperta. In altre parole: “Abbiamo inventato un nuovo martello, vediamo quali chiodi colpiranno con quello”.
I migliori team di applicazioni di intelligenza artificiale generativa lavorano avanti e indietro simultaneamente. Eseguono la ricerca sugli utenti e comprendono l’ampiezza e la profondità dei punti critici. Ma non avanzano semplicemente in sequenza attraverso una lista classificata. Tutti i membri del team, PM e designer inclusi, sono profondamente immersi nei recenti progressi dell’intelligenza artificiale. Collegano queste opportunità tecnologiche in espansione ai punti critici degli utenti in modi che sono spesso più complessi delle mappature uno a uno. Ad esempio, un team vedrà che i punti critici degli utenti n. 2, n. 3 e n. 6 potrebbero essere tutti mitigati tramite la svolta del modello X. Quindi potrebbe avere senso che il progetto successivo si concentri sul “lavorare avanti” incorporando la svolta del modello X. , piuttosto che “lavorare all’indietro” dal punto dolente n. 1.
Immergersi profondamente nei recenti progressi dell’intelligenza artificiale significa comprendere come si applicano alla tua applicazione nel mondo reale, non limitarsi a leggere documenti di ricerca. Ciò richiede la prototipazione. Finché non si prova una nuova tecnologia nel proprio ambiente applicativo, le stime dei vantaggi per l’utente sono solo speculazioni. L’elevata importanza della prototipazione richiede di ribaltare la tradizione spec → prototipo → build processo a prototipo → specifica → build. Vengono scartati più prototipi, ma questo è l’unico modo per specificare in modo coerente funzionalità che corrispondano alle nuove tecnologie utili alle esigenze ampie e profonde degli utenti.
Feedback per il miglioramento del sistema
I prodotti ML classici producono tipi di output relativamente semplici: numeri, categorie, elenchi ordinati. E gli utenti tendono ad accettare o rifiutare questi risultati: fai clic su un collegamento nella pagina dei risultati di ricerca di Google o contrassegni un’e-mail come spam. Ogni interazione dell’utente fornisce dati che vengono reimmessi direttamente nella riqualificazione del modello, quindi il collegamento tra l’uso nel mondo reale e il miglioramento del modello è forte (e meccanico).
Sfortunatamente, la maggior parte dei prodotti di intelligenza artificiale generativa tendono a non produrre nuovi dati di addestramento concreti ad ogni interazione dell’utente. Questa sfida è legata a ciò che rende i modelli generativi così potenti: la loro capacità di produrre artefatti complessi che combinano testo, immagini, video, audio, codice, ecc. Per un artefatto complesso, è raro che un utente lo “prendi o lo lasci” . La maggior parte degli utenti, invece, perfeziona l’output del modello, con un’intelligenza artificiale maggiore/diversa o manualmente. Ad esempio, un utente può copiare l’output di ChatGPT in Word, modificarlo e quindi inviarlo a un collega. Questo comportamento impedisce all’applicazione (ChatGPT) di “vedere” la forma finale desiderata dell’artefatto.
Una delle implicazioni è consentire agli utenti di eseguire l’iterazione dell’output all’interno dell’applicazione. Ma ciò non elimina il problema: quando un utente non esegue l’iterazione su un output, significa “wow” o “guai”? Potresti aggiungere un indicatore del sentiment (ad esempio pollice su/giù) a ciascuna risposta dell’IA, ma i tassi di risposta al feedback a livello di interazione tendono ad essere molto Basso. E le risposte fornite tendono ad essere sbilanciate verso gli estremi. Gli utenti percepiscono per lo più gli sforzi di raccolta del sentiment come un ulteriore attrito, poiché nella maggior parte dei casi non aiutano l’utente a ottenere immediatamente un risultato migliore.
Una strategia migliore consiste nell’identificare un passaggio nel flusso di lavoro dell’utente che indichi che “questo output ora è abbastanza buono”. Crea questo passaggio nella tua app e assicurati di registrare l’aspetto dell’output a questo punto. Per Tome, dove aiutiamo gli utenti a creare presentazioni con l’intelligenza artificiale, il passaggio chiave è condividere una presentazione con un’altra persona. Per inserirlo nella nostra app, abbiamo investito molto nella condivisione delle funzionalità. E poi valutiamo quali output dell’intelligenza artificiale erano “condivisibili” e quali richiedevano un massiccio editing manuale per essere condivisibili.
Feedback per l’assistenza agli utenti
Il testo libero è emerso come il metodo dominante desiderato dagli utenti per interagire con le applicazioni di intelligenza artificiale generativa. Ma il testo libero è un vaso di Pandora: fornisci a un utente un input di testo libero per l’intelligenza artificiale e chiederà al prodotto di fare ogni sorta di cose che non può. Il testo libero è un meccanismo di input notoriamente difficile attraverso il quale trasmettere i vincoli di un prodotto; al contrario, un modulo web vecchio stile rende molto chiaro quali informazioni possono e devono essere inviate e esattamente in quale formato.
Ma gli utenti non vogliono moduli quando svolgono lavori creativi o complessi. Vogliono testo libero e indicazioni su come creare suggerimenti efficaci, specifici per il loro compito da svolgere. Le tattiche per assistere gli utenti includono prompt o modelli di esempio, indicazioni sulla lunghezza e la formattazione ottimali dei prompt (dovrebbero includere esempi di pochi scatti?). Anche i messaggi di errore leggibili dall’uomo sono fondamentali (ad esempio: “Questo messaggio era nella lingua X, ma supportiamo solo le lingue Y e Z.”)
Un risultato degli input di testo libero è che le richieste non supportate possono essere una fantastica fonte di ispirazione per cosa costruire dopo. Il trucco sta nell’essere in grado di identificare e raggruppare ciò che gli utenti stanno cercando di fare in testo libero. Ne parleremo più avanti nella prossima sezione…
Qualcosa da costruire, qualcosa da conservare, qualcosa da scartare
Costruzione: analisi del linguaggio naturale
Molte applicazioni di intelligenza artificiale generativa consentono agli utenti di perseguire flussi di lavoro molto diversi dallo stesso punto di ingresso: un’interfaccia aperta e con testo libero. Gli utenti non selezionano da un menu a discesa “Sto facendo brainstorming” o “Voglio risolvere un problema di matematica”: il flusso di lavoro desiderato è implicito nel testo inserito. Pertanto, per comprendere i flussi di lavoro desiderati dagli utenti è necessario segmentare l’input di testo libero. È probabile che alcuni approcci di segmentazione siano duraturi: noi di Tome siamo sempre interessati alla lingua e al tipo di pubblico desiderati. Esistono anche segmentazioni ad hoc, per rispondere a domande specifiche sulla roadmap del prodotto: ad esempio, quanti prompt richiedono un elemento visivo come un’immagine, un video, una tabella o un grafico, e quindi su quale elemento visivo dovremmo investire?
L’analisi del linguaggio naturale dovrebbe integrare, e non sostituire, gli approcci di ricerca tradizionali. La PNL è particolarmente potente se abbinata a dati strutturati (ad esempio, SQL tradizionale). Molti dati chiave non sono testo libero: quando si è registrato l’utente, quali sono gli attributi dell’utente (organizzazione, lavoro, area geografica, ecc.). Noi di Tome tendiamo a considerare i cluster linguistici in base alla funzione lavorativa, all’area geografica e allo stato dell’utente libero/a pagamento, che richiedono tutti SQL tradizionale.
E non si dovrebbe mai fare affidamento sugli insight quantitativi senza insight qualitativi. Ho scoperto che osservare un utente mentre naviga nel nostro prodotto vivere a volte può generare 10 volte la visione di un’intervista con un utente (in cui l’utente discute la sua impressione sul prodotto post-hoc). E ho trovato scenari in cui una buona intervista con un utente ha sbloccato 10 volte la comprensione dell’analisi quantitativa.
Keep: strumenti per la prototipazione low-code
Due tipi di strumenti consentono lo sviluppo di app AI generative ad alta velocità e di alta qualità: strumenti di prototipazione e strumenti di valutazione della qualità dell’output.
Esistono molti modi diversi per migliorare un’applicazione ML, ma esiste una strategia veloce e accessibile ingegneria tempestiva. È veloce perché non richiede la riqualificazione del modello; è accessibile perché coinvolge il linguaggio naturale, non il codice. Consentire ai non tecnici di manipolare approcci ingegneristici tempestivi (in un ambiente di sviluppo o locale) può aumentare notevolmente la velocità e la qualità. Spesso questo può essere implementato tramite un notebook. Il notebook può contenere molto codice, ma un non ingegnere può fare progressi significativi ripetendo le istruzioni in linguaggio naturale senza toccare il codice.
Valutare la qualità dell’output del prototipo è spesso piuttosto difficile, soprattutto quando si crea una funzionalità completamente nuova. Piuttosto che investire nella misurazione automatizzata della qualità, ho trovato molto più veloce e utile interrogare colleghi o utenti in un “programma beta tester” per 10-100 valutazioni strutturate (punteggi + note). La tecnologia abilitante per un “approccio polling” può essere leggera: un taccuino per generare esempi di input/output su scala modesta e inserirli in un foglio Google. Ciò consente di parallelizzare la valutazione manuale e normalmente è facile valutare circa 100 esempi, tra una manciata di persone, in meno di un giorno. Le note dei valutatori, che forniscono informazioni sui modelli di fallimento o di eccellenza, rappresentano un ulteriore vantaggio; le note tendono ad essere più utili per identificare cosa correggere o costruire successivamente rispetto ai punteggi numerici.
Scarto: misure di qualità automatizzate e verificate
Un principio dell’ingegneria ML classica è investire in un robusto backtest. I team riqualificano frequentemente i modelli classici (settimanalmente o giornalmente) e un buon backtest garantisce che solo i nuovi candidati validi vengano rilasciati in produzione. Ciò ha senso per i modelli che emettono numeri o categorie, che possono essere facilmente valutati rispetto a un insieme di verità.
Ma la precisione del punteggio è più difficile con output complessi (forse multimodali). Potresti avere un testo che consideri eccezionale e quindi sei propenso a chiamarlo “verità fondamentale”, ma se l’output del modello si discosta da esso di 1 parola, è significativo? Con 1 frase? E se i fatti fossero tutti uguali, ma la struttura fosse diversa? E se fossero testo e immagini insieme?
Ma non tutto è perduto. Gli esseri umani tendono a trovare facile valutare se l’output dell’intelligenza artificiale generativa soddisfa i loro standard di qualità. Ciò non significa che sia facile trasformare un output scadente in buono, ma solo che gli utenti tendono ad essere in grado di esprimere un giudizio se testo, immagine, audio, ecc. siano “buoni o cattivi” in pochi secondi. Inoltre, la maggior parte dei sistemi di intelligenza artificiale generativa a livello di applicazione non vengono riqualificati su base giornaliera, settimanale o addirittura mensile, a causa dei costi di calcolo e/o delle lunghe tempistiche necessarie per acquisire un segnale utente sufficiente a garantire la riqualificazione. Quindi non abbiamo bisogno di processi di valutazione della qualità eseguiti ogni giorno (a meno che tu non sia Google, Meta o OpenAI).
Data la facilità con cui gli esseri umani possono valutare l’output dell’intelligenza artificiale generativa e la rarità della riqualificazione, spesso ha senso valutare i nuovi candidati modello sulla base di test manuali interni (ad esempio l’approccio di polling descritto nella sottosezione precedente) piuttosto che su un backtest automatizzato.
Fonte: towardsdatascience.com
