Andrew Missey, CTO et co-fondateur de Convos – Série d’entretiens

Andrew Missey, CTO et co-fondateur de Convos, est un ingénieur logiciel et un leader de produit avec une expérience qui s’étend sur le développement de produits d’IA, l’architecture logicielle, les réseaux et l’ingénierie full-stack. Avant de co-fonder Convos, il a aidé à développer et à lancer deux plateformes créatives et marketing alimentées par l’IA chez Forum3, combinant l’ingénierie pratique avec la gestion de produit technique. Ses rôles précédents chez N-able (NABL ), Autoshop Solutions et Brand IQ ont impliqué la construction d’applications frontend, de systèmes backend, de tableaux de bord client et d’outils logiciels internes en utilisant des technologies telles que Svelte, NestJS, Angular et JavaScript. Cette expérience multidisciplinaire lui a permis de relier l’exécution technique à la stratégie de produit alors qu’il dirige le développement de la plateforme de communication alimentée par l’IA de Convos.

Convos est une plateforme de messagerie instantanée alimentée par l’IA conçue pour aider les campagnes politiques et les entreprises de communication à remplacer les messages de masse unidirectionnels par des conversations personnalisées et bidirectionnelles à grande échelle. La plateforme convertit les réponses en analyse de sentiment en temps réel, en classifications de sujets, en résultats d’appel à l’action, en mesures d’engagement et en insights structurés sur les électeurs que les campagnes peuvent utiliser pour affiner leur portée. Son système d’IA fermé fonctionne dans les limites des matériaux et des messages approuvés par la campagne, tout en fournissant des fonctionnalités telles que la segmentation des contacts, les historiques de conversation, le suivi des liens, les exports de données et les traçages d’audit axés sur la conformité. Convos peut également compléter l’infrastructure de messagerie existante d’une organisation plutôt que de l’obliger à remplacer ses systèmes de communication actuels.

Vous avez co-fondé Convos après avoir observé comment le texte politique et organisationnel était devenu principalement une communication unidirectionnelle. Quelle était l’insight originale qui vous a convaincu qu’il y avait une opportunité de transformer le texte de masse en conversations alimentées par l’IA, et quels étaient les plus grands défis techniques que vous avez rencontrés lors de la construction de la plateforme ?

L’insight est venue du fait d’être à la réception de cela.

Autour de l’élection de 2024, j’ai été bombardé de textes politiques, comme beaucoup de gens. À un moment donné, j’ai commencé à répondre à eux. J’ai posé une question ou répondu, et rien n’est jamais revenu. Les messages étaient envoyés par millions, mais le moment où vous essayiez d’avoir un véritable échange, il n’y avait personne.

Cela m’a frappé comme une énorme opportunité manquée. La personne à l’autre bout était déjà engagée. Elle posait une vraie question. Mais aucune réponse ne serait jamais envoyée.

L’idée derrière Convos était simple. Transformer la diffusion en une véritable conversation, à grande échelle, sans avoir besoin d’une salle pleine de personnes pour la gérer.

Les plus grands défis techniques sont venus de trois choses : l’échelle, la latence et la conformité.

L’échelle est l’évidente. Vous gérez des milliers de conversations en même temps, et chacune a son propre état et son propre historique. La latence compte plus que les gens ne le pensent. Si quelqu’un répond et que la réponse prend trop de temps, le moment est passé. Le texte semble presque immédiat, et l’expérience doit correspondre à cela.

La conformité était la partie la plus difficile, et c’était quelque chose que nous avons priorisé dès le début. Le texte politique est lourdement réglementé, et se tromper n’est pas une option. Beaucoup de notre ingénierie initiale est allée dans la garantie que le système restait dans les limites des messages et respectait le consentement et les opt-out de manière à aller bien au-delà de simplement attraper le mot “STOP”.

Convos opère à l’intersection de l’IA conversationnelle, de la messagerie à grande échelle et de l’analyse de sentiment en temps réel. Quelles leçons avez-vous apprises en déployant des systèmes d’IA qui doivent engager des milliers de personnes simultanément tout en restant personnels et authentiques ?

La plus grande leçon est que “personnaliser à grande échelle” est quelque chose que vous devez ingénier. Cela n’arrive pas par défaut.

Lorsque vous exécutez des milliers de conversations à la fois, la tentation est de les traiter comme un grand lot. Mais la personne qui reçoit le texte ne se soucie pas de votre lot. Pour elle, c’est un échange un-à-un, et cela doit se sentir ainsi. Cela signifie que chaque conversation doit avoir son propre contexte et son propre historique, afin qu’une réponse réponde réellement à ce que cette personne spécifique a dit, et non à une moyenne de tout le monde.

Nous avons également appris à prêter une attention particulière à ce que les gens nous disent vraiment. Une réponse n’est pas seulement une réponse. Elle porte un sentiment. Quelqu’un peut répondre avec une question, avec enthousiasme, avec frustration ou avec un signal clair qu’il veut être laissé seul. Lire ces nuances correctement est ce qui fait ou défait une interaction.

À la fin, l’authenticité vient de l’écoute, et non de sonner intelligent. L’échange qui se sent le plus humain est celui qui répond à la vraie question et respecte le temps de la personne.

Vous avez soutenu que de nombreuses organisations se concentrent trop lourdement sur les références de modèle tout en ignorant la personnalité et le style de communication. Pourquoi pensez-vous que la personnalité devient un facteur critique dans le déploiement de l’IA d’entreprise, et comment les organisations devraient-elles l’évaluer ?

Les références mesurent la capacité. Ils ne mesurent pas l’adéquation.

Un modèle peut obtenir un score extrêmement élevé en raisonnement ou en codage et être encore le mauvais choix pour une conversation avec un électeur. La façon dont il formule les choses, à quel point il sonne chaud ou formel, s’il sait quand être bref, tout cela compte énormément une fois qu’une véritable personne est à l’autre bout.

Dans notre monde, le modèle ne résout pas un problème mathématique. Il représente une campagne dans un message texte. Chaque campagne a sa propre voix, et le modèle doit correspondre à celle-ci plutôt que d’imposer la sienne. Si le ton est faux, cela n’a pas d’importance à quel point le modèle sous-jacent est intelligent. L’interaction échoue.

Il y a également un aspect de capacité que les références manquent. Une campagne peut donner à l’agent des conseils détaillés sur ce qu’il faut dire, ce qu’il faut éviter et comment gérer des sujets spécifiques. Le modèle doit suivre tout cela, de manière cohérente, sur une longue période. Certains modèles sont beaucoup meilleurs que d’autres pour retenir des instructions complexes sans dériver à mi-chemin de la conversation. Cette capacité fait également partie de la personnalité, car un modèle qui sonne bien mais cesse de suivre ses instructions n’est pas celui que vous pouvez mettre devant de vraies personnes.

C’est pourquoi la personnalité devient un facteur réel dans le déploiement de l’IA d’entreprise. À mesure que les modèles deviennent plus capables dans l’ensemble, l’écart de capacité brute entre eux se réduit. Ce qui reste, c’est le caractère. Comment ils communiquent, et s’ils restent dans les limites que vous établissez.

La façon de l’évaluer n’est pas sur un tableau de bord. C’est de tester les modèles sur votre cas d’utilisation réel, avec votre contenu réel, et de lire les sorties de la manière dont votre utilisateur final le ferait. Nous faisons passer les modèles par le même type d’échanges qu’ils géreront en production et les jugeons sur le fait que la conversation se sente correcte. Cela nous dit beaucoup plus que tout score de référence.

Votre équipe a testé plusieurs modèles leaders et a observé des différences significatives dans la façon dont ils performaient sur différentes tâches. Qu’est-ce que vous avez appris sur les forces et les faiblesses des principaux LLM actuels, et pourquoi certains sont mieux adaptés pour un travail conversationnel que d’autres ?

Ce que nous avons appris, c’est qu’il n’y a pas de meilleur modèle unique. Il n’y a que le meilleur modèle pour un travail donné.

Certains modèles sont excellents pour suivre les instructions avec précision, ce qui compte lorsque vous avez besoin que le système reste à l’intérieur de limites strictes. Certains sont plus forts dans le ton conversationnel naturel. Certains sont plus rapides, ce qui est une force en soi lorsque la latence fait partie de l’expérience. D’autres sont meilleurs pour raisonner à travers une demande compliquée mais se sentent rigides ou prennent trop de temps pour répondre dans un échange casual.

Pour le travail conversationnel en particulier, les qualités qui comptent ne sont pas toujours celles qui obtiennent les gros titres. La vitesse compte. La cohérence compte. Savoir quand être bref compte. Un modèle qui écrit une belle réponse de trois paragraphes est souvent le mauvais choix lorsque la bonne réponse est une phrase.

Rien de tout cela n’apparaît sur un tableau de bord. Vous n’apprenez cela qu’en mettant les modèles face au travail réel et en prêtant attention à la façon dont ils le gèrent.

De nombreuses entreprises adoptent de plus en plus des stratégies multi-modèles plutôt que de compter sur un seul fournisseur d’IA. Quels sont les avantages de la construction de systèmes qui peuvent basculer entre les modèles, et quels sont les considérations architecturales nécessaires pour que cela soit possible ?

L’avantage principal est que vous n’êtes pas verrouillé.

Si vous construisez tout autour d’un fournisseur, vous héritez de toutes leurs contraintes. Leurs prix, leurs limites de taux, leur latence, leurs temps d’arrêt et leur calendrier de publication deviennent les vôtres. Une approche multi-modèle vous permet de router chaque tâche vers le modèle qui la gère le mieux, et cela vous donne un endroit où aller lorsque l’un des fournisseurs a une mauvaise journée.

Cela vous permet également de faire correspondre le coût au travail. Toute interaction n’a pas besoin de votre modèle le plus puissant et le plus coûteux. Pouvoir envoyer le travail simple à un modèle plus léger et réserver le modèle lourd pour les cas difficiles fait une grande différence à grande échelle.

L’architecture est ce qui rend cela possible, et la décision clé est de construire une couche d’abstraction entre votre application et tout modèle spécifique. Votre système ne devrait pas parler directement à l’API d’un fournisseur tout au long de la base de code. Il devrait parler à votre propre interface interne, et cette interface décide quel modèle gère réellement la demande.

Une fois que vous avez cela, vous pouvez ajouter une logique de routage, des sauvegardes lorsque le fournisseur échoue, et la capacité de basculer entre les modèles sans réécrire votre application. Vous avez également besoin d’un traitement cohérent des invites et des sorties entre les modèles, car chacun se comporte un peu différemment, et votre système doit lisser ces différences.

C’est plus de travail au début. Mais cela vous achète une flexibilité qui est très difficile à ajouter plus tard.

Vous avez récemment souligné à quel point les modèles d’IA évoluent rapidement, avec de nouvelles versions qui changent parfois les caractéristiques de performance de manière inattendue. Comment les entreprises doivent-elles équilibrer le désir d’adopter les derniers modèles avec le besoin de stabilité, de fiabilité et de performances prévisibles ?

La réponse honnête est qu’un nouveau modèle n’est pas une mise à niveau jusqu’à ce que vous ayez prouvé qu’il l’est.

Chaque version est excitante, et il y a une véritable pression pour adopter la dernière chose tout de suite. Mais nous avons vu de nouveaux modèles changer de comportement de manière que nous ne nous attendions pas. Quelque chose qui fonctionnait de manière fiable commence à répondre un peu différemment, et dans un système de production, ces petits changements s’additionnent.

La façon dont nous le gérons est simple. Aucun modèle ne rentre dans notre pipeline jusqu’à ce que nous l’ayons testé nous-mêmes. Lorsqu’une nouvelle version est publiée, nous ne prenons pas les références ou l’annonce à leur parole. Nous nous asseyons et exécutons le modèle à travers les mêmes types de conversations qu’il gérerait en production, et nous lisons les sorties nous-mêmes.

Cette étape manuelle n’est pas facultative pour nous. Un modèle peut sembler meilleur sur papier et gérer un véritable échange d’une manière que nous ne sommes pas à l’aise de mettre devant les électeurs. La seule façon de le savoir est de le soumettre aux mêmes situations que notre système traite chaque jour et de voir comment il répond réellement.

C’est un autre endroit où la couche d’abstraction gagne sa place. Puisque notre application ne dépend pas d’un modèle spécifique, nous pouvons introduire une nouvelle version, la tester contre les conversations que nous traitons réellement, et la comparer honnêtement à ce que nous exécutons actuellement. Si cela franchit la barre, nous basculons. Si cela ne le fait pas, nous attendons.

Les hallucinations restent l’un des plus grands obstacles à l’adoption de l’IA d’entreprise, en particulier lorsqu’ils travaillent avec de grands ensembles de données et des informations complexes. Quelles techniques pratiques se sont avérées les plus efficaces pour réduire les hallucinations dans les environnements de production ?

La technique la plus efficace que nous ayons trouvée est de restreindre ce que le modèle est autorisé à savoir.

Beaucoup d’hallucinations proviennent de demander à un modèle de répondre à partir de ses propres connaissances générales, où il sera heureux de combler les lacunes avec quelque chose qui sonne juste. Nous faisons le contraire. Notre IA travaille strictement à partir des informations que la campagne a fournies. Il n’a pas accès à Internet ouvert et ne tire pas sur une vague mémoire du monde.

Si la réponse n’est pas dans le matériel qui lui a été donné, la bonne réponse est de dire qu’il n’a pas cette information. Cette seule limite supprime un énorme risque.

Nous n’arrêtons pas là, cependant. Nous avons plusieurs vérifications en place pour nous assurer qu’une réponse correspond à ce que la campagne a fourni. Même après que le modèle génère une réponse, cette réponse est vérifiée contre les informations de la campagne avant d’aller n’importe où. Si quelque chose ne correspond pas, cela n’est pas envoyé.

Au-delà de cela, les techniques pratiques sont liées à l’ancrage et aux garde-fous. Donnez au modèle le contexte spécifique et pertinent dont il a besoin pour la tâche devant lui, plutôt qu’une grande pile indifférenciée de données. Plus l’information est ciblée, moins il y a de place pour dériver.

Nous mettons également des limites claires sur ce que le système est autorisé à faire et à dire, et nous surveillons les véritables conversations plutôt que de supposer que tout va bien. Vous ne détectez pas les problèmes en faisant confiance au modèle. Vous les détectez en regardant la sortie.

Dans un espace réglementé comme le texte politique, une réponse inventée est une responsabilité, nous avons donc conçu le système pour privilégier la transparence plutôt que de deviner.

À mesure que les organisations déployeront des agents d’IA à travers le support client, la communication, le marketing et les opérations, quels sont les erreurs que vous voyez les équipes répéter lors du passage des projets pilotes aux déploiements à grande échelle ?

L’erreur que je vois le plus est que les équipes testent si leur agent fonctionne, mais pas s’il peut être cassé.

Je ne peux pas compter le nombre de fois qu’une entreprise a publié un chatbot d’IA, et dans un jour, quelqu’un en ligne l’a jailbreaké pour qu’il dise quelque chose qu’il n’aurait jamais dû dire. Cela se fait détourner de ses instructions, trompé pour sortir du script, ou manipulé pour représenter la marque d’une manière qui finit par être une capture d’écran que tout le monde passe.

Cela se produit parce que, dans un pilote, tout le monde se comporte bien. Vous testez l’agent avec des personnes raisonnables qui posent des questions raisonnables, et cela semble génial. La production est à l’opposé. Le moment où quelque chose est public, une partie des personnes qui lui parlent essaient activement de le faire dérailler.

Si vous n’avez pas testé pour ce cas adversatif, vous n’avez pas vraiment testé. Vous devez essayer de casser votre propre système avant que quelqu’un d’autre ne le fasse. Poussez-le, alimentez-le avec des entrées étranges et hostiles, et voyez si cela tient ses limites lorsque quelqu’un travaille activement contre lui.

L’autre erreur répétée est de supposer qu’un démo qui fonctionne est un système qui fonctionne. Un pilote est une poignée de conversations surveillées sur le chemin heureux. La production est des milliers de personnes à toutes les heures se comportant de manière que vous n’avez pas anticipée, et les cas de bordure que vous avez écartés deviennent des événements quotidiens à grande échelle.

Mon conseil est de passer moins de temps à perfectionner le démo et plus de temps à essayer de casser la chose vous-même. Si cela ne peut pas survivre à votre attaque, cela ne survivra pas à être public.

Les agents d’IA deviennent de plus en plus capables de gérer des conversations qui nécessitaient autrefois un personnel humain. Où voyez-vous l’équilibre entre l’automatisation et la surveillance humaine au cours des cinq prochaines années, et quels flux de travail devraient toujours garder un humain dans la boucle ?

C’est difficile, et je ne pense pas que quiconque sache exactement où la ligne atterrit dans cinq ans. La façon dont je le vois, la véritable valeur de l’IA est en tant que multiplicateur de force. Cela permet à un petit groupe de personnes de faire beaucoup plus qu’elles ne pourraient jamais le faire seules.

Les équipes qui tirent le plus parti de ces outils les utilisent exactement de cette façon. L’IA prend le volume et la répétition, et les gens passent leur temps sur le jugement, la stratégie et les situations qui nécessitent vraiment un humain. C’est un objectif très différent de celui qui consiste à remplacer les gens.

Lorsque l’objectif est un remplacement pur, vous tendez à pousser la technologie au-delà de ce qu’elle est vraiment bonne, et cela échoue de manière visible et coûteuse. Lorsque l’objectif est de multiplier vos personnes, vous laissez l’IA faire ce qu’elle fait bien et gardez les humains là où ils ajoutent le plus de valeur. La deuxième approche fonctionne mieux, et elle est plus honnête sur la technologie telle qu’elle est aujourd’hui.

Au cours des cinq prochaines années, j’attends que les agents prennent en charge une plus grande partie de la charge conversationnelle de routine, et ils devraient. Ce travail n’a pas besoin d’une personne pour regarder chaque mot.

Les flux de travail qui devraient toujours impliquer un humain sont ceux où les enjeux sont élevés ou la situation est vraiment nouvelle. Tout ce qui touche au consentement, à la conformité ou à une décision qui serait difficile à annuler. Une personne devrait posséder la direction, et l’IA devrait l’aider à couvrir beaucoup plus de terrain qu’elle ne pourrait autrement.

En regardant vers l’avenir, quels développements dans l’IA conversationnelle vous excitent le plus, et comment voyez-vous les plateformes comme Convos évoluer à mesure que les modèles deviennent plus capables, multimodaux et autonomes ?

Ce qui m’excite le plus, c’est que les conversations vont continuer à s’améliorer.

À mesure que les modèles s’améliorent, les échanges que notre plateforme gère deviennent plus naturels et plus utiles sans que nous devions reconstruire les fondations chaque fois. Puisque nous avons conçu le système pour basculer entre les modèles, nous pouvons apporter ces améliorations à mesure qu’elles arrivent.

Le multimodal est le développement que je surveille le plus étroitement. Actuellement, la conversation est textuelle. À mesure que les modèles gèrent les images et d’autres formats plus efficacement, il y a une véritable opportunité de rendre ces échanges plus riches tout en gardant l’immédiateté qui fait que le texte fonctionne.

En ce qui concerne l’autonomie, je suis optimiste mais prudent. Des agents plus capables sont publiés mensuellement, et ils seront en mesure de gérer beaucoup de choses seuls. Mais dans un espace réglementé, plus d’autonomie doit venir avec plus de discipline, et non moins. Les limites comptent plus à mesure que la capacité augmente.

Je me suis lancé dans cela parce que j’étais la personne qui textait dans le vide et ne recevait rien en retour. C’est toujours le problème dont je me soucie le plus. Quelle que soit la capacité de ces modèles, la mesure à laquelle je reviens toujours est simple. La personne à l’autre bout se sent-elle entendue ?

Je vous remercie pour cette grande interview. Les lecteurs qui souhaitent en savoir plus peuvent visiter Convos.