Conception de binders protéiques BindCraft2 : comment générer et scorer des binders spécifiques d’une cible ?

Concevoir un binder protéique qui reconnaît une cible avec une haute affinité et une haute spécificité est un besoin central en biologie et en médecine, et y parvenir à partir d’une structure cible seule, sans longues séries d’optimisation expérimentale, supprimerait un goulot d’étranglement majeur. Identifier des candidats de haute affinité reste un goulot d’étranglement car la conception de binders nécessite typiquement de générer et de cribler virtuellement des milliers de conceptions pour récupérer quelques hits prometteurs [5]. Cela signifie que tout pipeline capable d’augmenter la fraction de conceptions générées par ordinateur qui se révèlent capables de se lier en laboratoire humide a une valeur pratique directe : moins de conceptions doivent être synthétisées et testées, ce qui économise du temps et le coût des réactifs.

Deux familles d’approches computationnelles traitent ce problème. Les approches fondées sur la structure, comme RFDiffusion et AlphaProteo, peuvent générer des backbones de binders conditionnés par une structure cible [5]. Une famille distincte, les méthodes fondées sur l’hallucination, optimise une structure directement à l’intérieur d’un réseau de prédiction de structure plutôt que d’échantillonner à partir d’un modèle génératif de backbone. BindCraft est une méthode de conception de binders fondée sur l’hallucination qui exploite le réseau AlphaFold2 [5]. Cette distinction compte pour un constructeur car elle détermine quels logiciels et quels poids sont nécessaires : une méthode d’hallucination a besoin d’un prédicteur de structure différentiable et d’une boucle d’optimisation par gradient, tandis qu’une méthode de diffusion de backbone a besoin d’un modèle de diffusion entraîné plus une étape distincte de conception de séquence.

La question de savoir à quel point ces binders sont réellement bons une fois synthétisés est distincte du fonctionnement du pipeline, et les preuves sur ce point sont inégales selon les articles. BindCraft a rapporté des taux de succès expérimentaux allant de 10% à 100% [7], une fourchette large qui dépend fortement de la classe de cible. Les scores de confiance des modèles de prédiction de structure, en particulier l’ipTM (interface pTM), corrèlent avec la force de liaison [5], mais la corrélation de métriques de confiance telles que pLDDT, ipTM et ipAE avec les résultats expérimentaux de liaison n’a été validée que sur des jeux de données limités et reste mal comprise selon les cibles et les régimes de conception [6]. Un constructeur ne doit donc pas traiter un nombre de confiance isolé comme une preuve de liaison, seulement comme un filtre qui a montré une certaine corrélation dans certains contextes.

En raison de cet écart entre confiance in silico et résultat en laboratoire humide, les efforts de benchmarking et les améliorations de fonctions de score sont devenus des domaines de travail actifs aux côtés des pipelines génératifs eux-mêmes. BindEnergyCraft a été construit spécifiquement pour fournir un signal d’optimisation plus dense et plus informatif que l’ipTM [5], et ProtDBench a été construit pour fournir un protocole d’évaluation standardisé multi-vérificateurs afin de comparer des binders générés [6]. Ensemble, ces deux fils, de meilleurs objectifs d’optimisation et de meilleurs benchmarks, sont ce qu’un développeur doit comprendre avant de décider quel pipeline et quelle fonction de score adopter pour une cible donnée.

BindCraft est un pipeline open source et automatisé pour la conception de binders protéiques de novo [7]. Il exploite les poids d’AlphaFold2 pour générer des binders protéiques à partir de structures cibles [7]. Cela signifie que l’utilisateur n’entraîne pas un nouveau modèle : à la place, le pipeline exécute une procédure d’optimisation à l’intérieur du graphe de calcul existant d’AlphaFold2, en traitant des parties de l’entrée (la séquence ou la structure du binder) comme variables libres et tout le reste (la structure cible) comme fixe.

Le pipeline a été appliqué largement. BindCraft a été appliqué à des récepteurs de surface cellulaire, des allergènes courants, des protéines conçues de novo et des nucléases multi-domaines telles que CRISPR-Cas9 [7]. Dans plusieurs de ces applications, les binders conçus ont montré des effets fonctionnels au-delà de la simple liaison. Des binders conçus ont été rapportés comme réduisant la liaison des IgE à l’allergène du bouleau, modulant l’activité d’édition génique de Cas9, réduisant la cytotoxicité d’une entérotoxine bactérienne d’origine alimentaire et redirigeant les capsides de virus adéno-associés pour une délivrance génique ciblée [7]. Dans une démonstration, BindCraft a généré des binders d’affinité nanomolaire sans criblage à haut débit ni optimisation expérimentale, y compris pour des cibles sans site de liaison connu [7].

Des groupes indépendants ont depuis stress-testé BindCraft sur des classes de cibles spécifiques pour voir dans quelle mesure ces affirmations tiennent en dehors de l’article original. Pour MDM2, BindCraft a généré 70 peptides uniques, 15 ont été synthétisés, et 7 ont montré une liaison spécifique avec des affinités nanomolaires [12]. Des tests de compétition ont confirmé la liaison site-spécifique des peptides MDM2 au site cible prévu [12], ce qui est une vérification importante car une liaison non site-spécifique ne serait pas utile pour la plupart des applications. Pour WDR5, six des neuf candidats se sont liés au site WBM de liaison à MYC avec une affinité submicromolaire [12], et une modification chimique rationnelle a amélioré la puissance d’un binder WDR5 d’un facteur six, jusqu’à un KD de 39 nM [12]. Cela montre que les sorties de BindCraft peuvent servir de point de départ pour une optimisation ultérieure de chimie médicinale, pas seulement de réponse finale. Cependant, aucun des peptides générés par BindCraft testés pour PD-1 et PD-L1 n’a montré de liaison détectable [12], ce qui est un contre-exemple direct montrant que le succès dépend de la cible et n’est pas garanti. BindCraft peut générer des peptides de haute affinité uniquement à partir d’une structure cible [12], mais le résultat PD-1/PD-L1 montre que cette capacité ne se transfère pas uniformément à toutes les cibles.

À plus grande échelle, le Human Bindome intègre la méthode BindCraft testée expérimentalement dans un cadre accéléré et parallélisé avec sélection automatisée de cibles au niveau du domaine [13]. En utilisant ce cadre, 306,146 candidats binders ont été générés pour 8,296 protéines humaines, couvrant 40.9% du protéome complet [13]. Chaque candidat du Human Bindome comprend une séquence définie, un modèle de structure binder-cible prédit et des métriques de confiance in silico [13], ce qui donne à un constructeur un modèle de ce qu’un enregistrement candidat doit contenir lors de l’exécution d’un pipeline à grande échelle.

BindCraft hallucine des structures de binders avec AlphaFold2 et effectue une optimisation par gradient de l’interface predicted TM-score (ipTM), entre autres pertes [5]. En pratique, cela signifie que la séquence du binder (et implicitement sa structure, telle que prédite par AlphaFold2) est mise à jour itérativement par descente de gradient afin d’augmenter le score ipTM qu’AlphaFold2 attribue au complexe binder-cible prédit, aux côtés d’autres termes de perte. Il s’agit d’un mécanisme fondamentalement différent de celui d’un modèle de diffusion qui échantillonne un backbone puis conçoit une séquence pour celui-ci : ici, le réseau de prédiction de structure agit lui-même comme la fonction objectif optimisée.

Le choix de l’ipTM comme cible principale d’optimisation présente une faiblesse connue. L’ipTM ne reflète pas directement la vraisemblance statistique de l’interaction complète binder-cible [5]. Cela importe car le but de la conception de binders est de trouver des séquences susceptibles de se replier réellement en un complexe stable et correctement docké, et un score qui ne suit pas cette vraisemblance peut pousser l’optimiseur vers des structures qui paraissent confiantes au score mais ne sont pas nécessairement des complexes physiquement favorables.

La raison mécanistique précise de cette faiblesse réside dans la manière dont l’ipTM est calculé. Parce que l’ipTM calcule un maximum sur les indices de résidus de la cible, il produit des gradients épars concentrés sur seulement un petit sous-ensemble de paires de résidus d’interface [5]. Dans une optimisation par gradient, un gradient épars signifie que seules quelques positions de la structure reçoivent un signal de mise à jour significatif à chaque étape, tandis que la majorité de l’interface n’est pas directement façonnée par l’objectif. Cela peut conduire à des conceptions qui satisfont le score sur quelques paires de résidus sans que le reste de l’interface soit bien formé, ce qui est une raison plausible des clashes structuraux ou de la mauvaise qualité globale du complexe dans les conceptions générées.

Ce diagnostic mécanistique, explicité dans l’article BindEnergyCraft, a motivé la recherche d’une fonction de score alternative donnant un signal de gradient plus dense sur toute l’interface plutôt qu’un signal épars. Le reste du cadre d’optimisation, la boucle d’hallucination fondée sur AlphaFront2 et le concept général de mises à jour de structure et de séquence par gradient, est conservé ; seul le score d’interface optimisé doit changer.

pTMEnergy réinterprète les logits d’erreur d’alignement prédite (pAE) d’AlphaFold comme un modèle fondé sur l’énergie sur les complexes binder-cible [5]. Plutôt que de prendre un résumé scalaire unique (comme le fait l’ipTM, via une opération de maximum sur les paires de résidus), pTMEnergy traite la distribution complète des logits pAE comme définissant un paysage énergétique, donnant un score qui, en principe, puise des informations dans toute l’interface prédite plutôt que dans un petit sous-ensemble de celle-ci.

pTMEnergy fournit un signal dense et différentiable destiné à refléter la vraisemblance d’un complexe replié sous la distribution apprise d’AlphaFold [5]. Parce qu’il est différentiable, il peut être substitué directement dans la même boucle d’optimisation par gradient que celle déjà utilisée par BindCraft, sans nécessiter un autre type d’optimiseur. Cela cible directement la faiblesse des gradients épars décrite ci-dessus : un signal dense signifie que davantage de paires de résidus d’interface contribuent à un gradient significatif à chaque étape d’optimisation, contrairement au calcul d’ipTM fondé sur un maximum.

Un détail d’implémentation clé pour un constructeur est que pTMEnergy est dérivé des mêmes sorties pAE que celles utilisées pour calculer l’ipTM et ne nécessite aucun appel de modèle supplémentaire ni modification d’architecture [5]. Cela signifie qu’adopter pTMEnergy ne nécessite pas de réentraîner AlphaFold2 ni d’ajouter de nouveaux composants réseau : les logits pAE qu’AlphaFold2 produit déjà sont simplement traités différemment pour produire le nouveau score. C’est un point pratique important car cela maintient le coût de calcul du pipeline modifié essentiellement identique à celui du pipeline BindCraft original, puisqu’aucune passe avant ou arrière supplémentaire dans un modèle différent n’est nécessaire.

La méthode résultante, BindEnergyCraft, qui conserve le cadre d’optimisation de BindCraft tout en remplaçant l’ipTM par pTMEnergy, a atteint des taux de succès in silico de binders plus élevés et réduit les clashes structuraux par rapport à BindCraft, RFDiffusion et ESM3 sur de multiples cibles difficiles [5]. Il s’agit d’une comparaison in silico, évaluée sur les cibles difficiles utilisées dans le benchmark de cet article ; les affirmations sources ne rapportent pas de comparaison directe en laboratoire humide entre BindEnergyCraft et BindCraft, RFDiffusion ou ESM3 sur les mêmes candidats synthétisés, donc un constructeur doit lire l’amélioration comme une conclusion computationnelle au niveau du benchmark plutôt que comme un avantage expérimental confirmé sur ces alternatives spécifiques.

Parce que les scores de confiance des modèles de prédiction de structure sont connus pour être des proxys imparfaits de la liaison réelle, et parce que leur fiabilité est mal caractérisée selon les cibles, un benchmark standardisé pour comparer les méthodes de conception de binders et les fonctions de score est nécessaire. ProtDBench est un tel benchmark, construit spécifiquement pour évaluer les backbones de binders générés de manière reproductible et multi-vérificateurs.

ProtDBench évalue les backbones de binders générés en échantillonnant plusieurs séquences pour chaque backbone, en appliquant un vérificateur et un filtre à chaque séquence, et en calculant le taux de succès par séquence [6]. Cette procédure sépare deux étapes de conception souvent confondues : l’étape de génération du backbone (qui fixe le repliement) et l’étape de conception de séquence (qui fixe les identités réelles des acides aminés enfilés sur ce repliement). En échantillonnant plusieurs séquences par backbone, le benchmark peut distinguer les backbones pour lesquels il est facile de concevoir de bonnes séquences de ceux qui ne réussissent qu’occasionnellement.

ProtDBench définit l’ensemble des backbones passants comme les backbones pour lesquels au moins une séquence échantillonnée passe le filtre [6]. Il s’agit d’un critère indulgent de type meilleur-de-plusieurs au niveau du backbone : un backbone compte comme un succès s’il a produit au moins une bonne séquence, même si la plupart des séquences échantillonnées pour lui ont échoué. ProtDBench regroupe uniquement les backbones passants par similarité structurale à l’aide de FoldSeek ou TM-score [6], ce qui permet au benchmark de rapporter non seulement un nombre brut de succès mais aussi la diversité structurale des conceptions réussies, en évitant le cas où tous les succès rapportés sont des quasi-doublons du même repliement.

Une conclusion centrale de ce travail de benchmark est une mise en garde contre la confiance excessive accordée à un seul vérificateur. ProtDBench rapporte un biais substantiel dépendant du vérificateur et un accord limité entre les modèles de prédiction de structure utilisés comme vérificateurs d’évaluation [6]. Cela renforce directement le point précédent selon lequel l’ipTM et les métriques de confiance associées n’ont une corrélation validée avec la liaison réelle que sur des jeux de données limités [6] : si différents modèles de prédiction de structure utilisés comme vérificateurs divergent substantiellement entre eux, alors un taux de succès calculé avec un vérificateur (par exemple l’ipTM fondé sur AlphaFold2) ne peut pas être supposé tenir lorsqu’un autre vérificateur (par exemple AlphaFold3) est utilisé à la place. Pour un constructeur, cela signifie que rapporter des résultats d’un seul vérificateur sans divulguer lequel a été utilisé, ou sans les recouper avec un second vérificateur, risque de surestimer la confiance dans une conception.

Tous les pipelines de conception de binders ne sont pas fondés sur l’hallucination. Un workflow distinct, fondé sur la structure, illustre à la fois la promesse et la difficulté pratique de passer d’une conception computationnelle à un binder validé. Un workflow de conception de binders guidé par hotspot intégrait RFdiffusion, ProteinMPNN, AlphaFold, des simulations de dynamique moléculaire et une évaluation structurale manuelle [3]. Ce workflow combine une étape de diffusion de backbone (RFdiffusion), une étape de conception de séquence (ProteinMPNN), une vérification de confiance structurale (AlphaFold), une étape de simulation physique (dynamique moléculaire) et une revue humaine, ce qui est un pipeline plus lourd et plus supervisé manuellement que la boucle automatisée à réseau unique de BindCraft.

Le workflow guidé par hotspot a généré quatre conceptions protéiques qui ont été soumises à validation expérimentale [3]. C’est un petit nombre de conceptions par rapport au

Les pipelines de conception de binders s’appuient de plus en plus sur les modèles de langage protéiques (pLMs) comme outil complémentaire ou alternatif de génération de séquences. Les modèles de langage protéiques (pLMs) sont pré-entraînés sur des données de séquences évolutives à grande échelle et adaptent de grands modèles de langage aux séquences biologiques [17]. Il s’agit d’un mécanisme distinct de l’hallucination fondée sur AlphaFold2 ou de la génération de backbone fondée sur RFdiffusion : un pLM apprend des motifs directement à partir de grandes bases de données de séquences plutôt que de données d’entraînement structurales, et il est généralement utilisé pour proposer ou scorer des séquences plutôt que des coordonnées 3D.

Plusieurs architectures spécifiques existent dans cette famille, et un constructeur qui les choisit doit connaître leurs différences structurelles. ESM2 est un modèle transformer encodeur de style BERT, tandis que ProtGPT2 et ProGen2 sont des modèles transformer décodeur de style GPT et ProtT5 est un modèle transformer encodeur-décodeur [17]. Un modèle encodeur seul comme ESM2 est typiquement utilisé pour scorer ou encoder une séquence existante, un modèle décodeur seul comme ProtGPT2 ou ProGen2 est typiquement utilisé pour générer de nouvelles séquences de manière autorégressive, et un modèle encodeur-décodeur comme ProtT5 peut être utilisé pour des tâches qui transforment une représentation de séquence en une autre. Aucune des affirmations citées ne décrit des pLMs substitués directement dans la boucle d’optimisation de BindCraft ou de BindEnergyCraft, donc un constructeur doit traiter la génération de séquences fondée sur les pLMs comme un outil séparé et complémentaire pour proposer ou filtrer des séquences candidates, et non comme un remplacement documenté et directement interchangeable de l’hallucination fondée sur AlphaFold2 dans ces pipelines spécifiques.

La limitation centrale pour quiconque construit sur cette littérature est que les scores de confiance ne sont pas une preuve de liaison. La corrélation de métriques de confiance telles que pLDDT, ipTM et ipAE avec les résultats expérimentaux de liaison n’a été validée que sur des jeux de données limités et reste mal comprise selon les cibles et les régimes de conception [6]. Cela signifie qu’un score élevé d’ipTM ou de pTMEnergy doit être lu comme un filtre qui augmente la probabilité de trouver un hit, et non comme une garantie, et que tout taux de succès rapporté est lié à la classe de cible et au jeu de données spécifiques sur lesquels il a été mesuré.

L’ipTM lui-même porte une faiblesse mécanistique connue. L’ipTM ne reflète pas directement la vraisemblance statistique de l’interaction complète binder-cible [5], et parce qu’il calcule un maximum sur les indices de résidus de la cible, il produit des gradients épars concentrés sur seulement un petit sous-ensemble de paires de résidus d’interface [5]. C’est une raison mécanistique précise de préférer pTMEnergy comme objectif d’optimisation lors de la reproduction de pipelines de style BindCraft, bien que la comparaison entre BindEnergyCraft et BindCraft sur de vraies cibles en laboratoire humide n’ait pas été rapportée dans les affirmations citées, seulement la comparaison in silico sur des cibles de benchmark [5].

Des choix différents de benchmark et de vérificateur compliquent aussi toute comparaison entre articles. ProtDBench rapporte un biais substantiel dépendant du vérificateur et un accord limité entre les modèles de prédiction de structure utilisés comme vérificateurs d’évaluation [6], donc les taux de succès calculés avec différents vérificateurs, ou rapportés par différents articles utilisant différents pipelines, ne peuvent pas être directement comparés sans savoir quel vérificateur a été utilisé. De même, les résultats sur des classes de cibles spécifiques ne sont pas uniformes : la même méthode générale (BindCraft) a fortement réussi pour MDM2 et WDR5 [12] mais n’a produit aucun binder détectable pour PD-1 et PD-L1 [12], et un workflow distinct guidé par hotspot utilisant des outils entièrement différents (RFdiffusion, ProteinMPNN, AlphaFold, dynamique moléculaire [3]) n’a réussi que pour une des quatre conceptions contre le domaine LEDGF PWWP [3], ce seul succès étant compliqué par une homodimérisation indésirable [3]. Aucun de ces résultats ne doit être extrapolé à des cibles ou conditions non directement testées.

Enfin, identifier des candidats de haute affinité reste un goulot d’étranglement car la conception de binders nécessite typiquement de générer et de cribler virtuellement des milliers de conceptions pour récupérer quelques hits prometteurs [5]. Même avec une fonction de score améliorée comme pTMEnergy, ou un effort de génération à grande échelle comme le Human Bindome couvrant 40.9% du protéome humain [13], le besoin fondamental de filtrer un large pool de candidats jusqu’à un petit nombre de conceptions testables en laboratoire humide n’a pas été éliminé par les travaux cités, seulement partiellement atténué. Un développeur doit prévoir ce budget pour cette étape de filtrage et ne doit pas s’attendre à ce qu’un score in silico unique supprime le besoin de validation expérimentale.

1. Configurer l’environnement BindCraft de base. Installez le pipeline BindCraft open source et automatisé pour la conception de binders protéiques de novo [7], qui exploite les poids d’AlphaFold2 pour générer des binders protéiques à partir de structures cibles [7]. Vous aurez besoin des poids du modèle AlphaFold2 disponibles localement et d’une pile d’inférence JAX/AlphaFold2 fonctionnelle, puisque le pipeline exécute une optimisation par gradient à l’intérieur de ce réseau plutôt que d’appeler une API externe.
2. Préparer l’entrée de structure cible. Obtenez un fichier de structure PDB pour votre protéine cible. Si vous prévoyez plutôt de reproduire une conception guidée par hotspot, notez qu’un workflow publié distinct intégrait RFdiffusion, ProteinMPNN, AlphaFold, des simulations de dynamique moléculaire et une évaluation structurale manuelle [3] comme alternative à l’hallucination à réseau unique ; décidez dès le départ laquelle des deux familles vous construisez, car elles nécessitent des piles logicielles différentes.
3. Choisir l’objectif d’optimisation. La perte par défaut de BindCraft est une optimisation par gradient fondée sur l’hallucination de l’interface predicted TM-score (ipTM), entre autres pertes [5]. Si vous voulez la variante améliorée, remplacez l’ipTM par pTMEnergy, qui réinterprète les logits d’erreur d’alignement prédite (pAE) d’AlphaFold comme un modèle fondé sur l’énergie sur les complexes binder-cible [5] et ne nécessite aucun appel de modèle supplémentaire ni modification d’architecture [5], puisqu’il est dérivé des sorties pAE que vous calculez déjà.
4. Exécuter la boucle d’optimisation. Itérez les mises à jour de gradient sur la séquence/structure du binder pour augmenter le score choisi (ipTM ou pTMEnergy) contre la cible fixe. Gardez à l’esprit que l’ipTM produit des gradients épars concentrés sur seulement un petit sous-ensemble de paires de résidus d’interface [5], donc si vous observez des clashes ou des interfaces mal formées en dehors de quelques résidus de contact, il s’agit d’un mode d’échec connu de l’optimisation fondée sur l’ipTM, et pTMEnergy est l’atténuation documentée [5].
5. Générer un large pool de candidats. Parce que l’identification de candidats de haute affinité reste un goulot d’étranglement et nécessite typiquement de générer et de cribler virtuellement des milliers de conceptions pour récupérer quelques hits prometteurs [5], planifiez votre budget de calcul pour un lot de nombreux candidats par cible, pas une poignée.
6. Scorer et filtrer les candidats avec des modèles de prédiction de structure. Les modèles de prédiction de structure tels qu’AlphaFold2 et AlphaFold3 permettent une évaluation de la liaison sans structures cristallines [5], et les scores de confiance, en particulier l’ipTM, corrèlent avec la force de liaison [5]. Utilisez ces scores comme filtre initial, mais rappelez-vous que cette corrélation n’a été validée que sur des jeux de données limités [6].
7. Benchmarker avec un protocole multi-vérificateurs par séquence. Suivez l’approche ProtDBench : échantillonnez plusieurs séquences par backbone généré, appliquez un vérificateur et un filtre à chaque séquence, et calculez le taux de succès par séquence [6]. Définissez votre ensemble de backbones passants comme les backbones ayant au moins une séquence qui passe le filtre [6], et regroupez uniquement les backbones passants par similarité structurale à l’aide de FoldSeek ou TM-score [6] pour vérifier la diversité des conceptions.
8. Recouper avec plus d’un vérificateur. Parce que ProtDBench rapporte un biais substantiel dépendant du vérificateur et un accord limité entre les modèles de prédiction de structure utilisés comme vérificateurs [6], exécutez votre filtre avec au moins deux modèles de prédiction de structure différents et rapportez les deux résultats plutôt que de vous fier à un seul.
9. Sélectionner une liste restreinte pour la synthèse. À partir de vos candidats filtrés et regroupés, choisissez une liste restreinte diversifiée pour les tests en laboratoire humide. Attendez-vous à une variance dépendante de la cible : des tests indépendants ont trouvé que 7 des 15 peptides MDM2 synthétisés se liaient spécifiquement [12], 6 des 9 candidats WDR5 se liaient en submicromolaire [12], mais aucun des peptides PD-1/PD-L1 testés ne se liait du tout [12], donc traitez votre liste restreinte in silico comme une hypothèse à tester, pas comme une garantie.
10. Valider expérimentalement. Utilisez un essai de liaison biophysique (comme utilisé pour confirmer une affinité micromolaire basse pour un binder du domaine LEDGF PWWP [3]) et, lorsque pertinent, un essai de compétition pour confirmer la spécificité de site, comme cela a été fait pour les peptides MDM2 [3][12]. Surveillez les comportements inattendus tels que l’homodimérisation, qui dans un cas a interféré avec la liaison en solution bien que la protéine reste co-cristallisable avec sa cible à une résolution de 2.1 Å [3].
11. Rapporter les résultats avec toutes les conditions. Lorsque vous publiez ou journalisez des taux de succès, indiquez toujours quel vérificateur, quel benchmark et quelle classe de cible ont produit le nombre, puisque des taux de succès allant de 10% à 100% [7] et la conclusion de divergence entre vérificateurs [6] signifient qu’un nombre de taux de succès non qualifié n’est pas informatif en lui-même.

Esquisse de pseudocode de la boucle d’hallucination centrale avec l’option pTMEnergy :

load target_structure from PDB file
initialize binder_sequence randomly
for step in range(num_steps):
    complex_pred = alphafold2_forward(binder_sequence, target_structure)
    if objective == "ipTM":
        loss = -complex_pred.ipTM
    elif objective == "pTMEnergy":
        loss = -pTMEnergy(complex_pred.pae_logits)
    grads = backprop(loss, wrt=binder_sequence)
    binder_sequence = update(binder_sequence, grads)
return binder_sequence, complex_pred.ipTM, complex_pred.pTMEnergy

Le script ci-dessous implémente, sur nos propres données SQLite, une version simplifiée des deux idées d’évaluation centrales de cette note : (1) un calcul ProtDBench-style de taux de succès par séquence et d’ensemble de backbones passants sur les candidats générés (affirmations R et S), utilisant un regroupement par similarité structurale des conceptions passantes via un proxy de type TM-score (affirmation T), et (2) une comparaison de deux fonctions de score analogues à ipTM contre pTMEnergy (affirmations B, I, J, M, N, O, P), calculée à partir des colonnes de notre propre table `forecasts` (q10, q50, q90, p_up) tenant lieu de scores de style confiance, puisque nos données ne contiennent pas de vrais logits pAE d’AlphaFold ni de valeurs ipTM. Parce que notre schéma n’a pas de tables de conception de binders, nous traitons chaque ligne de `forecasts` comme une conception candidate pour un symbole/cible, `p_up` comme le score de confiance épars de style ipTM, et une combinaison dense de l’étalement q10/q50/q90 comme le score dense de style pTMEnergy (cette substitution est clairement commentée dans le code ; c’est une démonstration de la méthode de comparaison de scores, pas une affirmation que nos données de marché sont des données protéiques). La référence à battre est le taux de succès du filtre simple de style ipTM ; le score dense de style pTMEnergy est censé donner un classement plus stable et moins épars, ce que nous vérifions en comparant combien de caractéristiques proxy distinctes de paires de résidus (q10, q50, q90) varient réellement par rapport à la part du changement de score entraînée par une seule caractéristique (vérification proxy de gradient épars contre dense, affirmation J). Le script construit aussi un petit rapport de style ProtDBench : taux de succès par candidat, taille de l’ensemble de backbones passants et un regroupement jouet par arrondi des scores (proxy pour le regroupement FoldSeek/TM-score, affirmation T). Il imprime ses nombres et les compare à un taux de succès de référence aléatoire. Tout s’exécute hors ligne contre `data.sqlite` (ou QOURAT_DB), se termine en bien moins de trois minutes sur CPU, et ne lève aucune exception si les tables existent (il crée un petit jeu de données synthétique si le fichier n’a pas de données, donc il est aussi exécutable de manière autonome).

import os
import sqlite3
import sys
import time
import numpy as np
import pandas as pd

# ---------------------------------------------------------------------------
# Config
# ---------------------------------------------------------------------------
DB_PATH = os.environ.get("QOURAT_DB", "data.sqlite")
RNG = np.random.default_rng(0)


def get_connection(path):
    # Opens (or creates) the sqlite file. No network access needed.
    conn = sqlite3.connect(path)
    return conn


def ensure_tables(conn):
    # Creates the required tables if they do not exist yet, so the script
    # is runnable even against a fresh empty file. Schema matches the spec.
    cur = conn.cursor()
    cur.execute("""CREATE TABLE IF NOT EXISTS bars (
        symbol TEXT, tf TEXT, ts TEXT, open REAL, high REAL, low REAL,
        close REAL, volume REAL)""")
    cur.execute("""CREATE TABLE IF NOT EXISTS forecasts (
        symbol TEXT, horizon TEXT, made_at TEXT, q10 REAL, q50 REAL,
        q90 REAL, p_up REAL)""")
    cur.execute("""CREATE TABLE IF NOT EXISTS trades (
        symbol TEXT, ts TEXT, price REAL, size REAL, side TEXT)""")
    cur.execute("""CREATE TABLE IF NOT EXISTS book (
        symbol TEXT, ts TEXT, level INTEGER, bid_price REAL,
        bid_size REAL, ask_price REAL, ask_size REAL)""")
    conn.commit()


def maybe_seed_forecasts(conn):
    # If the forecasts table is empty, populate it with a small synthetic
    # set of "candidate designs" so the pipeline below has something to
    # score. This stands in for generated binder candidates: each row is
    # one candidate for one "target" (symbol), analogous to one sampled
    # sequence for one backbone in ProtDBench (claim R).
    df = pd.read_sql_query("SELECT COUNT(*) AS n FROM forecasts", conn)
    if df["n"].iloc[0] > 0:
        return
    symbols = ["AAPL", "MSFT", "BTC-USD"]
    rows = []
    for sym in symbols:
        for i in range(60):
            q50 = RNG.normal(0, 1)
            spread = abs(RNG.normal(0.5, 0.2)) + 0.01
            q10 = q50 - spread
            q90 = q50 + spread
            p_up = float(np.clip(RNG.normal(0.5, 0.2), 0, 1))
            rows.append((sym, "1d", f"2024-01-{(i % 28) + 1:02d}T00:00:00",
                         q10, q50, q90, p_up))
    conn.executemany(
        "INSERT INTO forecasts (symbol, horizon, made_at, q10, q50, q90, p_up) "
        "VALUES (?,?,?,?,?,?,?)", rows)
    conn.commit()


# ---------------------------------------------------------------------------
# Scoring functions
# ---------------------------------------------------------------------------

def sparse_score(row):
    # Proxy for ipTM-style scoring: BindCraft optimizes ipTM, a score that
    # computes a max over target residue indices and gives sparse
    # gradients concentrated on a small subset of interface pairs
    # (claims B and J). Here we proxy this by taking the single most
    # extreme of the three quantile-derived features, i.e. a max-like
    # operation over a small set of "residue pair" proxies (q10, q50, q90).
    feats = np.array([abs(row["q10"]), abs(row["q50"]), abs(row["p_up"] - 0.5)])
    return float(feats.max())


def dense_score(row):
    # Proxy for pTMEnergy-style scoring: pTMEnergy is derived from the same
    # underlying outputs (here: q10, q50, q90, p_up) but combines them into
    # a dense signal rather than taking a single max (claims M, N, O).
    # We use a simple mean of the same features, so every feature
    # contributes to the score, not just the largest one.
    feats = np.array([abs(row["q10"]), abs(row["q50"]), abs(row["q90"]),
                       abs(row["p_up"] - 0.5)])
    return float(feats.mean())


def gradient_sparsity(row):
    # Checks how much of the sparse score is driven by a single feature
    # versus spread across features, as a numeric illustration of claim J
    # (sparse gradients concentrated on a small subset of interface pairs).
    # Returns the fraction of total feature magnitude held by the largest
    # single feature: close to 1.0 means very sparse, close to 1/n means
    # evenly dense.
    feats = np.array([abs(row["q10"]), abs(row["q50"]), abs(row["q90"]),
                       abs(row["p_up"] - 0.5)])
    total = feats.sum()
    if total = threshold
    per_seq_success_rate = float(df["passes"].mean())

    backbone_groups = df.groupby("symbol")
    passing_backbones = []
    for symbol, group in backbone_groups:
        if group["passes"].any():
            passing_backbones.append(symbol)
    passing_backbone_set = set(passing_backbones)

    return per_seq_success_rate, passing_backbone_set, df


def cluster_passing_backbones(df, passing_backbone_set):
    # Proxy for claim T: ProtDBench clusters only passing backbones by
    # structural similarity using FoldSeek or TM-score. We do not have
    # real structures, so we use a simple proxy: cluster passing backbones
    # by rounding their mean score to one decimal place, as a stand-in
    # for a structural-similarity bucket.
    passing_df = df[df["symbol"].isin(passing_backbone_set)]
    if len(passing_df) == 0:
        return {}
    means = passing_df.groupby("symbol")["score"].mean()
    clusters = {}
    for symbol, m in means.items():
        key = round(m, 1)
        clusters.setdefault(key, []).append(symbol)
    return clusters


# ---------------------------------------------------------------------------
# Baseline: random scoring, to check the two methods beat pure chance
# ---------------------------------------------------------------------------

def random_baseline_success_rate(n_rows, threshold, n_trials=200):
    # A simple baseline: if scores were pure random noise in [0, 1.5],
    # what fraction would pass the threshold? This is the number to beat.
    rates = []
    for _ in range(n_trials):
        fake_scores = RNG.uniform(0, 1.5, size=n_rows)
        rates.append(float((fake_scores >= threshold).mean()))
    return float(np.mean(rates))


def main():
    start = time.time()
    conn = get_connection(DB_PATH)
    ensure_tables(conn)
    maybe_seed_forecasts(conn)

    df = pd.read_sql_query(
        "SELECT symbol, horizon, made_at, q10, q50, q90, p_up FROM forecasts",
        conn)
    conn.close()

    if len(df) == 0:
        print("No forecast rows found even after seeding, aborting.")
        sys.exit(1)

    threshold = 0.5  # fixed filter threshold for both scoring functions

    sparse_rate, sparse_passing, sparse_df = protdbench_style_eval(
        df, sparse_score, threshold)
    dense_rate, dense_passing, dense_df = protdbench_style_eval(
        df, dense_score, threshold)

    sparsity_values = df.apply(gradient_sparsity, axis=1)
    mean_sparsity = float(sparsity_values.mean())

    sparse_clusters = cluster_passing_backbones(sparse_df, sparse_passing)
    dense_clusters = cluster_passing_backbones(dense_df, dense_passing)

    baseline_rate = random_baseline_success_rate(len(df), threshold)

    print("=== BindCraft-style scoring comparison (proxy data) ===")
    print(f"Rows (candidate designs) evaluated: {len(df)}")
    print(f"Backbones (symbols) evaluated: {df['symbol'].nunique()}")
    print()
    print("-- ipTM-style (sparse, max-based) scoring --")
    print(f"Per-sequence success rate: {sparse_rate:.3f}")
    print(f"Passing backbone set size: {len(sparse_passing)} "
          f"of {df['symbol'].nunique()}")
    print(f"Structural-similarity clusters (proxy): {sparse_clusters}")
    print()
    print("-- pTMEnergy-style (dense, mean-based) scoring --")
    print(f"Per-sequence success rate: {dense_rate:.3f}")
    print(f"Passing backbone set size: {len(dense_passing)} "
          f"of {df['symbol'].nunique()}")
    print(f"Structural-similarity clusters (proxy): {dense_clusters}")
    print()
    print(f"Mean gradient sparsity of ipTM-style score (1.0 = fully "
          f"sparse, 0.25 = fully dense over 4 features): {mean_sparsity:.3f}")
    print()
    print(f"Random baseline success rate to beat: {baseline_rate:.3f}")
    print()
    if dense_rate >= sparse_rate and dense_rate > baseline_rate:
        print("RESULT: dense (pTMEnergy-style) scoring matched or beat "
              "sparse (ipTM-style) scoring, and both beat the random baseline.")
    else:
        print("RESULT: dense scoring did not clearly beat sparse scoring "
              "on this data; inspect thresholds and feature scaling.")

    elapsed = time.time() - start
    print(f"\nElapsed time: {elapsed:.2f} seconds")


if __name__ == "__main__":
    main()