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

Andrew Missey, CTO e cofondatore di Convos, è un ingegnere del software e responsabile di prodotto con esperienza nello sviluppo di prodotti di IA, nell’architettura software, nelle reti e nell’ingegneria full-stack. Prima di cofondare Convos, ha contribuito allo sviluppo e al lancio di due piattaforme creative e di marketing basate sull’IA presso Forum3, unendo il lavoro diretto di ingegneria alla gestione tecnica del prodotto. Nei precedenti incarichi presso N-able (NABL ), Autoshop Solutions e Brand IQ ha realizzato applicazioni frontend, sistemi backend, dashboard per i clienti e strumenti software interni, utilizzando tecnologie tra cui Svelte, NestJS, Angular e JavaScript. Questo percorso multidisciplinare gli ha permesso di collegare l’esecuzione tecnica alla strategia di prodotto mentre guida lo sviluppo della piattaforma di comunicazione basata sull’IA di Convos.

Convos è una piattaforma di messaggistica basata su un’IA controllata, progettata per aiutare le campagne politiche e le società di comunicazione a sostituire gli invii di massa unidirezionali con conversazioni personalizzate e bidirezionali con gli elettori, su larga scala. La piattaforma trasforma le risposte in analisi del sentiment in tempo reale, classificazioni per argomento, risultati degli inviti all’azione, metriche di coinvolgimento e informazioni strutturate sugli elettori, che le campagne possono usare per perfezionare le proprie attività di contatto. La sua IA opera in un sistema chiuso, entro i materiali approvati dalla campagna e i limiti stabiliti per i messaggi, offrendo funzioni quali segmentazione dei contatti, cronologie delle conversazioni, tracciamento dei link, esportazione dei dati e registri di audit orientati alla conformità. Convos può anche affiancare l’infrastruttura di messaggistica già utilizzata da un’organizzazione, senza richiedere la sostituzione degli attuali sistemi di comunicazione.

Hai cofondato Convos dopo aver osservato che la messaggistica politica e delle organizzazioni era diventata in gran parte unidirezionale. Quale intuizione iniziale ti ha convinto che fosse possibile trasformare gli invii di massa in conversazioni basate sull’IA, e quali sono state le maggiori sfide tecniche nella realizzazione della piattaforma?

L’intuizione è nata dal trovarmi dall’altra parte, come destinatario.

Nel periodo delle elezioni del 2024 ero bombardato di messaggi politici, come molte altre persone. A un certo punto ho iniziato a rispondere. Facevo una domanda o inviavo una risposta, e non ricevevo mai nulla. I messaggi partivano a milioni, ma nel momento in cui cercavi di avere uno scambio vero, non c’era nessuno.

Mi sembrava un’enorme occasione persa. La persona dall’altra parte era già coinvolta. Stava ponendo una domanda reale. Eppure non avrebbe mai ricevuto risposta.

L’idea alla base di Convos era quindi semplice: trasformare la comunicazione a senso unico in una vera conversazione, su larga scala, senza bisogno di una stanza piena di persone a gestirla.

Le maggiori sfide tecniche si riducevano a tre aspetti: scala, latenza e conformità.

La scala è l’aspetto più ovvio. Gestisci migliaia di conversazioni contemporaneamente, ognuna con il proprio stato e la propria cronologia. La latenza conta più di quanto si pensi. Se qualcuno risponde a un messaggio e la replica arriva troppo tardi, l’occasione è sfumata. La messaggistica dà una sensazione di quasi immediatezza, e l’esperienza deve rispecchiarla.

La conformità è stata la parte più difficile, e le abbiamo dato priorità fin dall’inizio. La messaggistica politica è fortemente regolamentata e non ci si può permettere di sbagliare. Gran parte del lavoro ingegneristico iniziale è servita a garantire che il sistema restasse coerente con i messaggi della campagna e rispettasse il consenso e le richieste di non ricevere più comunicazioni, andando ben oltre il semplice riconoscimento della parola «STOP».

Convos opera all’incrocio tra IA conversazionale, messaggistica su larga scala e analisi del sentiment in tempo reale. Quali lezioni avete imparato distribuendo sistemi di IA che devono interagire con migliaia di persone contemporaneamente, mantenendo un tono personale e autentico?

La lezione principale è che la personalizzazione su larga scala va progettata. Non nasce da sola.

Quando gestisci migliaia di conversazioni contemporaneamente, la tentazione è trattarle come un unico grande blocco. Ma a chi riceve il messaggio non interessa come organizzi gli invii. Per quella persona è uno scambio individuale, e deve sembrarlo. Ogni conversazione deve quindi conservare il proprio contesto e la propria cronologia, affinché la replica risponda davvero a ciò che ha detto quella specifica persona, non a una sorta di media di tutti gli interlocutori.

Abbiamo anche imparato a prestare molta attenzione a ciò che le persone ci stanno davvero comunicando. Una risposta non è soltanto una risposta: esprime uno stato d’animo. Qualcuno può rispondere con una domanda, con entusiasmo, con frustrazione o con un segnale chiaro che vuole essere lasciato in pace. Interpretare correttamente queste sfumature determina il successo o il fallimento dell’interazione.

Alla fine, l’autenticità nasce dall’ascolto, non dal sembrare brillanti. Lo scambio che appare più umano è quello che risponde alla domanda effettiva e rispetta il tempo della persona.

Hai sostenuto che molte organizzazioni si concentrano troppo sui benchmark dei modelli, trascurando personalità e stile comunicativo. Perché ritieni che la personalità stia diventando un fattore fondamentale nell’adozione aziendale dell’IA, e come dovrebbero valutarla le organizzazioni?

I benchmark misurano le capacità. Non misurano l’adeguatezza al contesto.

Un modello può ottenere risultati eccellenti nel ragionamento o nella programmazione ed essere comunque la scelta sbagliata per una conversazione con un elettore. Il modo in cui formula le frasi, quanto risulta cordiale o formale, se sa quando essere conciso: tutto questo conta enormemente quando dall’altra parte c’è una persona reale.

Nel nostro ambito il modello non risolve un problema matematico. Rappresenta una campagna attraverso un messaggio. Ogni campagna ha una propria voce, e il modello deve adeguarvisi anziché imporre la sua. Se il tono è sbagliato, non importa quanto sia intelligente il modello sottostante. L’interazione fallisce.

C’è anche un aspetto legato alle capacità che i benchmark non colgono. Una campagna può fornire all’agente indicazioni dettagliate su cosa dire, cosa evitare e come trattare determinati argomenti. Il modello deve seguirle tutte, con coerenza, durante uno scambio prolungato. Alcuni modelli sono molto più bravi di altri a mantenere istruzioni complesse senza deviare a metà conversazione. Anche questa capacità fa parte della personalità, perché un modello che si esprime benissimo ma smette di seguire le proprie istruzioni non è qualcosa che puoi mettere davanti a persone reali.

Ecco perché la personalità sta diventando un fattore concreto nell’adozione aziendale. Man mano che i modelli migliorano in tutti gli ambiti, il divario nelle capacità di base si restringe. Ciò che resta è il carattere: come comunicano e se rispettano i limiti che stabilisci.

Non la si valuta con una classifica. Bisogna provare i modelli sul proprio caso d’uso reale, con i propri contenuti, e leggere i risultati dal punto di vista dell’utente finale. Sottoponiamo i modelli esattamente al tipo di scambi che dovranno gestire in produzione e li giudichiamo in base a quanto la conversazione risulta appropriata. Questo dice molto più di qualsiasi punteggio di benchmark.

Il vostro team ha testato diversi modelli di primo piano e ha osservato differenze significative nelle prestazioni a seconda dei compiti. Cosa avete imparato sui punti di forza e sui limiti dei principali LLM attuali, e perché alcuni sono più adatti di altri alle conversazioni?

Abbiamo imparato che non esiste un unico modello migliore in assoluto. Esiste soltanto il modello migliore per un determinato lavoro.

Alcuni modelli sono eccellenti nel seguire le istruzioni con precisione, un aspetto importante quando il sistema deve restare entro confini rigidi. Altri hanno un tono più naturale e colloquiale. Alcuni sono più veloci, il che costituisce un punto di forza quando la latenza fa parte dell’esperienza. Altri ancora ragionano meglio su richieste complesse, ma risultano rigidi o impiegano troppo tempo a rispondere in uno scambio informale.

Per le conversazioni, in particolare, le qualità che contano non sono sempre quelle che fanno notizia. Conta la velocità. Conta la coerenza. Conta sapere quando essere brevi. Un modello che scrive una splendida risposta di tre paragrafi è spesso la scelta sbagliata quando la risposta giusta è una sola frase.

Nulla di tutto questo emerge da una classifica. Lo impari soltanto mettendo i modelli alla prova con il lavoro effettivo e osservando attentamente come lo svolgono.

Sempre più aziende adottano strategie basate su più modelli anziché affidarsi a un unico fornitore di IA. Quali sono i vantaggi dei sistemi capaci di passare da un modello all’altro, e quali scelte architetturali servono per renderlo possibile?

Il vantaggio principale è non rimanere vincolati a un solo fornitore.

Se costruisci tutto attorno a un fornitore, ne erediti tutti i vincoli. I suoi prezzi, i limiti alle richieste, la latenza, le interruzioni del servizio e il calendario dei rilasci diventano anche i tuoi. Un approccio multimodello consente di indirizzare ogni compito al modello che lo gestisce meglio e offre un’alternativa quando un fornitore ha problemi.

Permette anche di adeguare il costo al lavoro. Non tutte le interazioni richiedono il modello più potente e costoso. Affidare i compiti semplici a un modello più leggero e riservare quello più potente ai casi difficili fa una differenza concreta su larga scala.

È l’architettura a renderlo possibile, e la decisione fondamentale è creare un livello di astrazione tra l’applicazione e qualsiasi modello specifico. Il sistema non dovrebbe comunicare direttamente con l’API di un solo fornitore in tutto il codice. Dovrebbe dialogare con una propria interfaccia interna, che decide quale modello gestirà effettivamente la richiesta.

Una volta predisposta questa struttura, puoi aggiungere logiche di instradamento, alternative in caso di guasto di un fornitore e la possibilità di sostituire i modelli senza riscrivere l’applicazione. Serve anche una gestione coerente dei prompt e delle risposte tra modelli, perché ciascuno si comporta in modo leggermente diverso e il sistema deve compensare queste differenze.

Richiede più lavoro all’inizio. Ma offre una flessibilità che è molto difficile aggiungere in seguito.

Di recente hai sottolineato la rapidità con cui evolvono i modelli di IA: a volte nuovi rilasci modificano le caratteristiche delle prestazioni in modi inattesi. Come dovrebbero le imprese bilanciare il desiderio di adottare gli ultimi modelli con l’esigenza di stabilità, affidabilità e prestazioni prevedibili?

La risposta sincera è che un nuovo modello non costituisce un miglioramento finché non hai dimostrato che lo è.

Ogni rilascio suscita entusiasmo e c’è una forte pressione ad adottare subito l’ultima novità. Ma abbiamo visto nuovi modelli cambiare comportamento in modi che non ci aspettavamo. Qualcosa che funzionava in modo affidabile comincia a rispondere un po’ diversamente, e in un sistema in produzione queste piccole variazioni si sommano.

Il nostro approccio è semplice. Nessun modello entra nella nostra pipeline finché non lo abbiamo testato direttamente di persona. Quando arriva un nuovo rilascio, non prendiamo per buoni i benchmark o l’annuncio. Lo mettiamo alla prova esattamente con il tipo di conversazioni che gestirebbe in produzione e leggiamo personalmente i risultati.

Per noi questa verifica diretta non è facoltativa. Un modello può sembrare migliore sulla carta e gestire comunque uno scambio reale in un modo che non ci sentiamo di proporre agli elettori. L’unico modo per saperlo è sottoporlo alle stesse situazioni che il nostro sistema affronta ogni giorno e vedere come risponde davvero.

Anche qui il livello di astrazione dimostra il proprio valore. Poiché la nostra applicazione non dipende da un modello specifico, possiamo introdurre un nuovo rilascio, provarlo sulle conversazioni che gestiamo realmente e confrontarlo in modo onesto con quello già in uso. Se supera la soglia richiesta, passiamo al nuovo modello. Altrimenti aspettiamo.

Le allucinazioni restano uno dei maggiori ostacoli all’adozione aziendale dell’IA, soprattutto quando i modelli lavorano con grandi insiemi di dati e informazioni complesse. Quali tecniche pratiche si sono rivelate più efficaci per ridurle negli ambienti di produzione?

La tecnica più efficace che abbiamo trovato è limitare ciò che il modello può conoscere.

Molte allucinazioni nascono quando si chiede a un modello di rispondere attingendo alle proprie conoscenze generali: tende a colmare le lacune con qualcosa che sembra corretto. Noi facciamo il contrario. La nostra IA lavora esclusivamente sulle informazioni fornite dalla campagna. Non ha accesso a Internet aperta e non attinge a una vaga memoria del mondo.

Se la risposta non è nel materiale ricevuto, la risposta corretta è dichiarare di non disporre di quell’informazione. Questo solo limite elimina una quantità enorme di rischio.

Ma non ci fermiamo qui. Abbiamo diversi controlli per assicurarci che una risposta corrisponda a quanto fornito dalla campagna. Anche dopo che il modello ha generato una replica, la confrontiamo con le informazioni della campagna prima di inviarla. Se qualcosa non torna, non viene mandata.

Per il resto, le tecniche pratiche riguardano l’ancoraggio alle informazioni e i limiti operativi. Bisogna dare al modello il contesto specifico e pertinente necessario per il compito che sta affrontando, anziché un’enorme massa indistinta di dati. Più le informazioni sono mirate, minore è lo spazio per deviare.

Stabiliamo inoltre limiti chiari a ciò che il sistema può fare e dire e monitoriamo le conversazioni reali, invece di presumere che vada tutto bene. I problemi non si individuano fidandosi del modello, ma osservando ciò che produce.

In un settore regolamentato come la messaggistica politica, una risposta inventata comporta responsabilità e rischi; per questo abbiamo progettato il sistema affinché privilegi la trasparenza rispetto alle supposizioni.

Mentre le organizzazioni introducono agenti di IA nell’assistenza clienti, nella comunicazione, nel marketing e nelle attività operative, quali errori vedi ripetere ai team nel passaggio dai progetti pilota alle implementazioni su scala produttiva?

L’errore che vedo più spesso è che i team verificano se il loro agente funziona, ma non se sia possibile metterlo in crisi.

Ho perso il conto delle volte in cui un’azienda ha lanciato un chatbot di IA e, nel giro di un giorno, qualcuno online ne ha aggirato le protezioni facendogli dire qualcosa che non avrebbe mai dovuto dire. Viene convinto ad abbandonare le istruzioni, ingannato per uscire dal copione o manipolato per rappresentare il marchio in un modo che finisce in uno screenshot condiviso da tutti.

Succede perché in un progetto pilota tutti si comportano bene. Si prova l’agente con persone ragionevoli che pongono domande ragionevoli, e sembra ottimo. In produzione accade il contrario. Nel momento in cui qualcosa diventa pubblico, una parte degli interlocutori cerca attivamente di farlo inciampare.

Se non hai testato questo scenario avversario, non lo hai davvero messo alla prova. Devi cercare di mandare in crisi il tuo sistema prima che lo faccia qualcun altro. Spingilo ai limiti, dagli input strani e ostili e verifica se mantiene i propri confini quando qualcuno cerca deliberatamente di aggirarli.

L’altro errore ricorrente è presumere che una demo funzionante equivalga a un sistema funzionante. Un progetto pilota comprende poche conversazioni sorvegliate lungo il percorso ideale. In produzione ci sono migliaia di persone, a tutte le ore, che si comportano in modi imprevisti, e i casi limite trascurati diventano eventi quotidiani su larga scala.

Il mio consiglio è dedicare meno tempo a perfezionare la demo e più tempo a cercare di mettere in crisi il sistema in prima persona. Se non resiste ai tuoi attacchi, non resisterà all’esposizione al pubblico.

Gli agenti di IA sono sempre più capaci di gestire conversazioni che un tempo richiedevano personale umano. Come vedi l’equilibrio tra automazione e supervisione umana nei prossimi cinque anni, e quali flussi di lavoro dovrebbero, secondo te, mantenere sempre una persona coinvolta?

È una domanda difficile, e non credo che qualcuno sappia davvero dove si troverà esattamente il confine tra cinque anni. Per come la vedo io, il vero valore dell’IA è moltiplicare le capacità delle persone. Permette a un piccolo gruppo di fare molto più di quanto potrebbe fare da solo.

I team che ricavano il massimo da questi strumenti li usano proprio così. L’IA si occupa dei grandi volumi e delle ripetizioni, mentre le persone dedicano il proprio tempo al giudizio, alla strategia e alle situazioni che richiedono davvero un intervento umano. È un obiettivo molto diverso dal cercare di eliminare le persone dal processo.

Quando l’obiettivo è la pura sostituzione, si tende a spingere la tecnologia oltre ciò che sa fare bene, e i fallimenti risultano evidenti e costosi. Quando invece si vuole amplificare il lavoro delle persone, si lascia all’IA ciò che sa fare e si mantengono gli esseri umani dove aggiungono più valore. Il secondo approccio funziona meglio ed è più onesto sul livello effettivo della tecnologia di oggi.

Nei prossimi cinque anni mi aspetto che gli agenti assumano una quota sempre maggiore delle conversazioni di routine, ed è giusto che sia così. Quel lavoro non richiede una persona che controlli ogni parola.

I flussi di lavoro che dovrebbero mantenere sempre una persona coinvolta sono quelli in cui la posta in gioco è alta o la situazione è davvero nuova. Tutto ciò che riguarda il consenso, la conformità o una decisione difficile da revocare. Una persona dovrebbe mantenere la responsabilità della direzione, e l’IA dovrebbe aiutarla a fare molto più di quanto potrebbe altrimenti.

Guardando al futuro, quali sviluppi dell’IA conversazionale ti entusiasmano di più, e come immagini l’evoluzione di piattaforme come Convos man mano che i modelli diventano più capaci, multimodali e autonomi?

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

Man mano che i modelli migliorano, gli scambi gestiti dalla nostra piattaforma diventano più naturali e utili senza doverne ricostruire ogni volta le fondamenta. Avendo progettato il sistema per passare da un modello all’altro, possiamo introdurre questi miglioramenti quando arrivano.

La multimodalità è lo sviluppo che seguo più da vicino. Oggi la conversazione è testuale. Quando i modelli sapranno gestire meglio immagini e altri formati, avremo una concreta opportunità di arricchire gli scambi mantenendo l’immediatezza che rende efficace la messaggistica.

Sull’autonomia sono ottimista, ma prudente. Ogni mese vengono rilasciati agenti più capaci, che potranno gestire molto da soli. Ma in un settore regolamentato, una maggiore autonomia deve accompagnarsi a più disciplina, non a meno. Quanto più crescono le capacità, tanto più contano i limiti.

Ho iniziato perché ero io la persona che mandava messaggi nel vuoto senza ricevere nulla in risposta. È ancora il problema che mi sta più a cuore. Per quanto questi modelli diventino capaci, il criterio a cui torno è semplice: la persona dall’altra parte si sente ascoltata?

Grazie per questa bella intervista. I lettori che desiderano saperne di più possono visitare Convos.