OpenBind y EERAT: una prueba de reproducibilidad para benchmarks de IA de afinidad estructural

Por qué OpenBind necesita una ruta de evidencia

Un benchmark de afinidad estructural no es útil porque sea abierto. Se vuelve útil cuando un segundo equipo puede reconstruir la ruta de evidencia, reproducir la partición, volver a ejecutar la línea base y luego mostrar que una mejor ordenación cambia qué compuestos se prueban.

Esa es la prueba que OpenBind merece. No un resumen de una tabla de clasificación. No una vuelta de celebración para la IA basada en estructuras. Un estándar de cuaderno de laboratorio.

La primera publicación pública de afinidad estructural de OpenBind es interesante porque los artefactos públicos exponen más que una sola puntuación de modelo. El repositorio del benchmark EV-A71 2A describe una publicación que combina cribado cristalográfico de fragmentos, optimización posterior de compuestos y mediciones de afinidad para la proteasa 2A enteroviral. También incluye material de benchmark de referencia para docking, co-folding, cribado virtual y predicción de afinidad. El blog de la primera publicación de OpenBind informa 925 eventos de unión cristalográficos a partir de 699 compuestos, con mediciones de afinidad para 601 compuestos. El repositorio de publicación del modelo OpenBind-0 apunta a un conjunto de benchmarking en Zenodo de 462 sistemas proteína-ligando.

Esos son ingredientes útiles. No son prueba de que un método de ordenación deba orientar el cribado experimental. La visión estricta es simple: si un benchmark no puede sobrevivir a la reconstrucción de identificadores, las comprobaciones de fuga y un holdout externo, es un artefacto de investigación, no un control operativo.

El marco EERAT de Optijara, Experimental Evidence Route Acceptance Test, trata a OpenBind como un caso de estudio para la evaluación disciplinada de IA científica. El estándar es deliberadamente estricto. Toda afirmación de rendimiento se mantiene como informada por los autores hasta que un equipo externo la reproduzca bajo condiciones fijadas y registre dónde difiere su ejecución.

La pila de fuentes que debe inspeccionarse

Haga la auditoría de fuentes antes de debatir sobre la calidad del modelo. Un equipo debe usar artefactos públicos canónicos, no fragmentos de búsqueda, URL supuestas, redirecciones o páginas bloqueadas. Para este artículo, el conjunto de fuentes utilizable es la organización de GitHub de OpenBind, el repositorio del benchmark EV-A71 2A, el repositorio de información de publicación del modelo OpenBind-0, el repositorio del flujo de trabajo de docking, el sitio web de OpenBind, el blog de la primera publicación de OpenBind y el registro de Zenodo.

Las licencias necesitan la misma separación. Un conjunto de datos puede ser abierto mientras el código, los pesos del modelo, los activos de docking, los binarios externos, los registros de ensayo y los documentos de protocolo tienen condiciones diferentes. Eso no es un detalle administrativo. Decide si el artefacto puede usarse para entrenar, redistribuirse, incorporarse a un producto o usarse solo para investigación interna.

EERAT en siete puertas

EERAT plantea una pregunta práctica: ¿la ruta de evidencia es lo bastante sólida para justificar más esfuerzo de evaluación? No certifica un modelo. No dice que un compuesto deba avanzar. Indica al equipo si el benchmark está listo para influir en la siguiente decisión de cribado.

Puerta 1, procedencia de espécimen y ensayo

Empiece con la identidad del target, la construcción, la preparación de la muestra, el método de ensayo, el formato de afinidad, el historial del compuesto y los registros de protocolo. Un aprobado significa que otro revisor puede señalar el artefacto detrás de cada medición y explicar qué se probó. Si faltan esos enlaces, el benchmark puede seguir siendo interesante, pero no está listo para usarse en decisiones.

Puerta 2, calidad de estructura y afinidad

Inspeccione la cobertura estructural, los eventos de unión, la confianza de la pose, la consistencia de la afinidad, los valores censurados, los registros faltantes y los compuestos fallidos. Los 925 eventos de unión cristalográficos informados en el blog de OpenBind a partir de 699 compuestos, con mediciones de afinidad para 601 compuestos, dan a los revisores material concreto para inspeccionar. La estructura del repositorio importa porque expone rutas de datos y análisis en lugar de solo texto resumido.

Puerta 3, normalización de identificadores

Normalice identificadores de compuestos, construcciones de proteínas, IDs de cadena, nombres de ligandos, IDs de ensayo y registros versionados. El registro de publicación del modelo en Zenodo muestra por qué esto no es trabajo administrativo. Describe 462 consultas con 483 entradas de cadena de proteína y 890 de ligando, 599 cadenas de proteína individuales y un mapa de cadenas deduplicado a 302 representantes MSA. Si los identificadores son imprecisos, los duplicados y alias pueden distorsionar el benchmark de forma silenciosa.

Puerta 4, fugas e integridad de particiones

Audite similitud de scaffolds, similitud de bolsillos, proximidad de familia de targets, ligandos casi duplicados, conformaciones reutilizadas, pasos de preprocesamiento y compuestos que influyeron en la selección del modelo. La separación de archivos no basta. Una partición puede parecer limpia en disco y aun así permitir que el conjunto de evaluación se filtre en las decisiones de entrenamiento.

Puerta 5, paridad de líneas base y fijación del entorno

Guarde commits de repositorio, archivos de entorno, versiones de software, supuestos de hardware, semillas, logs y binarios externos. El repositorio de docking requiere instalaciones de GNINA, Smina y DiffDock y está construido alrededor de ejecución con Slurm. Eso significa que la comparación de líneas base es en parte un problema de sistemas. Las entradas, la preparación del receptor, el presupuesto de cómputo y el reporte de métricas necesitan paridad.

Puerta 6, holdout externo y cribado prospectivo

Ejecute un pequeño holdout externo antes de tratar la ordenación del benchmark como guía de cribado. Luego bloquee un cribado prospectivo antes de conocer los resultados: método de ordenación del modelo, reglas de docking, compatibilidad del ensayo, protocolo de confirmación y umbral de interpretación. Aquí es donde un benchmark empieza a ganar relevancia operativa.

Puerta 7, canario, suspensión de uso y confirmación en laboratorio experimental

Defina compuestos canario, comprobaciones de deriva, reglas de confirmación en laboratorio experimental y disparadores de suspensión de uso. Pause el benchmark para la decisión si cambia el comportamiento de los canarios, aparece fuga en la partición, los términos de licencia entran en conflicto con el uso previsto o falla la confirmación prospectiva. Un benchmark sin una regla de suspensión se vuelve fácil de racionalizar después de decepcionar.

Reproducir el benchmark sin engañarse

Un registro de reproducción limpio supera a una puntuación ligeramente más alta. El trabajo es procedimental y, francamente, aburrido. Por eso funciona.

La fuga suele entrar de forma silenciosa. Scaffolds similares pueden cruzar la partición. Bolsillos relacionados pueden hacer que la generalización por familia de targets parezca mejor de lo que es. Una conformación reutilizada puede dar a un método de docking o co-folding una pista que no tendría durante un cribado real. El preprocesamiento puede aprender de todo el conjunto de datos antes de aplicar la partición. Los compuestos de evaluación también pueden seleccionarse después de explorar modelos, lo que convierte el benchmark en un registro de decisiones de ajuste.

Decisiones de modelo, docking y experimento

Esta es la lectura del consultor: no se debe permitir que un benchmark influya en el gasto de laboratorio experimental hasta que el equipo pueda medir si la calidad de la ordenación cambia los hits confirmados, los compuestos rechazados o el coste por hit confirmado en su propio flujo de trabajo. Si el equipo no puede medir eso, el benchmark sigue siendo evidencia de investigación útil. No es una regla de cribado.

Errores comunes

Error 1, tratar apertura como reproducibilidad

Los repositorios abiertos ayudan a la inspección. La reproducibilidad necesita hashes de commits, entornos fijados, versiones de datos, scripts de partición, logs de líneas base y desviaciones claras. Sin ese rastro, los revisores confían en un objetivo móvil.

Error 2, tratar el rendimiento de partición como valor prospectivo

Una partición de benchmark puede enseñar mucho a un equipo y aun así fallar en un nuevo entorno de laboratorio. Los holdouts externos y los cribados prospectivos bloqueados son el puente entre una puntuación informada y una decisión de cribado.

Error 3, ocultar compuestos fallidos y datos faltantes

Los compuestos fallidos, los valores de afinidad censurados, los formatos de ensayo inconsistentes y los metadatos faltantes a menudo contienen la señal operativa más importante. Un método que parece fuerte en registros limpios puede ser débil donde el trabajo de cribado es más desordenado.

Error 4, colapsar las licencias en una sola respuesta

Los términos del conjunto de datos, las licencias de código, los términos de pesos del modelo, los términos de software de docking, los activos de flujo de trabajo y los registros experimentales pueden no coincidir. Tratarlos como una sola respuesta de permiso crea riesgo evitable.

Error 5, comparar líneas base sin paridad

La paridad de líneas base significa entradas, elecciones de receptor, reglas de preparación, presupuestos de cómputo, semillas y reporte de métricas comparables. Sin paridad, una tabla de clasificación puede recompensar decisiones de flujo de trabajo en lugar de capacidad del modelo.

Advertencias y plan de medición

EERAT es conservador por diseño. Las advertencias científicas incluyen variabilidad de ensayo, especificidad del target, límites de calidad estructural y transferencia débil a otros targets. Las advertencias operativas incluyen reproducibilidad de cómputo, deriva de software externo, cachés obsoletas y el trabajo necesario para mantener el linaje de datos. Las advertencias legales atraviesan términos de conjuntos de datos, términos de código, pesos de modelo, herramientas de docking, documentos de protocolo y registros experimentales. Las advertencias de evaluación incluyen intervalos de confianza, manejo de compuestos fallidos y si el holdout externo es verdaderamente externo.

{
  "framework": "EERAT",
  "gates": ["provenance", "quality", "identifier_normalization", "leakage", "baseline_parity", "external_holdout", "canary_stop_use"],
  "requiredArtifacts": ["canonical_repositories", "dataset_record", "license_terms", "split_scripts", "baseline_logs", "holdout_report"],
  "acceptCriteria": "reproducible, leakage audited, license clear, externally tested, and tied to wet lab confirmation",
  "rejectCriteria": "unclear provenance, unresolved leakage, incompatible terms, non comparable baselines, weak holdout, or missing stop use criteria",
  "recommendedNextStep": "run a small, pinned reproduction before using rankings for screening"
}

OpenBind merece atención porque da a los revisores artefactos reales que inspeccionar. EERAT mantiene honesto el siguiente paso. Rastree la evidencia. Reconstruya los identificadores. Recree la partición. Vuelva a ejecutar la línea base. Pruebe un holdout externo. Luego pregunte si una mejor ordenación reduce experimentos innecesarios en el contexto de cribado propio del equipo.