# machine-learning-clasico-con-python
Machine Learning con scikit-learn y XGBoost
Volver a la portada del cursoMars Climate Orbiter: una sonda perdida por unidades mezcladas
Sección 2 · Preparación de datos y pipelines
Transcripción
El 23 de septiembre de 1999, a las nueve de la mañana con cuatro minutos, hora universal, la sonda Mars Climate Orbiter de la NASA pasó por detrás de Marte para encender su motor y entrar en órbita. Era una maniobra planeada: durante unos minutos, el planeta bloquea la señal. El problema es que la señal nunca volvió.
La misión tenía un objetivo ambicioso. Según el informe de la junta que investigó el accidente, la sonda iba a ser el primer satélite meteorológico interplanetario, y además debía servir de enlace de comunicaciones para otra nave, la Mars Polar Lander, que llegaría a Marte en diciembre de ese año. Había despegado el 11 de diciembre de 1998 desde Cabo Cañaveral. Llevaba nueve meses de viaje.
La pregunta obvia era qué había fallado. La NASA formó una junta de investigación, y su primer informe, publicado en noviembre de 1999, señaló una causa raíz que suena casi increíble: alguien no usó unidades métricas.
Te lo explico con más detalle. Durante el viaje, la nave tenía que corregir de vez en cuando la acumulación de momento angular en sus ruedas de reacción, unas especies de volantes que la mantienen orientada. Cada corrección encendía pequeños propulsores, y cada encendido empujaba un poco la trayectoria. Un programa de tierra, llamado Small Forces, calculaba el impulso de esos encendidos y dejaba el resultado en un archivo. Ese archivo, según la documentación de interfaz del proyecto, debía venir en unidades métricas, en newton segundo. El equipo de navegación lo leyó suponiendo justo eso. Pero el programa entregaba los datos en unidades inglesas, en libras fuerza segundo. Una libra fuerza equivale a unos cuatro punto cuarenta y cinco newtons, así que cada impulso entraba al modelo con un valor equivocado.
Aquí hay un detalle que vuelve la historia todavía más instructiva. El error no apareció de golpe. La junta explica que estas correcciones ocurrieron entre diez y catorce veces más seguido de lo que esperaba el equipo de navegación, porque los paneles solares de la sonda eran asimétricos y la presión de la luz del Sol la desbalanceaba más. Cada corrección añadía un pequeño error a la estimación de la trayectoria. Ninguno era escandaloso por sí solo. Pero se fueron sumando durante nueve meses. Al llegar a Marte, la trayectoria estaba unos ciento setenta kilómetros más baja de lo planeado. La sonda se destruyó en la atmósfera o salió rebotada hacia el espacio.
La junta no se quedó en la causa raíz. También listó causas que contribuyeron: el equipo de navegación no conocía bien la nave, una maniobra de corrección de trayectoria que pudo salvarla no se ejecutó, la comunicación entre los equipos era deficiente y la verificación del software de tierra no fue suficiente. Y escribió algo que vale la pena repetir: los errores ocurren en los proyectos espaciales, pero normalmente hay procesos que los atrapan antes de que se vuelvan críticos. En este caso, esos procesos no lo atraparon.
Ahora llévalo a tus datos. En el CSV sucio de PyRitmo hay diecinueve canciones cuya duración no viene en segundos, sino en milisegundos. Una canción de tres minutos y medio aparece con más de doscientos mil segundos. Si entrenas un modelo sin revisar eso, nadie te va a avisar. Python no lanza un error, pandas no protesta, scikit-learn ajusta el modelo como si nada. El StandardScaler va a calcular una media y una desviación inflada por esos valores, y la regresión va a aprender coeficientes distorsionados. Igual que en la sonda: el dato tiene el tipo correcto, un número, pero la unidad equivocada.
Por eso, antes de modelar, la validación de unidades, rangos y formatos no es opcional. Un describe que muestra una duración máxima de más de cuatrocientos mil segundos es una alarma: ninguna canción dura casi cinco días. Conviene escribir reglas explícitas, como que la duración esté entre un minuto y diez minutos, que el tempo esté en un rango razonable, que el género pertenezca a una lista conocida. Y conviene que esas reglas vivan en el código, no en la memoria de alguien del equipo.
La idea con la que conviene quedarse es esta: los errores de unidades no hacen ruido. No rompen el programa, solo cambian los números. Y como en la sonda, pueden acumularse en silencio hasta que el resultado ya no tiene arreglo. Revisar tus datos antes de ajustar cualquier cosa es parte del modelo, no un trámite previo.