METEOMATIC 2006: PREDICCION METEREOLOGICA INTELIGENCIA EN REDES DE COMUNICACIONES. PRÁCTICA 1

Ramón Andrío Viloria, 100029784

INTRODUCCION

3

OBJETIVO

5

PREPROCESADO

6

PRUEBAS

8

ALGORITMOS EJEMPLOS DE FUNCIONAMIENTO

CONCLUSIONES

8 10

15

INTRODUCCION La minería de datos, Data mining o KDD (Knowledge Discovery in Databases) se define como "Proceso de extracción de información y patrones de comportamiento que permanecen ocultos entre grandes cantidades de información", y consiste en el conjunto de

técnicas avanzadas para la extracción de información escondida en grandes bases de datos. Las bases de datos actuales han acumulado una gran variedad y cantidad de datos, estadísticas, índices, etc. en los cuales la información útil no es fácil de encontrar o inferir a simple vista. Muchas empresas o entidades están interesadas en rescatar esa información y con la utilización de estas herramientas se pueden generar nuevas oportunidades de negocio. Algunas posibilidades que ofrecen estas herramientas son: •

Mejorar el funcionamiento de la organización.

•

Optimizar el manejo de sus bases de datos.

•

Predicción automatizada de tendencias y comportamientos.

•

Obtener ventajas comerciales.

•

Mejorar calidad de productos.

•

Descubrimiento automatizado de modelos desconocidos.

•

Descubrimiento de anomalías y acciones fraudulentas por parte de

clientes. Las técnicas de Data mining son utilizadas habitualmente para el análisis y explotación de datos de un data warehouse (almacén de datos). Su objetivo es encontrar relaciones en las bases de datos que no resultan evidentes a simple vista. Los resultados que arroja la minería de datos suelen ser conocidos o despreciables pero existe una pequeña porción de relaciones que se desconocían. Ahí reside el interés de estas herramientas. La minería de datos es fundamental en la investigación científica y técnica, como herramienta de análisis y descubrimiento de conocimiento a partir de datos de observación o de resultados de experimentos.

La herramienta que se va a emplear para la obtención de resultados es Weka. Weka no solo es el nombre de un pájaro neozelandés, si no también una aplicación de distribución gratuita para la experimentación con técnicas de minería de datos. Está implementada en java, lo que conlleva alguna situación desagradable con la pila que se comentará más adelante, y permite la aplicación de varios algoritmos de minería de datos. En concreto, vamos a usar Weka para experimentar con datos metereológicos de los últimos años. Pretendemos un sistema capaz de realizar predicciones metereológicas fiables sobre lo que ocurrirá dentro de una hora y lo que ocurrirá dentro de veinticuatro horas

OBJETIVO Ya se ha comentado que pretendemos predecir condiciones metereológicas. Es nuestro objetivo final, para posibles usuarios de la aplicación. Para ello, y empleando las técnicas de minería de datos, esperamos encontrar patrones de comportamiento en el tiempo. Por ejemplo, si durante dos días llueve y en el segundo se levanta viento, el tercer día habrá nubes y claros. Una vez detectado este patrón podría aplicarse de forma que siempre que nos encontramos con dos días de lluvia, el segundo con viento, tenderíamos a pensar en nubes y claros para el siguiente. Esto no es un descubrimiento de la minería de datos, el acervo popular esta lleno de frases que recogen este conocimiento: “marzo ventoso y abril lluvioso hacen a mayo florido y hermoso”, “cielo aborregado suelo mojado”, etc. Además esperamos que el sistema pueda detectar diferencias que resultan de triviales y no dependen de datos anteriores. En general, para un día cualquiera se podria esperar más calor a las tres de la tarde que a las ocho, o más calor en un día de agosto que en un día de febrero. Por último indicar que el sistema sólo usa datos referentes a Madrid. Esto no sólo es imperativo del enunciado. Si intentásemos un sistema que predijese en más de una localización geográfica tendríamos problemas. Se ve esto claramente si nos decidimos a predecir las condiciones en Madrid y Buenos Aires de forma simultánea. Mientras en un sitio es verano, en el otro es invierno y si introducimos todos los datos sin diferenciar, el sistema no podría generalizar.

PREPROCESADO Los pasos a seguir para la realización de un proyecto de minería de datos son siempre los mismos, independientemente de la técnica específica de extracción de conocimiento usada, y siempre se necesita un preprocesado de l información a tratar. Esta es un de las labores más tediosas, y determinará el resultado final, de forma que con una mala elección de los datos el sistema no funcionará. Para ello, partiendo de los datos que se han proporcionado (el fichero de nombre lemd) se ha desarrollado una aflicción semiautomática en java para el tratamiento de los datos. La aplicación se subdivide en dos programas. El primero realizaba un procesado sobre todos los datos: Programa 1: 1. Suprimir espacios. Se han suprimido los espacios de forma que, por ejemplo, el atributo Lluvia Leve, pasa a ser Lluvia_Leve. 2. Cambio de variables incoherentes: Algunas variables tomaban valores que no representaban información, o representaban una información que no era consistente con el resto. La primera situación se subsanó empleando el valor ‘?’ que en Weka significa desconocimiento del valor del atributo. El segundo caso sólo se presento una vez. Se decidió que la velocidad del viento sería un valor real, pero entre los valores de ese atributo se encontraba Calm. Calm pasó a ser cero, ya que se interpreto que Calm equivalía a viento en calma. 3. Preparación: La principal función del programa era preparar los datos para incorporarlos a Weka. Estos datos, una vez limpios no servían para predecir lo que buscábamos por que faltaba el atributo a predecir. Este programa se encargo de colocar al final de cada instancia un nuevo atributo que correspondía según el caso con la temperatura que haría dentro de una hora, la temperatura que haría dentro de veinticuatro horas o las condiciones climatológicas dentro de una hora. Una vez con todos los datos preprocesados, al introducirlos en Weka apareció un problema con el tamaño de la pila. Había demasiadas instancias, pero no sabíamos cual era el número máximo de instancias que Weka podía procesar. Se empezó por eliminar

años que apenas contenían información: 1994, 1995 y 1996. Sin embargo el problema con la pila persistía. Se siguieron eliminando los años que parecían contener menos información hasta quedarnos son 2001,2002 y 2003, ya que eran los más cercanos y los mas densos en lo que a información completa se refiere (2004 se decidió que podría servir como test). Si seguíamos eliminando años podrías surgir graves problemas en cuanto a la posible generalización. Ya tres años sólo eran peligrosos. Si en ese tiempo hubo una sequía el sistema se entrenaría para épocas de sequía únicamente. Optamos por realizar un muestreo sobre esos tres años y se diseño un nuevo programa en java. Programa 2: Muestreo: Este programa muestreó los años 2001, 2002 y 2003 tomando uno de cada dos registros. El muestreo se realizo dos veces, por lo que finalmente, quedo uno de cada cuatro de los registros iniciales. El fichero que quedó si lo pudo cargar Weka satisfactoriamente, pero aún surgieron sorpresas en registros puntuales que se solucionaron a mano. El principal problema fue que algunos registros tenían el símbolo % y esos mismos registros se encontraban incompletos en algunos campos y se completaron con ?. Para acabar el preprocesado de los datos, se eligió un conjunto de test. Decidimos testear con el año 2004 por que era cómodo coger un año completo. Además permitía testear todas las diferentes condiciones climatológicas que se dan en un año. También se probó con validación cruzada, ya que la proporciona Weka, aunque esto tiene el problema de falsear un poco los resultados, ya que parte de los datos de entrenamiento pasan después a ser de test. El entrenar y testear con los mismos datos hace que los resultados no sean del todo fiables. Sin embargo con estos métodos se puede evitar en parte el sobreentrenamiento, al ir cambiando los datos de entrenamiento. Se evito tomar algún conjunto de test elegido al azar, ya que quitaría datos de forma poco homogénea del conjunto de entrenamiento para pasarlos al de test y podríamos quedarnos con conjuntos poco representativos e incluso disjuntos. Imaginemos que cogiese casi todos los datos de test de los meses de verano. Entonces el sistema intentaría aproximar el verano con datos de invierno, otoño y primavera y no daría buenos resultados.

PRUEBAS ALGORITMOS En esta sección se explican las pruebas realizadas para el aprendizaje inductivo mediante árboles de decisión. Más concretamente, mediante los conocidos métodos denominados id3 (j 48 en Weka) [Quinlan, 1986], su sucesor c4.5 (M5 en Weka) [Quinlan, 1993] y algunas de las ampliaciones realizadas hasta la fecha. Se comentarán los elementos básicos relacionados con la versión id3 dado que es la base de los dos algoritmos utilizados. Aunque no todas las tareas inductivas (p.ej., problemas de regresión lineal) son tratables por el tipo de algoritmos aquí tratados, estos han resultado ser unos de los más utilizados en el campo del aprendizaje automático. Ello se debe a sus destacables ventajas: aprenden funciones de valores discretos, admiten ejemplos con ruido y obtienen un conjunto de expresiones fácilmente transformable en un conjunto de reglas, que forman opciones alternativas (disyuntivas) que cubren el espacio de ejemplos presentados. Por otro lado, las estrategias que se tienen un alto rendimiento y se han aplicado a los más variados dominios (p.ej., diagnóstico médico, predicción de fraudes en créditos bancarios, organización personalizada de eventos en una agenda, etc.). En especial y para el caso que nos ocupa son notables las aplicaciones de M5 en el campo de la minería de datos, tal y como se refleja en la versión comercial denominada c5.01. El objetivo básico, al igual que en otros tantos algoritmos inductivos, es clasificar los ejemplos presentados en sus respectivas clases o categorías, manteniendo un alto grado de predicción sobre los ejemplos no presentados. En concreto, en este caso se trata de obtener un árbol de decisión simple que clasifique correctamente los ejemplos presentados y sea capaz de predecir correctamente las clases de futuros ejemplos. En concreto, un árbol de decisión es una estructura que pueden tener los siguientes tipos de nodos: 1. Nodo interno (o de decisión): Consiste en una pregunta o test relativa al valor de un atributo. De cada nodo interno parten tantas ramas como respuestas haya a la

pregunta, que normalmente equivale al número de posibles valores que puede tener el atributo en cuestión. 2. Nodos hoja: En cada nodo hoja sólo puede haber instancias con un único valor de clase. Con este planteamiento, el objetivo podría ser la búsqueda exhaustiva de un árbol lo más simple y predictivo posible. Sin embargo, este es un problema cuya solución óptima no puede garantizarse para la mayoría de los casos, dado que su complejidad es NP. Frente a este problema, la gran ventaja de id3 y sus sucesores (como c4.5) es que son capaces de obtener una buena solución que considera ambas cuestiones, aunque el algoritmo no garantice que la solución sea la óptima. En definitiva, el algoritmo responde a un esquema clásico de clasificación en el que se distinguen dos requisitos para las clases: 1. Clases predefinidas: Se parte de un problema de aprendizaje supervisado en el que el atributo que hace las veces de clase está perfectamente identificado de antemano. 2. Clases: Se exige que haya un conjunto preciso de clases que sirven para clasificar claramente todos los ejemplos presentados. 2.1 Clases discretas: El algoritmo id3 usa conjuntos de clases discretas. Se ha usado su equivalente en Weka, J48, para el último apartado propuesto: la predicción de las condiciones metereológicas. 2.2 Clases continuas: El algoritmo usado para esto es el c4.5, en Weka M5. Clásicamente, se ha utilizado la regresión cuando las clases eran continuas ocurría, pero los modelos obtenidos eran numéricos. Con c4.5 obtenemos árboles de decisión. Es una variación de cart (Breiman et al., 84).

Por otro lado, se supone que el número de ejemplos presentados tiene que ser muy superior al de posibles clases. Esto se debe a que el proceso de generalización está basado en un análisis estadístico que no podría distinguir patrones de interés a partir de coincidencias aleatorias. Un problema real puede requerir cientos o miles de ejemplos de entrenamiento.

EJEMPLOS DE FUNCIONAMIENTO Se van a presentar en este apartado algunos de los árboles que se han obtenido en Weka. Prediccion a una hora Primero se probo la predicción a una hora tanto con validación cruzado como usando como test los datos del año 2004. En ambos casos el error absoluto fue mucho más alto que el deseable (31.0501 para la validación cruzada y 32.671 con el año 2004). Se obtuvo un árbol de derivación casi idéntico en ambos casos, así que el hecho de que el error sea ligeramente más alto con los datos del 2004 se debe a que no se entreno al sistema con ellos. El árbol para la validación cruzada es: dia=10,08,07,15,17,18,14,16,11,05,06,19,04,12,20,03,13,02,01,28,29,30,21,31

0.5 : LM10

(6544/12.862%)

Vemos como el día y el mes del año son determinantes, ya que aparecen en las primeras discriminaciones. Algo que cabía esperar ya que no es lo mismo enero que agosto para la temperatura. Además tienen incidencia

rocío, humedad, presión,

modelos lineales y velocidadViento. Se diseño entonces un nuevo modelo sólo con estos datos, ya que se pensó que el resto podían introducir ruido. No se obtuvo el resultado esperado, ya que el error se mantuvo en el umbral de los 30 grados y el arbol de decisión no vario en sus nodos principales. Sólo la presion paso a tener un poco más de incidencia, con tres nodos en vez de uno. Predicción a 24 horas Se trabajo de manera análoga al caso anterior, pero obviando la validación con el año 2004, ya que aportaba una complicación extra (en la definición del fichero) y anteriormente nos habia dado el mismo árbol de decisión que la validación cruzada. El árbol que resulto fue: –

presión 29.875 :

–

| temperatura 61.7 : LM7 (2911/31.557%)

Ahora es un árbol de menos niveles y variables aunque aparece una que, viendo el apartado anterior es una contradicción con lo que a priori podíamos esperar: pasa a tener en cuenta la temperatura actual. Cuando quería predecir en el umbral de una hora la temperatura (que en una hora no esperamos que cambie bruscamente) no se tenia en cuenta y en veinticuatro horas (donde esperamos una incidencia mucho menor) aparece aunque no como un nodo determinante. Además ahora aparece como discriminante la hora del día. Esto tiene sentido (la temperatura a las ocho será menor que a las doce) y sorprende que no apareciese en el modelo a una hora. De nuevo ser probo dejando sólo los atributos que tenían alguna incidencia, resultando un modelo muy similar y en ambos casos unos datos de error poco satisfactorios: 9.1742 en el primer caso y 9.431 en el segundo. Aunque se han reducido mucho con respecto a la predicción a una hora, equivale a decir que si hoy hacden veinte grados, mañana puede que hagan entre treinta y diez. Una decisión difícil si de

eso depende que se activen los servicios de emergencia o incluso que salgamos de fin de semana. Predicción de las condiciones En esta caso volvimos ha hacer lo mismo: probar el algoritmo y de nuevo probarlo con menos atributos (sólo año, mes, día y condiciones). Obtuvimos unos árboles desmesuradamente grande de los que se presenta un extracto: –

visibilidad