Comment Spotify a conçu Vedder, son produit de Text-to-Insights

Guillaume Perchais, Senior Product Manager de Spotify, présentait un talk très attendu lors de l'AI Product Day sur leur nouvel outil interne, Vedder. Un cas d’école pour comprendre le nouveau champ de compétences nécessaires aux Product Managers de demain. Mémorable.

⌛ 7 min de lecture pour partir into the Wild de l'IA

🎫 Les membres Premium du Ticket ont un accès intégral à cet article

C’est l’histoire d’un hack qui est devenu l’outil du quotidien pour les analystes de Spotify.

Product Manager depuis 15 ans, dont 5 chez le leader du streaming audio (750 millions d’utilisateurs dont 290 M payants), Guillaume Perchais travaille dans une équipe qui conçoit des outils internes pour analyser les données de la plateforme.

Plutôt “l’océan” de données : 1,4 trillions d’événements chaque jour, répartis dans 70 000 datasets et accessibles via 7 000 tableaux de bord ! Des infos qui servent aussi bien à personnaliser les playlists des utilisateurs, à détecter les fraudes qu’à établir le reporting financier.

Le travail de Guillaume ? Rendre cette donnée accessible au plus grand nombre d'utilisateurs, à moindre coût.

Voici pour le contexte.

Il y a quelques mois, Guillaume et son équipe se sont posés une question : avec l’émergence de l’IA générative, n’y aurait-il pas une façon de transformer une demande en langage naturel en requête SQL fiable ?

L’objectif : décharger les 300 Data Scientists et Analysts (appelés Data Majors) et aider les 4 500 personnes en interne (= Data Minors) qui consultent cette donnée à le faire de manière plus autonome.

Guillaume Perchais Spotify — Crédit : Hymaïa

8 semaines pour construire un POC de “text-to-SQL”

Après 2 semaines de recherche et 6 semaines de construction, l’équipe aboutit à une première interface basique : un notebook Python qui affiche la requête SQL générée.

L'objectif n'est plus de prouver que ça marche techniquement. Le LLM sait écrire du SQL. Mais de comprendre quelles questions les utilisateurs posent vraiment”, indique Guillaume.

Et comme le monde du produit le sait (trop) bien, la preuve du concept n’est que le début du chemin. Certes, il fonctionne auprès de 2 puis 5 puis 10 utilisateurs.

Mais ces derniers posent des questions complexes qui n’ont pas été anticipées (du style “pourquoi on a moins d’utilisateurs en Inde ces 6 derniers mois ?”).

Les ingénieurs, de leur côté, veulent mettre un nouveau LLM qui vient de sortir… mais la squad réalise qu’elle n’a aucun moyen de savoir si cela va améliorer ou dégrader le système.

Bref, la traditionnelle difficulté de passer de l’étape du POC à un véritable produit.

Produit IA vs Produit traditionnel : la différence fondamentale de la stabilité

Guillaume prend alors un pas de recul pour expliquer le nouveau monde que représente un produit IA.

Dans un produit traditionnel, les étapes sont linéaires : le ou la PM fait les spec de la fonctionnalité, les ingés la construisent, l’équipe la teste puis la met en prod’.

Logique : déterministe
Dès qu’il y a une erreur, tu sais pourquoi.

Pour un produit IA, c’est-à-dire qui comporte un LLM en son cœur, la différence tient en un mot : le contrôle. Ou plutôt la perte de contrôle.

Logique : non déterministe
Les Product ne peuvent plus garantir le résultat final (ni comprendre exactement pourquoi le produit déraille parfois)

Tout notre boulot consiste désormais à recréer cette stabilité”, résume Guillaume.

Comment ? En agissants à 3 niveaux différents :

Les garde-fous (guardrails) > restreindre le champ des possibles en entrée
Les évaluations > s’assurer que le LLM fasse bien ce qu’on lui demande quand il est en capacité d’y répondre.
Augmenter la confiance dans les réponses en sortie

Zoomons sur ces 3 points cruciaux. Le cœur de l’intervention. Magistral.