Building computational benchmarks: an Omnibenchmark reimplementation of a single-cell preprocessing pipeline evaluation

Resumen Técnico: Construcción de Benchmarks Computacionales: Una Reimplementación de un Omnibenchmark de un Pipeline de Preprocesamiento de Célula Única

Planteamiento del Problema
La rápida proliferación de técnicas y conjuntos de datos de secuenciación de ARN de célula única (scRNA-seq) ha venido acompañada de una explosión de herramientas y marcos de análisis computacional. Aunque existen numerosos benchmarks "neutrales" para evaluar tareas computacionales específicas, estos suelen sufrir de una falta de estandarización. Los problemas críticos incluyen el uso de conjuntos de datos, métricas o conjuntos de parámetros incompatibles entre diferentes estudios, lo que dificulta las comparaciones entre estudios. Además, los benchmarks existentes a menudo carecen de reproducibilidad debido a la falta de artefactos, procedencia incompleta, código de simulación no disponible y entornos de software frágiles. El campo carece de un marco unificado y extensible que permita la investigación sistemática de pipelines de análisis completos, incluyendo el aislamiento de pasos específicos y la exploración de amplios espacios de parámetros.

Metodología
Los autores presentan scrna-bench, una reimplementación y mejora de un benchmark previo de un pipeline "end-to-end" [21], construido utilizando el framework Omnibenchmark [17]. El objetivo era crear una plantilla reproducible, estandarizada y extensible para evaluar pipelines de scRNA-seq.

• Estructura del Framework: El benchmark está organizado en cuatro etapas distintas: datasets (conjuntos de datos), methods (métodos), metrics (métricas) y un report (recolector de métricas). El flujo de trabajo se orquesta mediante un plan de benchmark autodescrito en YAML que define las entradas, salidas, entornos de software y repositorios de código para cada etapa.
• Datasets y Pipelines: El estudio se centra en tres datasets (sc-mix, cb y be1) y cinco pipelines de análisis principales: Seurat, Scrapper, OSCA, Scanpy y Rapids-singlecell.
• Estandarización y Armonización: Los autores inyectaron fragmentos de código para armonizar las entradas y salidas en todas las etapas. Expusieron parámetros comúnmente ajustados para permitir una búsqueda de cuadrícula (grid search) más amplia en el espacio de parámetros, incluyendo:
  • Número de componentes de PCA ($n\_comp$)
  • Número de vecinos más cercanos ($n\_neig$)
  • Número de genes altamente variables ($n\_hvg$)
  • Desplazamiento del conteo de clusters ($\delta_{cluster}$), definido como el desplazamiento con signo respecto al número real de clusters.
  • Estrategias de filtrado (manual vs. automatizado).
• Reproducibilidad: Para asegurar la reproducibilidad y abordar las inestabilidades específicas de las versiones, los autores crearon tres imágenes de Apptainer (contenedor). Se construyeron dos imágenes basadas en Python para probar diferentes versiones del paquete rapids-singlecell (v0.13.5 y v0.14.1), ya que el estudio original encontró caídas significativas de rendimiento con la versión más antigua debido a inestabilidades en el algoritmo de PCA.
• Métricas: El rendimiento se evaluó utilizando el Índice de Rand Ajustado (ARI) como métrica principal para la precisión de agrupamiento (clustering) (usando anotaciones de células de verdad fundamental/ground-truth), junto con otras métricas de acuerdo de etiquetas (NMI, Fowlkes-Mallows, etc.) y métricas de estructura interna de clusters (Silhouette, Davies-Bouldin). También se registraron los tiempos computacionales para pasos individuales del pipeline (filtrado, PCA, UMAP, clustering de Leiden).
• Análisis Estadístico: Se ajustaron modelos lineales (tanto de efectos fijos como aleatorios) para determinar la influencia de la elección del pipeline y la configuración de parámetros en el rendimiento del ARI.

Resultados Clave

• Rendimiento Computacional: El tiempo de ejecución varió significativamente entre pipelines y parámetros. Rapids (acelerado por GPU) y Scrapper (C++ con bindings de R) fueron los pipelines más rápidos en general. OSCA exhibió una implementación de PCA más lenta, mientras que Scanpy mostró una implementación de UMAP más lenta. El estudio señaló que las comparaciones de tiempo de ejecución entre pipelines de CPU y GPU reflejan diferencias arquitectónicas y no deben interpretarse puramente como medidas de eficiencia algorítmica.
• Precisión de Clustering:
  • El número de clusters especificados fue el factor más fuerte en el rendimiento del agrupamiento (ARI).
  • No hubo un único "mejor performer" en todos los datasets; la estabilidad varió considerablemente según la parametrización, particularmente para el dataset cb.
  • Un hallazgo notable es que el parámetro de resolución se implementa de manera diferente en los distintos pipelines. En consecuencia, los autores cambiaron el parámetro de interés al número de clusters en lugar del parámetro de resolución para asegurar una comparación justa.
  • Rapids y Scrapper generalmente mantuvieron una alta precisión, aunque se observó una reversión en el rendimiento superior entre los datasets be1 y cb. Scanpy, Rapids y Seurat mostraron un rendimiento subóptimo en el dataset be1.
• Sensibilidad de Parámetros: La expansión de la cuadrícula de parámetros reveló que, si bien algunas configuraciones mejoraron el ARI respecto a los valores por defecto del estudio original, otras funcionaron peor, especialmente en el dataset cb. El modelado lineal indicó que los efectos específicos del dataset fueron dominantes, siendo la elección del pipeline y el número de clusters los principales impulsores de la varianza en el ARI.
• Desafíos de Reproducibilidad: La reimplementación descubrió una inestabilidad significativa en rapids-singlecell v0.13.5, donde los puntajes de ARI cayeron en todas las parametrizaciones debido a problemas subyacentes en el algoritmo de PCA. Esto resaltó la necesidad de probar múltiples versiones de software, tratando los benchmarks como pruebas continuas para paquetes en evolución.

Significancia y Reivindicaciones
El artículo posiciona a scrna-bench no meramente como un conjunto de resultados, sino como un template y lienzo para futuros esfuerzos de benchmarking. Su principal significancia radica en:

1. Estandarización: Unifica el proceso de construcción de benchmarks, permitiendo comparaciones de métodos consistentes y facilitando la extensión de los benchmarks a barridos de parámetros más amplios, diferentes versiones de software y pipelines adicionales.
2. Reproducibilidad y Extensibilidad: Al archivar todos los artefactos en Zenodo y utilizar entornos contenedorizados, todo el benchmark es reproducible, bifurcable (forkable) y modificable. Esto aborda las barreras recurrentes de artefactos faltantes y entornos frágiles encontradas en estudios previos.
3. Colaboración Comunitaria: Los autores ven el benchmark como una "plantilla borrador" destinada a ser mejorada iterativamente por la comunidad. Proponen que los benchmarks deberían convertirse en "entidades continuas" que evolucionen junto con los métodos y los datasets.
4. Generalizabilidad: Aunque se centra en scRNA-seq, los autores argumentan que esta estrategia de plantillas de benchmarking estandarizadas y extensibles puede aplicarse a otras áreas de la biología computacional y subcampos computacionales para permitir módulos de código abierto que puedan ser reutilizados y actualizados continuamente.

Los autores mantienen la modestia sobre el alcance, reconociendo que actualmente evaluaron solo tres datasets y cinco pipelines, y que los métodos basados en CPU fueron probados en núcleos únicos. Identifican la expansión de los entornos de software a través de versiones de paquetes y la inclusión de pasos de integración (para el procesamiento de múltiples muestras) como extensiones futuras necesarias.