Résumé Technique : TwinBI – Un jumeau numérique agentique pour des interactions augmentées et efficientes avec les tableaux de bord de Business Intelligence

1. Énoncé du problème

Les systèmes de Business Intelligence (BI) sont essentiels à la prise de décision fondée sur les données, pourtant un décalage significatif existe entre la génération de langage naturel fluide (via les modèles de langage de grande taille - LLM) et un support à la décision analytiquement rigoureux. Bien que les agents basés sur les LLM puissent convertir des requêtes en langage naturel en SQL ou en exécutions d'outils, ils échouent souvent à maintenir une cohérence analytique lors d'interactions multi-étapes.

Plus précisément, lorsque les utilisateurs passent de la manipulation directe du tableau de bord (ex. : filtrage, forage/drill-down) aux requêtes en langage naturel, le système peine à préserver un état cohérent concernant :

• Les définitions de métriques et les grains d'agrégation.
• La portée des filtres et les niveaux de hiérarchie.
• Le contexte analytique actuel (ex. : quel graphique est actif, quels filtres sont appliqués).

Les agents LLM dérivent souvent hors des contraintes sémantiques précises du système BI, produisant des réponses linguistiquement cohérentes mais analytiquement incohérentes avec l'état réel du système. Les solutions existantes traitent souvent le langage naturel et l'interaction avec le tableau de bord comme des modes distincts plutôt que comme un flux de travail unifié et synchronisé.

2. Méthodologie : Le cadre TwinBI

TwinBI répond à ce défi en introduisant un cadre de jumeau numérique agentique qui couple un système d'agent basé sur un LLM avec un état exécutable de tableau de bord BI. La philosophie centrale est de faire évoluer le rôle des agents LLM de "remplacement de la BI" vers un travail "en concert avec la BI" grâce à une couche de coordination explicite.

Architecture du système

Le système repose sur une architecture à cinq couches :

1. Couche de Présentation : Combine une interface de chat (Streamlit) avec des tableaux de bord BI intégrés (Apache Superset). Elle suit les contextes analytiques actifs (graphiques sélectionnés, onglets, interactions récentes) et envoie des signaux au backend.
2. Couche d'Orchestration Backend et d'Intelligence : Un système multi-agents basé sur FastAPI qui gère l'historique du dialogue, les journaux d'interaction du tableau de bord et les sorties d'outils. Il route les sous-tâches vers des agents spécialisés (ex. : Explorateur de Schéma, Gestionnaire de Graphiques) et consolide les résultats ancrés dans l'état actuel.
3. Couche Sémantique : Construite sur Cube, cette couche capture la signification métier à l'aide de modèles déclaratifs de mesures, de dimensions et de hiérarchies. Elle impose des grains compatibles et des jointures valides, fournissant un modèle sémantique partagé pour les sorties conversationnelles et les requêtes du tableau de bord.
4. Couche d'Outil BI : Utilise Apache Superset pour le rendu des visualisations et la capture d'événements d'interaction détaillés.
5. Couche de Données : Stocke les ensembles de données analytiques dans DuckDB, accédés exclusivement via la couche sémantique pour garantir l'uniformité des définitions de métriques.

Mécanismes fonctionnels clés

• Journal d'Interaction Unifié : Le système enregistre tous les échanges conversationnels, les opérations du tableau de bord (ex. : filtrage croisé, basculement de séries) et les métadonnées des outils. Ce journal sert de registre faisant autorité pour la reconstruction de l'état et la provenance.
• Reconstruction de l'État : Avant d'interpréter une nouvelle requête conversationnelle, TwinBI encode les actions du tableau de bord sous forme d'événements structurés pour reconstruire l'état analytique actuel. Cela garantit que les questions de suivi sont résolues par rapport au même contexte que les manipulations de tableau de bord précédentes.
• Artefacts de Transparence : Le système expose trois artefacts d'inspection pour soutenir la vérification par l'utilisateur :
  1. Graphe de Schéma Hiérarchique : Une vue navigable des mesures, dimensions et hiérarchies.
  2. Exposition SQL : Le SQL associé à chaque requête de graphique.
  3. Journal d'Interaction Unifié : Trace la relation entre les réponses conversationnelles et les opérations antérieures du tableau de bord.
• Commande /insights : Une commande spécialisée qui génère des résumés sensibles à l'état. Elle assemble un contexte d'exécution compact (conversations récentes, graphique actif, filtres) et renvoie un résumé d'observations quantitatives et de suggestions d'étapes suivantes, strictement ancré dans les preuves visibles actuelles.

3. Évaluation et Résultats

Les auteurs ont évalué TwinBI via deux études complémentaires : un benchmark A/B contrôlé et une étude d'utilisabilité.

Benchmark A/B (Performance de l'Agent)

• Configuration : Comparaison de TwinBI avec une ligne de base "Tableau de bord uniquement" utilisant le même moteur d'agent (gpt-5-mini) et un budget fixe de 30 étapes d'interaction sur 30 requêtes analytiques.
• Métriques : Précision de correspondance exacte, précision à crédit partiel, taux d'expiration (timeout) et efficacité de l'interaction (étapes pour compléter).
• Résultats :
  • Précision de correspondance exacte : Améliorée de 43,3 % (Tableau de bord) à 63,3 % (TwinBI).
  • Précision à crédit partiel : Améliorée de 48,3 % à 70,8 %.
  • Taux d'expiration : Réduit substantiellement de 40,0 % à 10,0 %.
  • Efficacité : Le nombre moyen d'étapes pour compléter est passé de 16,47 à 6,90.
  • Comportement : TwinBI a considérablement réduit les actions invalides et les expirations, indiquant une plus grande stabilité d'interaction. Bien que les taux d'étapes en boucle soient restés non négligeables pour certains échecs, le système a réussi à éviter le "probing d'interface fragile" qui causait l'échec de la ligne de base.

Étude d'Usabilité

• Configuration : Une étude intra-sujets avec cinq participants complétant trois scénarios de complexité croissante (Performance du magasin, Prix des produits, Croissance des catégories).
• Résultats :
  • Précision des tâches : Est restée élevée (100 % dans S1 et S3, 73,33 % dans S2), bien que les scénarios plus complexes aient nécessité un coût d'interaction plus élevé.
  • Modèles de flux de travail : Les participants ont systématiquement utilisé le tableau de bord pour établir le contexte, puis ont exploité le chat pour la comparaison, la vérification de seuils ou l'explication. Ils n'ont que rarement abandonné totalement le tableau de bord.
  • Charge de travail : Malgré un coût d'interaction accru dans les tâches complexes, la charge de travail perçue est restée dans une plage faible à modérée (NASA-TLX).
  • Préférence de fonctionnalité : Les participants ont classé les combinaisons sensibles à l'état (ex. : "Clic + Chat") plus haut que le chat seul ou l'inspection SQL directe. La fonctionnalité /insights s'est révélée utile lorsque les participants avaient déjà restreint l'analyse à une vue spécifique.

4. Contributions Clés

1. Cadre de Jumeau Numérique Agentique : Une architecture novatrice qui synchronise un jumeau d'agent LLM (modélisant l'intention) avec un jumeau BI (état exécutable), assurant l'alignement entre l'intention de l'utilisateur et l'exécution du système.
2. Gestion Unifiée de l'État : Un mécanisme pour reconstruire les états analytiques à partir d'un journal d'interaction unifié, permettant aux requêtes en langage naturel d'être ancrées dans les filtres, hiérarchies et métriques actuellement actifs dans le tableau de bord.
3. Transparence Accrue : L'exposition des vues de schéma, du SQL et des journaux d'interaction pour soutenir le débogage et le suivi de la provenance, allant au-delà des réponses "boîte noire" des agents.
4. Validation Empirique : Preuve que l'intégration de l'état du tableau de bord dans l'orchestration de l'agent améliore à la fois la fiabilité analytique (précision) et la stabilité de l'interaction (réduction des expirations) par rapport aux approches de tableau de bord seul ou d'agents sans état.

5. Signification et Revendications

L'article affirme que TwinBI démontre qu'une "BI agentique" robuste nécessite une couche de coordination explicite qui aligne l'intention de l'utilisateur, les définitions sémantiques et l'exécution des requêtes, plutôt que de compter uniquement sur le langage naturel. En transformant l'état visible du tableau de bord en un contexte actionnable plus riche, TwinBI améliore :

• La fiabilité analytique de l'agent : Réduisant la dérive des agents LLM par rapport aux contraintes sémantiques.
• Le support analytique pour l'utilisateur : Permettant un flux de travail où les utilisateurs peuvent passer fluidement de la manipulation directe à l'assistance conversationnelle sans perdre le contexte.

Les auteurs positionnent TwinBI comme une étape vers des systèmes où les agents travaillent en concert avec les outils BI, renforçant ainsi la robustesse du support à la décision. Ils reconnaissent les limites, notant que l'étude impliquait un échantillon de petite taille et un ensemble de données de vente au détail spécifique, et suggèrent des travaux futurs pour passer à l'échelle sur des ensembles de données plus vastes, des utilisateurs diversifiés et le transfert d'états analytiques entre différents tableaux de bord.