La métrica que decidí no usar

La v1 daba números altos. Y precisamente por altos me hicieron desconfiar. Al revisar el flujo con más criterio del que tenía cuando lo diseñé, encontré asunciones en la preparación y partición de los datos —en la normalización alélica y en cómo separaba entrenamiento de test— que, con toda probabilidad, dejaban filtrar información entre conjuntos. Es el clásico data leakage: el modelo parece brillante porque, sin quererlo, ha visto parte de la respuesta.

Podría haber dejado el 86,89% en el portfolio y a nadie le habría extrañado. Decidí no hacerlo. Una métrica que no puedo defender metodológicamente no es un logro, es un riesgo. Publicarla como definitiva sería, además de incorrecto, exactamente el tipo de práctica que quiero evitar en un dominio clínico donde un error se traduce en una decisión sobre un paciente.

Lo que la v1 sí demostró se mantiene: la señal gen–fármaco es aprendible con esta representación, y decisiones como usar PubChem CID en lugar de ATC o el identificador Genalle funcionan. Eso es lo que me llevo. La cifra, no.

Por qué grafos (v2, frente científico)

La v1 representaba fármacos y variantes como vectores tabulares. Pero una molécula es un grafo (átomos, enlaces) y el contexto genómico también tiene topología. Forzar esa estructura dentro de una tabla pierde información.

La v2 adopta una arquitectura Two-Tower GATv2 con PyTorch Geometric:

• Torre del fármaco: grafos moleculares construidos con RDKit desde SMILES canónicos.
• Torre del genotipo: grafos posicionales de variantes, validados contra GRCh38.
• Ambas torres se fusionan en cabezas multi-tarea.

La atención sobre grafos (GATv2) permite que el modelo aprenda qué partes de la molécula y del contexto genómico importan para cada interacción, en lugar de asumirlo yo con feature engineering manual.

Por qué estándares de industria (v2, frente de ingeniería)

Cuando diseñé la v1 no sabía lo que no sabía. No usaba validación de tipos, ni tests, ni un servicio de inferencia, ni CI. Funcionaba, pero era frágil: un cambio en un sitio rompía otro en silencio.

La v2 incorpora lo que la primera versión no tenía:

• Pydantic v2 tipando cada frontera de datos (Drug, Variant, Genotype, peticiones de la API…). Si un dato entra mal, falla fuerte y pronto, no tres capas más abajo.
• FastAPI como servicio de inferencia, con OpenAPI y health/readiness probes.
• CI con ruff + pytest (~240 tests unitarios) en cada push y PR.
• uv para dependencias reproducibles, con lockfile como fuente de verdad.

Nada de esto mejora la métrica del modelo. Lo que mejora es la confianza: que el proyecto se pueda mantener, auditar y desplegar, y que otra persona —o un tribunal, o un supervisor— pueda leer el código y creer en él.

Rehacer la evaluación

La pieza central de la v2 no es la arquitectura, es el protocolo de evaluación. Particiones sin fugas, una línea base explícita contra la que comparar, y métricas balanceadas reportadas siempre junto a la metodología que las produjo. Cuando tenga cifras que pueda defender, se publicarán aquí con ese protocolo al lado. Ni antes, ni sin él.

Lo que me llevo

He aprendido más corrigiendo la v1 que construyéndola. Detectar el problema de evaluación por mí mismo, aceptar que las cifras bonitas no valían, y reconstruir el proyecto con rigor ha sido la parte más formativa de todo Pharmagen. Si algo define a un buen investigador o ingeniero no es no equivocarse nunca, sino ver el error, admitirlo y corregirlo con método. En eso estoy.

¿Comentarios o quieres seguir el desarrollo? El código está en GitHub y puedes escribirme por LinkedIn.

Por qué DeepFM y no un modelo tabular clásico

La farmacogenómica presenta un problema poco habitual en machine learning: las interacciones entre variantes genéticas y fármacos son combinatorias y no lineales. Un modelo como XGBoost captura bien las relaciones de primer orden, pero la epistasia (la interacción entre múltiples loci genéticos) requiere modelar explícitamente las interacciones de segundo orden y superiores.

La arquitectura DeepFM combina lo mejor de dos mundos:

• Máquinas de Factorización (FM): Capturan todas las interacciones de segundo orden entre features de forma eficiente, sin necesidad de feature engineering manual.
• Red Neuronal Profunda (DNN): Aprende patrones de orden superior que las FM no alcanzan.

Ingeniería de características: las decisiones que importan

Resultados preliminares (v1) (ver nota de honestidad arriba)

Estas cifras corresponden a las particiones internas de la v1 y probablemente están infladas por fuga de datos. Las dejo por transparencia y trazabilidad, no como resultado validado:

La tarea de dirección del efecto (increased/decreased) es la más difícil porque depende de contextos clínicos que no siempre están codificados en los datos genómicos puros. Es un área donde las futuras GNN podrían aportar mejoras significativas.

Lecciones aprendidas

1. La ingeniería de características importa más que la arquitectura. Cambiar de ATC a PubChem CID mejoró más el rendimiento que cualquier ajuste de hiperparámetros.
2. El desbalance de clases en dominios clínicos no es un problema técnico, es un problema ético. Optimizar por accuracy global puede enmascarar un modelo que falla sistemáticamente en los casos más peligrosos.
3. Optuna + validación cruzada estratificada es la combinación correcta para datasets pequeños con muchas clases. 40 trials fueron suficientes para converger.
4. La evaluación es tan importante como el modelo. Una métrica alta no vale nada si el protocolo permite fuga de datos. Detectarlo yo mismo y rehacer la validación en la v2 ha sido la lección más valiosa de todo el proyecto: es lo que separa un experimento de una herramienta fiable.