GenerativSchool
Et si… · Dossier 003 · PAH / PKU

Reproduire et comprendre le prototype PAH

Installation hors réseau, audit, modèles, comparaison et restauration : reproduire le framework PAH 1.0.1 étape par étape.

Par Soufiane Lemqari ·

Prototype · calculs exécutés

Soufiane Lemqari — paquet generativschool-pku-public 1.0.1

Ce parcours accompagne le dossier français. Il reproduit des calculs sur des moyennes publiées, puis exporte une conception de collecte non exécutée. Il ne réalise aucun essai biologique. Les preuves techniques de la version 1.0.1 conservent les commandes et sorties du paquet source, avec leurs chemins temporaires anonymisés.

La distribution sélectionnée a également été extraite dans un dossier neuf pour vérifier les neuf commandes unitaires ci-dessous : version 1.0.1, 68 comparaisons numériques, écart maximal nul et rapport restauré identique. Ce contrôle informatique ne constitue pas une validation biologique.

1. Préparer le paquet et choisir le parcours

Téléchargez l’archive autonome 1.0.1, comparez son SHA-256 au fichier d’empreinte, puis extrayez-la et placez-vous dans le dossier pku-v1.0.1/. Il contient README.md, scripts/verify.py, src/pku_public/, les tests et une roue Python déjà construite dans evidence/. Le dépôt GitHub permet aussi d’inspecter les fichiers et leurs notices.

Python 3.9 ou ultérieur est requis par le projet. L’environnement réellement vérifié est Python 3.9.6 sur macOS 26.2 arm64. Linux n’est pas vérifié dans cette livraison ; Windows n’est pas pris en charge par la mesure de ressources utilisée. L’exécution du paquet ne demande pas de bibliothèque externe, de GPU, de poids IA ou de service cloud.

Deux parcours sont possibles. Pour reconstruire et contrôler toute la chaîne, utilisez une destination inexistante :

python3 scripts/verify.py --out /tmp/pku-public-proof

Python, setuptools ≥58 et wheel ≥0.37 doivent déjà être disponibles pour cette construction. Le script travaille hors index, crée un environnement neuf sans paquets système et utilise la bibliothèque installée depuis un répertoire extérieur aux sources. Il conserve les commandes, sorties, durées et résultats. L’essai négatif qui altère volontairement les données doit échouer avec le code 2 ; ce rejet est attendu.

Pour comprendre chaque étape, suivez plutôt le parcours unitaire ci-dessous, qui utilise la roue déjà construite. Ne réutilisez pas une destination d’une tentative précédente : le programme refuse l’écrasement. Après une interruption, inspectez et renommez le dossier partiel avant de reprendre avec une nouvelle destination. Ces commandes n’installent rien depuis Internet.

2. Installer la version livrée

Depuis la racine pku-v1.0.1/ :

python3 -m venv /tmp/pku-env
/tmp/pku-env/bin/python -m pip install --no-index --no-deps evidence/generativschool_pku_public-1.0.1-py3-none-any.whl
/tmp/pku-env/bin/python -c 'import pku_public; print(pku_public.__version__)'

La version affichée doit être 1.0.1. La roue inclut le code, les données, les sources et les références numériques : elle ne lit pas un ancien dossier privé de recherche. Le contrôle complet vérifie aussi que le module importé vient de l’environnement installé.

3. Admettre les données, puis examiner l’audit

/tmp/pku-env/bin/pku-public ingest --out /tmp/pku-inputs
/tmp/pku-env/bin/pku-public audit --bundle /tmp/pku-inputs --out /tmp/pku-audit.json

ingest copie le lot admis. Il ne constitue pas une API d’import générique : cette version est verrouillée à D01. audit contrôle les empreintes, la source, les droits et la cohérence des observations avec l’extraction du XML. Les deux commandes doivent annoncer status: ok, observations: 14, variants: 7.

Dans /tmp/pku-inputs, examinez data/activity_pairs.csv, data/assay-context.json, sources/PMC6628251.xml, NOTICE.md, lock.json et admission.json. Le fichier /tmp/pku-audit.json conserve le résultat du nouvel audit. Les clés de variant et de contexte empêchent de confondre des conditions incompatibles. Le CSV distingue activité, écart-type et proportion de tétramères ; les champs vides restent inconnus.

Pour Ala342Pro, la ligne sans GroEL/ES porte une valeur 0 avec not_detected_LOD_unreported. Elle signifie non détecté, limite de détection non rapportée. Le contexte conserve l’ambiguïté de normalisation WT et la sélection des fractions de purification. Lire seulement la colonne value ferait perdre ces limites. Le calcul utilise néanmoins le zéro publié comme valeur numérique, sans modèle de censure : l’activité réelle sous le seuil de détection reste inconnue. Cette convention affecte la différence calculée et la covariable témoin utilisée par la ridge.

Un audit ne valide pas la conclusion biologique de l’article source. Il établit que le paquet respecte le contrat informatique déclaré. En cas de rejet, lisez la première cause bloquante ; n’effacez pas le verrou pour faire accepter un autre jeu de données.

4. Évaluer les trois modèles

/tmp/pku-env/bin/pku-public evaluate --bundle /tmp/pku-inputs --out /tmp/pku-run

L’évaluation réaudite les entrées. Elle calcule les paires et les sept plis d’exclusion de variant pour chacun des deux scénarios. La cible est delta_pp, l’activité avec intervention moins l’activité témoin, en points WT. Le rapport garde aussi les activités absolues.

Ouvrez /tmp/pku-run/report.json dans un lecteur JSON. Les éléments à examiner sont :

ChampLecture utile
statusCalcul exécuté, sans validation biologique.
validationleave_one_variant_out : un variant entier réservé par pli.
scenariostable3 et section3.3_Ile406Met, conflit conservé.
pairsSept paires, activités, différences, SD et conflits.
predictionsPrédictions de chaque modèle pour le variant réservé.
train_variantsLes six variants autorisés pour ajuster ce pli.
parametersMoyennes d’apprentissage, pente, intercept, α et échelle.
metricsMAE et RMSE en points WT ; la RMSE accorde plus de poids aux grandes erreurs.
selected_model / calibrated_intervalsnull : aucun modèle sélectionné, aucun intervalle calibré.

Le rapport livré permet une lecture concrète. Dans le scénario table3, pour Ala342Pro réservé, la différence observée vaut 9,9 points. Les prédictions valent 0 pour zéro effet, environ −0,116667 pour la moyenne d’apprentissage et 0,052852 pour la ridge. Les six variants d’apprentissage n’incluent pas Ala342Pro. La moyenne des différences d’apprentissage est −0,116667, la pente ridge environ −0,371888 et son intercept 0,052852. L’activité témoin d’Ala342Pro étant codée 0, la prédiction ridge est ici égale à l’intercept.

Cela montre pourquoi la fiche Ala342Pro n’est pas une découverte du modèle : son contraste vient de la publication et n’est pas anticipé correctement par ces modèles dans ce pli. Une prédiction négative exprime une différence attendue, pas une activité absolue négative ; le programme la conserve.

La ridge utilise x = activité témoin / 100. Pour les six exemples d’apprentissage, sa pente est Σ(x−moyenne(x))(y−moyenne(y)) / (Σ(x−moyenne(x))² + 1). L’intercept n’est pas pénalisé. Le 1 est α, fixé avant calcul ; aucune optimisation de paramètres n’a été menée sur ces sept plis. Les moyennes sont calculées uniquement sur l’apprentissage. Modèles du paquet.

Pour table3, les MAE doivent être 4,942857 / 5,823810 / 6,732753 points WT, dans l’ordre zéro effet / moyenne / ridge. Pour le scénario du texte, elles doivent être 5,128571 / 5,947619 / 6,890344. La ridge ne dépasse aucune des deux références. Les SD sont conservées, mais la covariance et les mesures brutes manquent : delta_uncertainty reste null.

5. Comparer au pilote et comprendre ce contrôle

/tmp/pku-env/bin/pku-public compare --run /tmp/pku-run --out /tmp/pku-comparison.json

La sortie livrée annonce status: passed, numeric_comparisons: 68, max_abs_error: 0.0, tolerance: 1e-10. C’est un contrôle de concordance numérique avec le pilote de référence. Il ne compare pas les prédictions à de nouvelles données expérimentales indépendantes. Le verrou de comparaison provient du paquet installé, pas d’un fichier candidat librement remplaçable.

6. Exporter la question de collecte

/tmp/pku-env/bin/pku-public export --run /tmp/pku-run --out /tmp/pku-hypothesis.json

La fiche porte le statut design_only_not_executed. Elle rassemble l’observation Ala342Pro, l’hypothèse de reproductibilité dans le même système, les contrôles envisagés, les données à conserver et les critères d’échec. Elle propose notamment de renseigner les limites de détection, le dénominateur WT et les fractions purifiées. Les paramètres d’une future expérience doivent être définis par l’équipe scientifique compétente. La commande n’exécute pas cette expérience et ne classe pas des traitements.

7. Restaurer l’exécution

/tmp/pku-env/bin/pku-public restore --run /tmp/pku-run --out /tmp/pku-restored

restore vérifie l’intégrité et le code, copie les éléments puis recalcule le rapport. La preuve livrée annonce report_identical: true. manifest.json conserve les empreintes ; runtime.json sépare les mesures de ressources et les éléments variables du rapport déterministe. Deux exécutions peuvent produire le même rapport avec des durées différentes.

Les empreintes SHA-256 détectent une dérive accidentelle. Elles ne sont pas signées : une personne qui modifierait simultanément le code et les verrous pourrait contourner cette protection. Il s’agit d’une limite du mécanisme d’intégrité, pas d’une validation de provenance par un tiers.

Le journal du lot technique montre 17 tests réussis et 12 commandes avec leurs codes attendus, dont le rejet volontaire. Ces preuves concernent l’exécution informatique. Le coût total, incluant le travail de préparation, les agents, la machine et l’énergie, reste inconnu ; les durées d’un petit calcul ne mesurent pas une économie de recherche.

8. Étendre à une étude nouvelle : un travail de contrat

Cette étape est une démarche future, pas une commande déjà disponible. Le guide technique d’extension impose une nouvelle version de contrat et un adaptateur spécifique relu. La préparation peut se décomposer ainsi :

  1. Archiver la source primaire, sa version, son localisateur et les droits de chaque fichier. Conserver les transformations et l’attribution. Une source accessible gratuitement n’est pas automatiquement redistribuable.
  2. Décrire chaque contexte : système, construction, intervention, méthode, référence WT, fraction et objet mesuré. Vérifier la référence protéique et le transcript. Rechercher les observations recopiées entre études.
  3. Définir les observations et les paires admissibles. Séparer zéro, non-détection et inconnu ; conserver les mesures brutes si disponibles. Ne pas mélanger abondance, activité et classes cliniques. Toute conversion d’unité doit être explicite et testée.
  4. Développer l’adaptateur et ses tests sur la nouvelle source : extraction, unités, doublons, paires incomplètes, conflits, droits et intégrité. Figer le contrat après relecture, sans remplacer silencieusement le verrou D01.
  5. Évaluer d’abord cette étude séparément. Un regroupement futur doit exclure le variant entier dans tous les contextes et prévoir une étude externe. Les paramètres et le choix des modèles ne doivent pas exploiter les cibles de test.
  6. Produire des résultats de référence inspectables, vérifier l’installation en environnement neuf et conserver l’archive pour la revue du paquet figé.

La prochaine version utile dépendra ainsi de la qualité de la comparaison ajoutée. Un CSV supplémentaire augmente le nombre de lignes ; seules des mesures documentées et un protocole d’évaluation adapté peuvent augmenter ce que l’on est en droit de conclure.