english version
Comme décrit dans l’entrée précédente, PredictiveDB permet de compléter les valeurs NULL d’une table en associant un risque d’erreur à ses prédictions.
On effectue ces prédictions très simplement, en SQL.
“Très simplement” signifie qu’il suffit de connaitre deux instructions:
…et rien de plus.
Vue prédictive: select
Afin de consulter les prédictions d’une table, il convient d’effectuer un select sur une vue particulière, nommée vue prédictive.
Dans l’exemple précédent:
select * from iris where id = 150;
interrogeait la table elle-même, tandis que:
select * from pdb.iris where id = 150;
interrogeait la vue prédictive. Dans cette dernière, les valeurs NULL sont remplacées par des prédictions.
Comment créer une vue prédictive?: insert
Pour créer la vue prédictive d’une table, il faut renseigner la table pdb.predictiveview qui les indexe:
\d pdb.predictiveview
Column | Type
-------------------+-------------------
view_name | character varying
schema_name | character varying
table_name | character varying
key_column | character varying
predictive_column | character varying
On la complète à l’aide d’un insert, et la vue prédictive correspondante se trouvera automatiquement créée.
Un exemple
Nous disposons d’une base de données recensant certains votes des membres du congrès aux États-Unis.
Il s’agit d’une table recensant 16 votes clefs identifiés par le Congressional Quarterly Almanac en 1984:
\d vote
Colonne | Type
----------------------------------------+-------------------
id | integer
handicapped_infants | character varying
water_project_cost_sharing | character varying
adoption_of_the_budget_resolution | character varying
physician_fee_freeze | character varying
el_salvador_aid | character varying
religious_groups_in_schools | character varying
anti_satellite_test_ban | character varying
aid_to_nicaraguan_contras | character varying
mx_missile | character varying
immigration | character varying
synfuels_corporation_cutback | character varying
education_spending | character varying
superfund_right_to_sue | character varying
crime | character varying
duty_free_exports | character varying
export_administration_act_south_africa | character varying
party | character varying
Par exemple, le membre du congrès numéro 1, un républicain, a effectué les votes suivants:
select * from vote where id=1;
1 | n | y | n | y | y | y | n | n | n | y | | y | y | y | n | y | republican
(Remarque: vous avez peut-être noté qu’un vote n’a pas été renseigné (pas de “y” ni de “n”): cela traduit une absence de vote — enfin, pas tout à fait, voir la source pour plus de détails. Les valeurs manquantes ne posent aucun problème à PredictiveDB qui s’en accommode sans peine, contrairement à certaines approches (réseaux de neurones, SVM).
Or, concernant certains membres, nous connaissons leurs votes, mais pas leur parti (ex. membre n°435):
demo=> select id,party from vote offset 430;
id | party
-----+------------
431 | republican
432 | democrat
433 | republican
434 | republican
435 |
PredictiveDB, en se basant sur les votes de ce membre et sur ceux de ses pairs, va permettre de prédire son étiquette politique.
1) On crée une vue prédictive à l’aide d’un insert dans l’index des vues prédictives pdb.predictiveview:
insert into pdb.predictiveview values('vote','public','vote','id','party');
On renseigne successivement:
view_name: le nom de la vue (“vote”)
schema_name: le nom du schéma Postgresql (“public”)
table_name: le nom de la table cible (“vote”)
key_column: la clef de la table cible (“id”)
predictive_column: la colonne à prédire (“party”)
Éventuellement, on peut vérifier la déclaration de la nouvelle vue prédictive:
demo=> select * from pdb.predictiveview;
view_name | schema_name | table_name | key_column | predictive_column
-----------+-------------+------------+------------+-------------------
vote | public | vote | id | party
2) Maintenant que la vue a été créée, on peut la consulter:
demo=> select * from pdb.vote offset 430;
id | party | error_risk
-----+------------+-------------------
431 | republican |
432 | democrat |
433 | republican |
434 | republican |
435 | republican | 7.339449541284404
Selon PredictiveDB, le membre 435 est un républicain.
PredictiveDB offre l’avantage de fournir un indicateur de la qualité de ses prédictions: ici, il s’agit d’une prédiction plutôt fiable, puisqu’on a (environ) 93 chances sur 100 de ne pas se tromper.
(Cette mesure se base sur une méthodologie éprouvée développée dans le cadre de l’apprentissage supervisé, nous reviendrons sur ces notions lors d’une future entrée.)
Autre exemple
Un peu plus haut, nous remarquions qu’un vote du membre n°1 était non-renseigné (pas de “y” ni de “n”):
select * from vote where id=1;
1 | n | y | n | y | y | y | n | n | n | y | | y | y | y | n | y | republican
^ NULL
Il s’agit du vote synfuels_corporation_cutback:
demo=> select synfuels_corporation_cutback from vote where id=1 ;
synfuels_corporation_cutback
------------------------------
NULL
Or, on peut exploiter PredictiveDB pour spéculer sur la décision du membre n°1 s’il avait pris part au vote:
1) Création de la vue prédictive:
insert into pdb.predictiveview values('votescc','public','vote','id','synfuels_corporation_cutback');
2) Consultation des prédictions:
demo=> select * from pdb.votescc where id=1 ;
id | synfuels_corporation_cutback | error_risk
----+------------------------------+-------------------
1 | n | 30.76923076923077
À en croire PrédictiveDB, le membre n°1 aurait voté “non”.
À noter que, cette fois, une relative incertitude plane, puisque le SGBD prédictif évalue à 30 chances sur 100 le risque de fausses prédictions.
Autrement dit, c’est une indication suffisante pour un pari (2 chances sur 3 d’avoir raison), mais pas suffisamment performante pour voter à la place de l’intéressé.
Pour que PredictiveDB puisse fournir une prédiction plus fine, des données de meilleures qualités seraient nécessaires. Par exemple, de nouveaux exemples de votes d’autres membres concourraient peut-être à améliorer la qualité de ses analyses.