Andrew Missey, CTO e Co-Fondatore di Convos – Serie di Interviste

Andrew Missey, CTO e Co-Fondatore di Convos, è un ingegnere software e leader di prodotto con esperienza che spazia dalla sviluppo di prodotti AI alla progettazione di software, networking e ingegneria full-stack. Prima di co-fondare Convos, ha aiutato a sviluppare e lanciare due piattaforme creative e di marketing alimentate da AI presso Forum3, combinando ingegneria pratica con gestione tecnica del prodotto. I suoi ruoli precedenti in N-able (NABL ), Autoshop Solutions e Brand IQ hanno comportato la costruzione di applicazioni frontend, sistemi backend, dashboard client e strumenti software interni utilizzando tecnologie come Svelte, NestJS, Angular e JavaScript. Questo background multidisciplinare gli ha permesso di colmare il divario tra esecuzione tecnica e strategia di prodotto mentre guidava lo sviluppo della piattaforma di comunicazione alimentata da AI di Convos.

Convos è una piattaforma di texting alimentata da AI controllata progettata per aiutare le campagne politiche e le società di comunicazione a sostituire la messaggistica di massa unidirezionale con conversazioni personalizzate e bidirezionali con gli elettori su larga scala. La piattaforma converte le risposte in analisi dei sentimenti in tempo reale, classificazioni di argomenti, risultati di azioni, metriche di coinvolgimento e informazioni strutturate sugli elettori che le campagne possono utilizzare per raffinare il loro approccio. Il suo sistema AI a circuito chiuso opera all’interno di materiali e messaggi approvati dalla campagna, fornendo funzionalità come la segmentazione dei contatti, la cronologia delle conversazioni, il tracciamento dei link, l’esportazione dei dati e tracciamenti di audit focalizzati sulla conformità. Convos può anche complementare l’infrastruttura di texting esistente di un’organizzazione senza richiedere di sostituire i sistemi di comunicazione attuali.

Hai co-fondato Convos dopo aver osservato come il texting politico e organizzativo fosse diventato in gran parte una comunicazione unidirezionale. Qual è stata l’intuizione originale che ti ha convinto che c’era un’opportunità per trasformare il texting di massa in conversazioni alimentate da AI, e quali sono stati i più grandi sfidi tecnici che hai affrontato nella costruzione della piattaforma?

L’intuizione è arrivata dall’essere stato io stesso a ricevere quei messaggi.

Intorno alle elezioni del 2024, stavo ricevendo una valanga di messaggi politici, come molte altre persone. A un certo punto, ho iniziato a rispondere. Chiedevo una domanda o rispondevo, e non arrivava mai una risposta. I messaggi venivano inviati a milioni, ma nel momento in cui cercavi di avere una vera conversazione, non c’era nessuno dall’altra parte.

Mi ha colpito come un’opportunità enorme perduta. La persona dall’altra parte era già coinvolta. Stava facendo una domanda reale. Ma non sarebbe mai arrivata una risposta.

L’idea dietro Convos era semplice. Trasformare la trasmissione in una vera conversazione, su larga scala, senza aver bisogno di una stanza piena di persone per gestirla.

I più grandi sfidi tecnici sono stati tre: scala, latenza e conformità.

La scala è l’ovvio. Stai gestendo migliaia di conversazioni contemporaneamente, e ognuna ha la sua storia e il suo stato. La latenza conta più di quanto la gente si aspetti. Se qualcuno risponde e la risposta tarda troppo, il momento è perso. Il texting sembra quasi immediato, e l’esperienza deve corrispondere.

La conformità è stata la parte più difficile, e l’abbiamo priorizzata fin dall’inizio. Il texting politico è fortemente regolamentato, e sbagliare non è un’opzione. Molto del nostro lavoro di ingegneria iniziale è stato dedicato a garantire che il sistema rimanesse fedele al messaggio e rispettasse il consenso e le rinunce in modi che vanno ben oltre il semplice rilevamento della parola “STOP”.

Convos opera all’intersezione dell’AI conversazionale, della messaggistica su larga scala e dell’analisi dei sentimenti in tempo reale. Quali lezioni hai imparato dal deploy di sistemi AI che devono coinvolgere migliaia di persone contemporaneamente mentre mantengono un’esperienza personale e autentica?

La lezione più grande è che il “personale su larga scala” è qualcosa per cui bisogna progettare.

Quando esegui migliaia di conversazioni contemporaneamente, la tentazione è quella di trattarle come un’unica grande partita. Ma la persona che riceve il messaggio non si cura della tua partita. Per loro è uno scambio uno a uno, e deve sembrare tale. Ciò significa che ogni conversazione deve avere il suo contesto e la sua storia, in modo che una risposta risponda effettivamente a ciò che quella persona specifica ha detto, e non a una media di tutti.

Abbiamo anche imparato a prestare molta attenzione a ciò che le persone ci stanno realmente dicendo. Una risposta non è solo una risposta. Porta con sé il sentimento. Qualcuno può rispondere con una domanda, con entusiasmo, con frustrazione o con un chiaro segnale che vuole essere lasciato solo. Leggere quelle sfumature correttamente è ciò che fa o disfa un’interazione.

Alla fine, l’autenticità deriva dall’ascolto, non dal suono intelligente. Lo scambio che sembra più umano è quello che risponde alla domanda reale e rispetta il tempo della persona.

Hai sostenuto che molte organizzazioni si concentrano troppo sui benchmark dei modelli mentre trascurano la personalità e lo stile di comunicazione. Perché credi che la personalità stia diventando un fattore critico nella distribuzione dell’AI aziendale, e come le organizzazioni dovrebbero valutarla?

I benchmark misurano la capacità. Non misurano l’adattabilità.

Un modello può ottenere punteggi estremamente alti in ragionamento o codifica e comunque essere la scelta sbagliata per una conversazione con un elettore. Il modo in cui formula le cose, quanto è caldo o formale, se sa quando essere breve, tutto ciò conta enormemente una volta che una persona reale è dall’altra parte.

Nel nostro mondo, il modello non sta risolvendo un problema matematico. Sta rappresentando una campagna in un messaggio di testo. Ogni campagna ha la sua voce, e il modello deve adattarvisi piuttosto che imporre la propria. Se il tono è sbagliato, non importa quanto intelligente sia il modello sottostante. L’interazione fallisce.

C’è anche un lato di capacità che i benchmark mancano. Una campagna può fornire all’agente indicazioni dettagliate su cosa dire, cosa evitare e come gestire argomenti specifici. Il modello deve seguire tutte queste indicazioni in modo coerente, lungo una lunga conversazione. Alcuni modelli sono molto migliori di altri nel mantenere istruzioni complesse senza deviare a metà conversazione. Quella capacità fa parte della personalità anche perché un modello che suona grande ma smette di seguire le istruzioni non è uno che puoi mettere di fronte a persone reali.

Ecco perché la personalità sta diventando un fattore reale nella distribuzione aziendale. Mentre i modelli diventano più capaci in generale, il divario di capacità grezza tra di loro si restringe. Ciò che rimane è il carattere. Come comunicano, e se rimangono entro i confini che stabilisci.

Il modo per valutarlo non è su una classifica. È testare i modelli sul tuo caso d’uso reale, con il tuo contenuto reale, e leggere i risultati come li leggerebbe l’utente finale. Mettiamo i modelli attraverso gli stessi tipi di scambi che gestiranno in produzione e li giudichiamo in base a se la conversazione sembra giusta. Ciò dice molto più di un punteggio di benchmark.

Il tuo team ha testato più modelli leader e ha osservato differenze significative nel modo in cui si eseguono attraverso i compiti. Cosa hai imparato sui punti di forza e debolezza dei principali LLM attuali, e perché alcuni sono più adatti al lavoro conversazionale di altri?

Quello che abbiamo imparato è che non c’è un unico modello migliore. C’è solo il modello migliore per un lavoro specifico.

Alcuni modelli sono eccellenti nel seguire le istruzioni con precisione, il che conta quando il sistema deve rimanere all’interno di confini rigorosi. Alcuni sono più forti in un tono conversazionale naturale. Alcuni sono più veloci, il che è una forza a sé stante quando la latenza fa parte dell’esperienza. Altri sono migliori nel ragionamento attraverso una richiesta complessa ma sembrano rigidi o impiegano troppo tempo per rispondere in uno scambio casuale.

Per il lavoro conversazionale in particolare, le qualità che contano non sono sempre quelle che ricevono i titoli. La velocità conta. La coerenza conta. Sapere quando essere breve conta. Un modello che scrive una bella risposta di tre paragrafi è spesso la scelta sbagliata quando la risposta giusta è una frase.

Nessuna di queste cose appare su una classifica. Puoi solo impararlo mettendo i modelli di fronte al lavoro reale e prestando attenzione a come lo gestiscono.

Molte aziende stanno adottando sempre più strategie multi-modello piuttosto che affidarsi a un solo fornitore di AI. Quali sono i vantaggi di costruire sistemi che possono passare tra modelli, e quali considerazioni architettoniche sono necessarie per renderlo possibile?

Il principale vantaggio è che non sei bloccato.

Se costruisci tutto intorno a un fornitore, erediti tutte le loro limitazioni. I loro prezzi, i limiti di velocità, la latenza, gli outage e il calendario di rilascio diventano i tuoi. Un approccio multi-modello ti consente di instradare ogni compito al modello che lo gestisce meglio, e ti dà un posto dove andare quando un fornitore ha una brutta giornata.

Ti consente anche di adattare il costo al lavoro. Non ogni interazione richiede il tuo modello più potente e più costoso. Poter inviare il lavoro semplice a un modello più leggero e riservare il modello pesante per i casi difficili fa una grande differenza su larga scala.

L’architettura è ciò che rende possibile questo, e la decisione chiave è costruire uno strato di astrazione tra la tua applicazione e un modello specifico. Il tuo sistema non dovrebbe parlare direttamente con l’API di un fornitore in tutto il codice. Dovrebbe parlare con la tua interfaccia interna, e quell’interfaccia decide quale modello gestisce effettivamente la richiesta.

Una volta che hai questo, puoi aggiungere logica di routing, fallback quando un fornitore fallisce e la capacità di scambiare modelli senza riscrivere la tua applicazione. Hai anche bisogno di un handling coerente di prompt e output tra modelli, poiché ognuno si comporta leggermente in modo diverso, e il tuo sistema deve livellare quelle differenze.

È più lavoro all’inizio. Ma ti compra flessibilità che è molto difficile aggiungere in seguito.

Hai recentemente sottolineato come i modelli di AI si evolvano rapidamente, con nuovi rilasci che a volte cambiano le caratteristiche di prestazione in modi inaspettati. Come le aziende dovrebbero bilanciare il desiderio di adottare i modelli più recenti con la necessità di stabilità, affidabilità e prestazioni prevedibili?

La risposta onesta è che un nuovo modello non è un aggiornamento fino a quando non hai provato che lo è.

Ogni rilascio è emozionante, e c’è una vera pressione per adottare l’ultima cosa subito. Ma abbiamo visto nuovi modelli cambiare comportamento in modi che non ci aspettavamo. Qualcosa che funzionava in modo affidabile inizia a rispondere leggermente in modo diverso, e in un sistema di produzione quei piccoli cambiamenti si sommano.

Il modo in cui lo gestiamo è semplice. Nessun modello entra nel nostro flusso di lavoro fino a quando non lo abbiamo testato manualmente noi stessi. Quando esce un nuovo rilascio, non prendiamo i benchmark o l’annuncio alla lettera. Ci sediamo e lo eseguiamo attraverso le sue capacità sullo stesso tipo di conversazioni che gestirebbe in produzione, e leggiamo i risultati noi stessi.

Quel passaggio manuale non è opzionale per noi. Un modello può sembrare migliore sulla carta e comunque gestire una vera conversazione in un modo che non siamo disposti a mettere di fronte agli elettori. L’unico modo per saperlo è metterlo attraverso le stesse situazioni che il nostro sistema affronta ogni giorno e vedere come risponde effettivamente.

Questo è un altro posto in cui lo strato di astrazione si guadagna il suo posto. Poiché la nostra applicazione non dipende da un modello specifico, possiamo portare un nuovo rilascio dentro, testarlo contro le conversazioni che effettivamente gestiamo, e confrontarlo onestamente con ciò che stiamo già eseguendo. Se supera la barra, lo sostituiamo. Se non lo fa, aspettiamo.

Le allucinazioni rimangono uno dei più grandi ostacoli all’adozione dell’AI aziendale, specialmente quando i modelli lavorano con grandi set di dati e informazioni complesse. Quali tecniche pratiche si sono rivelate più efficaci nel ridurre le allucinazioni in ambienti di produzione?

La tecnica più efficace che abbiamo trovato è limitare ciò che il modello è autorizzato a sapere.

Molte allucinazioni derivano dal chiedere a un modello di rispondere dalla sua conoscenza generale, dove sarà felice di colmare le lacune con qualcosa che suona giusto. Facciamo il contrario. Il nostro AI lavora strettamente dalle informazioni fornite dalla campagna. Non ha accesso a Internet aperto e non attinge a qualche vaga memoria del mondo.

Se la risposta non è nel materiale che gli è stato fornito, la risposta corretta è dire che non ha quell’informazione. Quel singolo confine rimuove un enorme quantità di rischio.

Non ci fermiamo lì, però. Abbiamo più controlli in atto per assicurarci che una risposta corrisponda a ciò che la campagna ha fornito. Anche dopo che il modello genera una risposta, quella risposta viene verificata contro le informazioni della campagna prima di andare da qualche parte. Se qualcosa non corrisponde, non viene inviato.

Oltre a questo, le tecniche pratiche sono su base e guardrail. Dare al modello il contesto specifico e rilevante di cui ha bisogno per il compito che ha di fronte, piuttosto che un’enorme quantità indifferenziata di dati. Più le informazioni sono focalizzate, meno c’è spazio per deviare.

Abbiamo anche messo chiari limiti a ciò che il sistema è autorizzato a fare e dire, e monitoriamo conversazioni reali piuttosto che supporre che tutto sia a posto. Non si catturano problemi fidandosi del modello. Li si catturano guardando l’output.

In uno spazio regolamentato come il texting politico, una risposta inventata è un passivo, quindi abbiamo progettato il sistema per preferire la trasparenza all’indovinello.

Le tue squadre hanno testato più modelli leader e hanno osservato differenze significative nel modo in cui si eseguono attraverso i compiti. Quali lezioni hai imparato sui punti di forza e debolezza dei principali LLM attuali, e perché alcuni sono più adatti al lavoro conversazionale di altri?

Quello che abbiamo imparato è che non c’è un unico modello migliore. C’è solo il modello migliore per un lavoro specifico.

Alcuni modelli sono eccellenti nel seguire le istruzioni con precisione, il che conta quando il sistema deve rimanere all’interno di confini rigorosi. Alcuni sono più forti in un tono conversazionale naturale. Alcuni sono più veloci, il che è una forza a sé stante quando la latenza fa parte dell’esperienza. Altri sono migliori nel ragionamento attraverso una richiesta complessa ma sembrano rigidi o impiegano troppo tempo per rispondere in uno scambio casuale.

Per il lavoro conversazionale in particolare, le qualità che contano non sono sempre quelle che ricevono i titoli. La velocità conta. La coerenza conta. Sapere quando essere breve conta. Un modello che scrive una bella risposta di tre paragrafi è spesso la scelta sbagliata quando la risposta giusta è una frase.

Nessuna di queste cose appare su una classifica. Puoi solo impararlo mettendo i modelli di fronte al lavoro reale e prestando attenzione a come lo gestiscono.

Molte aziende stanno adottando sempre più strategie multi-modello piuttosto che affidarsi a un solo fornitore di AI. Quali sono i vantaggi di costruire sistemi che possono passare tra modelli, e quali considerazioni architettoniche sono necessarie per renderlo possibile?

Il principale vantaggio è che non sei bloccato.

Se costruisci tutto intorno a un fornitore, erediti tutte le loro limitazioni. I loro prezzi, i limiti di velocità, la latenza, gli outage e il calendario di rilascio diventano i tuoi. Un approccio multi-modello ti consente di instradare ogni compito al modello che lo gestisce meglio, e ti dà un posto dove andare quando un fornitore ha una brutta giornata.

Ti consente anche di adattare il costo al lavoro. Non ogni interazione richiede il tuo modello più potente e più costoso. Poter inviare il lavoro semplice a un modello più leggero e riservare il modello pesante per i casi difficili fa una grande differenza su larga scala.

L’architettura è ciò che rende possibile questo, e la decisione chiave è costruire uno strato di astrazione tra la tua applicazione e un modello specifico. Il tuo sistema non dovrebbe parlare direttamente con l’API di un fornitore in tutto il codice. Dovrebbe parlare con la tua interfaccia interna, e quell’interfaccia decide quale modello gestisce effettivamente la richiesta.

Una volta che hai questo, puoi aggiungere logica di routing, fallback quando un fornitore fallisce e la capacità di scambiare modelli senza riscrivere la tua applicazione. Hai anche bisogno di un handling coerente di prompt e output tra modelli, poiché ognuno si comporta leggermente in modo diverso, e il tuo sistema deve livellare quelle differenze.

È più lavoro all’inizio. Ma ti compra flessibilità che è molto difficile aggiungere in seguito.

Hai recentemente sottolineato come i modelli di AI si evolvano rapidamente, con nuovi rilasci che a volte cambiano le caratteristiche di prestazione in modi inaspettati. Come le aziende dovrebbero bilanciare il desiderio di adottare i modelli più recenti con la necessità di stabilità, affidabilità e prestazioni prevedibili?

La risposta onesta è che un nuovo modello non è un aggiornamento fino a quando non hai provato che lo è.

Ogni rilascio è emozionante, e c’è una vera pressione per adottare l’ultima cosa subito. Ma abbiamo visto nuovi modelli cambiare comportamento in modi che non ci aspettavamo. Qualcosa che funzionava in modo affidabile inizia a rispondere leggermente in modo diverso, e in un sistema di produzione quei piccoli cambiamenti si sommano.

Il modo in cui lo gestiamo è semplice. Nessun modello entra nel nostro flusso di lavoro fino a quando non lo abbiamo testato manualmente noi stessi. Quando esce un nuovo rilascio, non prendiamo i benchmark o l’annuncio alla lettera. Ci sediamo e lo eseguiamo attraverso le sue capacità sullo stesso tipo di conversazioni che gestirebbe in produzione, e leggiamo i risultati noi stessi.

Quel passaggio manuale non è opzionale per noi. Un modello può sembrare migliore sulla carta e comunque gestire una vera conversazione in un modo che non siamo disposti a mettere di fronte agli elettori. L’unico modo per saperlo è metterlo attraverso le stesse situazioni che il nostro sistema affronta ogni giorno e vedere come risponde effettivamente.

Questo è un altro posto in cui lo strato di astrazione si guadagna il suo posto. Poiché la nostra applicazione non dipende da un modello specifico, possiamo portare un nuovo rilascio dentro, testarlo contro le conversazioni che effettivamente gestiamo, e confrontarlo onestamente con ciò che stiamo già eseguendo. Se supera la barra, lo sostituiamo. Se non lo fa, aspettiamo.

Le allucinazioni rimangono uno dei più grandi ostacoli all’adozione dell’AI aziendale, specialmente quando i modelli lavorano con grandi set di dati e informazioni complesse. Quali tecniche pratiche si sono rivelate più efficaci nel ridurre le allucinazioni in ambienti di produzione?

La tecnica più efficace che abbiamo trovato è limitare ciò che il modello è autorizzato a sapere.

Molte allucinazioni derivano dal chiedere a un modello di rispondere dalla sua conoscenza generale, dove sarà felice di colmare le lacune con qualcosa che suona giusto. Facciamo il contrario. Il nostro AI lavora strettamente dalle informazioni fornite dalla campagna. Non ha accesso a Internet aperto e non attinge a qualche vaga memoria del mondo.

Se la risposta non è nel materiale che gli è stato fornito, la risposta corretta è dire che non ha quell’informazione. Quel singolo confine rimuove un enorme quantità di rischio.

Non ci fermiamo lì, però. Abbiamo più controlli in atto per assicurarci che una risposta corrisponda a ciò che la campagna ha fornito. Anche dopo che il modello genera una risposta, quella risposta viene verificata contro le informazioni della campagna prima di andare da qualche parte. Se qualcosa non corrisponde, non viene inviato.

Oltre a questo, le tecniche pratiche sono su base e guardrail. Dare al modello il contesto specifico e rilevante di cui ha bisogno per il compito che ha di fronte, piuttosto che un’enorme quantità indifferenziata di dati. Più le informazioni sono focalizzate, meno c’è spazio per deviare.

Abbiamo anche messo chiari limiti a ciò che il sistema è autorizzato a fare e dire, e monitoriamo conversazioni reali piuttosto che supporre che tutto sia a posto. Non si catturano problemi fidandosi del modello. Li si catturano guardando l’output.

In uno spazio regolamentato come il texting politico, una risposta inventata è un passivo, quindi abbiamo progettato il sistema per preferire la trasparenza all’indovinello.

Le tue squadre hanno testato più modelli leader e hanno osservato differenze significative nel modo in cui si eseguono attraverso i compiti. Quali lezioni hai imparato sui punti di forza e debolezza dei principali LLM attuali, e perché alcuni sono più adatti al lavoro conversazionale di altri?

Quello che abbiamo imparato è che non c’è un unico modello migliore. C’è solo il modello migliore per un lavoro specifico.

Alcuni modelli sono eccellenti nel seguire le istruzioni con precisione, il che conta quando il sistema deve rimanere all’interno di confini rigorosi. Alcuni sono più forti in un tono conversazionale naturale. Alcuni sono più veloci, il che è una forza a sé stante quando la latenza fa parte dell’esperienza. Altri sono migliori nel ragionamento attraverso una richiesta complessa ma sembrano rigidi o impiegano troppo tempo per rispondere in uno scambio casuale.

Per il lavoro conversazionale in particolare, le qualità che contano non sono sempre quelle che ricevono i titoli. La velocità conta. La coerenza conta. Sapere quando essere breve conta. Un modello che scrive una bella risposta di tre paragrafi è spesso la scelta sbagliata quando la risposta giusta è una frase.

Nessuna di queste cose appare su una classifica. Puoi solo impararlo mettendo i modelli di fronte al lavoro reale e prestando attenzione a come lo gestiscono.

Molte aziende stanno adottando sempre più strategie multi-modello piuttosto che affidarsi a un solo fornitore di AI. Quali sono i vantaggi di costruire sistemi che possono passare tra modelli, e quali considerazioni architettoniche sono necessarie per renderlo possibile?

Il principale vantaggio è che non sei bloccato.

Se costruisci tutto intorno a un fornitore, erediti tutte le loro limitazioni. I loro prezzi, i limiti di velocità, la latenza, gli outage e il calendario di rilascio diventano i tuoi. Un approccio multi-modello ti consente di instradare ogni compito al modello che lo gestisce meglio, e ti dà un posto dove andare quando un fornitore ha una brutta giornata.

Ti consente anche di adattare il costo al lavoro. Non ogni interazione richiede il tuo modello più potente e più costoso. Poter inviare il lavoro semplice a un modello più leggero e riservare il modello pesante per i casi difficili fa una grande differenza su larga scala.

L’architettura è ciò che rende possibile questo, e la decisione chiave è costruire uno strato di astrazione tra la tua applicazione e un modello specifico. Il tuo sistema non dovrebbe parlare direttamente con l’API di un fornitore in tutto il codice. Dovrebbe parlare con la tua interfaccia interna, e quell’interfaccia decide quale modello gestisce effettivamente la richiesta.

Una volta che hai questo, puoi aggiungere logica di routing, fallback quando un fornitore fallisce e la capacità di scambiare modelli senza riscrivere la tua applicazione. Hai anche bisogno di un handling coerente di prompt e output tra modelli, poiché ognuno si comporta leggermente in modo diverso, e il tuo sistema deve livellare quelle differenze.

È più lavoro all’inizio. Ma ti compra flessibilità che è molto difficile aggiungere in seguito.

Hai recentemente sottolineato come i modelli di AI si evolvano rapidamente, con nuovi rilasci che a volte cambiano le caratteristiche di prestazione in modi inaspettati. Come le aziende dovrebbero bilanciare il desiderio di adottare i modelli più recenti con la necessità di stabilità, affidabilità e prestazioni prevedibili?

La risposta onesta è che un nuovo modello non è un aggiornamento fino a quando non hai provato che lo è.

Ogni rilascio è emozionante, e c’è una vera pressione per adottare l’ultima cosa subito. Ma abbiamo visto nuovi modelli cambiare comportamento in modi che non ci aspettavamo. Qualcosa che funzionava in modo affidabile inizia a rispondere leggermente in modo diverso, e in un sistema di produzione quei piccoli cambiamenti si sommano.

Il modo in cui lo gestiamo è semplice. Nessun modello entra nel nostro flusso di lavoro fino a quando non lo abbiamo testato manualmente noi stessi. Quando esce un nuovo rilascio, non prendiamo i benchmark o l’annuncio alla lettera. Ci sediamo e lo eseguiamo attraverso le sue capacità sullo stesso tipo di conversazioni che gestirebbe in produzione, e leggiamo i risultati noi stessi.

Quel passaggio manuale non è opzionale per noi. Un modello può sembrare migliore sulla carta e comunque gestire una vera conversazione in un modo che non siamo disposti a mettere di fronte agli elettori. L’unico modo per saperlo è metterlo attraverso le stesse situazioni che il nostro sistema affronta ogni giorno e vedere come risponde effettivamente.

Questo è un altro posto in cui lo strato di astrazione si guadagna il suo posto. Poiché la nostra applicazione non dipende da un modello specifico, possiamo portare un nuovo rilascio dentro, testarlo contro le conversazioni che effettivamente gestiamo, e confrontarlo onestamente con ciò che stiamo già eseguendo. Se supera la barra, lo sostituiamo. Se non lo fa, aspettiamo.

Le allucinazioni rimangono uno dei più grandi ostacoli all’adozione dell’AI aziendale, specialmente quando i modelli lavorano con grandi set di dati e informazioni complesse. Quali tecniche pratiche si sono rivelate più efficaci nel ridurre le allucinazioni in ambienti di produzione?

La tecnica più efficace che abbiamo trovato è limitare ciò che il modello è autorizzato a sapere.

Molte allucinazioni derivano dal chiedere a un modello di rispondere dalla sua conoscenza generale, dove sarà felice di colmare le lacune con qualcosa che suona giusto. Facciamo il contrario. Il nostro AI lavora strettamente dalle informazioni fornite dalla campagna. Non ha accesso a Internet aperto e non attinge a qualche vaga memoria del mondo.

Se la risposta non è nel materiale che gli è stato fornito, la risposta corretta è dire che non ha quell’informazione. Quel singolo confine rimuove un enorme quantità di rischio.

Non ci fermiamo lì, però. Abbiamo più controlli in atto per assicurarci che una risposta corrisponda a ciò che la campagna ha fornito. Anche dopo che il modello genera una risposta, quella risposta viene verificata contro le informazioni della campagna prima di andare da qualche parte. Se qualcosa non corrisponde, non viene inviato.

Oltre a questo, le tecniche pratiche sono su base e guardrail. Dare al modello il contesto specifico e rilevante di cui ha bisogno per il compito che ha di fronte, piuttosto che un’enorme quantità indifferenziata di dati. Più le informazioni sono focalizzate, meno c’è spazio per deviare.

Abbiamo anche messo chiari limiti a ciò che il sistema è autorizzato a fare e dire, e monitoriamo conversazioni reali piuttosto che supporre che tutto sia a posto. Non si catturano problemi fidandosi del modello. Li si catturano guardando l’output.

In uno spazio regolamentato come il texting politico, una risposta inventata è un passivo, quindi abbiamo progettato il sistema per preferire la trasparenza all’indovinello.

Le tue squadre hanno testato più modelli leader e hanno osservato differenze significative nel modo in cui si eseguono attraverso i compiti. Quali lezioni hai imparato sui punti di forza e debolezza dei principali LLM attuali, e perché alcuni sono più adatti al lavoro conversazionale di altri?

Quello che abbiamo imparato è che non c’è un unico modello migliore. C’è solo il modello migliore per un lavoro specifico.

Alcuni modelli sono eccellenti nel seguire le istruzioni con precisione, il che conta quando il sistema deve rimanere all’interno di confini rigorosi. Alcuni sono più forti in un tono conversazionale naturale. Alcuni sono più veloci, il che è una forza a sé stante quando la latenza fa parte dell’esperienza. Altri sono migliori nel ragionamento attraverso una richiesta complessa ma sembrano rigidi o impiegano troppo tempo per rispondere in uno scambio casuale.

Per il lavoro conversazionale in particolare, le qualità che contano non sono sempre quelle che ricevono i titoli. La velocità conta. La coerenza conta. Sapere quando essere breve conta. Un modello che scrive una bella risposta di tre paragrafi è spesso la scelta sbagliata quando la risposta giusta è una frase.

Nessuna di queste cose appare su una classifica. Puoi solo impararlo mettendo i modelli di fronte al lavoro reale e prestando attenzione a come lo gestiscono.

Molte aziende stanno adottando sempre più strategie multi-modello piuttosto che affidarsi a un solo fornitore di AI. Quali sono i vantaggi di costruire sistemi che possono passare tra modelli, e quali considerazioni architettoniche sono necessarie per renderlo possibile?

Il principale vantaggio è che non sei bloccato.

Se costruisci tutto intorno a un fornitore, erediti tutte le loro limitazioni. I loro prezzi, i limiti di velocità, la latenza, gli outage e il calendario di rilascio diventano i tuoi. Un approccio multi-modello ti consente di instradare ogni compito al modello che lo gestisce meglio, e ti dà un posto dove andare quando un fornitore ha una brutta giornata.

Ti consente anche di adattare il costo al lavoro. Non ogni interazione richiede il tuo modello più potente e più costoso. Poter inviare il lavoro semplice a un modello più leggero e riservare il modello pesante per i casi difficili fa una grande differenza su larga scala.

L’architettura è ciò che rende possibile questo, e la decisione chiave è costruire uno strato di astrazione tra la tua applicazione e un modello specifico. Il tuo sistema non dovrebbe parlare direttamente con l’API di un fornitore in tutto il codice. Dovrebbe parlare con la tua interfaccia interna, e quell’interfaccia decide quale modello gestisce effettivamente la richiesta.

Una volta che hai questo, puoi aggiungere logica di routing, fallback quando un fornitore fallisce e la capacità di scambiare modelli senza riscrivere la tua applicazione. Hai anche bisogno di un handling coerente di prompt e output tra modelli, poiché ognuno si comporta leggermente in modo diverso, e il tuo sistema deve livellare quelle differenze.

È più lavoro all’inizio. Ma ti compra flessibilità che è molto difficile aggiungere in seguito.

Hai recentemente sottolineato come i modelli di AI si evolvano rapidamente, con nuovi rilasci che a volte cambiano le caratteristiche di prestazione in modi inaspettati. Come le aziende dovrebbero bilanciare il desiderio di adottare i modelli più recenti con la necessità di stabilità, affidabilità e prestazioni prevedibili?

La risposta onesta è che un nuovo modello non è un aggiornamento fino a quando non hai provato che lo è.

Ogni rilascio è emozionante, e c’è una vera pressione per adottare l’ultima cosa subito. Ma abbiamo visto nuovi modelli cambiare comportamento in modi che non ci aspettavamo. Qualcosa che funzionava in modo affidabile inizia a rispondere leggermente in modo diverso, e in un sistema di produzione quei piccoli cambiamenti si sommano.

Il modo in cui lo gestiamo è semplice. Nessun modello entra nel nostro flusso di lavoro fino a quando non lo abbiamo testato manualmente noi stessi. Quando esce un nuovo rilascio, non prendiamo i benchmark o l’annuncio alla lettera. Ci sediamo e lo eseguiamo attraverso le sue capacità sullo stesso tipo di conversazioni che gestirebbe in produzione, e leggiamo i risultati noi stessi.

Quel passaggio manuale non è opzionale per noi. Un modello può sembrare migliore sulla carta e comunque gestire una vera conversazione in un modo che non siamo disposti a mettere di fronte agli elettori. L’unico modo per saperlo è metterlo attraverso le stesse situazioni che il nostro sistema affronta ogni giorno e vedere come risponde effettivamente.

Questo è un altro posto in cui lo strato di astrazione si guadagna il suo posto. Poiché la nostra applicazione non dipende da un modello specifico, possiamo portare un nuovo rilascio dentro, testarlo contro le conversazioni che effettivamente gestiamo, e confrontarlo onestamente con ciò che stiamo già eseguendo. Se supera la barra, lo sostituiamo. Se non lo fa, aspettiamo.

Le allucinazioni rimangono uno dei più grandi ostacoli all’adozione dell’AI aziendale, specialmente quando i modelli lavorano con grandi set di dati e informazioni complesse. Quali tecniche pratiche si sono rivelate più efficaci nel ridurre le allucinazioni in ambienti di produzione?

La tecnica più efficace che abbiamo trovato è limitare ciò che il modello è autorizzato a sapere.

Molte allucinazioni derivano dal chiedere a un modello di rispondere dalla sua conoscenza generale, dove sarà felice di colmare le lacune con qualcosa che suona giusto. Facciamo il contrario. Il nostro AI lavora strettamente dalle informazioni fornite dalla campagna. Non ha accesso a Internet aperto e non attinge a qualche vaga memoria del mondo.

Se la risposta non è nel materiale che gli è stato fornito, la risposta corretta è dire che non ha quell’informazione. Quel singolo confine rimuove un enorme quantità di rischio.

Non ci fermiamo lì, però. Abbiamo più controlli in atto per assicurarci che una risposta corrisponda a ciò che la campagna ha fornito. Anche dopo che il modello genera una risposta, quella risposta viene verificata contro le informazioni della campagna prima di andare da qualche parte. Se qualcosa non corrisponde, non viene inviato.

Oltre a questo, le tecniche pratiche sono su base e guardrail. Dare al modello il contesto specifico e rilevante di cui ha bisogno per il compito che ha di fronte, piuttosto che un’enorme quantità indifferenziata di dati. Più le informazioni sono focalizzate, meno c’è spazio per deviare.

Abbiamo anche messo chiari limiti a ciò che il sistema è autorizzato a fare e dire, e monitoriamo conversazioni reali piuttosto che supporre che tutto sia a posto. Non si catturano problemi fidandosi del modello. Li si catturano guardando l’output.

In uno spazio regolamentato come il texting politico, una risposta inventata è un passivo, quindi abbiamo progettato il sistema per preferire la trasparenza all’indovinello.

Gli agenti di AI stanno diventando sempre più capaci di gestire conversazioni che una volta richiedevano personale umano. Dove vedi l’equilibrio tra automazione e supervisione umana nei prossimi cinque anni, e quali flussi di lavoro dovrebbero sempre mantenere un umano nel ciclo?

Questa è una domanda difficile, e non credo che qualcuno sappia esattamente dove si trova la linea in cinque anni. Il modo in cui ci penso è che il vero valore dell’AI è come moltiplicatore di forza. Lascia che un piccolo gruppo di persone faccia molto più di quanto avrebbero potuto fare da soli.

Le squadre che ottengono il massimo da questi strumenti li stanno usando esattamente in questo modo. L’AI prende il volume e la ripetizione, e le persone spendono il loro tempo in giudizio, strategia e situazioni che richiedono veramente un essere umano. Quello è un obiettivo molto diverso dal cercare di rimuovere le persone dall’immagine.

Quando l’obiettivo è la sostituzione pura, si tende a spingere la tecnologia oltre ciò che è realmente brava, e fallisce in modi visibili ed espensivi. Quando l’obiettivo è moltiplicare le persone, si lascia che l’AI faccia ciò che fa bene e si mantengono gli esseri umani dove aggiungono più valore. L’approccio funziona meglio e è più onesto su dove si trova effettivamente la tecnologia oggi.

Nei prossimi cinque anni, mi aspetto che gli agenti prendano su di sé sempre più del carico conversazionale di routine, e dovrebbero farlo. Quel lavoro non richiede una persona che guarda ogni parola.

I flussi di lavoro che dovrebbero sempre mantenere un umano nel ciclo sono quelli in cui le poste in gioco sono alte o la situazione è veramente nuova. Qualsiasi cosa che tocchi il consenso, la conformità o una decisione che sarebbe difficile da annullare. Una persona dovrebbe possedere la direzione, e l’AI dovrebbe aiutarla a coprire molto più terreno di quanto potrebbe altrimenti.

Guardando avanti, quali sviluppi nell’AI conversazionale ti entusiasmano di più, e come immagini che le piattaforme come Convos evolveranno man mano che i modelli diventano più capaci, multimodali e autonomi?

Ciò che mi entusiasma di più è che le conversazioni continueranno a migliorare.

Mentre i modelli migliorano, gli scambi che la nostra piattaforma gestisce diventano più naturali e più utili senza che noi dobbiamo ricostruire le fondamenta ogni volta. Poiché abbiamo progettato il sistema per spostarsi tra modelli, possiamo portare quei miglioramenti dentro man mano che arrivano.

Multimodale è lo sviluppo che sto guardando più da vicino. Attualmente la conversazione è testo. Mentre i modelli gestiscono immagini e altri formati in modo più capace, c’è un’opportunità reale per rendere questi scambi più ricchi mentre si mantiene l’immediatezza che fa funzionare il texting.

Sull’autonomia, sono ottimista ma cauto. Modelli più capaci vengono rilasciati ogni mese, e saranno in grado di gestire molto da soli. Ma in uno spazio regolamentato, più autonomia deve venire con più disciplina, non meno. I confini contano di più man mano che la capacità cresce.

Sono entrato in questo perché ero la persona che stava inviando messaggi nel vuoto e non riceveva nulla in risposta. Quello è ancora il problema di cui mi preoccupo di più. Non importa quanto capaci diventino questi modelli, la misura a cui continuo a tornare è semplice. La persona dall’altra parte si sente ascoltata?

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Convos.