De V2.3 à V2.4 : enrichissement des corpus Ames et hERG, architecture tri-modèle sélective, et les leçons méthodologiques d'un cycle d'amélioration contrôlé
ToxTwin V2.3 couvre 14 endpoints toxicologiques — 12 Tox21, Ames mutagénicité, hERG inhibition — via un pipeline GNN end-to-end validé en 5-fold scaffold CV strict. Le router V2.3 sélectionnait, par endpoint, le meilleur entre deux modèles : un GINEConv fine-tuné (V2.0a) et un ensemble multi-représentation GINEConv + AttentiveFP + Morgan ECFP6 (V2.2). Les métriques V2.3 établissaient Tox21 mean AUC à 0.867, Ames à 0.843, hERG à 0.785. Douze endpoints sur quatorze atteignaient leur seuil cible. Les deux manquants — Ames (−0.027 sous cible) et hERG (−0.045) — posaient une question précise : le levier est-il l’architecture ou les données ?
L’AID 1259411 de PubChem, étiqueté « Ames » dans plusieurs méta-analyses, est en réalité un assay de carcinogénicité in vivo multi-espèces. Ses labels ne corrèlent que partiellement avec la mutagénicité bactérienne au sens ICH S2R1. L’intégration naïve de ces 547 composés dans le fine-tuning multi-tâche a produit une régression sur tous les endpoints : de 0.769 à 0.698 en V2.0a sur Ames.
La leçon est simple dans son énoncé, coûteuse dans ses conséquences : un composé « Ames positif » dans un assay carcinogénicité in vivo et un composé Ames positif au sens ICH S2R1 (Salmonella reverse mutation, TA98/TA100 ± S9) ne portent pas la même information. Les confondre injecte du bruit, pas du signal.
Corpus Ames — ISS comme source primaire réglementaire. Le dataset de l’Istituto Superiore di Sanità, distribué via Mendeley Data, présente trois propriétés décisives : labels par souche bactérienne (TA98, TA100, TA102, TA1535, TA1537), curation multi-étapes documentée, et harmonisation selon la convention ICH S2R1 (positif si au moins une souche positive). Après sanitization RDKit et déduplication InChIKey contre le corpus Hansen existant, 1 511 composés nouveaux ont été intégrés, avec un ratio positifs/négatifs quasi-équilibré (1.1:1).
Corpus hERG — ChEMBL v34. La cible CHEMBL240 (KCNH2) agrège 22 273 activités IC50/Ki. Après filtrage nM, binarisation au seuil 10 µM, sanitization et déduplication, 6 485 composés nouveaux ont été intégrés. Effet collatéral bénéfique : le corpus hERG passe d’un déséquilibre 65/35 à un ratio 48.5/51.5, rééquilibrage qui améliore directement la calibration du modèle.
L’hypothèse testée était la suivante : le canal hERG étant pharmacologiquement sensible à la forme 3D du ligand dans son vestibule, l’ajout de descripteurs conformationnels (NPR, USR, USRCAT, 79 dimensions) devrait améliorer la prédiction. Les résultats sur 5-fold scaffold CV invalident l’hypothèse.
| Configuration | Ames AUC | hERG AUC |
|---|---|---|
| Morgan ECFP6 seul | 0.841 | 0.750 |
| 3D seul | 0.763 | 0.679 |
| Morgan + 3D | 0.842 | 0.764 |
Le gain marginal sur hERG (+0.014) et nul sur Ames (+0.001) indique que le GNN et les fingerprints topologiques capturent déjà l’essentiel de l’information structurale exploitable à cette échelle de corpus. Le plafond de performance actuel est un plafond de couverture chimique, pas de capacité représentationnelle.
La découverte opérationnelle de V2.4 est que les données Ames ISS et les données hERG ChEMBL ne bénéficient pas au même modèle d’ensemble. Un ensemble entraîné sur le corpus Ames enrichi (V2.4b) produit le meilleur score Ames mais un score hERG inférieur. Un ensemble entraîné sur le corpus hERG enrichi (V2.4d) produit l’inverse. La solution est structurelle, pas paramétrique : un tri-routeur qui sélectionne, pour chaque endpoint, le modèle optimal parmi trois — V2.0a (GINEConv multi-tâche), V2.4b (ensemble optimisé Ames), V2.4d (ensemble optimisé hERG).
Table de routage V2.4 : V2.4b sert 10 endpoints (NR-AR-LBD, NR-AhR, NR-ER, NR-ER-LBD, NR-PPAR-γ, SR-ARE, SR-HSE, SR-MMP, SR-p53, Ames) ; V2.4d sert 4 endpoints (NR-AR, NR-Aromatase, SR-ATAD5, hERG). L’encodeur V2.0a reste disponible en fallback mais n’est sélectionné par aucun endpoint dans le routing optimal.
| Métrique | V2.3 | V2.4 | Delta |
|---|---|---|---|
| Tox21 mean AUC | 0.867 | 0.898 | +0.031 |
| Ames AUC | 0.843 | 0.853 | +0.010 |
| hERG AUC | 0.785 | 0.800 | +0.015 |
| Cibles atteintes | 12/14 | 12/14 | = |
Protocole inchangé : 5-fold scaffold CV strict Bemis-Murcko, vérification InChIKey train ∩ val = ∅, holdout gelé non utilisé pour la sélection. Les deux endpoints manquants restent Ames (0.853 vs cible 0.87, gap −0.017) et hERG (0.800 vs cible 0.83, gap −0.030). Les gaps se sont réduits de 37 % (Ames) et 33 % (hERG) par rapport à V2.3.
Un modèle unique est un compromis, pas un optimum. Le fine-tuning multi-tâche produit un encodeur généraliste, mais la spécialisation par endpoint — données spécifiques, tête spécifique, sélection par routeur — surpasse systématiquement l’encodeur partagé. Le tri-routeur ne choisit pas le « meilleur modèle » mais le meilleur modèle pour cette tâche.
Les données battent l’architecture, mais pas n’importe quelles données. L’injection de données mal étiquetées dégrade les performances même si le volume augmente. La curation — vérification de la source primaire, harmonisation des labels selon les conventions réglementaires, contrôle du ratio positifs/négatifs — est le travail qui produit le gain, pas le téléchargement.
Les features supplémentaires ne compensent pas les données manquantes. Les descripteurs 3D, malgré leur justification pharmacologique, n’apportent qu’un gain marginal quand le modèle topologique est déjà correctement entraîné.
Le tri-routeur introduit une complexité opérationnelle : trois modèles chargés en mémoire GPU au lieu de deux, et une table de routage qui devra être revalidée à chaque évolution des données. La sélection par endpoint repose sur un val set unique par fold — la variance de sélection n’est pas quantifiée. Les métriques V2.4 ne sont pas directement comparables aux métriques V2.3 pour les endpoints dont le corpus a changé (Ames, hERG), bien que le protocole de validation reste identique. Le holdout gelé n’a pas été utilisé : il reste disponible pour une validation finale pré-déploiement.
L’API REST V2.4 expose le tri-routeur via les mêmes endpoints que V2.3. Aucune modification côté client n’est nécessaire — le champ routing dans la réponse API indique désormais V2.4b ou V2.4d au lieu de V2.0a ou V2.2.