Revenir au contenu principal

Architecture de référence Next Best Action pour les télécoms - Clonée

Cette architecture présente les intégrations avec les sources et destinations courantes pour les cas d'usage de Next Best Action dans les télécoms. Elle détaille les meilleures pratiques de conception pour l'architecture lakehouse.

Reference architecture with Databricks product elements overlaid on top of industry data sources and sinks.

Mettez en place une architecture télécom qui permet de déployer la "next best action" en temps réel et à grande échelle

Flux de données et de plateforme :

Next Best Action (NBA), Next Best Experience (NBX)

  1. Ingestion des données depuis les systèmes opérationnels télécoms
    Les données sur le comportement des clients, la facturation, les CDR (enregistrements d'appels/données/SMS), le CRM, les recharges et les transactions fintech sont collectées à partir de systèmes hybrides/locaux via des interfaces d'intégration BSS/OSS ou des connecteurs de données tiers comme Informatica et Lakeflow. Ces flux de données sont envoyés en temps quasi réel ou par lots (batch) vers la couche d'ingestion en continu (Streaming Ingestion Layer) (par exemple, Kafka, Azure Event Hub), où un prétraitement léger est effectué (par exemple, filtrage des PII, conversion de protocoles).
  2. Stockage Lakehouse unifié et préparation des données brutes
    Les données ingérées arrivent dans les tables Bronze de Delta Lake, partitionnées par des attributs tels que les OpCo, l'ID du site ou le canal. À ce stade, des opérations telles que l'application du schéma et le masquage des PII peuvent avoir lieu. De là, les données progressent vers les tables Silver, où elles sont dédoublonnées, jointes et enrichies pour créer des profils Client 360, des résumés d'utilisation et des indicateurs de désabonnement (churn), créant ainsi une base harmonisée et prête pour l'analyse.
  3. Ingénierie des caractéristiques (Feature Engineering) et entraînement des modèles
    Les données Silver nettoyées alimentent des pipelines de transformation avancés à l'aide de Lakehouse Pipelines. Cette étape comprend :
    • La dérivation de caractéristiques d'intention (intent features) et leur enregistrement dans un Feature Store centralisé, déconnecté de la logique spécifique aux canaux, régions ou pays.
    • L'activation de l'enrichissement temporel (point-in-time enrichment) et de l'unification de l'identité de l'audience.
    • L'entraînement de modèles NBA à l'aide de Databricks, y compris des cas d'usage comme la prédiction du churn, le score d'acceptation des offres et l'apprentissage par renforcement (Reinforcement Learning) pour l'optimisation dynamique des offres.
    • Les modèles sont entraînés et gérés au sein de la plateforme unifiée avec un suivi de la généalogie (lineage), de l'observabilité et de la gouvernance via Unity Catalog.
    • Une boucle de rétroaction essentielle dans cette architecture est l'A/B testing :
      1. Les modèles sont continuellement évalués via des tests de lift par lots intégrés au processus CICD, mesurant l'impact commercial (par exemple, l'uplift, la rétention, la conversion).
      2. Ces informations permettent de savoir si les modèles actuels surpassent les modèles de référence (baselines) afin de prendre des décisions objectives concernant le déploiement ou le réentraînement.
  4. Insights commerciaux et activation de la CX
    Les résultats scorés des pipelines ML sont stockés dans des tables Gold, prêtes pour les applications BI et CX en temps réel :
    • Databricks SQL permet de suivre les KPI en temps réel, d'analyser le comportement des abonnés et de mesurer le ROI des campagnes NBA.
    • Les équipes de direction et de marketing accèdent à ces données via des outils familiers tels que Power BI, Tableau et Looker.
    • Les applications Lakehouse permettent la segmentation de l'audience, la simulation de campagnes et le ciblage de ventes croisées/montées en gamme (cross-sell/up-sell) pour les équipes CX.
  5. Déploiement des modèles et inférence en temps réel
    Les modèles NBA entraînés sont exposés pour une activation en temps réel via :
    • Des API de Model Serving hébergées sur Databricks ou Databricks Model Serving, prenant en charge les déploiements hybrides.
    • Les API sont déployées ou relayées (proxied) dans des environnements opérationnels basés sur le cloud et/ou locaux (on-prem) pour une intégration directe avec les systèmes SMS, les centres d'appels, les applications mobiles ou les IVR.
    • Les résultats de la NBA sont surveillés en continu à l'aide de tableaux de bord, de résultats de tests A/B et du suivi des performances des modèles afin de garantir leur pertinence et de minimiser la dérive (drift).

Recommandé

Architecture de référence pour la surveillance des performances du réseau de télécommunications

Architecture sectorielle

Architecture de référence pour la surveillance des performances du réseau de télécommunications
Architecture de référence pour la gestion des investissements dans les services financiers

Architecture sectorielle

Architecture de référence pour la gestion des investissements dans les services financiers
Architecture de référence de la chaîne d'approvisionnement numérique pour la fabrication

Architecture sectorielle

Architecture de référence de la chaîne d'approvisionnement numérique pour la fabrication