💻 computer science

Schema-Agnostic Process Trace Construction: From Raw Tables to Execution Behavior

Cet article propose un pipeline agnostique au schéma qui reconstruit automatiquement des traces d'exécution de processus de haute fidélité à partir de tables relationnelles brutes et lâchement connectées en identifiant statistiquement les attributs clés et temporels, en découvrant les connexions entre les tables et en utilisant un réseau de neurones convolutifs temporel pour modéliser l'ordonnancement des événements, éliminant ainsi le besoin de schémas prédéfinis ou de modèles de domaine dans les systèmes d'information dynamiques.

Auteurs originaux : Joel Lim Zhi Quan, Tan Kar Way, Lau Hoong Chuin

Publié 2026-06-16

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Joel Lim Zhi Quan, Tan Kar Way, Lau Hoong Chuin

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un détective tentant de reconstruire l'histoire d'un braquage de banque. Dans un monde parfait, la police vous remettrait un journal de bord chronologique et bien ordonné où chaque entrée indique exactement qui a fait quoi et quand.

Mais dans le monde réel, les preuves sont éparpillées. Vous avez un tas de reçus volants, une pile de journaux de caméras de surveillance, quelques notes manuscrites et un tableur d'appels téléphoniques. Aucun de ces documents ne communique avec les autres. Les reçus n'ont pas de noms, les journaux de caméras n'ont pas d'horodatages, et les notes téléphoniques sont écrites dans une langue différente. De plus, la banque change son système de classement chaque semaine.

C'est le problème que les auteurs de ce document tentent de résoudre. Ils traitent des systèmes informatiques modernes (comme les banques ou les grandes entreprises) où les données sont désordonnées, éparpillées dans de nombreuses tables différentes et en constante évolution. Les méthodes traditionnelles d'analyse de ces systèmes échouent car elles exigent une carte parfaite et préorganisée (un « schéma ») qui n'existe tout simplement pas.

Voici comment leur solution fonctionne, décomposée en étapes simples :

Le Problème : Le « Classeur Désordonné »

Dans les anciens systèmes informatiques, les données étaient comme une bibliothèque bien organisée. Chaque livre avait une étiquette claire et vous saviez exactement à quelle étagère il appartenait.
Dans les systèmes modernes, les données sont comme le grenier d'un collectionneur compulsif.

Pas d'étiquettes : Vous ne pouvez pas facilement dire quelle donnée appartient à quel client (absence de « clés »).
Indices éparpillés : L'histoire d'une seule transaction est divisée entre cinq tables différentes.
Chronologies confuses : Une table indique « 10h00 », une autre « 10h05 », et une troisième dit simplement « Hier ».
Rénovations constantes : Le grenier est réorganisé pendant que vous essayez de le nettoyer.

À cause de cela, construire une chronologie claire de ce qui s'est passé (appelée « trace de processus ») nécessite généralement qu'un expert humain assemble manuellement tous les éléments, ce qui est lent, coûteux et sujet aux erreurs.

La Solution : Un Détective « Agnostique au Schéma »

Les auteurs ont construit un pipeline automatisé qui agit comme un super-détective intelligent qui n'a pas besoin de carte. Au lieu de demander : « Où est la carte ? », il examine simplement les preuves elles-mêmes pour comprendre l'histoire.

Voici les quatre étapes que suit leur « détective » :

1. Repérer les indices (Profilage)

D'abord, le système scanne chaque colonne de données pour deviner ce qu'elle est.

La chasse aux ID : Il cherche des colonnes qui ressemblent à des noms uniques (comme un identifiant client). Il vérifie : « Cette valeur est-elle unique ? Est-elle toujours présente ? Ressemble-t-elle à un nom ? »
La chasse au temps : Il cherche des colonnes qui ressemblent à des dates. Il vérifie : « Cela ressemble-t-il à un horodatage ? Est-ce cohérent ? »
Analogie : Imaginez que vous triez un tas de pièces de puzzle mélangées. Le détective n'a pas besoin de l'image sur la boîte ; il regarde simplement la forme des pièces pour deviner lesquelles appartiennent au ciel et lesquelles appartiennent à l'herbe.

2. Relier les points (Découverte de relations)

Puisqu'il n'y a pas de lignes officielles de « relier les points » (clés étrangères), le système utilise des signaux statistiques.

Il compare les colonnes de différentes tables. Si la Table A possède une liste de nombres et que la Table B possède une liste de nombres qui correspondent parfaitement, le système suppose qu'elles sont connectées.
Il ignore les règles « officielles » et observe les modèles de données réels.
Analogie : Si vous trouvez un reçu dans une poche et un relevé de carte de crédit correspondant dans une autre, vous savez qu'ils appartiennent à la même personne, même s'ils ne sont pas agrafés ensemble.

3. Construire la chronologie (Séquençage)

Une fois que le système sait quelles tables sont connectées, il rassemble tous les événements pour un seul « cas » (comme une commande client spécifique).

Il trie ces événements par ordre chronologique.
Si les heures sont confuses ou manquantes, il utilise la logique pour deviner l'ordre.
Analogie : Le détective prend toutes les notes, reçus et journaux éparpillés pour un braquage spécifique et les dispose sur une table pour voir la séquence des événements.

4. Apprendre le modèle (Le « Cerveau » - TCN)

C'est la partie la plus avancée. Parfois, les horodatages sont trop désordonnés pour savoir quel événement s'est produit en premier.

Le système utilise un type spécial d'IA appelé Réseau de Convolution Temporelle (TCN). Voyez cela comme un moteur de reconnaissance de formes.
Il observe des milliers d'exemples passés pour apprendre : « Généralement, quand l'Événement A se produit, l'Événement B suit ».
Même si l'horloge est cassée, l'IA peut prédire l'étape suivante en se basant sur le flux de l'histoire.
Analogie : Si vous voyez quelqu'un mettre un manteau, prendre ses clés et ouvrir une porte, vous savez qu'il est sur le point de partir, même si vous n'avez pas vu l'instant exact où il est sorti. L'IA apprend ces « flux d'histoires ».

Les Résultats : À quel point le détective est-il efficace ?

Les auteurs ont testé ce système sur des données fictives (simulant des banques désordonnées), des benchmarks standards et un jeu de données industriel réel.

Précision : Il a prédit correctement l'étape suivante d'un processus 85 % du temps.
Récupération : Il a réussi à trouver et à reconstruire environ 82 % de l'ordre correct des événements, même lorsque les données étaient manquantes ou désordonnées.
Résilience : Lorsque les données ont subi une « dérive » (changement de noms, dates manquantes), le système a continué à fonctionner, tandis que les méthodes traditionnelles se sont effondrées.

Pourquoi cela importe

L'article soutient que nous devons cesser d'attendre des données parfaites avant de pouvoir les analyser. Au lieu de forcer des données réelles désordonnées dans une boîte rigide et prédéfinie, nous devrions laisser les données parler d'elles-mêmes.

En supprimant le besoin d'un « schéma » parfait (la carte), cette approche permet aux entreprises de comprendre automatiquement leurs propres systèmes, même si ces systèmes sont désordonnés, en constante évolution ou mal documentés. Cela transforme un tas chaotique de preuves en une histoire claire et lisible sans avoir besoin qu'un humain fasse tout le travail difficile.

Résumé Technique : Construction de Traces de Processus Agnostique au Schéma

Énoncé du Problème

Les systèmes d'information (SI) modernes, particulièrement dans les environnements OLTP, sont caractérisés par des tables relationnelles à l'évolution rapide et faiblement couplées. Dans ces contextes, les hypothèses traditionnelles de schémas stables, de clés primaires/étrangères explicites et de journaux d'événements curatés échouent souvent. Les schémas dérivent, les clés de substitution sont appliquées ou refactorisées de manière incohérente, et les traces d'exécution sont dispersées à travers de multiples tables avec des clés éparses et des champs d'horodatage ambigus ou multiples.

Par conséquent, la reconstruction de traces d'exécution de processus (journaux d'événements) pour des tâches telles que l'audit, la conformité et le minage de processus nécessite une intervention manuelle coûteuse et fragile, impliquant des jointures ad hoc et des règles d'horodatage. Les approches existantes reposent généralement sur des schémas prédéfinis, des structures PK/FK fiables ou des modèles spécifiques au domaine, ce qui les rend inapplicables aux environnements à faible densité de clés, hétérogènes et en changement continu. Le problème central abordé est la manière de construire automatiquement des séquences d'exécution de haute fidélité (cas, événements et ordonnancement temporel) directement à partir de données relationnelles brutes sans dépendre de schémas prédéfinis, de clés étrangères fiables ou de l'expertise métier.

Méthodologie

Les auteurs proposent un pipeline agnostique au schéma en quatre étapes qui infère les liens inter-tables à partir de signaux statistiques, assemble les champs temporels et apprend les modèles d'ordonnancement. Le pipeline fonctionne sans nécessiter la reconstruction complète du schéma ou des mappages ontologiques.

Étape 1 : Profilage des Colonnes d'Identifiants et d'Horodatage

Le pipeline profile les colonnes de chaque table pour estimer leur probabilité de fonctionner comme identifiants de cas ou horodatages.

Score d'Identifiant : Un score $spk(c)$ est calculé basé sur la distinction ( $u$ ), la complétude ( $\gamma$ ) et la stabilité de la longueur des chaînes ( $\lambda$ ). Les colonnes doivent obtenir un score élevé sur ces trois métriques pour être conservées comme identifiants candidats.
Score d'Horodatage : Un score $sdt(c)$ est calculé à l'aide d'une somme pondérée des rangs de centiles pour la dispersion et les métriques de variation (complétude, distinction, écart-type, intervalle interquartile et entropie).
Sortie : Les top- $k$ identifiants candidats et colonnes d'horodatage sont sélectionnés pour chaque table.

Étape 2 : Découverte de Relations (Liens Colonne-Colonne)

Au lieu de s'appuyer sur les clés étrangères déclarées, le pipeline découvre les connexions inter-tables en utilisant une similitude statistique sensible au type.

Mécanisme de Scoring : Pour chaque paire de colonnes inter-tables $(c_i, c_k)$ $(c_{i}, c_{k})$ , un score de lien $s(c_i, c_k)$ $s (c_{i}, c_{k})$ est calculé comme le produit de quatre facteurs :
1. Compatibilité de Type (TC) : Réduit le poids des paires ayant des types de données faiblement compatibles.
2. Qualité de Colonne (Q) : Pénalise les paires impliquant des colonnes à faible complétude ou faible distinction.
3. Couverture (U) : Garantit que le chevauchement n'est pas piloté par des valeurs marginales rares.
4. Similitude de Valeur (R) : Mesure l'alignement réel des valeurs en utilisant la similitude de Jaccard (JS) pour les données symboliques et un mélange JS/Kolmogorov-Smirnov (KS) pour les distributions numériques.
Formation de Liens : Les paires dépassant un seuil $\tau_S$ sont conservées pour former un multigraphe non orienté de liens candidats.

Étape 3 : Temporalisation et Séquençage

En utilisant l'ensemble de liens découvert, le pipeline propage les identifiants de cas échantillonnés à travers les tables atteignables pour collecter les lignes correspondantes et les candidats d'horodatage.

Assemblage d'Événements : Chaque paire (ligne, horodatage) est traitée comme un événement provisoire.
Ordonnancement : Les événements pour un cas spécifique sont triés par horodatage. Les égalités sont résolues de manière déterministe en utilisant les noms de tables et les identifiants de lignes. Les doublons d'étiquettes adjacents sont compressés, tandis que les répétitions non adjacentes sont préservées.
Contexte : Des attributs métier optionnels (ex: région, produit) sont intégrés dans des vecteurs de contexte pour conditionner l'apprentissage ultérieur sans altérer l'ordre des événements.
Sortie : Des traces d'exécution riches en provenance, au format JSON, exportables vers XES ou convertibles en OCEL.

Étape 4 : Apprentissage de Séquence (Ordonnancement à travers les Tables)

Pour traiter les cas où les horodatages sont ambigus, manquants ou insuffisants pour déterminer l'ordre, le pipeline emploie un Réseau de Convolution Temporelle Causale (TCN).

Objectif d'Apprentissage : Le TCN prédit l'événement suivant $e_{t+1}$ étant donné une fenêtre d'événements passés et un vecteur de contexte optionnel.
Extraction de la Précedence : En agrégeant les prédictions de l'événement suivant, une matrice de transition est formée. Des arêtes dirigées $i \to j$ sont ajoutées lorsque la probabilité que $j$ suive $i$ dépasse significativement l'inverse. Les paires présentant des fréquences bidirectionnelles similaires sont marquées comme présentant une Variabilité d'Ordre Bidirectionnelle (BOV).
Sortie : Un graphe de précédence minimal résumant les relations de flux, qui peut être consommé par des outils standards de minage de processus.

Contributions Clés

Pipeline Agnostique au Schéma : Une nouvelle approche de bout en bout qui reconstruit les traces de processus à partir de données relationnelles brutes à faible densité de clés, sans schémas prédéfinis, diagrammes ER ou modèles de domaine.
Découverte de Liens Statistique : Une méthode pour inférer les relations entre tables en utilisant une similitude statistique sensible au type (JS/KS) plutôt que de s'appuyer sur des clés étrangères explicites, ce qui la rend robuste à la dérive des schémas et aux clés manquantes.
Apprentissage de la Précedence : L'application des TCN pour apprendre l'ordonnancement et les relations de flux inter-tables directement à partir des traces reconstruites, gérant les scénarios où les horodatages sont insuffisants ou conflictuels.
Robustesse Opérationnelle : Une voie pour générer des journaux d'événements qui restent robustes aux horodatages manquants, aux homonymes et aux clés partielles, permettant la construction automatisée de journaux dans des environnements SI dynamiques.

Résultats

Le pipeline a été évalué sur des benchmarks TPC-H/E, des corpus synthétiques (Synth-Light, Synth-Heavy) et un jeu de données industriel réel (Industry-1).

Récupération d'Événements (RQ1) : Le pipeline a atteint une haute précision de récupération de l'ensemble d'événements, avec une précision de jeton indépendante de la position (PITA) allant de 0,82 (Synth-Heavy) à 1,00 (TPC-H). Il a prédit correctement l'événement suivant avec une précision de 85 %.
Apprentissage de la Précedence (RQ2) : L'approche basée sur le TCN a surpassé les bases n-gramme et LSTM en termes de prédiction de l'événement suivant et de métriques de conformité. Elle a récupéré environ 82 % des relations de précédence de vérité terrain (score F1 de 0,74–0,82) et a démontré une capacité supérieure à capturer les relations de flux inter-tables par rapport aux approches basées sur des règles ou des schémas.
Résilience au Changement (RQ3) : Sous une dérive contrôlée (renommage d'attributs et absence d'horodatage), le pipeline complet a conservé plus de 80 % de ses performances de données propres, tandis qu'une base de référence déterministe est tombée sous les 50 %. Cela démontre une résilience significative à l'évolution des schémas et des données.
Attribution par Étape : Les études d'ablation ont confirmé que les étapes S1–S3 pilotent la qualité de la reconstruction, tandis que l'étape S4 (TCN) améliore significativement la fidélité des relations de précédence, particulièrement pour capturer les dépendances à longue portée et les flux contextuels.

Signification et Revendications

L'article prétend offrir une voie généralisable et évolutive pour la reconstruction automatisée du comportement d'exécution dans des environnements SI dynamiques. Il remet en question l'hypothèse de longue date en ingénierie des SI selon laquelle des journaux d'événements fiables présupposent des schémas propres et des clés curatées. En passant d'une approche "schéma d'abord" à une approche "données d'abord", les auteurs soutiennent qu'il est possible de construire des journaux de haute qualité même lorsque les schémas dérivent et que les systèmes évoluent.

Ce travail suggère un nouveau paradigme d'ingénierie des SI où les schémas opérationnels peuvent évoluer librement, tandis qu'une couche d'ingénierie de données assure la continuité pour l'analyse, l'audit et la conception. Les auteurs positionnent cela comme une solution au goulot d'étranglement de la construction manuelle des traces dans les systèmes OLTP modernes, faiblement couplés, permettant le minage de processus et la surveillance de la conformité dans des environnements auparavant considérés comme trop bruités ou non structurés pour une telle analyse.