Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
#Tech4Exec
OUI.sncf propose des voyages moins chers grâce
au Big Data et au Machine Learning
Agenda
•Contexte Data OUI.sncf
•Exemple « Trajets alternatifs »
•Conclusion & Questions
Contexte Data OUI.sncf
Chiffres
•1,5 Mds de recherches d’itinéraires /
an
•33 M de possibilités de voyages
•100 To de données / mois
Usages
•Assu...
Focus sur la Proposition de trajets alternatifs
2013 – 2015 : POC par une « Component Team »
•6 mois pour explorer la donn...
Trajets alternatifs
Et autres contributions de la Data et du Machine Learning au développement de l’Offre OUI.sncf
Problème : un cache de données inadapté
Contraintes
•Distributeur contractuellement limité dans sa capacité de
requêter le...
Proof of Concept - Démarche
Démarche Agile Exploratoire
•Kanban sur la totalité du projet
Atelier initiaux pour déterminer...
Proof of Concept - Dispositif
Une mini équipe :
● 1 Architecte et Dev Sénior (compétences
écosystème Hadoop)
● 1 Data Scie...
Step 1 : Analyse exploratoire & Data Cleaning
•Analyse exploratoire des LOGs
•Statistiques de fréquence de renouvellement ...
Step 2 : Système naïf / Modélisation
•Une architecture sans intelligence « Machine Learning »
•On reçoit un historique de ...
Step 3 : Machine Learning
•La machine ne suffit pas
→ des « sachants » métiers pour révéler le sens des données
•Le Data S...
Step 3 : Machine Learning
•Les services historiques du cache portés sur le nouveau système
•Volume : 200 à 2000 trajets pr...
Step 3 : Machine Learning
•L’équipe est devenue une « Feature Team »
•Compétences Front
•API Management
•Service évolué d’...
Depuis 2016
•Le système est très évolutif et les métiers ont pleins d’idées J
•Passer en mode « push » (Kafka)
•Répliquer ...
Le système aujourd’hui
Data
•7 M de Logs traités / jour ; chaque Log est traité et indexé en 1,5s
•22 M de propositions Tr...
Conclusions et enseignements
Le chemin est long … mais nécessaire
•La valeur se développe au fur et à mesure, différemment...
Des questions
Prochain SlideShare
Chargement dans…5
×

TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au Machine Learning

83 vues

Publié le

Dans un format intimiste, Tech4Exec démystifie, le temps d’une matinée, les sujets et technologies stratégiques du moment, pour en comprendre les implications, les déclinaisons opérationnelles concrètes et leur intérêt pour l’entreprise.

Le format est simple et efficace : 15 mn de vulgarisation, 25 mn de mise en oeuvre et 1h de retours d’expérience client.

La vidéo est disponible ici : https://youtu.be/U79Dp7xiF4E

https://tech4exec.fr/

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au Machine Learning

  1. 1. #Tech4Exec OUI.sncf propose des voyages moins chers grâce au Big Data et au Machine Learning
  2. 2. Agenda •Contexte Data OUI.sncf •Exemple « Trajets alternatifs » •Conclusion & Questions
  3. 3. Contexte Data OUI.sncf
  4. 4. Chiffres •1,5 Mds de recherches d’itinéraires / an •33 M de possibilités de voyages •100 To de données / mois Usages •Assurer la QoS de nos SI •Centralisation des LOGs •Hypervision •Personnaliser les Offres •Prédiction des prix et Propositions de trajets alternatifs
  5. 5. Focus sur la Proposition de trajets alternatifs 2013 – 2015 : POC par une « Component Team » •6 mois pour explorer la donnée •18 mois pour construire et prouver la fiabilité du nouveau système 2016 – aujourd’hui : Indus. et Valorisation par une « Feature Team » •Construction de fonctionnalités •Exposition de service
  6. 6. Trajets alternatifs Et autres contributions de la Data et du Machine Learning au développement de l’Offre OUI.sncf
  7. 7. Problème : un cache de données inadapté Contraintes •Distributeur contractuellement limité dans sa capacité de requêter le Catalogue du transporteur •Refonte Offre SNCF avec effet volume sur l’Entrepôt d’Offres •Cache limité à 200 trajets •Asset peu résiliant Innovation •Créer un cache avec un volume de prix suffisant pour proposer le meilleur prix à la journée Décision •Utiliser le trafic naturel du passé pour remplacer l’EO Une expérimentation sur 6 mois pour dire si le produit est viable et mérite une équipe à plein temps
  8. 8. Proof of Concept - Démarche Démarche Agile Exploratoire •Kanban sur la totalité du projet Atelier initiaux pour déterminer les objectifs => Fonction du coût Puis cadencée par des paliers et des “ stop ou encore “ mensuels
  9. 9. Proof of Concept - Dispositif Une mini équipe : ● 1 Architecte et Dev Sénior (compétences écosystème Hadoop) ● 1 Data Scientist (issu de la finance et du marketing) ● 1 Dev plus junior (réparti sur 2 personnes) ● 1 Scrum Master ● Des contacts métiers pour aider le Data Scientist à décoder les modèles de données Objectif : articuler ces compétences autour d’objectifs communs
  10. 10. Step 1 : Analyse exploratoire & Data Cleaning •Analyse exploratoire des LOGs •Statistiques de fréquence de renouvellement des informations (trajets/tarifs) •Data Cleaning •Facteurs d'influence sur la vitesse de disparition d'un trajet/tarif (saisonnalité, classes de tarifs, comportements clients) •Analyse de l'évolution du stock •Tech : Flume, Hadoop & Jobs Map/Reduce •Technos déjà en place chez OUI.sncf en 2013 •Résilientes – Tolérance à la panne 1
  11. 11. Step 2 : Système naïf / Modélisation •Une architecture sans intelligence « Machine Learning » •On reçoit un historique de donnée et on publie la plus « fraiche » •Aucune règle •Construction de la Mesure du taux d’erreurs •Quels sont les taux d'erreurs ? •Déduire les axes d'amélioration •Modélisation et développement de la fonction de coût •Ce qu’on va chercher à optimiser •Comment faire progresser la fiabilité de la donnée sans retomber dans un cache basique ou tout est requêté à période fixe •Tech : ELS, Greenplum, Spark, Mahout, Akka 2
  12. 12. Step 3 : Machine Learning •La machine ne suffit pas → des « sachants » métiers pour révéler le sens des données •Le Data Scientist cherche des logiques pour générer l’information qu’on n’a pas •Ex. : on a reconstruit toute la matrice de corrélation des gammes de services •Le ML a montré les modèles qui permettaient de générer de l’information d’aussi bonne qualité que si on l’avait reçue •Ex. : déduire les prix « avec cartes de fidélité » (peu de volumes) à partir du flux « sans cartes » … simulation du volume •On a cherché à prédire le prix suivant •Rétro-engineering sur le Yield •Remarque : parfois les modèles pensés par le Data Scientist n’étaient pas automatisables → introductions des compétences de Data Engineers •Pragmatisme & Culture du quick win •Réduction du nombre de requêtes au catalogue 3
  13. 13. Step 3 : Machine Learning •Les services historiques du cache portés sur le nouveau système •Volume : 200 à 2000 trajets proposés • Le système devient ouvert et force de potentiel grâce au Big Data •« Meilleur tarif pour un trajet » devient le « Flux Trains » càd « le meilleur tarif pour 10 trajets différent », avec le même niveau d’expérience client •À ce stade on propose de nouvelles Feature en Production directement à partir du gisement de données •« Meilleur prix du jour » + « n clients ont vu la même chose que vous » •« Jauge de prix » pour aider les clients à fixer leurs seuils d’alerte sur les tarifs 4
  14. 14. Step 3 : Machine Learning •L’équipe est devenue une « Feature Team » •Compétences Front •API Management •Service évolué d’alerte sur le Petits prix •Propositions de trajets alternatifs, moins chers et plus longs •Services Front : •Meilleur prix du jour, du mois •Meilleur prix des trains de la journée •toute variété tarifaire confondue •Au lieu de 6 propositions dans un devis standard •Flux comparateurs et Ciblages proposés à des partenaires 5
  15. 15. Depuis 2016 •Le système est très évolutif et les métiers ont pleins d’idées J •Passer en mode « push » (Kafka) •Répliquer rapidement sur un autre transporteur (les BUS) •On refait en quelques sprints le parcours de initial de plusieurs mois •Donnée plus volatile → mise en qualité ; confirme l’importance du Data Engineer •Réinjecter du Machine Learning •Privilégier la Data Analyse pour anticiper les changements plutôt que de repartir d’une copie blanche en Data Science •Data ré-engineering sous contrainte pour rafraichir nos données avant le client (INRIA – Tech : Algo. Random Forest) •Prioriser nos prochains Dévs par la mesure •mieux isoler les pbs, analyser dans le détail (Tech : Kibana, Grafana)
  16. 16. Le système aujourd’hui Data •7 M de Logs traités / jour ; chaque Log est traité et indexé en 1,5s •22 M de propositions Train •2 M de propositions Bus •78 M de préférences utilisateurs •500 K statistiques de prix •250 K trajets trains •Cluster Elasticsearch de Production : 200 M de documents •Hadoop/HDFS : 64 TO de données ; une dizaine de traitements Spark •Kafka : 300 messages/s
  17. 17. Conclusions et enseignements Le chemin est long … mais nécessaire •La valeur se développe au fur et à mesure, différemment de ce qu’on imagine au départ •donc il ne faut rien promettre au départ J mais prouver progressivement (mesures) •au final : des règles assez simples •Equipe évolutive : Component & Tech → Feature & Multi-compétences •La vraie Data Science est nécessaire mais ponctuellement •Il faut orienter les Data Scientist vers la Data Analyse •C’est là qu’on a le plus de valeur, par incréments •C’est aussi leur meilleur apprentissage Aujourd’hui chez OUI.sncf •30 collaborateurs font du Big Data toutes disciplines et territoires confondus
  18. 18. Des questions

×