Vistaly : l'IA redéfinit les arbres de solutions d'opportunités

L'impact de l'IA sur le développement de produits

Récemment, j'ai terminé un projet d'ingénierie particulièrement intense. Bien que je sois familier avec le codage depuis plusieurs années, je ne me considère pas comme un ingénieur de formation. Mon parcours professionnel est davantage orienté vers la gestion de produits et le design. Cependant, l'introduction de l'intelligence artificielle dans notre quotidien professionnel change radicalement la donne. Elle nous permet de réaliser des choses que nous n'aurions jamais cru possibles. Cette expérience en est la parfaite illustration.

Aujourd'hui, je souhaite partager avec vous une aventure d'ingénierie. Bien que certains aspects techniques puissent sembler complexes, il est important de souligner que je n'avais aucune connaissance préalable de ces concepts il y a un an. Grâce à l'IA, j'ai pu apprendre et progresser. Mon but en partageant cette histoire est de démontrer ce qui est désormais réalisable grâce à ces nouvelles technologies.

Lancement des arbres de solutions d'opportunités par Vistaly

En février, j'ai annoncé le développement de deux nouveaux services pour Vistaly : des instantanés d'entretiens générés par l'IA et des arbres de solutions d'opportunités également générés par l'IA. Nous avons lancé un appel à partenaires pour tester ces innovations, et plus de 100 entreprises ont manifesté leur intérêt. Après une sélection rigoureuse, nous avons retenu huit partenaires pour la phase de conception initiale.

Chaque équipe a téléchargé trois entretiens clients, à partir desquels nous avons extrait des moments clés et des opportunités. Ces informations ont ensuite été utilisées pour générer un arbre de solutions d'opportunités. Mon rôle était de fournir les services d'IA, tandis que Vistaly se concentrait sur la création de l'interface utilisateur et des flux de travail associés.

Les premiers retours ont été extrêmement positifs. Les équipes ont rapidement exprimé le souhait de pouvoir intégrer davantage d'entretiens, ce qui a nécessité des ajustements de notre part pour répondre à cette demande croissante.

Les défis de l'intégration de nouveaux entretiens

Mettre à jour un arbre de solutions d'opportunités avec de nouveaux entretiens s'est avéré être un défi bien plus complexe que prévu. Initialement, j'avais sous-estimé la difficulté de cette tâche.

Notre objectif commun avec Vistaly est de ne pas simplement produire des arbres de solutions d'opportunités générés par l'IA, mais de permettre aux utilisateurs d'interagir avec eux, de les ajuster et de collaborer avec l'IA. Nous souhaitons faciliter la synthèse des entretiens, sans pour autant la réaliser entièrement à leur place.

Une capture d'écran de Vistaly montre comment deux opportunités peuvent être fusionnées, avec des modifications visibles et interactives. Notre but est de communiquer clairement chaque changement, permettant ainsi à l'équipe d'accepter, de modifier ou de rejeter les modifications proposées. Pour cela, nous avons décidé de nous inspirer de l'outil git diff, qui est couramment utilisé pour suivre les modifications dans le code. Nous avons donc cherché à créer un équivalent pour nos arbres de solutions d'opportunités.

Cette décision s'est avérée judicieuse, mais elle a également engendré un volume de travail considérable. Il ne suffisait pas que notre service génère un arbre mis à jour ; il devait également fournir un guide détaillé des changements effectués.

Le prototype : une étape parmi d'autres

Un thème récurrent dans mon podcast Just Now Possible est qu'il est relativement aisé de créer un prototype impressionnant avec l'IA, mais bien plus ardu de transformer ce prototype en un produit prêt pour la production. Cela a été exactement mon expérience.

Mon service d'arbre de solutions d'opportunités se compose de deux sous-services : le premier génère un nouvel arbre à partir de zéro, et le second met à jour un arbre existant avec de nouveaux entretiens.

Le premier service faisait partie de notre phase alpha initiale et fonctionnait correctement. Cependant, le second service devait être développé de toutes pièces avant que nos partenaires puissent ajouter un quatrième entretien.

Chaque opportunité dans l'arbre possède des sources et des enfants qui ne doivent pas être perdus lors de modifications telles que la division, la fusion ou la suppression. Bien que ces éléments puissent sembler similaires en surface, ils sont en réalité très différents. Lors de la mise à jour d'un arbre, il est crucial de préserver autant que possible la structure existante, sauf si le nouveau contenu justifie un changement.

Malgré ces défis, j'ai été agréablement surpris de constater que j'ai pu obtenir un résultat fonctionnel en quelques jours seulement. Nos partenaires de conception ont commencé à utiliser le service, et l'un d'eux a rapidement atteint nos limites bêta. Ils ont alors demandé à passer à un abonnement payant pour obtenir un accès complet, ce qui nous a ravis.

Cependant, à mesure qu'ils téléchargeaient plus d'entretiens, mon design initial a commencé à montrer ses limites. Nous avons observé des comportements inattendus.

Le service d'IA générait un arbre mis à jour et fournissait un ensemble de changements avec des instructions détaillées. L'équipe de Vistaly a remarqué que ces instructions ne produisaient pas toujours l'arbre final attendu. Nous voulions guider le client à travers chaque changement, mais parfois, l'arbre généré par les instructions différait de celui produit par le service.

Vistaly a signalé ce problème alors que je me rendais à la Nouvelle-Orléans pour le Jazz Fest. Avec le recul, je suis heureux de ne pas avoir su l'ampleur du travail qui m'attendait à mon retour. Il restait environ 80 % du travail à accomplir pour transformer la mise à jour de l'arbre en un produit véritablement robuste.

Une analyse approfondie des problèmes

À mon retour, j'ai entrepris de diagnostiquer le problème et j'ai rapidement réalisé l'ampleur de la tâche. Mon service fonctionnait comme un pipeline combinant des étapes de LLM avec du code déterministe.

En examinant les bugs, j'ai compris que notre approche n'était pas optimale. Les différences entre les arbres, contrairement aux documents linéaires, sont ambiguës.

Si j'ajoute une phrase à un document, la différence est claire. Mais si je divise une opportunité en deux puis fusionne l'une d'elles avec une autre, le mouvement initial est masqué.

Lorsque A est divisé en A et B, les sources et les enfants d'A doivent être répartis entre A et B. Si le modèle décide de diviser une opportunité, il doit déterminer comment répartir les sources et les enfants entre les nouvelles opportunités.

Par exemple, si A a les sources 1, 2, 3 et les enfants x, y, z, après la division, A pourrait avoir les sources 1 et 2 et l'enfant x, tandis que B aurait la source 3 et les enfants y et z.

Lorsque B est fusionné avec C, C hérite des sources et des enfants de B. Si C a les sources 4 et 5 et les enfants t, u, v, après la fusion, C aurait les sources 3, 4, 5 et les enfants t, u, v, y, z.

En comparant l'arbre d'entrée à l'arbre de sortie, il semble que certaines sources et enfants d'A se déplacent vers C, mais sans explication visible. La division et la fusion sont conceptuellement claires, mais invisibles dans la différence.

J'ai réalisé que les différences d'arbres étaient bien plus complexes que celles des textes linéaires. Nous devions non seulement montrer ce qui avait changé, mais aussi expliquer pourquoi, afin d'impliquer l'utilisateur. J'avais besoin de reconstruire chaque mouvement étape par étape.

Cela signifiait que le modèle devait montrer son travail, ce qui a ouvert une nouvelle série de défis.

Refactorisation des prompts pour plus de transparence

J'ai décidé de refactoriser mes prompts pour que le modèle génère à la fois la sortie finale et les étapes intermédiaires.

Mes prompts indiquaient déjà les actions possibles : ajouter, supprimer, reformuler, fusionner, diviser, etc. Mais ces directives n'étaient pas suffisantes. Le modèle devait désormais montrer son travail dans le langage de nos ensembles de changements, des mouvements spécifiques compréhensibles pour l'utilisateur final.

En reformulant les prompts, j'ai demandé au modèle de détailler chaque étape du processus de création de l'arbre final. Cela impliquait de décomposer chaque action en mouvements distincts que l'utilisateur pourrait suivre et comprendre. Par exemple, si une opportunité devait être divisée, le modèle devait expliquer comment il répartissait les sources et les enfants entre les nouvelles opportunités. De même, pour une fusion, le modèle devait détailler comment les éléments des opportunités fusionnées étaient combinés.

Cette approche a permis de rendre le processus de mise à jour des arbres plus transparent et compréhensible pour les utilisateurs. En montrant chaque étape, nous avons pu non seulement clarifier ce qui avait changé, mais aussi pourquoi ces changements avaient eu lieu, renforçant ainsi la confiance des utilisateurs dans le système.

Cependant, cette refactorisation a également révélé de nouveaux défis. Le modèle devait être capable de gérer des cas complexes où plusieurs actions étaient nécessaires pour atteindre le résultat final. Cela a nécessité une collaboration étroite entre l'équipe de développement et le modèle d'IA pour affiner les prompts et s'assurer que chaque étape était correctement documentée.

En fin de compte, cette refactorisation a permis d'améliorer considérablement la qualité du service, en offrant aux utilisateurs une vue plus claire et plus détaillée des changements apportés à leurs arbres de solutions d'opportunités. Cela a également renforcé notre engagement envers la transparence et la collaboration, en montrant comment l'IA peut être utilisée pour faciliter des processus complexes tout en restant accessible et compréhensible pour les utilisateurs finaux.