KhiopsML
Provide list of useful input variables
Description
After training a model, we get the list of generated variables. But this variables are used in expressions (ex: Max(X.field_1) where field_2 <= 0.5)
So it is not possible/easy to know which input variable has been used by Khiops to build the model and optimize the scoring workflow (by pruning other variable earlier in the processing workflow).
Questions/Ideas
Proposed solution : in the dictionary object, include a list of input variables mandatory to use the model
With this example Max(X.field_1) where field_2 <= 0.5, we should get [ field_1, field_2 ]
Context
- Khiops version 10.2.4
Le besoin est pertinent, et d'un intérêt évident pour optimiser les accès aux données lors des phases de déploiement, pour n'utiliser que les données nécessaires pour la modélisation. Il y a également un enjeu pour l'interprétabilité des modéles, en recensant explicitement la liste des tables et variables secondaires exploitées pour chaque variable utilisée en modélisation par le SNB.
Cela pourrait se traduire par l'enrichissement du json en expliquant l'origine de chaque variable utilisée par le SNB
- pour une variable simple: une seule variable de la table principale exploitée
- pour une variable construite: la liste des variables principales ou secondaires, avec leur chemin de données dans l'arborescence multi-tables
- exemple, en rajoutant un section json "selectedVariableOrigins" après la section ""selectedVariables" des "trainedPredictorsDetails":
"selectedVariablesOrigin": [
{
"name": "lum",
"origin": [
["lum"]
]
{
"name": "Mode(vehicules.catv) where Max(usagers.an_nais) <= 1983.5",
"origin": [
["vehicles", "catv"],
["vehicles", "usagers", "an_nais"]
],
...
}
- pour une paire de variables: l'origine et l'union des origines de chaque variable de la paire
- pour un arbre: l'origine est l'union des origines des variables utilisées par l'arbre
Ce json est facile a exploiter depuis un script python, et on pourrait facilement en déduire la liste de toutes les tables et variable secondaire utilisée par un prédicteur. On peut prévoir un helper pykhiops pour exploiter cette liste.
L'outil Khiops visualisation pourrait également exploiter ces informations pour indiquer l'origine de chaque variable du SNB, voire par cross-réf montrer la liste des tables ou variable secondaires globalement exploitées, avec des stats par nombre d'utilisation.
On pourrait également en plus ajouter une méta-data (ex: <Selected>) associée à chaque variable principale ou secondaire exploitée le prédicteur, directement dans le fichier dictionnaire, pour en faciliter l'exploitation.
A noter: en plus de l'origine des variables construites, on pourrait également ajouter dans le json le type de construction (paires, arbres...) et les règles de construction utilisées (Mode, Selection, Max...).
Un solution alternative plus directe serait d'ajouter une fonctionnalité d’optimisation de dictionnaire pour le déploiement, consistant en la suppression de toutes les variable non utilisées pour le déploiement:
- suppression des variables calculées
- suppression des variables natives (mais cela entrainera des warnings lors de la lecture des fichiers données, s'ils possèdent des variables dans leur entête qui sont inconnues du dictionnaire)
- suppression des variable de type Entity ou Table du schéma multi-table (mais cela impliquera un changement de structure multi-table, avec moins de tables dans le schéma, et donc un paramétrage différent lors du déploiement)
Exemple de spécification
- nouvel item de menu "Optimize dictionary..." dans le menu dictionnaire
- ouvre une boite de dialogue "Optimize dictionary"
- un champ "Input dictionary"
- éventuellement, des options:
- "Delete unused native variables"
- "Delete unused secondary tables"
- un bouton "Optimize dictionary": demande un nom de fichier dictionnaire pour sauvegarder le dictionnaire optimisé
Après échange auprès de Mathieu, la dernière solution répond bien au besoin, et c'est celle qui est a prioriser.
L'extension des rapport json répond plus a un besoin d'interprétabilité, en permettant d'explorer de façon inter-active les variables utilisées par le modèle et leur origine.
L'ajout de méta-données additionnelles de type "Selected" dans les dictionnaires n'est sans doute pas utile, si les deux autres fonctionnalités sont prise en comptes.