Intelligence décisionnelle ? Oui s'il te plaît.

Je suis un lecteur régulier de Medium depuis un certain temps maintenant, et pour moi, l'une des principales raisons de m'avoir rejoint était le partage généreux d'expériences durement gagnées par les gens.

Je me souviens par exemple d'avoir lu « Ce que j'aurais aimé savoir avant de choisir X » où « X » était un choix technologique que nous venions de faire dans mon entreprise. L'article contenait une image de quelque chose brûlant à hautes flammes.

De bons insights, toujours à prendre avec des grains de sel, et toujours en se disant 'OK, ils n'ont pas eu de chance/trop tôt/pas si intelligents'. Nous sommes différents'. Tu souhaites…

Il est maintenant grand temps pour moi de commencer à redonner, peut-être donner à certains lecteurs un aperçu ou au moins le sentiment qu'ils ne sont pas seuls, ou peut-être même le sentiment chaleureux d'être bien meilleur que ce gars et ses coéquipiers.

Passons maintenant au titre de l'appât à clics, tout ce qui contient "Decision Intelligence" devrait, à juste titre, susciter l'intérêt de quiconque essaie de gagner sa vie dans le domaine de l'analyse.

Avertissement, tard je sais, ce texte n'est qu'une autre confirmation de l'importance de ce que surtout Cassie Kozyrkov ( Cassie Kozyrkov ) articule si bien. Si c'est ce que vous voulez vraiment en savoir plus, arrêtez de lire ceci et allez ici .

Nous y voilà.

La fête est prête.

Nous avons beaucoup de données et des gens qui sont vraiment doués pour faire "chanter" les données, nous avons les propriétaires des données, qui ne veulent rien de plus que de les faire tourner - pour voir ce que nous pouvons tous en tirer. Nous avons des assistants en mathématiques et des hackers, nous avons des hommes d'affaires et un ou deux "nous en savons plus sur ce domaine que n'importe qui". Nous avons couvert le diagramme de Drew Conway Venn , plusieurs fois.

Mais par où commencer ? Notre « façon de travailler » originale consistait, à l'époque de l'ancien (sic !) lac de données, à obtenir d'abord les données, puis à partir à la recherche d'affaires. Cela n'a pas été facile pour diverses raisons, et c'est un sujet qui lui est propre (indice : essayez de convaincre les propriétaires d'entreprise de sauter dans le train cool du ML, les propriétaires d'entreprise qui ne sont toujours pas très satisfaits des voyages antérieurs en BI).

Au fil du temps, après de nombreux appels à froid et malentendus, nous nous sommes améliorés dans la narration et dans la défense d'un MVP ou au moins d'un POC ('POC cimetières' est/devrait déjà être couvert ici à Medium, sinon s'il vous plaît ajoutez-le - le principale raison des MLOps d'aujourd'hui).

Parlez à la bonne personne.

Évident, non ? Pas si facile. Dans les grandes entreprises, il y a beaucoup de personnes entre une équipe d'analyse et son client visé. Toutes ces personnes sont nécessaires, j'en suis sûr, mais en tant que personne qui veut faire la différence en utilisant l'analyse, nous devons parler à la personne qui prend la décision réelle et à la ou aux personnes qui connaissent tous les détails pertinents sur la zone cible. /système/processus/…

Dans un projet, nous, moi et mon collègue data science, avons passé quelques mois (près de 6 mois à la fin) à développer des modèles pour prédire les pannes dans un service de télécommunication spécifique. À un moment donné (à la fin), nous donnions une démonstration lors d'un sommet d'analyse interne, démontrant ce sur quoi nous travaillions et quelques techniques d'apprentissage en profondeur intéressantes fraîchement sorties d'arXiv, que nous aimerions essayer sur certains projets (si quelqu'un comprendrais, s'il vous plaît, à quel point ce serait cool).

Un ingénieur principal est passé. Il avait vu quelques parcelles de notre projet de maintenance prédictive en cours. Il était intéressé car il travaillait sur le terrain avec ce service de télécommunication exact depuis des années. Beaucoup. Années. Il avait poliment quelques questions. Il était clair qu'il ne voulait pas nous embarrasser, mais les questions étaient très basiques et nous donnaient clairement l'air tout sauf cool.

« Quelles données météorologiques avez-vous utilisées ? Vous savez que la neige a un impact clair sur ces choses. Sans parler des étés chauds, mon garçon ! Encore une fois, il était juste curieux, comme tout bon ingénieur. Terminant avec le commentaire qui a finalement mis un gros point d'interrogation sur notre projet : "Vous savez, nous exécutons toujours ces choses avec des composants de sauvegarde, juste au cas où quelque chose se briserait".

Que s'était-il donc passé ici ? Nous avons démarré le projet avec une bonne motivation : l'intérêt de prédire les pannes de ces systèmes était évident, tout le monde le savait. De plus, il était prévu d'acheter peut-être une solution à l'extérieur, au lieu de la construire en interne.

Valeur — vérifier.

S'assurer que nous battons la solution externe prouvant notre valeur pour l'entreprise — oui, nous le ferons !

Parler à la bonne personne ? Non, évidemment pas.

Obtenez la bonne métrique. Obtenez une approbation : cible à atteindre, engagement à agir si la cible est atteinte.

Un premier signe d'avertissement (dans le même projet que ci-dessus) était lorsque nous avons discuté des mesures de réussite, nous avons vraiment essayé d'obtenir un engagement de l'entreprise à utiliser nos prédictions pour la prise de décision réelle, et pour y arriver, nous avions besoin d'avoir une métrique convenue et une valeur attachée à cette métrique.

Le signal d'alarme a été lors de l'une des premières réunions lorsque le fournisseur externe a impressionné notre entreprise avec une « très grande précision ». Maintenant. Dans ces environnements, les échecs sont rares (ce qui rend encore plus difficile la modélisation prédictive). Très rare. Si rare que n'importe qui pourrait apporter le modèle factice par défaut et avoir une grande précision. « Je ne prédis aucun échec. Oh, j'ai une précision de 99 %, cool !'. Non, pas cool.

Donc, d'une certaine manière, nous avons gagné notre place dans le projet en posant quelques questions sur la bonne métrique à utiliser, en faisant comprendre à notre propre entreprise pourquoi c'était une astuce bon marché de la part du fournisseur.

Maintenant. Avons-nous obtenu une métrique et une cible à atteindre ? Et étaient-elles fondées sur la valeur réelle qu'elles apporteraient à l'entreprise, si elles étaient utilisées, si elles prenaient des décisions basées sur notre analyse, sur nos données ?

Oui et non. Il n'était clairement pas entièrement compris et fondé, et finalement les performances de nos modèles (ont battu celles du fournisseur) n'étaient pas assez élevées pour être utilisées. Nous avons fait économiser beaucoup d'argent à l'entreprise, sans acheter une solution externe (qui n'aurait pas été utilisée de toute façon). Mais nous aurions pu arrêter des mois plus tôt.

Plus d'exemples, mêmes erreurs

Dans le deuxième exemple, si je ne vous ai pas déjà perdu, nous nous sommes déchaînés pour essayer un tas d'architectures d'apprentissage en profondeur, tout le tralala (à l'époque), le tout pour aider à créer un bon classificateur de texte (pensez à la zone de support client ).

Encore une fois, la valeur était claire et d'autres (équipe externe de science des données) s'y étaient essayés. Nous pourrions faire beaucoup mieux en un temps beaucoup plus court. Nous avons eu ce nouveau tas de nouveaux outils dans notre sac, et nous allions l'utiliser.

Encore. Oui, nous avons fait bien mieux que la concurrence, et j'ai pris une fraction du temps qu'il leur avait fallu. Alors, a-t-il été utilisé ?

Non. Cette fois, c'était dû à des limitations plus pratiques : oui, nous pouvions classer les textes en plus de 40 groupes raisonnables, tous parfaitement logiques pour les personnes de service. Mais, en réalité, les fils de messagerie se déplaçaient sur les classes, et les personnes du service géraient de nombreuses classes en parallèle (bien sûr), et - comme si souvent - le problème que nous résolvions était loin des problèmes qu'ils devaient résoudre en premier. Nous suggérions essentiellement du papier de verre 240 avant le 40.

Et, dans ce cas également, nous n'avons pas pu parler à toutes les bonnes personnes jusqu'à la fin. Et encore une fois, nous n'étions pas d'accord à l'avance sur l'engagement d'utiliser (si c'était assez bon) ce que nous avions développé.

Fais tes devoirs

Peut-être qu'une autre leçon d'en haut serait:

Ce n'est pas parce que d'autres ont essayé plus tôt que le problème est correctement formulé.

Dans les deux exemples, nous avons eu de meilleurs résultats que les équipes précédentes et, également en compétition frontale. Pourtant, cela ne signifie pas du tout que c'était le bon jeu à jouer. Je suppose que la leçon pourrait se résumer comme suit : "Faites vos devoirs !".

Ci-dessus, des exemples datant d'il y a cinq ans. Attendez-vous à plus, à la fois des cinq dernières années, mais certainement des erreurs futures.