SberZdorovye: el no determinismo de las redes neuronales es un fallo del pipeline, no una propiedad del modelo

SberZdorovie: no-determinismo en redes neuronales es un fallo de pipeline, no una propiedad del modelo

Ruslan Cherkas, arquitecto de SberZdorovie, se pronunció en contra de la tesis popular de que las redes neuronales son inherentemente no-deterministas por naturaleza. Su argumento principal: si los datos de entrada, los pesos del modelo y el entorno están fijos, el sistema debe producir el mismo resultado, y cualquier discrepancia es una señal de fallo en el pipeline, código o infraestructura.

De dónde surge la disputa

La ocasión para este análisis fue una situación típica de la práctica de ML: un equipo intenta reproducir un experimento pero obtiene métricas diferentes o una respuesta diferente del modelo. Tales casos se explican a menudo por la propia naturaleza de las redes neuronales, especialmente cuando se trata de LLMs, entrenamiento en GPUs y cadenas complejas de librerías y servicios. Cherkas cuestiona precisamente esta explicación y propone mirar el problema de forma más rigurosa, como un defecto de ingeniería en lugar de una característica inevitable de la tecnología.

Según su lógica, un modelo matemático no puede ser "aleatorio por sí mismo" si todos sus argumentos son conocidos e inalterados. Para una red neuronal, esto significa entrada fija, pesos fijos y condiciones de ejecución idénticas. En este modo, la fórmula debe llegar a la misma conclusión cada vez. Si esto no ocurre, entonces en algún lugar entre los datos, el hardware, las librerías y el algoritmo existe una variable no contabilizada que el equipo simplemente no controla.

Cuatro fuentes de fallos

El autor desglosa las explicaciones más comunes típicamente usadas para justificar resultados fluctuantes y las reduce a cuatro clases de problemas. Su posición general es rigurosa: el no-determinismo no es una "característica" útil si surge sin cambiar las condiciones de entrada. Esto importa no solo para la ciencia, sino también para desplegar el modelo en producción, donde cualquier discrepancia inexplicada rápidamente se convierte en un riesgo.

• Datos de entrada indefinidos — los datos en sí, pesos iniciales, seed o estados internos cambian aleatoriamente.
• Fallos de hardware — defectos en el equipamiento, diferencias en el orden de operaciones o entorno de ejecución inestable afectan el resultado.
• Discrepancias de software — versiones de librerías difieren, configuraciones de optimización, caching u otras variables de entorno cambian.
• Errores algorítmicos — orden de computación flotante, condiciones de carrera y paralelización incorrecta rompen la reproducibilidad.

Cherkas enfatiza por separado que las referencias a "factores externos" como efectos cuánticos no eximen a los desarrolladores de responsabilidad. Si un factor influye en la salida del modelo, debe incluirse en los argumentos o aislarse. De lo contrario, esta no es una cuestión filosófica sobre la naturaleza de la IA, sino un error de implementación ordinario.

El artículo también contiene una fórmula breve para la posición del autor:

"El no-determinismo es un error que debe y puede eliminarse."

Cómo lograr reproducibilidad

La conclusión práctica del artículo es simple: primero necesita reconocer el problema, luego localizar su fuente. Si un modelo se comporta diferente con ejecuciones idénticas, el equipo debe desglosar el incidente por capas: verificar los datos, comparar pesos, fijar la seed, asegurar hardware idéntico, versiones de librerías y entorno de runtime completo. Para sistemas de producción, esto ya no es una cuestión de conveniencia sino de confianza en los resultados y capacidad de investigar fallos adecuadamente.

El autor también advierte que no puede ciegamente pagar velocidad con la pérdida del orden de computación. Si la paralelización u optimización cambian el orden de operaciones de forma que los resultados comienzan a fluctuar, tal implementación no puede considerarse correcta para escenarios críticos. Esto especialmente se aplica a sistemas donde decisiones comerciales, recomendaciones médicas, seguridad u otros procesos de alto riesgo dependen del modelo. En estos casos, un pipeline determinista debe ser un objetivo de ingeniería separado, no un efecto secundario de sintonización exitosa.

Qué significa esto

El material de SberZdorovie es útil porque desplaza la conversación sobre "magia de redes neuronales" al ámbito de la ingeniería ordinaria. Cuanto más activamente las empresas insertan modelos en procesos importantes, menos aceptable es explicar la impredecibilidad por la naturaleza abstracta de la IA. En la práctica, los equipos que ganarán son aquellos que pueden demostrar reproducibilidad, describir fuentes de aleatoriedad y probar que el sistema permanece manejable incluso en escenarios complejos.