Modèle d'uplift de FWCI : qualités, précautions et tests

De quoi parle cette page

En une phrase. Le pipeline citation produit, pour le réseau EUNICoast, un modèle qui prédit la valeur ajoutée d’une collaboration entre deux chercheurs — et cette page explique ce que le modèle garantit, les précautions prises pour qu’il ne se trompe pas en se croyant juste, et les tests qui le prouvent.

Elle s’adresse à un lecteur non développeur (déployeur, relecteur, responsable de traitement) : la décision structurante vit dans l’ADR 0067 ; ici on décrit le comportement servi et les garde-fous vérifiables.

Glossaire express

FWCI (Field-Weighted Citation Impact) : indice d’impact d’une publication, normalisé par domaine et par année. Un FWCI de 1,0 = impact moyen du champ ; 2,0 = deux fois plus cité que la moyenne du domaine. Il vient de la source OpenAlex, capté par publication tout au long du pipeline.
Uplift : la valeur ajoutée d’une collaboration = FWCI obtenu ensemble moins le FWCI solo habituel des deux auteurs. C’est une mesure « 1 + 1 > 2 », pas l’impact absolu. Un uplift positif = la paire publie mieux ensemble que séparément.
EUNICoast : alliance européenne de 13 universités côtières et insulaires (dont Le Havre). Le périmètre du modèle se limite aux publications dont au moins un auteur y est affilié, et datant de moins de dix ans.
Subfield : sous-domaine thématique d’une publication (taxonomie OpenAlex). Un auteur est représenté par la distribution pondérée des subfields qu’il a traités.
MAE (Mean Absolute Error, erreur absolue moyenne) : moyenne des écarts (en valeur absolue) entre l’uplift prédit et l’uplift réel. Plus elle est basse, mieux c’est ; on la compare à une baseline triviale (prédire la moyenne) pour juger si le modèle apprend.
R² (coefficient de détermination) : part de la variance de l’uplift expliquée par le modèle. 0 = le modèle ne fait pas mieux que prédire la moyenne ; 1 = prédiction parfaite.

Ce que le modèle produit

À chaque exécution, le modèle sert deux jeux de données immuables (Parquet, sous dt=…/run=…) :

marts/pair_uplift_predictions : pour des paires de chercheurs (y compris des paires qui n’ont jamais collaboré — c’est tout l’intérêt), l’uplift prédit.
marts/author_recommendations : pour chaque chercheur, son top-10 de partenaires à fort uplift (la recommandation de thématiques se dérive ensuite du profil du partenaire).

Chaque jeu porte un served_mode qui dit comment il a été produit — c’est le cœur des précautions ci-dessous.

Précaution n°1 — Une personne n’est jamais une variable du modèle

Le principe. Pour l’entraînement, on n’utilise jamais l’identité d’un chercheur (son identifiant). Un chercheur entre dans le modèle uniquement par ses thématiques, via deux familles de features :

le vecteur de subfields (sa distribution pondérée de sous-domaines) — le socle, toujours présent et interprétable ;
l’embedding sémantique (un vecteur de 384 dimensions issu du texte de ses publications, researcher_embeddings) — qui capte une proximité thématique fine, au-delà des catégories. Quand un chercheur n’a pas d’embedding utilisable, cette famille est neutralisée pour la paire (et un indicateur le signale au modèle), sans jamais faire disparaître la paire ni écraser le socle thématique.

Une paire est décrite par la combinaison de ces vecteurs (leur proximité, leur complémentarité), pas par « qui » sont les deux personnes.

Pourquoi. Deux raisons.

Généralisation. Si le modèle apprenait par identité, il ne saurait rien dire d’une paire jamais vue. En apprenant sur les thématiques, il peut prédire l’uplift de deux chercheurs qui n’ont jamais collaboré — l’objectif même du produit.
Protection des personnes. L’identifiant sert de clé de jointure technique, jamais de variable explicative. Le modèle raisonne sur des domaines de recherche, pas sur des individus. Cela limite l’exposition au sens du RGPD (le code permet ce traitement ; il ne décide pas de sa licéité à la place du responsable — l’établissement déployeur).

Les features sont symétriques. Une paire n’est pas orientée : la description de (Alice, Bob) est identique à celle de (Bob, Alice). C’est garanti par construction (cosinus, différence absolue, produit terme à terme — tous symétriques).

Précaution n°2 — Jamais regarder le futur (anti-fuite temporelle)

Le principe. L’uplift compare le FWCI d’une collaboration au FWCI solo habituel de chaque auteur. Ce « solo habituel » est calculé uniquement sur les publications ANTÉRIEURES à la collaboration. On ne laisse jamais une publication postérieure gonfler la baseline — sinon on tricherait en utilisant l’avenir pour expliquer le passé.

Un exemple chiffré (refaisable à la main). Soit une paire avec deux co-publications :

Co-publication	Année	FWCI ensemble	Baseline solo (pubs antérieures seulement)	Uplift
W10	2018	10,0	(1,5 + 4,0) / 2 = 2,75	7,25
W11	2019	6,0	(1,5 + 4,0) / 2 = 2,75	3,25

Uplift moyen de la paire = (7,25 + 3,25) / 2 = 5,25.

Si une publication postérieure très citée (disons un FWCI de 100 en 2020) avait été intégrée à tort dans la baseline, le « solo habituel » exploserait et l’uplift s’effondrerait artificiellement. Le test test_uplift_anti_temporal_leakage vérifie exactement ce scénario : la valeur attendue est 5,25, et la publication future ne doit pas y figurer.

Une paire doit avoir au moins deux co-publications avec une baseline des deux côtés (HAVING count(*) >= 2), sinon elle est écartée — un seul point ne fait pas une tendance.

Précaution n°3 — La validation est honnête (et on le prouve par l’absurde)

C’est la précaution la plus importante, et la plus facile à négliger.

Validation groupée par auteur. Pour mesurer le pouvoir prédictif, on découpe les données de sorte qu’un même chercheur ne soit jamais à la fois dans l’échantillon d’entraînement et de test (technique GroupKFold). Sans cela, un chercheur « vu » à l’entraînement fuiterait via ses autres paires, et le R² serait faussement optimiste.

La preuve par l’absurde (le garde-fou falsifiable). Documenter une vertu ne prouve rien. On la teste à l’envers :

Sur un signal réel (l’uplift dépend vraiment des thématiques), le modèle l’apprend : R² > 0,2 en validation groupée (test_model_learns_thematic_signal).
Sur du bruit pur (un uplift sans aucun lien aux thématiques), le modèle n’apprend rien : R² < 0,05 (test_no_signal_gives_zero_r2).

Ce test négatif est essentiel : il démontre que notre validation ne se laisse pas abuser par un faux signal. Un modèle qui « apprendrait » du bruit serait en sur-apprentissage ; le nôtre, validé groupé, ne le fait pas. C’est ce qui rend la première mesure (R² > 0,2) crédible plutôt que décorative.

La porte de décision — prédictif ou repli descriptif

Un modèle ne mérite d’être servi que s’il a un pouvoir prédictif honnête. À chaque exécution, le pipeline applique une porte de décision :

Pouvoir confirmé (R² honnête > 0,05 et MAE meilleure que la baseline) → on sert les prédictions du modèle, served_mode = "predictive", y compris pour les paires inédites.
Pouvoir insuffisant (R² qui s’effondre, ou trop peu de données) → repli descriptif, served_mode = "descriptive" : on sert l’uplift observé des paires connues, sans rien prédire d’inédit. Mieux vaut une description honnête qu’une prédiction creuse.

Pourquoi le seuil à 0,05 ? Un R² ≤ 0 signifie « pas mieux que prédire la moyenne » ; on veut donc une marge strictement positive et non triviale. 0,05 est un plancher volontairement bas et prudent : on n’exige pas une forte corrélation pour basculer en prédictif, mais on refuse le bruit (le contrôle ci-dessus tombe sous ce seuil). Un seuil plus haut (0,10) rejetterait des modèles faibles mais réels (plus de repli descriptif) ; un seuil nul accepterait un modèle sans valeur. La condition jointe « et bat la baseline en MAE » empêche un R² légèrement positif mais inutile de passer la porte. Ce choix est révisable à la lumière des mesures de production.

Note sur les chiffres. Le seuil 0,05 est la porte de production. Le 0,2 des tests est le seuil d’une fixture synthétique (un signal fort par construction). Le 0,50 cité dans le rapport de reconnaissance est une mesure de spike ponctuelle et optimiste (script hors dépôt, échantillon Le Havre) : un indice de faisabilité, pas une garantie de performance en production. La performance réelle est ce que la porte de décision mesurera, honnêtement, à chaque exécution.

Surveiller la dérive du modèle dans le temps

La porte de décision protège à l’instant t. Mais un modèle peut se dégrader au fil des exécutions — les co-publications évoluent, le périmètre change, les embeddings disponibles varient. Un suivi de dérive (ADR 0068) compare chaque exécution à la précédente sur quatre signaux :

la distribution des uplift prédits (un décalage marqué est détecté par Evidently) ;
la qualité honnête (R², MAE) au fil des runs, suivie dans MLflow ;
la bascule du mode servi (predictive → descriptive) ;
la couverture embedding (part de chercheurs disposant d’un embedding).

Informatif, sauf un cas. Un décalage de distribution, une baisse de qualité ou de couverture sont signalés (visibles dans Dagster, journalisés dans MLflow) mais n’arrêtent pas le pipeline : ils nourrissent la décision de ré-entraîner. En revanche, une bascule predictive → descriptive arrête l’exécution : passer silencieusement de prédictions servies à un repli descriptif est un changement de contrat trop important pour rester inaperçu — un humain doit décider de la suite. C’est une porte de sécurité ciblée, pas une alarme tatillonne.

Le contrat des données servies (qualité bloquante)

Deux contrôles Great Expectations bloquants valident les marts servis avant qu’ils ne soient consommables (un échec fait échouer l’exécution) :

ge_pair_uplift_predictions : clés non nulles, paire canonique (auteur A < auteur B, pas de doublon orienté), served_mode dans le domaine fermé {predictive, descriptive}.
ge_author_recommendations : un chercheur ne se recommande pas lui-même, le rang est ≥ 1, clés non nulles.

Chaque mart est en outre accompagné d’un manifest atomique (sha256, nombre de lignes, sentinelle écrite en dernier) : le consommateur lit le manifest à côté du Parquet pour savoir que l’écriture est complète et intègre.

Les jeux de données utilisés

En entrée :

Snapshot OpenAlex (works + authors) : la source ouverte, d’où viennent FWCI, auteurs, affiliations (institutions.ror) et thématiques (subfields).
Référentiel EUNICoast (seeds/ref_eunicoast.csv, 14 lignes : les 13 établissements membres + 1 alias historique pour l’Université des Antilles). Il sert à filtrer le périmètre par ROR (Research Organization Registry, l’identifiant institutionnel standard).

Produits intermédiaires :

curated_eunicoast_works : les publications avec ≥ 1 auteur EUNICoast et datant de moins de dix ans, portant leur FWCI.
marts_author_profiles : pour chaque chercheur, sa distribution pondérée de subfields (sa représentation thématique). L’identifiant n’y est qu’une clé de jointure.
marts/researcher_vectors : pour chaque chercheur, son embedding sémantique (384 dimensions, L2-normalisé) — la seconde famille de features. Un chercheur sans embedding utilisable (vecteur nul) est simplement traité avec la famille embedding neutralisée.
curated_pair_uplift_labels : la cible d’apprentissage (l’uplift observé par paire), calculée avec l’anti-fuite temporelle décrite plus haut.

Données de test (déterministes). Les tests n’utilisent aucune donnée personnelle réelle : ils s’appuient sur des fixtures synthétiques à graine figée — soit un signal thématique construit de toutes pièces (pour vérifier que le modèle l’apprend), soit du bruit pur (pour vérifier qu’il ne l’apprend pas), soit de petits scénarios SQL contrôlés (pour l’anti-fuite). Cette reproductibilité est une exigence du dépôt.

Récapitulatif des tests

Test	Ce qu’il prouve
`test_pair_features_symmetric`	Une paire n’est pas orientée : f(A,B) = f(B,A).
`test_author_vectors_l2_normalized`	La représentation thématique est normalisée (comparable par cosinus).
`test_model_learns_thematic_signal`	Sur un vrai signal, le modèle l’apprend (R² > 0,2, validation groupée).
`test_no_signal_gives_zero_r2`	Sur du bruit pur, le modèle n’apprend rien (R² < 0,05) — anti-sur-apprentissage.
`test_build_dataset_skips_pairs_without_profile`	Une paire sans profil thématique des deux côtés est écartée.
`test_top_recommendations_per_author_ranked`	Les partenaires sont classés par uplift décroissant, top-N par auteur.
`test_top_recommendations_respects_top_n`	On ne garde que les N meilleurs partenaires.
`test_train_final_predicts`	Le modèle final prédit un uplift par paire.
`test_asset_serves_predictive_on_signal`	Porte de décision : signal réel → mode prédictif, sert toutes les paires.
`test_asset_falls_back_descriptive_on_noise`	Porte de décision : bruit → repli descriptif (paires connues seules).
`test_uplift_anti_temporal_leakage`	L’anti-fuite : une publication future ne gonfle pas la baseline (uplift = 5,25).
`test_pair_needs_two_copubs_with_baseline`	Une paire exige ≥ 2 co-publications avec baseline.
`test_copub_without_prior_solo_dropped`	Une co-publication sans solo antérieur est écartée.
`test_embedding_vectors_l2_normalized_and_skips_null`	L’embedding par auteur est L2-normalisé ; un vecteur nul/absent est écarté.
`test_pair_features_combined_symmetric_and_neutral_when_absent`	Features deux familles symétriques ; embedding neutralisé (+ drapeau) si absent.
`test_combined_features_capture_embedding_signal`	Un signal porté uniquement par l’embedding est appris (validation groupée).
`test_combined_dataset_rejects_noise`	Contrôle négatif avec embedding : le bruit reste à R² < 0,05 (pas de faux signal).
`test_asset_uses_embedding_family_when_available`	L’asset branche l’embedding et expose sa couverture (part d’auteurs concernés).
`test_served_mode_regression_blocks`	Suivi de dérive : une bascule `predictive → descriptive` bloque l’exécution.
`test_distribution_shift_alone_is_informative`	Suivi de dérive : un décalage de distribution seul est informatif (ne bloque pas).
`test_regression_only_on_predictive_to_descriptive`	Seule la bascule vers descriptif est une régression (le rétablissement ne l’est pas).

Ce qui n’est pas (encore) en place

Par honnêteté, ce que le modèle ne fait pas encore, malgré son intérêt :

La recommandation de thématiques explicites (au-delà des partenaires) est dérivable du profil des partenaires recommandés, mais n’est pas un livrable distinct à ce stade.

Ces points sont des perspectives, pas des promesses tenues — la distinction est faite ici pour ne pas laisser croire à un appui qui n’existe pas dans le code.