Quatre décisions, un coefficient — Analyse de données

Un programme d’eau rurale veut savoir quel modèle de gestion maintient les points d’eau en état. Le registre contient 2 629 visites avec un état de fonctionnement sur chacune, un modèle de gestion sur chaque point, et toutes les covariables qu’un modèle pourrait vouloir.

Ajuster ce modèle prend quatre lignes. Le faire correctement demande quatre décisions, et ce laboratoire consiste à les prendre explicitement et dans l’ordre — quelles covariables, quelle unité, quels poids, et que mettre dans le rapport.

Le fichier

water-point-monitoring-2024.v1.csv — 2 629 visites de suivi sur 242 points d’eau répartis sur 18 communautés et 3 districts, douze passages mensuels. Synthétique.

Préparez d’abord

Un environnement virtuel, le fichier en lecture seule, un répertoire outputs/, et un script qui s’exécute de bout en bout. Chaque nombre du rapport que vous rendez est imprimé par ce script.

Décision une : ce qu’est le résultat

functional_status a quatre valeurs, non deux. Avant qu’aucun modèle n’existe, décidez ce que « en état » signifie et notez la décision.

print(points["functional_status"].value_counts())

1 823 fonctionnels, 512 non fonctionnels, 160 abandonnés, 134 partiellement fonctionnels.

Trois résultats défendables, et ce sont des questions différentes :

functional contre tout le reste — l’eau est-elle disponible aujourd’hui ;
functional ou partially-functional contre le reste — le point est-il en service ;
écarter entièrement abandoned — parmi les points encore dans le programme, combien fonctionnent.

Choisissez-en un, dites pourquoi en commentaire, et employez-le partout. Le cours EAH a établi qu’un programme de points d’eau a trois taux de fonctionnalité plutôt qu’un ; c’est le même fait arrivant comme décision de modélisation.

Décision deux : quelles covariables

Bâtissez le modèle pour la question de gestion, non pour l’ajustement.

Disponibles : management, source_type, installed_year, users_estimated, district, community, round, fee_collected, queue_minutes, days_since_breakdown.

Trois d’entre elles ne doivent pas figurer dans un modèle d’effet total pour la gestion, et vous devez dire pourquoi. Trouvez lesquelles avant de lire la suite — le test de la leçon 5 consiste à demander si la variable est causée par l’exposition, causée par le résultat, ou les deux.

model = smf.logit(
    "working ~ management + source_type + age + district", data=points).fit()

Justifiez ensuite chaque inclusion en une ligne : facteur de confusion, cause concurrente, ou variable de plan. Une covariable que vous ne pouvez pas classer n’entre pas.

Décision trois : quelle est l’unité

C’est la décision que le registre rend inévitable, et ce n’est pas celle des leçons.

print(f"{len(points)} visits, {points['water_point_id'].nunique()} points")
print(points.groupby("water_point_id").size().describe())

242 points, visités onze fois en médiane. Les lignes ne sont pas 2 625 observations indépendantes d’un modèle de gestion — ce sont 242 points d’eau observés de façon répétée, et un point en panne en mars a de bonnes chances de l’être encore en avril.

Ajustez-le de trois façons et mettez-les côte à côte :

le modèle logistique naïf au niveau visite ;
le même modèle avec des erreurs-types groupées sur water_point_id ;
un modèle linéaire au niveau point sur la proportion de passages en état.

Chaque coefficient des deux premiers est identique. Seules les erreurs-types bougent, et elles bougent de façon inégale selon les termes — notez le rapport pour chacun.

Décision quatre : ce que dit le rapport

Produisez un tableau avec le coefficient, les deux erreurs-types, et une colonne disant si la conclusion change. Écrivez ensuite l’affirmation en quatre phrases du cours de statistiques pour la comparaison de gestion que vous jugez la mieux étayée.

Vérifiez vos nombres

	Attendu
Visites, points, communautés	2 629 · 242 · 18
En état (fonctionnel seul), niveau visite	environ 69,3 %
En état, niveau point	environ 69,2 %
Opérateur privé, RC naïf	environ 1,68, IC à 95 % 1,29 à 2,19
Opérateur privé, RC groupé	1,68, IC à 95 % 1,10 à 2,56
Gestion ONG, RC naïf	environ 1,44, z = 2,59
Gestion ONG, RC groupé	1,44, z = 1,61
Âge du point, naïf	RC 0,976 par an, z = −2,99
Âge du point, groupé	RC 0,976 par an, z = −1,65
Inflation de l’erreur-type	entre 1,1× et 2,0× selon le terme

Quatre termes traversent le seuil de 0,05 quand le regroupement est corrigé — gestion ONG, sources de captage, âge du point et le district de Sud-Est — et pas un coefficient ne change. Si vos coefficients ont bougé, vous avez réajusté au lieu de réestimer la covariance.

Si votre modèle au niveau point est en désaccord avec le modèle groupé sur les termes qui survivent, vérifiez si vous avez agrégé les covariables avec first — le modèle de gestion d’un point ne change pas d’un passage à l’autre, et prendre la moyenne d’une chaîne de caractères écarte silencieusement la colonne.

Les questions à traiter en prose

Trois phrases chacune.

1. Nommez les trois covariables que vous avez exclues et classez chacune — médiateur, collisionneur, ou en aval du résultat. Pour celle qui vous a le plus résisté, dites ce qu’il faudrait que le programme soit pour que votre classement soit faux.

2. Quatre termes perdent leur significativité sous regroupement et aucun coefficient ne bouge. Expliquez à un coordinateur EAH, sans employer le mot « variance », pourquoi l’estimation est inchangée et la conclusion non.

3. Le modèle naïf a 2 625 lignes et le modèle au niveau point 242. Énoncez la taille d’échantillon efficace qu’implique le modèle groupé, et dites à quoi devrait ressembler le registre pour que 2 625 soit le nombre honnête.

Ce qu’il faut rendre

Un script Python, exécuté depuis un environnement propre, produisant :

la définition du résultat en commentaire en tête de fichier, avec sa raison
le tableau des covariables : chaque variable, dedans ou dehors, et son classement
les trois ajustements dans un seul tableau, avec les deux erreurs-types et le rapport
l’ajustement au niveau point comme troisième colonne
un report.txt dans la forme des blocs « rapportez-le en entier », avec la comparaison de gestion écrite en quatre phrases et un paragraphe de limites nommant le regroupement, le caractère observationnel et la définition du résultat
les trois réponses en prose en bloc de commentaires en pied de fichier

Comment savoir que c’est fini

Supprimez outputs/, relancez, tout se régénère à l’identique. Changez ensuite la définition du résultat en tête de script, de functional à functional ou partially-functional : chaque nombre du rapport devrait bouger et la structure du rapport — quels termes survivent au regroupement — ne devrait pas. Si changer une constante en tête ne se propage pas partout, un nombre a été saisi plutôt que calculé.

Ce que ce laboratoire n’est pas

Ce n’est pas une analyse de survie des pannes, et ce n’est pas un modèle de days_since_breakdown — cette variable est en aval du résultat et relève d’une autre question. Ce n’est pas non plus une évaluation des modèles de gestion : personne n’a randomisé les points d’eau vers l’opération privée, et le coefficient d’opérateur privé est une comparaison de points qui différaient déjà. Ce laboratoire porte sur le fait que les quatre décisions sont prises que vous les preniez ou non — un ajustement par défaut les prend toutes les quatre mal et imprime un tableau qui ressemble exactement à un bon.