Les enseignements tirés de la création de produits d'IA en tant que PM

Lorsque votre produit ne convient pas

En tant que chef de produit, la mission est toujours la même : créer des produits qui apportent de la valeur à vos utilisateurs. Cependant, le chemin pour en créer un peut varier considérablement d'un produit à l'autre. Que se passe-t-il si votre produit n'est pas conforme au manifeste Agile ? Et si les sprints hebdomadaires ou bihebdomadaires ne s'appliquaient pas à l'échelle des délais de livraison de vos produits ? Et si la création d'un MVP exigeait des mois d'efforts ? Que ferais-tu ? Par où commencerais-tu ?

À Mindee, nous développons des produits basés sur le Deep Learning. Nous utilisons la vision par ordinateur pour extraire des informations clés des documents. Cela nécessite des tonnes de données et des algorithmes complexes, ce qui signifie que le développement peut prendre des mois, mais le résultat est incertain. Vous pouvez passer des semaines à travailler sur un algorithme qui échouera à sa mission. Même si, en tant que PM, vous ne serez pas en mesure de lever cette incertitude lors de l'expédition de votre produit, vous souhaitez la réduire autant que possible.

En tant qu'équipe chargée des produits, nous voulions améliorer notre rapidité en expédiant plus fréquemment des produits/fonctionnalités plus petits et en limitant « l'effet tunnel » qui se dégageait de nos derniers projets. Nous voulions également réduire les risques : et si nous consacrions des mois à un projet qui n'est jamais expédié ?

En moyenne, nous avons constaté qu'il nous fallait entre 4 et 6 mois pour créer une nouvelle fonctionnalité ou un nouveau produit complexe. Nous voulions trouver des moyens de passer en dessous de ce seuil de 4 mois. C'était notre objectif à atteindre.

Dans cet article, nous expliquerons le parcours que nous avons parcouru au cours des dernières API OCR pour factures itération, qui consiste à extraire des rubriques des factures, un problème complexe à résoudre du point de vue de l'apprentissage en profondeur. Tout d'abord, nous donnerons plus de contexte sur cette fonctionnalité, puis nous examinerons en profondeur ce que nous avons mis en œuvre pour réduire nos délais de livraison et comment nous avons réussi à expédier une première version en 3 mois.

Un peu de contexte

Pourquoi créer des produits basés sur la science des données prend du temps

De la compréhension des besoins de l'entreprise au déploiement de nouveaux modèles en production, cela peut prendre des mois. Mais pourquoi cela prend-il autant de temps ?

• Analyse de cas d'utilisation : Vous devez bien comprendre les cas d'utilisation métier pour pouvoir prendre des décisions ultérieurement (en matière de performances par exemple).
• Le exploration des données est la phase au cours de laquelle vous approfondissez les données pour comprendre la distribution, les modèles et les cas limites.
• Ensuite, vous devez démarrer un Annotation projet pour obtenir des données étiquetées pour entraîner votre modèle. Cela nécessite d'avoir collecté des données au préalable.
• Une fois les données annotées, elles sont ensuite divisées en 3 ensembles différents : l'ensemble d'apprentissage (données utilisées pour l'entraînement), le jeu de validation (données utilisées pour tester et affiner vos modèles) et le jeu de test (données utilisées une seule et unique fois pour l'évaluation finale du modèle). Le Modélisation la phase peut commencer à l'aide du kit d'entraînement. Cela comprend le choix, la formation et le réglage des modèles.
• Une fois qu'un modèle est prêt, nous devons le tester pour évaluer ses performances et analyser les erreurs qu'il commet. C'est le Évaluation étape.
• Lorsque le modèle est prêt, il peut être publié. C'est le Déploiement phase.

Les modèles de formation peuvent prendre des jours et il s'agit d'un processus itératif car vous devrez peut-être améliorer votre modèle en fonction de son évaluation. Pour chaque nouvelle version du modèle, nous analyserons ses performances et continuerons à l'itérer et à le peaufiner jusqu'à ce que ses performances soient à la hauteur des attentes de l'entreprise.

Toutes ces étapes combinées peuvent prendre des mois au total, car la plupart des étapes ne peuvent pas être facilement effectuées en parallèle. Par exemple, vous devez attendre d'avoir suffisamment de données annotées pour commencer à entraîner vos modèles. Lorsque vous démarrez un projet, il est impossible de donner une estimation juste du temps que cela va prendre :

• car vous avez besoin d'annotations extrêmement précises, ce qui nécessitera quelques révisions et itérations pour vous assurer qu'elles atteignent la qualité requise pour le projet.
• car vous ne savez pas combien d'itérations seront nécessaires sur votre modèle pour qu'il atteigne les performances attendues.
• car, comme nous l'avons mentionné plus haut, avec le deep learning, parfois, l'approche que vous choisissez échoue et vous repartirez de zéro avec une nouvelle approche.

Notre projet pilote : extraction des rubriques dans les factures

À Mindee, nous développons des produits pour les chefs de produit et les développeurs qui souhaitent extraire automatiquement des informations de documents. Nous développons en interne des algorithmes de Deep Learning adaptés à chaque type de document que nous voulons traiter. Notre technologie d'IA est ensuite exposée via des API pour la rendre accessible à tout développeur ou PM qui souhaite l'implémenter dans ses logiciels. Nous prenons en charge les factures, les reçus, les passeports et les documents personnalisés. Dans cet article, nous allons nous concentrer sur notre API d'OCR des factures qui extrait les informations clés des factures.

La version existante de l'API Invoice OCR prend en charge des champs génériques tels que montant total, numéro de facture, date d'échéance, nom du fournisseur etc... La liste exhaustive est disponible dans notre documentation.

Dans l'exemple ci-dessus, nous pouvons voir que le tableau et ses lignes ne sont pas encore extraits. L'extraction des éléments de ligne fait référence à l'extraction des lignes, comme indiqué en orange dans l'illustration ci-dessous.

Nous avions identifié que ce serait un problème difficile à résoudre pour extraire des lignes à l'aide de l'apprentissage profond. La principale mise en garde que nous voulions éviter était de consacrer trop de temps à la livraison et de consacrer notre énergie à de multiples sous-problèmes. Travailler sur cette nouvelle fonctionnalité a été l'occasion de remettre en question notre prestation et de nous améliorer en travaillant en équipe.

Comment nous avons trouvé des idées pour améliorer la livraison

Tout commence par la découverte 🙂 La première chose à comprendre était les points de friction au sein de notre organisation et les domaines dans lesquels, en tant que chefs de produit, nous pouvions aider l'équipe de science des données dans le processus de livraison.

J'ai travaillé main dans la main avec Rémy, notre responsable des données, pour identifier :

• comment nous pourrions décomposer le problème d'extraction des rubriques en problèmes plus petits à résoudre
• comment nous pourrions fixer des objectifs intermédiaires qui empêcheraient « l'effet tunnel »

De plus, au cours de cette phase, nous avons également identifié que les data scientists étaient confrontés à de nombreuses questions lors de la phase d'évaluation des modèles :

• quelles sont les attentes des clients à l'égard de ce produit ?
• quelles sont les attentes en matière de métriques, quand savons-nous que le modèle est prêt pour la production ?
• Allons-nous soutenir cette affaire ou non ? Devons-nous continuer à nous améliorer ou non ?

Les aider à obtenir des informations avant ces questions éviterait les allers-retours et nous ferait gagner beaucoup de temps. Cela a conduit à la proposition suivante :

• Avoir une vue d'ensemble de la façon dont les clients l'utiliseraient et de l'impact des performances sur leur cas d'utilisation
• Création de métriques sur mesure qui aideront à évaluer les performances pour ce problème spécifique que nous essayons de résoudre
• Être capable d'anticiper les problèmes d'algorithme (là où le modèle peut présenter des difficultés)
• Avoir une compréhension claire dès le départ des attentes en matière de performances
• Connaître les priorités et les problèmes sur lesquels ils devraient se concentrer par rapport aux cas extrêmes dont ils ne devraient pas se soucier

Cela a conduit à la construction de ce Plan d'action en 4 étapes:

1. 🔍 Analyse des cas d'utilisation : Explorez en profondeur les cas d'utilisation des clients et du secteur pour en extraire les principales fonctionnalités et comprendre les attentes en matière de performances.
2. 🔬 Exploration des données: Développez une compréhension approfondie de ce que sont les rubriques des documents. Identifiez les cas courants à partir des cas extrêmes.
3. ⚡️ Définition du MVP: À partir de l'exploration des données, établissez une liste de priorités, définissez un MVP potentiel et définissez les mesures viables minimales requises pour lancer une première version.
4. 🏗 Livraison : Définissez un rythme de livraison dans lequel les équipes de science des données et de produit se réunissent pour examiner à la fois l'évaluation quantitative des performances des modèles (mesures de science des données appelées rappel et précision) et les performances qualitatives issues de l'analyse des erreurs des modèles.

N'oubliez pas de consulter notre explication sur correspondance partielle de chaînes!

Comment nous avons mis en œuvre le plan d'action

La première partie de notre processus a consisté à définir des exigences complètes : de la compréhension des cas d'utilisation à l'exploration des données afin de définir les bonnes attentes. Cela diffère d'un document d'exigence de produit (PRD) traditionnel car la partie exploration des données est spécifique aux produits basés sur le Deep Learning.

1. 🔍 Analyse des cas d'utilisation

Les factures sont traitées dans de nombreux cas d'utilisation tels que les comptes fournisseurs, la comptabilité, les achats et bien d'autres. À titre d'exemple, je vais approfondir le cas d'utilisation des achats pour expliquer ce que nous avons appris et comment cela nous a aidés à définir nos exigences. Pour les achats, l'objectif est de faire correspondre ce qui a été commandé à ce qui est livré puis facturé. Ce processus s'appelle la mise en correspondance à trois voies, comme indiqué dans l'illustration ci-dessous.

Disons que vous devez acheter 5 ordinateurs. Une fois que vous acceptez un devis d'un revendeur, un bon de commande est émis contenant toutes les informations sur les articles commandés. Malheureusement, votre revendeur ne dispose pas d'un inventaire suffisant et seuls 3 ordinateurs sont livrés. Le bon de livraison contient ces informations. La dernière étape du processus est la facturation : vous voulez vous assurer que la facture contient la bonne quantité de marchandises livrées au bon prix.

Cela permet de comprendre clairement pourquoi les extractions d'articles sont essentielles pour les achats : vous avez besoin des détails des lignes pour chaque article pour effectuer la correspondance. De plus, ce cas d'utilisation donne également une idée des informations que nous devons extraire pour chaque ligne :

• un code ou une description qui identifie l'article
• quantité
• prix unitaire
• montant total

Nous l'avons fait sur les autres principaux cas d'utilisation, en tenant compte de tous les commentaires des clients que nous avions recueillis dans Carton de produits, car il était vraiment exhaustif. Cela nous a aidés à établir la liste des 10 champs que nous voulions extraire : description, code produit, quantité, prix unitaire, montant total, unité de mesure, taux d'imposition, montant de la taxe, taux d'escompte, montant de la réduction .

🎉 Résultat:

• Au cours de cette phase, nous avons documenté de manière exhaustive les commentaires des clients et analysé des cas d'utilisation afin de définir les domaines que nous voulions soutenir. Cela a permis à l'équipe de bien comprendre les attentes de l'entreprise.
• Cela nous a aidés à créer notre modèle PRD pour la prochaine itération de science des données sur nos produits.

2. 🔬 Exploration des données

Comme il s'agit essentiellement de quelque chose de très spécifique aux produits basés sur le Deep Learning, nous allons consacrer un peu plus de temps à cette partie.

L'exploration des données est le processus qui consiste à examiner une quantité de données suffisante pour que :

• il est représentatif autant que possible de ce que le modèle va rencontrer en production
• vous découvrirez quels sont les principaux cas d'utilisation et quels sont les cas extrêmes potentiels

Pourquoi est-ce un élément essentiel de la définition de nos exigences ?

• Parce qu'il permet de mettre en correspondance des documents réels avec les attentes des utilisateurs finaux.
• Il permet de se concentrer sur le bon problème à résoudre en fonction des statistiques d'occurrence.
• Parce que cela permet d'identifier les cas principaux et les cas limites. Vous pouvez rapidement voir où l'algorithme peut avoir du mal à trouver des informations pertinentes ou où il échouera.

Comme c'était la première fois que je faisais cette exploration de données exhaustive et méticuleuse, j'ai travaillé main dans la main avec l'équipe de science des données pour comprendre ce que nous devions examiner dans l'ensemble de données d'exploration. Ensemble, nous avons créé une petite liste de choses à rechercher, sur laquelle nous avons répété.

✅ Liste de contrôle:

1. Identification des modèles

• [] principaux cas d'utilisation — montrer des exemples
• [] cas extrêmes — occurrences et exemples

2. Informations générales sur la configuration des documents

• [] Distribution des déformations de l'image
• [] Nombre de lignes

3. Sortie d'écriture

• [] pour chaque exemple, écrivez la sortie attendue par l'utilisateur

Avant d'examiner certaines données, nous avons défini la taille de l'échantillon de données afin de minimiser la marge d'erreur. Dans la science des données, tout est une question de statistiques, il est essentiel d'être minutieux. Nous créons un ensemble de données d'exploration de plus de 400 documents garantissant une marge d'erreur d'environ 5 %. Et puis il est temps d'ouvrir les yeux 👀, car vous devez examiner cet ensemble de données plusieurs fois. C'est la partie la plus fastidieuse du processus, mais c'est la plus importante comme nous le verrons.

1. Identification des modèles

La première fois que vous examinez ces documents d'exploration, l'idée est de comprendre quels sont les modèles que vous pouvez identifier. Il existe des cas courants, que vous rencontrez plusieurs fois et qui semblent simples à extraire, comme celui ci-dessous : un tableau sur une seule ligne avec un en-tête clair et une mise en page standard.

Et puis il y a tous les cas extrêmes que vous pouvez voir. J'en ai décrit quelques-unes ci-dessous.

L'approche consiste à identifier pour chaque cas limite son occurrence, ainsi que la fréquence à laquelle il se répète dans l'ensemble de données. Pour ces exemples, vous savez que vous devrez faire attention aux performances du modèle sur ces configurations.

2. Informations générales sur la configuration des documents

Tout cela a été documenté dans une base de données conceptuelle contenant une liste des différents cas identifiés dans l'ensemble de données. Voici un extrait ci-dessous, avec l'exemple du nombre de lignes. C'était une information que nous voulions comprendre : combien de lignes y a-t-il en moyenne dans les tableaux des factures.

Par exemple, une distribution claire donne une idée de ce qui doit être pris en charge : si nous prenons en charge des tableaux de 10 lignes, nous couvrons 98,2 % des cas d'utilisation. Pour une première itération, inutile de dépenser de l'énergie pour être sûr de pouvoir extraire des tableaux de 50 lignes. Il est également essentiel de comprendre cela dès le début du processus, car il s'agit d'un paramètre qui peut avoir un impact sur le temps de calcul.

Jetons un coup d'œil à un autre exemple avec déformation de l'image. Parfois, les documents sont numérisés, ce qui entraîne des documents inclinés, flous ou pliés qui peuvent être difficiles à lire. Par expérience, nous savions que pour ce type de document, il serait difficile d'extraire des tableaux.

Quel type de déformation devons-nous supporter ?

L'exploration des données nous donne une idée du type de déformation et de leur distribution dans notre échantillon de données. Cela donne également une orientation pour un MVP. Grâce à son analyse, nous avons décidé qu'aucun effort ne devait être fait pour résoudre les problèmes liés aux documents fortement inclinés lors de la première itération.

3. Sortie d'écriture

Un dernier enseignement à ce sujet est que pour faire un effort supplémentaire pour tous les exemples que nous avons inclus, c'est-à-dire pour chaque tableau, j'ai écrit quel serait le résultat attendu du point de vue de l'utilisateur final. C'est très efficace pour identifier les nouveaux cas extrêmes ou pour faire émerger de nouveaux problèmes. Se mettre à la place du client est toujours une bonne idée 😉. Il donne également une idée de ce qui est acceptable du point de vue de l'utilisateur de ce qui ne l'est pas, et il permet de partager ces informations avec l'équipe de science des données à des fins de prise de décision.

Dans nos exigences, cela ressemble à ceci :

🎉 Résultat:

Soyons clairs, l'exploration des données prend du temps et demande beaucoup de rigueur, mais cela a joué un rôle clé dans la réussite du projet et l'amélioration de la livraison.

• Cela nous a permis de gagner beaucoup de temps pour définir clairement quel problème nous concentrer et lequel ignorer. D'une part, nous avions une vision claire des principaux cas. D'autre part, pour chaque cas limite que nous avons identifié, nous avions une statistique sur son occurrence. Cela nous a aidés à prendre des décisions fondées sur des données sur la base de ces statistiques. Nous avons évité certaines déformations de l'image, nous nous sommes concentrés sur la résolution de l'extraction de tableaux à 10 lignes grâce à ces statistiques. Nous gagnons certainement beaucoup de temps, d'efforts et de concentration.
• Nous avons créé de nouveaux outils, tels qu'une liste de contrôle des configurations à examiner pour identifier les documents que nous pourrons réutiliser ultérieurement.
• Nous avons organisé une session de plongée approfondie avec l'équipe afin de partager les enseignements tirés de cette exploration. Cela les a aidés à intégrer la synthèse des exigences, qui était dense, et leur a donné un aperçu de la direction que nous prenions.

Vous pouvez également consulter notre article sur scores de confiance en apprentissage automatique!

3. ⚡️ Création d'un MVP

En science des données, nous sommes obsédés par la manière d'évaluer les performances de nos modèles. C'est en quelque sorte notre étoile polaire, mais nous faisons également très attention, car si vous ne regardez que ces indicateurs, vous risquez de manquer des limites importantes de votre modèle. Travailler sur des problèmes de deep learning est une infinité de temps : on peut toujours s'améliorer (sous conditions bien sûr), il ne s'agit pas d'un problème binaire : travailler/ne fonctionne pas. Il est alors très important de définir les critères d'acceptation de votre modèle afin de savoir quand vous arrêter.

Un peu de contexte : comment évaluer les performances des modèles ? Connais-tu se rappeler et précision? Si ce n'est pas le cas, je vous suggère de lire ceci excellent post par Jonathan, notre PDG. Vous ne pouvez pas examiner l'une sans regarder l'autre, mais pour chaque fonctionnalité, nous avons tendance à nous concentrer sur celle qui sera importante pour notre cas d'utilisation. Et cette métrique est étroitement liée à l'expérience utilisateur.

1. Choisissez une métrique de science des données sur laquelle vous concentrer pour l'itération du modèle

Prenons un exemple : supposons que je sois l'utilisateur final d'un logiciel d'approvisionnement. J'ai téléchargé le bon de commande, le bon de livraison et je télécharge maintenant la facture correspondante qui contient le tableau ci-dessous. Une OCR basée sur le Deep Learning s'exécute dans ce logiciel d'approvisionnement pour extraire les informations clés de cette facture, afin que je n'aie pas à remplir toutes les informations manuellement. Mais vous savez, parfois les algorithmes font des erreurs.

En tant qu'utilisateur, quel type d'erreur est-ce que je préfère ? quels en sont les impacts pour moi ?

Recall vs Precision, qu'est-ce que cela signifie pour les rubriques ?

• Rappel — est-ce que je préfère corriger des informations erronées parce que le modèle a commis une erreur ? Cela signifie que le modèle préfère prédire un élément de ligne même s'il commet une erreur, car je peux apporter des modifications. Si vous regardez le tableau ci-dessus, cela signifie que le modèle peut extraire la ligne « Période de facturation : 01/01/21 — 31/01/21 » même s'il ne s'agit pas d'une rubrique selon notre définition (une rubrique est définie comme une description de l'article combinée à une tarification ; aucune tarification n'est associée à cette description). Dans ce cas, Rappel serait la métrique à examiner.
• Précision — je préfère plutôt saisir les informations manuellement, car je ne veux pas apporter ces modifications. Cela signifie que le modèle plutôt pas prédire quand il n'est pas « assez sûr » du résultat. Ainsi, par exemple, le fait de se concentrer sur Precision pourrait signifier que la seule rubrique « Abonnement mensuel [...] » risque d'être omise sous certaines conditions.

En résumé, nous utilisons des métriques pour définir le type d'erreurs que nous préférons accepter par rapport à celles que nous voulons éviter.

Pour les extractions d'articles de gamme, nous nous sommes concentrés sur la maximisation de notre se rappeler, car il semble plus facile de modifier les erreurs que de saisir manuellement toutes les informations d'une ligne.

2. Définissez votre MVP

Comme notre produit ne correspondait pas vraiment à la façon dont nous imaginons un MVP traditionnel, nous avons décidé de définir à quoi ressemblait le MVP pour nous. Notre définition du MVP est une combinaison de 2 critères d'acceptation :

• d'une part, il est quantitatif et repose sur des indicateurs de la science des données. Nous avons défini nos indicateurs minimaux viables : quels sont les minimums se rappeler / précision nous devons atteindre pour lancer ? Qu'est-ce qui est acceptable du point de vue de l'utilisateur ?
• en revanche, c'est qualitatif : les principaux cas sont-ils pris en charge ? Quels sont les cas extrêmes déjà pris en charge ? quels sont les types d'erreurs commises par le modèle ? sont-ils acceptables ?

En définissant en quoi consiste le modèle doit support au lancement, à la fois en termes de configuration des documents et en termes de mesures de performance, nous avons réussi à décomposer le projet en itérations plus petites.

Pour ce faire, nous avons identifié :

• d'une part, les priorités pour résoudre les différentes configurations identifiées dans le jeu de données

• d'autre part, nous avons également divisé nos 10 champs pour les extraire en 3 priorités différentes en fonction de notre compréhension des cas d'utilisation. L'idée était de ne pouvoir expédier qu'avec des champs P1 si P2 et P3 étaient peu performants.

3. Analysez manuellement les erreurs de modélisation et itérez

Mais travailler avec des métriques ne suffit pas. Vous voulez comprendre où le modèle ne parvient pas à extraire les informations : existe-t-il une configuration spécifique qui fonctionne mal ? La seule solution est d'examiner les documents pour lesquels le modèle fonctionne mal, dans votre ensemble de validation. ⚠️ L'idée n'est pas de les corriger au cas par cas car cela créerait un biais, mais cela donne des tendances de configuration qui peuvent être difficiles pour nos modèles. Revenir à votre exploration des données peut vous donner une idée de la fréquence à laquelle cette configuration se produit et si vous devez consacrer du temps et des efforts à la résoudre.

🎉 Résultat:

D'après ce que nous avons appris au cours de l'exploration des données, la définition des problèmes en priorités nous a permis de créer notre propre type de MVP. Cela nous a donné un cadre clair à utiliser lors de la livraison.

• Définition de la métrique clé sur laquelle se concentrer pour accélérer l'évaluation
• MVP Scoping : mappage de chaque champ à extraire avec une priorité P1, P2 ou P3
• MVP Scoping : pour chaque configuration (cas extrêmes), définissez le besoin à résoudre (élevé à faible)

4. 🏗 Livraison — amélioration de la vélocité

Pour nous assurer d'expédier le plus rapidement possible, nous avons défini des points de contact réguliers. L'idée de ces points de contact était d'analyser :

• les performances du modèle (indicateurs clés)
• les erreurs du modèle

Nous n'avons cessé de nous référer à notre définition de MVP et avons remis en question ce que nous voulions initialement soutenir :

• nous avons réalisé très tôt que les champs P3 (taux d'escompte et montant de la réduction) ne seraient pas pris en charge lors de notre première itération, car leurs performances étaient médiocres. En ayant défini ces priorités, nous n'avons pas passé de temps à essayer d'améliorer leurs performances, nous sommes restés concentrés sur les domaines P1 et P2.
• nous avons découvert de nouveaux cas extrêmes pour lesquels nous ne disposions pas de statistiques. Ensuite, nous avons effectué une autre série d'exploration des données pour nous assurer que nous disposions des bonnes statistiques pour prendre des décisions éclairées.

Cela nous a donné plus de vélocité et un objectif clair à atteindre entre chaque itération.

🎉 Résultat:

À ce stade, le gain de temps est réellement basé sur les étapes précédentes. Comme nous avions une idée claire de ce qu'il fallait résoudre en premier lieu et de ce sur quoi nous concentrer, nous avons pu prendre des décisions rapidement.

Ce que nous avons appris

🎯 Nous avons atteint notre objectif : il nous a fallu environ 3 mois pour expédier la première version de la fonctionnalité d'extraction des articles de ligne sur notre API d'OCR des factures. Du point de vue du deep learning, l'extraction de tableaux à partir de Invoices était un problème complexe à résoudre, c'est une véritable réussite d'équipe ! Si vous êtes curieux de comprendre comment nous avons procédé pour le déchiffrer, vous pouvez lire cet article qui décrit notre approche.

🔥 Ce qui a bien fonctionné :

• passer du temps sur Exploration des données nous a permis de bien comprendre ce qui pouvait mal tourner, les domaines dans lesquels nous aurions du mal, les domaines dans lesquels nous devrions concentrer nos efforts et les domaines dans lesquels nous devrions plutôt lâcher prise. Cela nous a permis de prendre des décisions plus rapidement.
• en poussant un Approche MVP en définissant des priorités claires pour chaque champ et pour chaque configuration à prendre en charge, nous avons pu définir quand poursuivre les itérations sur nos modèles et quand il était possible de les arrêter. Nous n'avons finalement généré que 7 champs sur les 10 identifiés dans la première version, en insistant vraiment pour qu'une première version de la fonctionnalité soit disponible dès que possible.

📑 Ce que nous avons découvert:

• L'exploration des données est une histoire sans fin : nous y revenions sans cesse à chaque nouveau problème rencontré. C'est un moyen efficace d'obtenir des statistiques avant les problèmes. Il permet de prendre des décisions fondées sur les données. Notre objectif est d'utiliser systématiquement les résultats de l'exploration des données pour prendre des décisions de manière pragmatique.

Conclusion

Être Premier ministre travaillant sur des produits de haute technologie issus de recherches avancées en matière d'apprentissage profond est très différent d'un rôle de produit SaaS. Les produits basés sur le deep learning impliquent des cycles de développement plus longs et des processus de développement sur mesure. De plus, le modèle que vous avez mis des semaines à développer peut échouer et vous devrez peut-être recommencer. En tant que responsable de la gestion des produits, cela nécessite d'adopter une approche différente des méthodologies de gestion de produits existantes.

En résumé, voici quelques points à retenir de ce que nous avons expérimenté pour accélérer la livraison de notre dernière API OCR pour les factures :

• Il est essentiel de comprendre les données. Cela prend du temps, mais le retour sur investissement est maximal. Cela nous a permis d'économiser beaucoup de temps et d'énergie.
• Si vous souhaitez communiquer efficacement avec l'équipe de science des données, vous devez comprendre en profondeur les indicateurs et vous assurer qu'il existe des objectifs clairs à atteindre.
• Le fait d'avoir défini des critères d'acceptation clairs nous a donné une vision claire de la direction que nous devrions prendre. Nous avons combiné des critères quantitatifs (objectifs en matière de métriques de science des données) avec des critères qualitatifs (configuration des documents et cas pratiques à l'appui) pour nous aider à définir la voie la plus rapide vers le lancement.
• L'établissement de priorités claires quant aux éléments à prendre en charge nous a aidés à surmonter les incertitudes liées à l'apprentissage profond et à réduire la portée des versions en cas de besoin. Nous n'avons pas hésité à affiner notre gamme de fonctionnalités en vue de son lancement.
• Lorsque les méthodologies standard ne s'appliquent pas aux vôtres, créez les vôtres : déterminez avec votre équipe d'ingénieurs les lacunes et revenez en arrière. C'est ainsi que nous avons élaboré notre processus et nos exigences en matière d'exploration des données.

Alors que nous sommes sur le point de lancer cette première itération, nous sommes impatients d'en savoir plus sur la manière dont nous pouvons améliorer ce que nous avons mis en œuvre jusqu'à présent et sur la manière dont nous pouvons proposer de manière itérative la prochaine itération de nos modèles. Nous recherchons maintenant d'autres idées pour nous améliorer encore, nous recherchons donc des conseils. Et vous, comment travaillez-vous sur vos produits d'IA ? Avez-vous des conseils à partager avec nous dans les commentaires ?

Photo de couverture par Augustin Wong sur Unsplash

‍