![\"Le](\"/assets/images/anscombes_quartet.png\")
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 livrer des applications d'IA. Pour ce faire, nous n'avons besoin de comprendre que 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 l'on pourrait 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 à une planche à roulettes. Vous allez livrer et réaliser que le produit a besoin de freins ou de direction. Alors vous livrez un scooter. Ensuite, vous vous rendez compte que le scooter a besoin de plus de levier, donc vous ajoutez des roues plus grandes et vous finissez 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\nLorsqu'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 qui sont complètes. Une fois les 2 fonctionnalités restantes 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, puis 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 des statistiques récapitulatives
\n
L'image ci-dessus est un exemple du quartet d'Anscombe. Il s'agit d'un ensemble de quatre ensembles 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 la raison pour laquelle 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 renforcer la confiance avec vos utilisateurs. Si vous pouvez identifier avec précision quand quelque chose fonctionnera mal et le rejeter avec confiance, alors vous pourriez être prêt à livrer un excellent produit tout en informant vos utilisateurs sur les limites de votre application.
\n
Il est très important de comprendre les limites 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. En effet, 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 l'ensemble 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 partie des requêtes concerne des requêtes temporelles. Si nos moteurs de recherche ne prennent pas en charge cette contrainte de temps, nous ne pourrons probablement pas bien performer.
\n\n| Query_id | \nScore | \nType de requête | \n
|---|---|---|
| 1 | \n0.9 | \nrecherche textuelle | \n
| 2 | \n0.8 | \nrecherche textuelle | \n
| 3 | \n0.9 | \nrecherche d'actualités | \n
| 4 | \n0.9 | \nrecherche d'actualités | \n
| 5 | \n0.0 | \ntemporelle | \n
| 6 | \n0.0 | \ntemporelle | \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 temporelles et lancer un avertissement. Au lieu d'essayer constamment d'améliorer l'algorithme, nous pouvons informer l'utilisateur et l'éduquer en modifiant la façon dont nous concevons le produit.
\n\n\n\n\nDétection des segments
\nLa détection de ces segments peut être réalisée de différentes manières. Nous pourrions construire un classifieur ou utiliser 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 dans des 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 de peu tout en ignorant un segment plus important de votre base d'utilisateurs.
\n\nEn repensant notre application et en reconnaissant ses limites, 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 d'intégrer ces données de segment dans une sorte d'observabilité interne, nous pouvons surveiller en toute sécurité la proportion de questions refusées 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 simplement... 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 significatifs et identifier une bonne niche à cibler. Si votre application est bonne pour une ou deux tâches, il est impossible que vous ne trouviez pas une centaine ou deux cents utilisateurs pour tester votre application et obtenir des retours rapidement. Alors que si votre application n'est bonne à rien, il sera 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 perdrez la confiance de vos utilisateurs et vous retrouverez dans une position où vous essayez de réduire le taux d'attrition.
\n\nLorsque nous sommes en phase initiale, la capacité à utiliser GPT-4 pour faire des prédictions et le temps de retour sont très importants. 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 d'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'informer vos utilisateurs sur les segments que vous ne servez pas bien. En comprenant les limites de votre système et en vous spécialisant, vous pouvez construire un produit mémorable qui offre quelque chose ayant 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 exploits de force.
", "source_hash": "sha256:145f757651a7540ac4d35b4afde9a79f337936029ace5840b1ff7b5d56b0fce6", "model": "deepseek/deepseek-v4-flash", "generated_at": "2026-08-07T08:07:23.805209+00:00" }