Arquitectura en profundidad: el concepto del compilador científico
La mayoría de las plataformas de IA para ciencia utilizan modelos de lenguaje para generar contenido científico. Hordago adopta un enfoque distinto: tratamos los flujos de trabajo científicos como canalizaciones de compilación en las que la IA asiste con el código y la configuración, pero nunca toca el núcleo determinista.
La metáfora del compilador
Un compilador tradicional toma código fuente y produce código máquina. El proceso es determinista: la misma entrada siempre produce la misma salida. Puedes inspeccionar las representaciones intermedias, rastrear cualquier salida hasta su origen y verificar la corrección en cada etapa.
Hordago aplica este patrón a los flujos de trabajo científicos:
| Concepto del compilador | Equivalente en Hordago |
|---|---|
| Código fuente | Datos experimentales + especificación de análisis |
| Analizador léxico / sintáctico | Ingesta de datos + validación |
| Representación intermedia | Artefactos científicos tipados |
| Generación de código | Compilación del informe |
| Símbolos de depuración | Manifiestos de procedencia |
La idea clave: el LLM es el programador, no el compilador. La IA te ayuda a escribir la especificación del análisis y a configurar la canalización. Pero una vez definida la especificación, la ejecución es determinista.
Si trabajas en laboratorio, piénsalo como un protocolo que siempre se ejecuta de la misma manera: metes tus datos y salen figuras validadas. El “compilador” es simplemente la versión automatizada de esa fiabilidad.
Arquitectura de tres capas
Hordago separa las responsabilidades en tres capas:
Capa 1: Sistemas operativos de dominio (DomainOS)
Envolturas de producto ligeras, adaptadas a dominios científicos específicos. CRISPRos para edición génica, GWASos para genética de poblaciones. Cada DomainOS ofrece una interfaz, una terminología y unos flujos de trabajo específicos del dominio, pero delega la computación a motores compartidos.
Los productos DomainOS son intencionadamente ligeros. Definen qué hace un flujo de trabajo en términos del dominio, pero no implementan cómo se ejecuta la computación.
Capa 2: Motores científicos compartidos
Motores de computación reutilizables que dan soporte a múltiples productos DomainOS:
- Figure Engine: genera figuras con calidad de publicación a partir de artefactos de datos. El mismo motor produce las figuras en CRISPRos y en GWASos.
- Statistics Engine: ejecuta pruebas estadísticas y produce resultados tipados. Admite corrección por múltiples pruebas, cálculo del tamaño del efecto y análisis de potencia.
- Provenance Engine: registra cada entrada, transformación y salida. Genera trazas de auditoría y manifiestos de procedencia.
- biocontext7: resuelve referencias a herramientas bioinformáticas. Garantiza que los asistentes de IA usen herramientas reales con las APIs correctas.
Cuando mejoramos un motor, todos los productos DomainOS se benefician. Cuando añadimos un nuevo DomainOS, arranca desde el primer día con motores maduros y probados.
Capa 3: Infraestructura de ejecución
La capa de plataforma gestiona el despliegue, el escalado y la orquestación. Los flujos de trabajo científicos se ejecutan sobre infraestructura reproducible: entornos contenedorizados con dependencias fijadas y builds deterministas.
¿Por qué no usar simplemente un LLM?
Los modelos de lenguaje son excelentes generando texto plausible. Ese es precisamente el problema. En ciencia, plausible y correcto no son lo mismo.
Piensa en un gráfico de Manhattan de un estudio GWAS. Un LLM podría describir cómo debería verse el gráfico. Pero generar el gráfico real requiere:
- Leer el archivo de estadísticas resumen (con su formato y columnas específicos)
- Calcular -log10(p-valores) para cada variante
- Mapear las variantes a sus posiciones cromosómicas
- Aplicar umbrales de significación a nivel del genoma
- Renderizar la figura con los ejes y etiquetas correctos
Cada paso es una computación determinista. Si el LLM genera cualquiera de esos números, no puedes confiar en la figura. Si el compilador los produce a partir de tus datos, puedes rastrear cada punto del gráfico hasta una fila de tu archivo de entrada.
La procedencia como concepto de primera clase
Todo artefacto producido por Hordago incluye un manifiesto de procedencia: un registro legible por máquina que contiene:
- Entradas: qué datos se usaron, de dónde vienen y cuándo se accedió a ellos
- Transformaciones: qué motor los procesó, con qué versión y con qué parámetros
- Salidas: qué se produjo, sumas de verificación y marcas de tiempo
Esto no es logging. Es la traza de auditoría que hace posible la reproducibilidad. Cuando un revisor pregunta “¿cómo calculaste este p-valor?”, la respuesta está en el manifiesto, no en la memoria del investigador.
Construyendo en abierto
Los motores científicos de Hordago son de código abierto. La canalización de compilación, el sistema de procedencia y el registro de herramientas (biocontext7) están todos disponibles en GitHub.
Creemos que la infraestructura científica debe ser transparente y auditable. Si no puedes inspeccionar la canalización que produjo tus resultados, no puedes confiar en esos resultados.
- GitHub: Hordago-Labs
- biocontext7: biocontext7.com
- Perspectivas: Estándares para la IA en ciencia
Hordago Labs construye herramientas de IA basadas en evidencia para las ciencias de la vida. Cada afirmación trazable. Cada figura reproducible.