Un produit minimum viable (MVP) est une version d'un produit avec juste assez de fonctionnalités pour être utilisable par les premiers clients, qui peuvent ensuite fournir des retours pour le développement futur du produit.
\n\nAujourd'hui, je veux me concentrer sur ce à quoi cela ressemble pour le déploiement d'applications IA. Pour cela, nous devons seulement comprendre 4 choses.
\nLe principe de Pareto, également connu sous le nom de règle des 80/20, s'applique toujours mais d'une manière différente de ce que vous pourriez penser.
\n\nUne analogie que j'utilise souvent pour aider à comprendre ce concept est la suivante : Vous avez besoin de quelque chose pour vous aider à aller du point A au point B. Peut-être que la vision est d'avoir une voiture. Cependant, le MVP n'est pas un châssis sans roues ni moteur. Au lieu de cela, il pourrait ressembler à un skateboard. Vous allez livrer et réaliser que le produit a besoin de freins ou de direction. Alors vous livrez une trottinette. Ensuite, vous découvrez que la trottinette a besoin de plus de levier, donc vous ajoutez des roues plus grandes et vous vous retrouvez avec un vélo. Limité par la force que vous pouvez appliquer en tant qu'être humain, vous commencez à penser aux moteurs et pouvez vous diversifier dans les cyclomoteurs, les vélos électriques et les motos. Puis un jour, vous livrez la voiture.
\n\nQuand on parle de quelque chose qui est fait à 80% ou prêt à 80%, c'est généralement dans un sens d'apprentissage automatique. Dans ce contexte, chaque composant est déterministe, ce qui signifie que 80% se traduit par 8 fonctionnalités sur 10 complètes. Une fois que les 2 fonctionnalités restantes sont prêtes, nous pouvons livrer le produit. Cependant, si nous voulons suivre la règle des 80/20, nous pourrions être en mesure de livrer le produit avec 80% des fonctionnalités et d'ajouter les 20% restants plus tard, comme une voiture sans radio ni climatisation. Cependant, la signification de 80% peut varier considérablement, et cette définition peut ne pas s'appliquer à une application alimentée par l'IA.
\n\nLe problème avec les statistiques récapitulatives
\n![\"Anscombe's](\"/assets/images/anscombes_quartet.png\")
\nL'image ci-dessus est un exemple du quartet d'Anscombe. C'est un ensemble de quatre jeux de données qui ont des statistiques descriptives simples presque identiques mais des distributions et des apparences très différentes. C'est une explication classique de pourquoi les statistiques récapitulatives peuvent être trompeuses.
\n\nConsidérez l'exemple suivant :
\n\n| Query_id | \nscore | \n
|---|---|
| 1 | \n0.9 | \n
| 2 | \n0.8 | \n
| 3 | \n0.9 | \n
| 4 | \n0.9 | \n
| 5 | \n0.0 | \n
| 6 | \n0.0 | \n
Le score moyen est de 0,58. Cependant, si nous analysons les requêtes par segments, nous pourrions découvrir que nous servons la majorité des requêtes exceptionnellement bien !
\n\n\n\n\nAdmettre ce dans quoi vous êtes mauvais
\nÊtre honnête sur ce dans quoi vous êtes mauvais est un excellent moyen de créer de la confiance avec vos utilisateurs. Si vous pouvez identifier avec précision quand quelque chose va mal fonctionner et le rejeter avec confiance, alors vous pourriez être prêt à livrer un excellent produit tout en éduquant vos utilisateurs sur les limitations de votre application.
\n
Il est très important de comprendre les limitations de votre système et d'être capable de comprendre avec confiance les caractéristiques de votre système au-delà des statistiques récapitulatives. C'est parce que tous les systèmes ne sont pas égaux. Le comportement d'un système probabiliste pourrait être très différent de l'exemple précédent. Considérez le jeu de données suivant :
\n\n| Query_id | \nScore | \n
|---|---|
| 1 | \n.59 | \n
| 2 | \n.58 | \n
| 3 | \n.59 | \n
| 4 | \n.57 | \n
Un système comme celui-ci a également le même score moyen de 0,58, mais il n'est pas aussi facile de rejeter un sous-ensemble de requêtes...
\n\nConsidérez une application RAG où une grande proportion des requêtes concerne des requêtes de chronologie. Si nos moteurs de recherche ne prennent pas en charge cette contrainte temporelle, nous serons probablement incapables de bien performer.
\n\n| Query_id | \nScore | \nQuery Type | \n
|---|---|---|
| 1 | \n0.9 | \ntext search | \n
| 2 | \n0.8 | \ntext search | \n
| 3 | \n0.9 | \nnews search | \n
| 4 | \n0.9 | \nnews search | \n
| 5 | \n0.0 | \ntimeline | \n
| 6 | \n0.0 | \ntimeline | \n
Si nous sommes pressés de livrer, nous pourrions simplement construire un modèle de classification qui détecte si ces questions sont des questions de chronologie ou non et lancer un avertissement. Au lieu d'essayer constamment de pousser l'algorithme à faire mieux, nous pouvons éduquer l'utilisateur en changeant la façon dont nous pourrions concevoir le produit.
\n\n\n\n\nDétecter les segments
\nLa détection de ces segments pourrait être accomplie de diverses manières. Nous pourrions construire un classificateur ou employer un modèle de langage pour les catégoriser. De plus, nous pouvons utiliser des algorithmes de clustering avec les embeddings pour identifier des groupes communs et potentiellement analyser les scores moyens au sein de chaque groupe. Le seul objectif est d'identifier des segments qui peuvent améliorer notre compréhension des activités au sein de sous-groupes spécifiques.
\n
L'une des pires choses que vous puissiez faire est de passer des mois à développer une fonctionnalité qui n'augmente votre productivité que légèrement tout en ignorant un segment plus important de votre base d'utilisateurs.
\n\nEn repensant notre application et en reconnaissant ses limitations, nous pouvons potentiellement améliorer les performances dans certaines conditions en identifiant les types de tâches que nous pouvons refuser. Si nous sommes capables de mettre ces données de segment dans une sorte d'observabilité intégrée au système, nous pouvons surveiller en toute sécurité quelle proportion de questions est refusée et prioriser notre travail pour maximiser la couverture.
\n\nL'une des choses dangereuses que j'ai remarquées en travaillant avec des startups est que nous pensons souvent que l'IA fonctionne tout court... En conséquence, nous voulons être en mesure de servir une grande application générale sans trop réfléchir à ce que nous voulons exactement accomplir.
\n\nÀ mon avis, la plupart de ces entreprises devraient essayer de se concentrer sur un ou deux domaines importants et identifier un bon créneau à cibler. Si votre application est bonne dans une ou deux tâches, il n'y a aucun moyen que vous ne puissiez pas trouver une centaine ou deux cents utilisateurs pour tester votre application et obtenir des retours rapidement. Alors que si votre application n'est bonne en rien, il va être difficile d'être mémorable et de fournir quelque chose qui a une utilisation répétée. Vous pourriez obtenir une certaine viralité, mais très rapidement, vous allez perdre la confiance de vos utilisateurs et vous retrouver dans une position où vous essayez de réduire le taux d'attrition.
\n\nLorsque nous sommes en amont, la capacité d'utiliser GPT-4 pour faire des prédictions, et le temps de retour est très important. Si nous pouvons obtenir des retours rapidement, nous pouvons itérer rapidement. Si nous pouvons itérer rapidement, nous pouvons construire un meilleur produit.
\n\nLe MVP pour une application IA n'est pas aussi simple que de livrer un produit avec 80% des fonctionnalités. Au lieu de cela, il nécessite une compréhension approfondie des segments de vos utilisateurs que vous pouvez bien servir et la capacité d'éduquer vos utilisateurs sur les segments que vous ne servez pas bien. En comprenant les limitations de votre système et en vous spécialisant, vous pouvez construire un produit qui est mémorable et fournit quelque chose qui a une utilisation répétée. Cela vous permettra d'obtenir des retours rapidement et d'itérer rapidement, conduisant finalement à un meilleur produit, en identifiant vos démonstrations de force.
", "source_hash": "sha256:628188f6afb27695d03e01274d59eb0b52134258149bbac07bab13c678413b93", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-15T20:07:06.000615+00:00" }