La Inteligencia artificial y chat GPT han dado de que hablar en los últimos meses, tanto en el ámbito privado como el profesional.
Pablo Montoliu, Chief Information & Innovation Officer en Aon; Ángel Niño, Concejal en Madrid delegado de Área de Innovación y Emprendimiento, además de Presidente de MercaMadrid; y Lourdes Hernández, CEO de datahack, presentarán y explicarán en detalle lo que esta moda o revolución trae consigo y si afectará de manera positiva o negativa a nuestra vida cotidiana.
¿Es la IA y chat GPT una moda pasajera o han llegado para quedarse?
El evento constará de la siguiente estructura:
Nuestros ponentes
Pablo Montoliu
Chief Information & Innovation Officer en Aon
Ángel Niño
Concejal en Madrid delegado de Área de Innovación y Emprendimiento, y Presidente de MercaMadrid
Lourdes Hernández
CEO de datahack
¡Inscríbete al evento y no te pierdas nada!
¿Qué tienes que hacer para asistir a este #evento? Muy sencillo. Únicamente tendrás que registrarte desde este evento y esperar al día 24 de mayo (se realizará desde LinkedIn Live por lo que se deberá acceder a la plataforma de LinkedIn a la hora del evento).
Regístrate aquí gratis para asistir online:
🔵 Esta sesión será online en directo y desde la plataforma de LinkedIn Live.
🔵 Este formulario es para apuntarte a la sesión online.
🔵 Durante la sesión podrás preguntar todas las dudas que tengas al ponente y las irá respondiendo. No te quedes con ninguna duda.
🔵 Al registrarte recibirás un enlace en tu email con el que podrás conectarte a la sesión online.
Adelántate al futuro con este evento y amplia tus conocimientos de la mano de profesionales.
Tématica
BigQuery
Tiempo de lectura
5 minutos
BigQuery es un almacén de datos como servicio que nos permite cargar nuestros datos y en pocos minutos hacer consultas SQL con ellos y sacar conclusiones de una manera económica, fiable y rápida.
Esta pensado tanto para una pequeña empresa como para grandes corporaciones ya que es escalable desde unos pocos gigabytes a cientos de petabytes. Tiene la ventaja de resolver las consultas utilizando el lenguaje SQL que es ampliamente conocido y por su puesto los datos cuentan con la seguridad que Google puede ofrecer.
Están cifrados en disco y en tránsito y son durables y altamente disponibles.
Y finalmente es un servicio gestionado, es decir, no nos tenemos que preocupar ni de la infraestructura ni de las comunicaciones ni de la seguridad, Google lo hace por nosotros.
Juan Valladares
CEO in Best In BI y profesor en Datahack School
Autor del artículo
Insertar
Almacenar
Analizar
Visualizar
Las organizaciones confían en los almacenes de datos para agregar datos de fuentes dispares, procesarlos y ponerlos a disposición para el análisis de datos que respalde su toma de decisiones estratégicas.
Puede insertar datos en BigQuery mediante la carga por lotes o la transmisión de datos directamente para brindar información en tiempo real.
Como almacén de datos totalmente administrado, Google se encarga de la infraestructura para que pueda concentrarse en analizar sus datos hasta una escala de petabytes.
Almacén de datos completamente administrado
ESCALA PETABYTE
Como almacén de datos totalmente administrado, Google se encarga de la infraestructura para que pueda concentrarse en analizar sus datos hasta una escala de petabytes.
Structured Query Language (SQL)
Si desea crear modelos de aprendizaje automático con los datos de su empresa, puede hacerlo con BigQuery ML. Con solo unas pocas líneas de SQL, puede entrenar y ejecutar modelos en sus datos de BigQuery sin necesidad de moverlos.
Cuando llega el momento de visualizar sus datos, BigQuery se integra con Looker, así como con varias otras herramientas de inteligencia comercial en su ecosistema de socios.
Ahora, ¿cómo usar BigQuery? Afortunadamente, es sencillo comenzar a utilizar BigQuery.
Después de crear un proyecto de GCP, puede comenzar de inmediato a consultar conjuntos de datos públicos, que Google Cloud aloja y pone a disposición de todos los usuarios de BigQuery, o puede cargar sus propios datos en BigQuery para analizarlos.
La interacción con BigQuery para cargar datos, ejecutar consultas o incluso crear modelos ML se puede hacer de tres maneras diferentes:
1. Mediante el uso de la interfaz de usuario y la Consola en la nube.
2. Mediante el uso de la herramienta de línea de comandos de BigQuery.
3. Haciendo llamadas a la API de BigQuery usando bibliotecas de clientes disponibles en varios idiomas.
BigQuery está integrado con el servicio de administración de acceso e identidad de Google Cloud para que pueda compartir de forma segura sus datos y conocimientos analíticos en toda la organización.
Con BigQuery, paga por almacenar y consultar datos y transmitir inserciones. La carga y exportación de datos son gratuitas.
El coste de almacenamiento se basa en la cantidad de datos almacenados y tiene dos tarifas según la frecuencia con la que cambian los datos.
El coste de la consulta puede ser bajo demanda, lo que significa que se le cobra por consulta, por la cantidad de datos procesados, o puede ser fijo para los clientes que desean comprar recursos dedicados.
7 minutos
Estamos ya en el año 2023, y como podemos constatar en cualquier medio de comunicación, la inteligencia artificial vuelve a estar de moda. ¿Vuelve? Sí, porque en realidad este término se acuñó en el año 1956, y en los casi 70 años de historia que tiene ya esta rama de la tecnología, la misma ha evolucionado a una escala que difícilmente podría haberse pronosticado.
Desde sus inicios, la inteligencia artificial ha perseguido el objetivo de crear máquinas con una inteligencia similar o superior a la nuestra, con el fin de poder delegar trabajo cognitivo en ellas, o como apoyo para poder aumentar nuestra propia capacidad de pensamiento. Pero este objetivo es más un sueño que una meta bien definida porque, ¿qué es en realidad la inteligencia? ¿Cómo la definimos? Y, sobre todo, ¿cómo funcionan nuestros propios cerebros, esos que queremos imitar mediante tecnología? No lo sabemos con precisión.
Álvaro Barbero Jiménez
Chief Data Scientist del Instituto de Ingeniería del Conocimiento (IIC)
Autor del artículo
Es por esta indefinición que el foco de la IA y los métodos para abordarla han ido cambiando a lo largo de estas 7 décadas. En sus inicios, muchos investigadores en IA centraban sus esfuerzos en crear sistemas que pudieran replicar la capacidad de los humanos en tareas intelectualmente complejas: jugar al ajedrez, demostrar teoremas, realizar un diagnóstico médico en base las evidencias… se trataba de una forma concreta de implementar la IA, que hoy conocemos como sistemas expertos, y que tratan de realizar razonamientos empleando una base de datos de conocimientos y reglas, así como un sistema de inferencia basado en la lógica formal. Un ejemplo habitual de este tipo de sistemas sería el que dispone de la siguiente información:
hombre(x) ->mortal(x) (si es un hombre, entonces también es mortal)
hombre(Sócrates)= True (Sócrates es un hombre)
De lo que el sistema puede deducir mediante implicación lógica que mortal(Sócrates)=True (Sócrates es mortal). Esta clase de sistemas llegaron a utilizarse con éxito en campos como el diagnóstico de enfermedades infecciosas en la sangre. No obstante, en general este tipo de sistemas de IA resultaban ser difíciles de construir, dado que es necesario contar con expertos en la materia con los que colaborar para formalizar su conocimiento y métodos de trabajo en reglas formales. Así mismo, su mantenimiento y actualización a nuevas situaciones implicaba revisar su juego de reglas, una tarea que podía llegar a ser muy costosa en sistemas de gran tamaño.
Por otra parte, en torno a la misma época en la que se descubrían las limitaciones de los sistemas expertos, se llegó a una conclusión inesperada en cuanto al funcionamiento de la inteligencia: que las tareas que a los humanos nos resultan cognitivamente complejas, como los razonamientos matemáticos o la lógica formal, ¡son en realidad muy sencillas de implementar en un computador! Especialmente cuando se comparan contra el desafío de desarrollar una máquina con las capacidades sensoriales y motoras que puede tener cualquier niño con un desarrollo normal. Este hecho se recoge en la famosa paradoja de Moravec, y ha demostrado ser uno de los mayores obstáculos en del desarrollo de la IA: que las habilidades que a nosotros nos resultan intuitivas y naturales son las más difíciles de replicar de manera artificial.
Una alternativa a los sistemas expertos de mayor aplicabilidad práctica y que se ha desarrollado con mucha solidez desde la década de los 80 es el aprendizaje automático o machine learning. En este tipo de IAs la clave radica en recopilar el conocimiento del experto no como una serie de reglas formales, sino como ejemplos que demuestren su forma de actuar. De este modo, podemos compilar una base de datos formada por casos médicos, en la que para cada caso recogemos la información utilizada el experto médico para su examen (constantes, analíticas, etc…), así como su diagnóstico, y el sistema de IA podrá aprender a imitar su forma de proceder. Dentro de este tipo de IA caben toda una variedad de algoritmos que afrontan este problema de aprendizaje empleando diferentes aproximaciones estadísticas: vecinos próximos, árboles de decisión, métodos de ensemble, máquinas de vectores de soporte, y muchos otros más.
Uno de los métodos que ha destacado especialmente durante la última década han sido los basados en redes neuronales artificiales, hoy día también conocidos como Deep Learning. Aunque en realidad este tipo de IAs llevan en desarrollo desde incluso antes de que se acuñara el término “inteligencia artificial”, no fue hasta 2010 y años posteriores cuando se descubrieron las estrategias clave para poder construir sistemas de esta clase a gran escala: de ahí el calificativo “Deep”.
En esencia, las redes neuronales son un subtipo del aprendizaje automático, en el que una serie de neuronas artificiales imitan superficialmente el comportamiento de una neurona real, y se encargan de realizar la tarea del aprendizaje en base a los datos. Su principal ventaja frente a otros modelos de aprendizaje automático es su flexibilidad, ya que pueden construirse redes desde unas decenas de neuronas hasta miles de millones, escalando así su capacidad para aprender de bases de datos de tamaño masivo.
Además, esta flexibilidad del Deep Learning ha permitido a los investigadores en IA desarrollar “neuronas” especializadas en el tratamiento de datos no estructurados: imágenes, vídeos, textos, audio, etc… si bien esta clase de redes neuronales artificiales cada vez están más alejadas de la biología real, han demostrado ser tremendamente prácticas para abordar problemas muy complejos como son la detección de objetos de interés en imágenes (ej: personas, coches, …), la traducción automática entre idiomas, o la síntesis de voz. Con este hito se ha logrado abordar de manera muy efectiva la clase de desafíos sobre los que la paradoja de Moravec nos alertaba: aquellos que nos resultan intuitivos a nosotros, pero de difícil implementación en una máquina.
¿Y qué podemos decir de estos últimos años? Sin duda, el avance más significativo en IA ha venido de la mano de los modelos base o foundation models. Se trata de un paso más en las redes neuronales artificiales, en el que redes de inmenso tamaño aprenden a modelar la dinámica de un proceso complejo mediante el análisis de bases de datos masivas.
Por ejemplo, un modelo base del lenguaje español es aquel que aprende cómo se estructura el idioma español y cómo suele usarse, mediante el procesado de gigabytes de textos escritos en este idioma. Este modelo no persigue un objetivo concreto, más allá de asimilar la estructura del lenguaje. Pero precisamente por eso puede alimentarse de cualquier texto escrito en el idioma, sin necesidad de que este haya sido preparado y validado por un experto, abriendo así la puerta a que la red neuronal pueda aprender de… básicamente todo el material que podamos suministrarle de Internet.
La pregunta que surge entonces es, ¿y para qué sirve un modelo así, si no tiene un objetivo práctico concreto? Pues porque como indica su nombre, sirven como base para crear modelos que apliquen a tareas concretas.
Por ejemplo, un modelo base del lenguaje español puede reajustarse a la tarea de analizar las emociones expresadas en un tweet, usando un conjunto de datos de tamaño medio con ejemplos de cómo hacer esta tarea. La ventaja de esta aproximación respecto de crear una red neuronal nueva que aprenda directamente de los datos es que el modelo base adaptado tendrá una efectividad mucho mayor, y requerirá de un juego de datos más pequeño para aprender a realizar su tarea. El motivo es que el modelo base ya conoce cómo se estructura el lenguaje español, y ahora solo le queda aprender cómo extraer la emoción de un texto en español.
Puede que los modelos base nos suenen a algo extraño, pero lo cierto es que están detrás de las IAs más famosas en la actualidad: GPT-3, ChatGPT, GPT-4, DALL-E 2, Stable Diffusion, … todas ellas utilizan de alguna manera u otra este concepto, y nos demuestran cómo aprender de fuentes de datos a tamaño Internet nos lleva a un tipo de Inteligencia Artificial muy superior a los vistos hasta ahora.
Con todas estas IAs a la carrera, demostrando resultados cada vez más impresionantes, la pregunta que cabe hacerse es: ¿qué podemos esperar a partir de ahora? Internet es una fuente masiva de información, pero al mismo tiempo es limitada cuando se compara con la percepción que los humanos tenemos del mundo. Los estudios sobre modelos base han demostrado que a mayor número de datos podemos observar, mayor es la capacidad del sistema de IA resultante. Por tanto, el siguiente paso natural sería permitir que estos sistemas puedan aprender también de observaciones que hagan del mundo real, y más aún, que consigan a través de su propia experiencia. Este es el objetivo del aprendizaje por refuerzo profundo o deep reinforcement learning, el cual persigue que una red neuronal artificial pueda experimentar con su entorno y mejorar en una tarea a base de observar los resultados de sus experimentos.
Un ejemplo de este tipo de Inteligencia Artificial es AlphaZero, la cual consiguió alcanzar un rendimiento sobrehumano en el juego de tablero Go en tan solo 24 horas de aprendizaje, u OpenAI Five, que logró derrotar al equipo campeón del mundo en el e-sport DOTA2. Y fuera del mundo de los juegos, se han aplicado incluso para mejorar el control de un reactor experimental de fusión nuclear. ¿Será este el siguiente paso en la evolución de la IA? Aunque hoy día son sistemas muy costosos y complejos de aplicar en proyectos prácticos, alguna de las ideas que subyacen a su funcionamiento ya han sido incorporadas en ChatGPT y GPT-4, por lo que la tendencia parece clara.
Temática
Big Data
Tiempo de lectura
3 minutos
¿Qué es el Big Data?
Aplicaciones
Formación
Salidas profesionales
El futuro del Big Data
El Big Data es uno de los temas más relevantes en el ámbito tecnológico en la actualidad. Este término se refiere a la gran cantidad de datos que se generan a diario y que son analizados para extraer información valiosa, mediante el uso de tecnologías que permiten su gestión y análisis de forma masiva. Los datos provienen de diversas fuentes, como las redes sociales, los dispositivos móviles, los sensores, entre otros. La capacidad de procesar y analizar esta información, en muchos casos en tiempo real, es lo que hace que el Big Data sea tan importante actualmente.
En este artículo Alejandro Vaca (Data Scientist en Instituto de Ingeniería del Conocimiento (IIC)) nos va a hablar sobre la importancia del Big Data y su recorrido hasta el día de hoy.
El impacto del Big Data en nuestras vidas es innegable. Muchas de las aplicaciones que utilizamos en nuestro día a día, desde redes sociales hasta aplicaciones de transporte o compras en línea, se basan en el análisis de grandes cantidades de datos para personalizar su oferta y mejorar la experiencia del usuario. Por ejemplo, cuando utilizamos una aplicación de transporte, el Big Data se utiliza para analizar las rutas más eficientes y predecir el tiempo de llegada con precisión.
Otro ejemplo es el sector de la salud, donde el análisis de datos masivos permite a los profesionales médicos personalizar los tratamientos y las intervenciones para cada paciente, lo que se traduce en mejores resultados y una mayor eficacia. También es posible detectar patrones y tendencias en el comportamiento de los pacientes, lo que puede ayudar a prevenir enfermedades y mejorar la atención médica.
Formarse en el ámbito del Big Data es fundamental para poder aprovechar al máximo su potencial. Actualmente existen numerosos cursos, grados, diplomas y programas de postgrado enfocados en el análisis de datos masivos, lo que permite a los profesionales adquirir habilidades y conocimientos específicos para trabajar en este campo. Es importante mencionar que el Big Data no sólo requiere habilidades técnicas, sino también habilidades de análisis y pensamiento crítico para poder extraer información valiosa de los datos. Un centro de excelencia en este sentido es Datahack, un centro de formación especializado en el ámbito del Big Data y el Data Science.
El campo del Big Data ofrece múltiples salidas profesionales, ya que es una herramienta fundamental en diversos ámbitos, como la salud, el comercio electrónico, la seguridad, la educación, entre otros. En el comercio electrónico, el Big Data se utiliza para analizar el comportamiento de los consumidores y personalizar las recomendaciones de productos y servicios. En la seguridad, el Big Data se utiliza para analizar grandes cantidades de información de seguridad y predecir posibles amenazas y riesgos. En la educación, el Big Data se utiliza para analizar los resultados de los estudiantes y personalizar la enseñanza para adaptarse a las necesidades de cada uno.
La importancia del Big Data continuará creciendo en el futuro próximo. Cada vez se generan más datos y se espera que en los próximos años se produzca un aumento exponencial en la cantidad de información que se recopila. Además, la capacidad de analizar y procesar grandes cantidades de datos se está volviendo cada vez más importante en el mundo empresarial y gubernamental. Por lo tanto, es fundamental que los profesionales se formen en el campo del Big Data, pues el impacto y la presencia de estas tecnologías en la vida de las personas irá en aumento.
En conclusión, el Big Data es un tema de gran relevancia en la actualidad y su importancia continuará creciendo en el futuro. Formarse en este ámbito ofrece numerosas oportunidades profesionales y permite aprovechar al máximo su potencial para mejorar diversas áreas de la sociedad. Además, el Big Data tiene un impacto directo en nuestras vidas y en la forma en que interactuamos con el mundo que nos rodea. Desde las aplicaciones móviles hasta la atención médica personalizada, el análisis de grandes cantidades de datos nos permite tomar mejores decisiones y mejorar nuestra calidad de vida.
Alejandro Vaca (Data Scientist en Instituto de Ingeniería del Conocimiento (IIC))
Atrévete a formarte con nuestro Máster Experto en Data Science y Big Data
Una formación 100% online y adaptada a ti para que te conviertas en un especialista en Inteligencia de Negocio
¡Si te ha gustado el contenido de este artículo no te olvides de suscribirte a la newsletter!
En este artículo creado por Pablo Sainz de Vicuña, profesor de visualización de datos en el master de Big Data &Analytics de datahack, conoceremos de su propia mano la herramienta Tableau:
Tableau es una herramienta de visualización de datos líder del mercado que se caracteriza por su fácil aprendizaje, es muy sencillo comenzar a extraer información con ella y representar los datos de forma eficiente. Además permite jugar con los datos de origen pudiendo crear tus propios campos calculados, dicho código también resulta bastante sencillo de codificar y de aprender
Me gustaría compartir un proyecto que realicé cuando comencé a trabajar con Tableau que me dio la oportunidad de combinar dos de mis aficiones, el Golf y la Visualización de datos. Seguro que todos habéis oído hablar de un torneo de Golf en el que el premio es una chaqueta verde, pues bien, este torneo es el más prestigioso del mundo y se llama Masters de Augusta.
Mi idea consistía en crear un cuadro de mando que nos permitiese explorar la clasificación así como los jugadores, los hoyos y los golpes realizados. Una idea ambiciosa por dos grandes motivos, primero, mi desconocimiento de la herramienta, la había utilizado en el master y poco más, y segundo, de donde sacaría los datos.
El primero de los problemas se podía solventar a base de trabajo, investigación y perseverancia, el segundo…es más complicado, estuve buscando bases de datos pero nunca encontré nada que se asemejara a los que buscaba por lo que si quería llevar a cabo mi proyecto tendría que conseguir los datos por mí mismo. Para ello podía ponerme a escribir los datos a mano, algo imposible e ineficiente, o podía utilizar una de las técnicas que aprendí durante el master, web scrapping, esta técnica consiste en sacar la información de una página web aprovechando el código HTML de la misma.
Visité la página oficial del torneo y comprobé que podía extraer toda la información de ella, por ejemplo, la siguiente imagen muestra la clasificación:
Y su código es el siguiente:
Podemos ver que esta página tiene una estructura que podemos aprovechar y llegar al dato que necesitamos, si nos fijamos en la línea sombreada en azul aparece el nombre del jugador en la segunda línea de la clasificación, así como sus valores en las líneas siguientes.
Localizada la fuente de datos ahora tocaba empezar a trabajar, no soy ningún experto en la programación pero si algo había aprendido durante el master de datahack era a investigar. Encontré una librería que nunca había utilizado de web scrapping llamada “Selenium” y comencé a hacer pruebas en un notebook de jupyter utilizando python como lenguaje. Pronto empecé a ver resultados satisfactorios ya que obtuve mucha información rápidamente.
Este es es script que utilicé para obtener los jugadores:
En él se puede ver que primero buscaba el listado de jugadores para después recorrer este listado con cada jugador y obtener sus datos (Player ID, Nombre, Altura, Peso, Edad, Pais, Descripción y Mejor resultado).
También aprovechamos la web para descargar las imágenes de los jugadores y de los hoyos para poder utilizarlas en nuestro cuadro de mando.
Más sencillo resultó el script para extraer la información de los hoyos:
Para cada hoyo obtenemos su Número, Nombre, Par (golpes con los que se debería hacer el hoyo), Distancia y Descripción.
Por último faltaba obtener cada golpe realizado por cada jugador, este script requirió más trabajo ya que el código resultaba más complejo, su tiempo de ejecución era muy elevado y afinarlo fue bastante tedioso, pero finalmente logré el dataset que buscaba:
De cada golpe obtuve el PlayerID, Ronda, Golpe, Distancia, Unidad de distancia, Distancia al hoyo, Unidad de distancia al hoyo, X, Y, X Origen, Y Origen. ¡Ya tenía todo lo necesario para representarlo en Tableau!
Lo primero al entrar en Tableau es crear la fuente de datos, en este caso resultó bastante sencilla debida a la labor previa que hicimos con la extracción en Python.
Simplemente unimos la tabla principal Golpes con Jugadores y Hoyos.
Utilizando la función de pivotar en la fuente de datos conseguimos juntar los puntos X e Y de origen y destino en una misma medida pudiéndolos diferenciar mediante una dimensión Origen/Destino. Esto iba a resultar imprescindible para el gráfico principal del dashboard, el shottracker.
SHOT TRACKER
La construcción del gráfico principal resultó bastante compleja, una vez resuelto el problema de unificar el origen y destino de las coordenadas en la fuente la construcción del gráfico no resulta demasiado compleja.
La hoja está compuesta por un gráfico de puntos y un gráfico de líneas en eje doble con la ronda en color, el tiro en texto, el jugador y el hoyo en detalle.
Lo que faltaba era conseguir cambiar la imagen del hoyo dinámicamente en función de la selección realizada. Para ello encontré una solución que consistía en editar las imágenes en segundo plano del el menú de Mapa.
Una vez dentro se creaban todas las imágenes una a una incluyendo un filtro personalizado en el que seleccionábamos el hoyo correspondiente.
Conseguir esta hoja me llevó una enorme labor de investigación para replicar todos los efectos deseados.
CLASIFICACIÓN
A simple vista no parece una gráfica muy compleja. Es un mapa de calor que cuenta los golpes por ronda de cada jugador. La dificultad vino de conseguir que ese cálculo fuese correcto, en esa etapa no sabía manejar las expresiones en nivel de detalle que ofrece Tableau, estas expresiones son parecido a subconsultas que se pueden hacer a la fuente de datos original para fijar el valor en una dimensión. Son unos de los conceptos más complejos de Tableau y comprenderlos lleva su tiempo, pero necesitaba utilizarlos así que tocaba de nuevo investigar y probar hasta conseguir el resultado deseado, finalmente lo conseguí con un campo calculado que a día de hoy tardaría segundos en hacer pero que en aquel momento me pudo llevar un par de días de prueba y error.
Para conseguir el color también necesite otros campos calculados:
PANEL DE JUGADOR SELECCIONADO
En función del jugador que se selecciona en el panel de clasificación cambia el panel del jugador con su nombre y su foto.
Este efecto requiere un trabajo bastante laborioso por detrás, primero hay que tener todas las imágenes guardadas en una carpeta dentro de la siguiente ruta:
C:\Users\My_User\Documents\Mi Repositorio de Tableau\Formas
Al reiniciar Tableau veremos que si creamos un gráfico de formas nos ofrece las que están dentro de la carpeta recién creada. Después hay que asignar manualmente cada foto a cada jugador.
Crear la gráfica es sencillo ya que únicamente requiere incluir los jugadores en Forma y mediante una acción de filtro en el dashboard conseguimos ver únicamente el jugador seleccionado.
En el tooltip del jugador podemos ver otros cálculos interesantes como la máxima distancia del drive y su promedio.
El número de greenes cogidos, se considera el número de golpes que se deberían dar para llegar al Green, en un par 4 serían dos golpes; para calcular esto nos basamos en las unidades que nos ofrece el dataset:
Si el golpe tiene una distancia en yardas es un golpe desde fuera de Green, mientras que si están en pies o pulgadas es un Putt.
Siguiendo esta lógica también se calcula el número de putts por ronda realizados. Una vez construidas las hojas monté todo en el dashboard de incluí las acciones de filtro necesarias para que todo respondiese correctamente.
Creo que lo más interesante de este proyecto es lo mucho que aprendí de Tableau partiendo desde cero, buscando ejemplos que me sirviesen a mi dashboard, utilizando fórmulas que nunca había realizado, queriendo crear gráficas que no sabía hacer, y pudiendo juntar dos de mis pasiones todo se hace más fácil.
Pablo Sainz de Vicuña Data Analyst Senior en Inetum • Profesor Visualización en datahack school •
¡Si te ha gustado el contenido de este artículo no te olvides de suscribirte a la newsletter!
En este artículo creado por José Manuel Sanz Candales , vamos a conocer qué es el DLR.
Los gestores de las redes eléctricas de transporte y distribución deben tener en cuenta los valores de capacidad de sus líneas eléctricas para cumplir con las normas establecidas al respecto. Tradicionalmente se han utilizado valores constantes estacionales, pero el avance de la tecnología está haciendo evolucionar estos valores hacia el cálculo dinámico de la capacidad de las líneas (DLR).
El DLR (Dynamic Line Rating) se basa en la estimación en tiempo real de la capacidad de las líneas de transporte de energía eléctrica (CdT), en función de distintas variables medibles (condiciones climáticas, medidas de temperatura del conductor en tiempo real, flecha del vano, etc.) así como su previsión para períodos futuros. En contraposición se encuentra el uso de una CdT estacional, con variables climatológicas fijas en cada estación, que, por lo general, resulta más conservadora, y que es la que se ha venido utilizando de manera generalizada en la actualidad.
Simplificadamente, hacer DLR consiste en predecir o calcular la intensidad máxima que puede transportar una línea en un periodo de tiempo determinado, atendiendo al valor de ciertas variables ambientales instantáneas, respetando en todo momento los límites térmicos de la instalación, y, en consecuencia, garantizando las distancias de seguridad establecidas en los reglamentos, sin provocar en la instalación ni una degradación ni un envejecimiento prematuro, al ser siempre las condiciones de funcionamiento coherentes con límites técnicos, como puede ser el fenómeno de recocido en los materiales.
La CdT de una línea aérea vendrá marcada por el vano (tramo entre dos apoyos consecutivos) que primero incumpla los límites mencionados anteriormente. En consecuencia, operar líneas con DLR significa estimar y monitorizar las condiciones de la línea a lo largo de todo su trazado, realizar un tratamiento de la información para determinar la intensidad máxima admisible en cada instante, así como establecer modelos de previsión que permitan predecir los valores estimados de capacidad de transporte para las próximas horas u otros horizontes de más largo plazo.
Para disponer de una predicción de capacidad de transporte, es necesario disponer de predicciones de variables medioambientales. De estas variables, la que más impacto tiene por su variabilidad e influencia es el viento. Obtener previsiones de viento con precisión suficiente es complejo y la Inteligencia Artificial puede ser de gran ayuda en este ámbito. Adicionalmente, dado que el viento es uno de los mayores problemas de la red de transporte en cuanto a averías graves por caída de torres y conductores, una estimación precisa y con antelación suficiente, ayudará también tanto en la optimización del diseño de apoyos como para predecir posibles afecciones por cambio en condiciones ambientales o de comportamiento de las supuestas en históricos.
Para entrenar estos modelos de IA, se requiere disponer de datos históricos de estaciones meteorológicas que recojan los valores reales en determinados puntos de las líneas eléctricas. Adicionalmente, la recepción de los datos de dichas estaciones meteorológicas en tiempo real (mediante uso de IoT) en los sistemas de predicción, permite utilizarlas para realizar predicciones más precisas en los primeros horizontes (< 6 horas) utilizando, por ejemplo, Redes Neuronales Recurrentes.
Jose Manuel Sanz Candales
Científico de Datos - Departamento de Modelos para la Operación del Sistema en Red Eléctrica
¡Si te ha gustado el contenido de este artículo no te olvides de suscribirte a la newsletter!
En este artículo creado por Rafael Garrote Hernández, vamos a conocer más a fondo el Snowflake.
El ecosistema de almacenes de datos está en continuo crecimiento y cada poco oímos de un nuevo miembro de la familia. En este caso quiero hablaros de Snowflake, que recoge la tradición de las bases de datos específicas para crear un data Warehouse y la actualiza para adecuarse a los tiempos que imperan, haciéndola nativa al cloud, con capacidades para gestionar grandes volúmenes de datos y con capacidades de procesamiento en streaming.
Snowflake, como su propio nombre indica, es una base de datos pensada para albergar los modelos de datos dimensionales tradicionales de un data warehouse, copo de nieve, data mart, pero además permite adecuarse a las necesidades para crear modelos más actuales como data vaults o data hubs. Sus principales características son que está diseñada para trabajar de forma nativa en los principales proveedores de infraestructura y que separa la capa de almacenamiento de datos de la capa de procesamiento de datos. Son precisamente estas dos características las que hacen que Snowflake pueda gestionar volúmenes de datos mucho más grandes que sus predecesoras. Vamos a ver sus características más en detalle.
Arquitectura
Snowflake está diseñada en una arquitectura con tres capas; la capa de almacenamiento que se encarga de persistir el dato y gestionar las micro particiones, una capa de procesamiento de datos independiente al resto organizada en clusters aislados de máquinas que trabajan sobre el conjunto de datos y por último la capa de servicios cloud entre los que encontramos la autorización, la gestión de la infraestructura, gestión de metadatos, control de accesos, seguridad y parseo y optimización de consultas.
Almacenamiento de datos
Como capa de almacenamiento Snowflake utiliza el sistema de almacenamiento del proveedor de infraestructura, AWS S3, Azure Blob Storage y Google Cloud Storage respectivamente. De esta manera, podemos utilizar estos almacenamientos como capa de staging desde la que cargar los datos de forma sencilla en Snowflake.
Permite almacenar tanto datos estructurados como semiestructurados y con soporte nativo para formatos abiertos de datos: JSON, XML, CSV, Avro, Parquet, ORC, etc.
El almacenamiento está orientado a columnas lo que la hace idónea para ejecutar trabajos de tipo analítico tradicionales de un data warehouse y además permite particionado de las tablas.
Y por último es transaccional y ACID, dos características muy valiosas y que no encontramos en todos los competidores.
Micro Particionado
Snowflake basa su almacenamiento en lo que él denomina micro particiones que gestiona de forma automática y transparente para el usuario. Las tablas se particionan de forma transparente utilizando el orden de carga o inserción de los datos creando particiones de 50 a 500 MB.
Para esas consultas que necesitan más rendimiento o para gestionar volúmenes de datos más grandes, Snowflake nos permite modificar el comportamiento por defecto del micro particionado y gestionar estas particiones para optimizar las consultas sobre conjuntos de datos más grandes especificando la clave de particionado con la cláusula CLUSTER BY tanto al crear la tabla como al modificarla. De esta manera podremos indicar qué campo o campos queremos utilizar como clave de particionado para crear unas particiones acordes al patrón de acceso al dato optimizando por tanto el rendimiento de las consultas.
Time travel
El almacenamiento de datos de Snowflake permite indicar un tiempo de retención a los datos entre 1 y 90 días, de tal forma que se puede consultar el estado de los datos en un punto anterior en el tiempo, por ejemplo, antes de que hayan sido modificados o borrados. También permite clonar o recuperar tablas en un punto en concreto en el pasado, incluso si se han borrado.
Adicionalmente al tiempo de retención del time travel, se le puede indicar a Snowflake un tiempo adicional de como máximo 7 días, en los que guardará los datos de las tablas para poder recuperarse de fallos eventuales. Estos datos sólo son recuperables por Snowflake y no se pueden consultar hasta su recuperación. Este tiempo de fail-safe empieza a contar justo después de que termine el tiempo de retención del time travel.
Capa de computación
Como se ha indicado antes, la capa de procesamiento está separada de la capa de almacenamiento y consta de uno o varios clusters de máquinas encargados de realizar las tareas de cómputo sobre los datos. Estos clusters se denominan Virtual Warehouses y podemos crear tantos como necesitemos. Idealmente crearemos uno por tipología de procesos que realicemos sobre los datos. Por ejemplo podemos tener un Virtual Warehouse para realizar las tareas de ETL y otro para los procesos de ciencia de datos. De esta manera garantizamos los recursos necesarios para cada uno de estos procesos ya que los Virtual Warehouses no comparten recursos entre sí.
Estos clusters se pueden configurar para que crezcan o decrezcan de forma elástica según la demanda de carga en cada momento y además se pueden auto suspender y reiniciar según las necesidades para hacer una correcta gestión de los recursos y del coste de la infraestructura.
Snowflake no sólo está pensada para ejecutar sentencias de consulta, sino que al igual que sus predecesoras, permite realizar procesos de Extracción Carga y Transformación (ELT) para realizar las transformaciones de los datos e integrarlos en el modelo dimensional creado. Para ello permite encadenar las sentencias para ejecutarlas en un orden específico y bajo ciertas condiciones.
Cada sentencia SQL es una tarea o task y estas task se pueden encadenar formando un árbol de ejecución. Este árbol representa el pipeline de ejecución de una ELT. Una Task se puede programar para ser ejecutada de forma periódica o como consecuencia de una Task anterior. Esto que permite encadenar Task en función del resultado anterior en lo que se denomina Tasks condicionales.
Adquisición o ingesta de datos
Para ingestar datos en Snowflake, esta hace uso del almacenamiento de datos nativo del cloud, así por ejemplo en AWS S3, dejaríamos los ficheros con el dato en bruto a ingestar en un bucket de S3. Indicaremos a snowflake que use ese bucket como staging, creamos la tabla que alojará estos datos y le decimos a Snowflake que copie los datos del staging a la tabla. Una vez que los datos ya están en Snowflake podemos crear los pipelines necesarios para transformar e integrar el dato según nuestras necesidades.
Además de este procesamiento de datos por lotes o en batch, Snowflake provee de un mecanismo para la ingesta de datos en streaming y/o tiempo real que denomina Snowpipe.
Snowpipe permite quedarse escuchando un fichero de la capa de almacenamiento de la infraestructura, por ejemplo AWS S3 y cada nueva inserción en este fichero, automáticamente se insertarla en la tabla de destino. Otra opción es utilizar el conector de Kafka que permite conectar Snowflake a Kafka para consumir los mensajes que se vayan almacenando en los topics de Kafka.
Junto con estos mecanismos de ingesta en streaming, Snowflake dispone de un conjunto de operaciones de ventana para poder realizar operaciones de transformación y cálculo en streaming.
A parte de todas estas funcionalidades Snowflake provee las siguientes capacidades:
Por todo lo que hemos visto en este artículo Snowflake moderniza los sistemas de bases de datos tradicionales para data Warehouses, actualizándose a las necesidades actuales del mercado convirtiéndose en una tendencia al alza sobre todo si se busca una alternativa que te independice del proveedor de infraestructura considerándola una alternativa a tener en cuenta a la hora de diseñar nuestro sistema informacional.
¡Si te ha gustado el contenido de este artículo no te olvides de suscribirte a la newsletter!
En este artículo creado por Héctor Escaso Gil, vamos a crear una red neuronal que nos sirva de clasificador de imágenes para algunas de las razas que habitan la tierra media.
Vamos a crear un dataset de imágenes de 5 razas del universo Tolkien: Orcos, Elfos, Enanos, Hobbits y Magos.
El principal problema que tenemos, es que contamos con un reducido número de imágenes, unas 200 de cada raza. Para solucionar esto, vamos a utilizar dos técnicas:
Transfer Learning -> Entrenar con tan pocas imágenes es un problema, ya que el modelo tiene pocos ejemplos para su aprendizaje, por lo que utilizaremos la red neuronal preentrenada “mobilenet_2”. Eliminaremos la capa de salida e incluiremos una nueva que se adapte a nuestro modelo.
Data Augmentation -> Aunque contemos con una red preentrenada muy potente, necesitamos entrenar la última capa. Así que utilizaremos esta técnica con la generaremos un mayor número de imágenes para nuestro entrenamiento.
Una vex hayamos entrenado nuestro modelo haremos algunas predicciones usando imágenes de prueba.
Comencemos con el ejercicio
1. Creación del dataset
Para crear nuestro dataset, vamos a buscar las imágenes directamente en google. Haremos una búsqueda por cada una de las razas y nos descargaremos todas las imágenes fácilmente con la extensión de Chrome Download All Images.
Tras esto limpiaremos nuestras imágenes, eliminando duplicados y borrando las que no nos sirvan para nuestro entrenamientos. Yo he seleccionado exactamente 200 por cada raza.
2. Descarga y preparación de los datos
Os dejo las imágenes que he utilizado en mi repositorio.
Tengo las imágenes en el drive, así que permito acceder a mis archivos desde colab.
from google.colab import drive
drive.mount('/content/drive')Mounted at /content/driveTras esto, entro en cada carpeta y descomprimo los archivos zip
!unzip /content/drive/MyDrive/ClasificadorImagenes/Elfos.zip
!unzip /content/drive/MyDrive/ClasificadorImagenes/Enanos.zip
!unzip /content/drive/MyDrive/ClasificadorImagenes/Magos.zip
!unzip /content/drive/MyDrive/ClasificadorImagenes/Orcos.zip
!unzip /content/drive/MyDrive/ClasificadorImagenes/Hobbits.zipRevisamos que la descarga haya sido correcta, mostrando el número de imágenes en cada carpeta.
#Mostrar cuantas imagenes tengo de cada categoria
!ls /content/Elfos | wc -l
!ls /content/Magos | wc -l
!ls /content/Orcos | wc -l
!ls /content/Hobbits | wc -l
!ls /content/Enanos | wc -l 200
200
200
200
200Una vez comprobado que la descarga ha sido correcta, elimino la conexión con drive.
drive.flush_and_unmount()Vamos a ver alguna imágenes a ver qué pinta tienen.
# Utilizaremos pyplot
import os
import matplotlib.pyplot as plt
import matplotlib.image as mpimg
plt.figure(figsize=(15,15))
carpeta = '/content/Hobbits'
imagenes = os.listdir(carpeta)
for i, nombreimg in enumerate(imagenes[:25]):
plt.subplot(5,5,i+1)
imagen = mpimg.imread(carpeta + '/' + nombreimg)
plt.imshow(imagen)
Instalamos 2 librerías que vamos a necesitar.
!pip install split-folders
!pip install pytest-shutilVamos a utilizar la librería splitfolders para separar nuestras imágenes en train, test y validación. Esta librería coge todas las carpetas que haya y crea 3 carpetas nuevas por cada una de ellas con la proporción de imágenes que le indiquemos.
Como tenemos la carpeta “sample_data” que se genera automáticamente y no la necesitamos, la vamos a eliminar previamente.
import shutil
shutil.rmtree('/content/sample_data') # Eliminamos la carpeta sample_dataTras esto, hacemos la división de las imágenes entre train, validation y test.
import splitfolders
splitfolders.ratio('/content', output = "dataset", ratio=(0.78, 0.2, 0.02)) # Haremos copia de la imágenes y las dividiremos en 3 carpetas dentro de "dataset".Copying files: 1003 files [00:00, 5322.86 files/s]Comprobamos una carpeta para ver que se haya realizado correctamente.
!ls /content/dataset/train/Elfos | wc -l
!ls /content/dataset/val/Elfos | wc -l
!ls /content/dataset/test/Elfos | wc -l 156
40
4Se ha creado un archivo .config en cada una de las carpetas. Los eliminamos porque sino aparecerían como una clase más e interferiría en el entrenamiento.
!rm -rf /content/dataset/train/.config
!rm -rf /content/dataset/val/.config
!rm -rf /content/dataset/test/.config3. Data Augmentation
Está técnica se basa en la creación de nuevas imágenes partiendo de los datos antiguos con los que contamos. En este caso haciendo zoom de las imágenes, reescalandolas, realizando un flip horizontal, etc…
Vamos a utilizar ImageDataGenerator para crear nuestros generadores de imágenes para los sets de entrenamiento y validación, aunque en la validación lo único que haremos será reescalar las imágenes.
#Aumento de datos con ImageDataGenerator
from tensorflow.keras.preprocessing.image import ImageDataGenerator
import numpy as np
#Crear el dataset generador
train_datagen = ImageDataGenerator(
rescale=1. / 255,
rotation_range = 30,
width_shift_range = 0.25,
height_shift_range = 0.25,
shear_range = 15,
zoom_range = [0.5, 1.5],
#validation_split = 0.2 -> En este caso no modificamos las imágenes de validación.
)
validation_datagen = ImageDataGenerator(rescale=1. / 255)
#Generadores para sets de entrenamiento y pruebas
data_gen_train = train_datagen.flow_from_directory('/content/dataset/train', target_size=(224,224),
batch_size=32, shuffle=True)
data_gen_val = validation_datagen.flow_from_directory('/content/dataset/val', target_size=(224,224),
batch_size=32, shuffle=True)
Found 780 images belonging to 5 classes.
Found 200 images belonging to 5 classes.Vamos a imprimir unas imágenes aleatorias para ver como funciona nuestro generador.
#Imprimir 10 imagenes del generador de entrenamiento
for imagen, etiqueta in data_gen_train:
for i in range(10):
plt.subplot(2,5,i+1)
plt.xticks([])
plt.yticks([])
plt.imshow(imagen[i])
break
plt.show()
4. Creación del modelo
Lo primero que vamos a hacer es buscar en tensorflow hub la red mobilenet_2. En este caso nos facilitan las cosas y tenemos la red ya empaquetada pero sin la capa de salida. Es el modo “feature_vector”.
La descargamos
import tensorflow as tf
import tensorflow_hub as hub
url = "https://tfhub.dev/google/tf2-preview/mobilenet_v2/feature_vector/4"
mobilenetv2 = hub.KerasLayer(url, input_shape=(224,224,3))Para no desaprovechar el entrenamiento que se ha realizado con esta red, congelamos todas las capas entrenadas.
mobilenetv2.trainable = FalseCreamos nuestro modelo con la red que nos hemos descargado añadiendo una capa densa de salida, de 5 neuronas, con activación softmax que es la que se suele utilizar en los casos de clasificación.
modelo = tf.keras.Sequential([
mobilenetv2,
tf.keras.layers.Dense(5, activation='softmax')
])Vemos el resumen del modelo que hemos creado.
modelo.summary()Model: "sequential"
_________________________________________________________________
Layer (type) Output Shape Param #
=================================================================
keras_layer (KerasLayer) (None, 1280) 2257984
dense (Dense) (None, 5) 6405
=================================================================
Total params: 2,264,389
Trainable params: 6,405
Non-trainable params: 2,257,984
_________________________________________________________________Compilamos nuestro modelo. Utilizamos el optimizador adam, para la función de pérdida seleccionamos categorical_crossentropy y por último como métrica accuracy.
modelo.compile(
optimizer='adam',
loss='categorical_crossentropy',
metrics=['accuracy']
)Antes de entrenar nuestro modelo definimos un par de callbacks para intentar afinar nuestro modelo.
Incluimos EarlyStopping para que al pasar más de 8 epochs sin que la función de pérdida disminuya, el entrenamiento se detenga. También incluimos ReduceLROPlateau para que modifique la tasa de aprendizaje pero en este caso en 4 epochs.
from keras.callbacks import EarlyStopping, ReduceLROnPlateau, ModelCheckpoint, Callback
early_stop = EarlyStopping(monitor='val_loss', patience=8, verbose=1, min_delta=1e-4)
reduce_lr = ReduceLROnPlateau(monitor='val_loss', factor=0.1, patience=4, verbose=1, min_delta=1e-4)
callbacks_list = [early_stop, reduce_lr] Entrenamos nuestro modelo durante 50 épocas.
#Entrenar el modelo
EPOCAS = 50
historial = modelo.fit(
data_gen_train,
epochs= EPOCAS,
batch_size= 32,
validation_data= data_gen_val,
callbacks= callbacks_list
)Epoch 1/50
25/25 [==============================] - 29s 553ms/step - loss: 1.6465 - accuracy: 0.3064 - val_loss: 1.2034 - val_accuracy: 0.4800 - lr: 0.0010
Epoch 2/50
25/25 [==============================] - 13s 517ms/step - loss: 1.2504 - accuracy: 0.4962 - val_loss: 0.9545 - val_accuracy: 0.6400 - lr: 0.0010
Epoch 3/50
25/25 [==============================] - 13s 518ms/step - loss: 1.0655 - accuracy: 0.5564 - val_loss: 0.8287 - val_accuracy: 0.6900 - lr: 0.0010
Epoch 4/50
25/25 [==============================] - 16s 654ms/step - loss: 0.9625 - accuracy: 0.6333 - val_loss: 0.7622 - val_accuracy: 0.7300 - lr: 0.0010
Epoch 5/50
25/25 [==============================] - 13s 521ms/step - loss: 0.8724 - accuracy: 0.6641 - val_loss: 0.7374 - val_accuracy: 0.7200 - lr: 0.0010
Epoch 6/50
25/25 [==============================] - 13s 517ms/step - loss: 0.8747 - accuracy: 0.6474 - val_loss: 0.6525 - val_accuracy: 0.7600 - lr: 0.0010
Epoch 7/50
25/25 [==============================] - 13s 515ms/step - loss: 0.8304 - accuracy: 0.6603 - val_loss: 0.6433 - val_accuracy: 0.7600 - lr: 0.0010
Epoch 8/50
25/25 [==============================] - 13s 525ms/step - loss: 0.7791 - accuracy: 0.7192 - val_loss: 0.6277 - val_accuracy: 0.7800 - lr: 0.0010
Epoch 9/50
25/25 [==============================] - 13s 529ms/step - loss: 0.7142 - accuracy: 0.7500 - val_loss: 0.6079 - val_accuracy: 0.7850 - lr: 0.0010
Epoch 10/50
25/25 [==============================] - 13s 518ms/step - loss: 0.6840 - accuracy: 0.7321 - val_loss: 0.6077 - val_accuracy: 0.7550 - lr: 0.0010
Epoch 11/50
25/25 [==============================] - 13s 513ms/step - loss: 0.7069 - accuracy: 0.7282 - val_loss: 0.5746 - val_accuracy: 0.7950 - lr: 0.0010
Epoch 12/50
25/25 [==============================] - 13s 523ms/step - loss: 0.6649 - accuracy: 0.7500 - val_loss: 0.5767 - val_accuracy: 0.8000 - lr: 0.0010
Epoch 13/50
25/25 [==============================] - 13s 521ms/step - loss: 0.6841 - accuracy: 0.7474 - val_loss: 0.5574 - val_accuracy: 0.7850 - lr: 0.0010
Epoch 14/50
25/25 [==============================] - 13s 519ms/step - loss: 0.6286 - accuracy: 0.7705 - val_loss: 0.5336 - val_accuracy: 0.8000 - lr: 0.0010
Epoch 15/50
25/25 [==============================] - 13s 519ms/step - loss: 0.6390 - accuracy: 0.7628 - val_loss: 0.5323 - val_accuracy: 0.8100 - lr: 0.0010
Epoch 16/50
25/25 [==============================] - 13s 517ms/step - loss: 0.6009 - accuracy: 0.7833 - val_loss: 0.5202 - val_accuracy: 0.8050 - lr: 0.0010
Epoch 17/50
25/25 [==============================] - 13s 520ms/step - loss: 0.6138 - accuracy: 0.7718 - val_loss: 0.5191 - val_accuracy: 0.8000 - lr: 0.0010
Epoch 18/50
25/25 [==============================] - 13s 521ms/step - loss: 0.6067 - accuracy: 0.7833 - val_loss: 0.5235 - val_accuracy: 0.8250 - lr: 0.0010
Epoch 19/50
25/25 [==============================] - 13s 520ms/step - loss: 0.5915 - accuracy: 0.7821 - val_loss: 0.5250 - val_accuracy: 0.8250 - lr: 0.0010
Epoch 20/50
25/25 [==============================] - 13s 518ms/step - loss: 0.5729 - accuracy: 0.7987 - val_loss: 0.5177 - val_accuracy: 0.8000 - lr: 0.0010
Epoch 21/50
25/25 [==============================] - 13s 517ms/step - loss: 0.5508 - accuracy: 0.7962 - val_loss: 0.5142 - val_accuracy: 0.8000 - lr: 0.0010
Epoch 22/50
25/25 [==============================] - 13s 527ms/step - loss: 0.5802 - accuracy: 0.7885 - val_loss: 0.5322 - val_accuracy: 0.8000 - lr: 0.0010
Epoch 23/50
25/25 [==============================] - 13s 513ms/step - loss: 0.5815 - accuracy: 0.7974 - val_loss: 0.5090 - val_accuracy: 0.8050 - lr: 0.0010
Epoch 24/50
25/25 [==============================] - 15s 614ms/step - loss: 0.5397 - accuracy: 0.8064 - val_loss: 0.5141 - val_accuracy: 0.8200 - lr: 0.0010
Epoch 25/50
25/25 [==============================] - 13s 531ms/step - loss: 0.5252 - accuracy: 0.8103 - val_loss: 0.5360 - val_accuracy: 0.8150 - lr: 0.0010
Epoch 26/50
25/25 [==============================] - 13s 524ms/step - loss: 0.5526 - accuracy: 0.7910 - val_loss: 0.4965 - val_accuracy: 0.8250 - lr: 0.0010
Epoch 27/50
25/25 [==============================] - 13s 517ms/step - loss: 0.5777 - accuracy: 0.7756 - val_loss: 0.4837 - val_accuracy: 0.8150 - lr: 0.0010
Epoch 28/50
25/25 [==============================] - 13s 521ms/step - loss: 0.5323 - accuracy: 0.8000 - val_loss: 0.5096 - val_accuracy: 0.8150 - lr: 0.0010
Epoch 29/50
25/25 [==============================] - 13s 516ms/step - loss: 0.5434 - accuracy: 0.7923 - val_loss: 0.5274 - val_accuracy: 0.8100 - lr: 0.0010
Epoch 30/50
25/25 [==============================] - 13s 512ms/step - loss: 0.5127 - accuracy: 0.8141 - val_loss: 0.5095 - val_accuracy: 0.8250 - lr: 0.0010
Epoch 31/50
25/25 [==============================] - ETA: 0s - loss: 0.4902 - accuracy: 0.8269
Epoch 31: ReduceLROnPlateau reducing learning rate to 0.00010000000474974513.
25/25 [==============================] - 13s 517ms/step - loss: 0.4902 - accuracy: 0.8269 - val_loss: 0.5002 - val_accuracy: 0.8400 - lr: 0.0010
Epoch 32/50
25/25 [==============================] - 13s 516ms/step - loss: 0.4964 - accuracy: 0.8167 - val_loss: 0.4903 - val_accuracy: 0.8500 - lr: 1.0000e-04
Epoch 33/50
25/25 [==============================] - 13s 508ms/step - loss: 0.4725 - accuracy: 0.8333 - val_loss: 0.4877 - val_accuracy: 0.8250 - lr: 1.0000e-04
Epoch 34/50
25/25 [==============================] - 13s 507ms/step - loss: 0.4926 - accuracy: 0.8385 - val_loss: 0.4862 - val_accuracy: 0.8400 - lr: 1.0000e-04
Epoch 35/50
25/25 [==============================] - ETA: 0s - loss: 0.4591 - accuracy: 0.8269
Epoch 35: ReduceLROnPlateau reducing learning rate to 1.0000000474974514e-05.
25/25 [==============================] - 13s 515ms/step - loss: 0.4591 - accuracy: 0.8269 - val_loss: 0.4869 - val_accuracy: 0.8300 - lr: 1.0000e-04
Epoch 35: early stoppingParece que tras 35 épocas la función de pérdida no disminuye, por lo que el entramiento se detiene.
Vamos a ver gráficamente como se han comportado la función de pérdida y el accuracy con datos de entrenamiento y validación.
#Graficas de precisión
acc = historial.history['accuracy']
val_acc = historial.history['val_accuracy']
loss = historial.history['loss']
val_loss = historial.history['val_loss']
rango_epocas = range(35)
plt.figure(figsize=(8,8))
plt.subplot(1,2,1)
plt.ylim(0, 1)
plt.plot(rango_epocas, acc, label='Precisión Entrenamiento')
plt.plot(rango_epocas, val_acc, label='Precisión Pruebas')
plt.legend(loc='lower right')
plt.title('Precisión de entrenamiento y pruebas')
plt.subplot(1,2,2)
plt.ylim(0, 1)
plt.plot(rango_epocas, loss, label='Pérdida de entrenamiento')
plt.plot(rango_epocas, val_loss, label='Pérdida de pruebas')
plt.legend(loc='upper right')
plt.title('Pérdida de entrenamiento y pruebas')
plt.show()
Podemos ver que el modelo se comporta correctamente, llegando a una accuracy de 0.85 con los datos de validación. El modelo nos puede servir.
5. Predicciones
Lo primero que vamos a ver es la etiqueta que se ha asignado a cada una de las razas.
data_gen_train.class_indices{'Elfos': 0, 'Enanos': 1, 'Hobbits': 2, 'Magos': 3, 'Orcos': 4}from PIL import Image
import cv2
dicc= data_gen_train.class_indices
for raza in list(dicc.keys()):
test = '/content/dataset/test/' + raza + '/'
lista = os.listdir('/content/dataset/test/'+ raza + '/')
for img in lista:
plt.imshow(mpimg.imread(test + img))
img = Image.open(test + str(img))
img = np.array(img).astype(float)/255
img = cv2.resize(img, (224,224))
prediccion = modelo.predict(img.reshape(-1, 224, 224, 3))
print("La imagen es de " + raza + " y el modelo predice: ", list(dicc.keys())[list(dicc.values()).index(np.argmax(prediccion[0], axis=-1))])
plt.show()1/1 [==============================] - 1s 720ms/step
La imagen es de Elfos y el modelo predice: Magos
1/1 [==============================] - 0s 19ms/step
La imagen es de Elfos y el modelo predice: Hobbits
1/1 [==============================] - 0s 19ms/step
La imagen es de Elfos y el modelo predice: Elfos
1/1 [==============================] - 0s 20ms/step
La imagen es de Elfos y el modelo predice: Elfos
1/1 [==============================] - 0s 19ms/step
La imagen es de Enanos y el modelo predice: Enanos
1/1 [==============================] - 0s 20ms/step
La imagen es de Enanos y el modelo predice: Enanos
1/1 [==============================] - 0s 20ms/step
La imagen es de Enanos y el modelo predice: Elfos
1/1 [==============================] - 0s 19ms/step
La imagen es de Enanos y el modelo predice: Enanos
1/1 [==============================] - 0s 19ms/step
La imagen es de Hobbits y el modelo predice: Hobbits
1/1 [==============================] - 0s 20ms/step
La imagen es de Hobbits y el modelo predice: Hobbits
1/1 [==============================] - 0s 20ms/step
La imagen es de Hobbits y el modelo predice: Hobbits
1/1 [==============================] - 0s 21ms/step
La imagen es de Hobbits y el modelo predice: Hobbits
1/1 [==============================] - 0s 25ms/step
La imagen es de Magos y el modelo predice: Enanos
1/1 [==============================] - 0s 23ms/step
La imagen es de Magos y el modelo predice: Magos
1/1 [==============================] - 0s 22ms/step
La imagen es de Magos y el modelo predice: Magos
1/1 [==============================] - 0s 22ms/step
La imagen es de Magos y el modelo predice: Magos
1/1 [==============================] - 0s 21ms/step
La imagen es de Orcos y el modelo predice: Orcos
1/1 [==============================] - 0s 22ms/step
La imagen es de Orcos y el modelo predice: Orcos
1/1 [==============================] - 0s 21ms/step
La imagen es de Orcos y el modelo predice: Orcos
1/1 [==============================] - 0s 24ms/step
La imagen es de Orcos y el modelo predice: Orcos
Vemos que las predicciones son bastante acertadas.
Ahora vamos a jugar un poco más con nuestro modelo, y vamos a realizar predicciones con imágenes completamente distintas del dataset original.
Así en cada raza tenemos:
Descargamos las imágenes de drive.
from google.colab import drive
drive.mount('/content/drive')!unzip /content/drive/MyDrive/ClasificadorImagenes/Predict.zipArchive: /content/drive/MyDrive/ClasificadorImagenes/Predict.zip
inflating: Predict/Elfo.jpg
inflating: Predict/Enano.jpg
inflating: Predict/hobbit.jpg
inflating: Predict/mago.jpg
inflating: Predict/orco.jpg Realizamos las predicciones, a ver si nuestro modelo es capaz de identificarlas.
test = '/content/Predict/'
lista = os.listdir('/content/Predict/')
for img in lista:
plt.imshow(mpimg.imread(test + img))
img = Image.open(test + str(img))
img = np.array(img).astype(float)/255
img = cv2.resize(img, (224,224))
prediccion = modelo.predict(img.reshape(-1, 224, 224, 3))
print("El modelo predice:", list(dicc.keys())[list(dicc.values()).index(np.argmax(prediccion[0], axis=-1))])
plt.show()1/1 [==============================] - 0s 21ms/step
El modelo predice: Orcos
1/1 [==============================] - 0s 19ms/step
El modelo predice: Enanos
1/1 [==============================] - 0s 28ms/step
El modelo predice: Hobbits
1/1 [==============================] - 0s 21ms/step
El modelo predice: Hobbits
1/1 [==============================] - 0s 19ms/step
El modelo predice: Magos
Hemos tenido un buen resultado, solo ha fallado al identificar al Elfo, quizás un duende de navidad se asemeja más a un hobbit.
Por último, vamos a ver en qué raza me ubica el modelo.
plt.imshow(mpimg.imread('/content/drive/MyDrive/foto_hector.jfif'))
img = Image.open('/content/drive/MyDrive/foto_hector.jfif')
img = np.array(img).astype(float)/255
img = cv2.resize(img, (224,224))
prediccion = modelo.predict(img.reshape(-1, 224, 224, 3))
print("El modelo predice:", list(dicc.keys())[list(dicc.values()).index(np.argmax(prediccion[0], axis=-1))])
plt.show()
1/1 [==============================] - 0s 43ms/step
El modelo predice: Hobbits6. Guardar el modelo
Creamos la carpeta para poder exportarla a donde queramos.
!mkdir -p carpeta_salida/modelo_razasGuardamos el modelo.
modelo.save('carpeta_salida/modelo_razas')Hacemos un zip de la carpeta para poder transportarlo.
!zip -r modelo_razas.zip /content/carpeta_salida/modelo_razas/ adding: content/carpeta_salida/modelo_razas/ (stored 0%)
adding: content/carpeta_salida/modelo_razas/saved_model.pb (deflated 92%)
adding: content/carpeta_salida/modelo_razas/variables/ (stored 0%)
adding: content/carpeta_salida/modelo_razas/variables/variables.data-00000-of-00001 (deflated 8%)
adding: content/carpeta_salida/modelo_razas/variables/variables.index (deflated 78%)
adding: content/carpeta_salida/modelo_razas/keras_metadata.pb (deflated 81%)
adding: content/carpeta_salida/modelo_razas/assets/ (stored 0%)Este sería el final del proyecto, espero haya explicado bien las distintas técnicas empleadas.
¡Si te ha gustado el contenido de este artículo no te olvides de suscribirte a la newsletter!
La nuestra es la era de los datos. Cada día se generan inmensas cantidades de datos y tanto la infrastructura para almacenarlos, como las herramientas y técnicas para tratar y analizar este volumen tan ingente de información, evoluciona a pasos agigantados.
Pero los datos no van solos y se ha demostrado que los proyectos más exitosos son aquellos que entienden las necesidades de las personas y se adaptan de forma personalizada. El futuro, por tanto, es impulsado por las personas y guiado por los datos.
Así pues, ¿Podremos avanzar a la misma velocidad que la tecnología? ¿O en algún momento seremos o estamos siendo un freno?
Según un artículo de MIT Sloan, los factores culturales, aquellos que tienen que ver con el cambio de pensamiento y manera de hacer de las personas, son los principales obstáculos para transformar este oro que son los datos, en valor de negocio y ventaja competitiva. No la tecnología o la arquitectura, las personas.
También podemos encontrar numerosos artículos sobre la importancia de generar e impulsar la Cultura del Dato en las personas de la organización, como este de Deloitte.
Cualquier proyecto de Big Data y Analytics ha de partir de las personas y las necesidades de los que serán sus usuarios, desde el momento del diseño. Es necesario entender sus miedos, estereotipos, sesgos, creencias y alinear con sus prioridades de negocio.
Tomar como punto de partida estas necesidades de negocio y orientarnos a resolverlas y no al revés (el a veces típico ‘tengos estos datos y herramientas, ¿qué puedo hacer con ellos?’), es imprescindible para un resultado exitoso. Y aunque suene básico, es el aspecto que muchas veces se deja en segundo término, deslumbrados por las técnicas o tecnologías de moda.
Cambiar las metodologías de trabajo o aprender a usar nuevas herramientas no es como apretar un botón, requiere su tiempo, incluso si se trata de herramientas Low Code o No Code.
Es muy importante por tanto planificar con tiempo, definir cuál es nuestro objetivo como empresa, realizar un diagnóstico del punto de partida 360º evaluando el punto de partida de las habilidades técnicas de las personas que conforman la empresa, uso de herramientas, así como disponibilidad, catalogación y calidad de los datos, automatización de procesos y gestión del cambio.
A partir de ahí, diseñar un plan de formación personalizado que acompañe la formación técnica con la democratización de los datos disponibles, para la resolución de casos de uso reales y una integración de las nuevas técnicas en el día a día. Empezar por casos de uso pequeños pero con el impacto más relevante, e ir escalando a mayores proyectos.
Sólo partiendo de la definición del reto de negocio de resolver, alineando los esfuerzos a la cobertura de las necesidades, aportando valor desde el primer minuto y orientados a las personas, conseguiremos implantar con éxito los proyectos de Big Data, Analytics o Business Intelligence y convertirnos realmente en empresas Data Driven de forma transversal.
Marta Regina Cano Jiménez
Directora de Inteligencia de Negocio
Si quieres más información sobre nuestro master, puedes contactar con nosotros bien por teléfono al +34 910 91 28 42 o +34 630 88 13 53, por whatsapp directamente pinchando aquí o aquí, o mandando un mail con tus datos de contacto (nombre completo y teléfono) a: info@datahack.es
Por Julián García Trueba.
En un tiempo en el que la escasez de recursos ocupa una de las principales preocupaciones de nuestra sociedad, existe un recurso cuya generación crece de forma exponencial con el paso de los años. Este recurso no es otro que los Datos. Los datos generados pueden ser de diversa tipología y procedencia, cada una de las cuales con una serie de aplicaciones de elevado valor para las empresas y administraciones. En concreto, en el presente artículo vamos a focalizarnos en la aportación de los datos geolocalizados de movilidad al contexto de la sociedad actual.
En primer lugar, cabe enfatizar que, si bien la recolección, representación y, en definitiva, el análisis de los datos geolocalizados puede resultar un tema de última tendencia, sus primeras aplicaciones se remontan a mucho antes de que se dieran los primeros hitos de la Inteligencia Artificial o de que se empezase a hablar del Big Data. Prueba de ello es, por ejemplo, es el empleo que el célebre médico inglés Jon Snow hizo de la visualización geolocalizada para salvar a la ciudad de Londres de una de los mayores brotes de cólera de su historia. En concreto, el análisis realizado por Jon Snow consistió en identificar sobre un mapa los hogares de los ciudadanos afectados por cólera, así como la fuente principal de agua que surtía dichos hogares. De tal forma, una vez recogidos los datos y representados en el mapa, le permitió determinar de forma objetiva cuáles eran las fuentes “infectadas”. Con dichos datos, no le resulto difícil la tarea a Jon Snow de convencer a las autoridades de la necesidad de clausurar dichas fuentes y, de esta forma, dar por concluida la epidemia de cólera que solaba la ciudad.
No obstante, si bien como hemos visto el empleo de la geolocalización no es algo que atañe únicamente a nuestros tiempos, en la actualidad, la convergencia de tecnologías tanto de comunicación como de información ha incentivado la aparición de innumerables aplicaciones multisectoriales. Un ejemplo de ello es las llamadas plataformas de Smart Cities, las cuales proveen de la infraestructura necesaria para garantizar la recopilación de datos resultantes de diversos puntos de la ciudad, la representación de los mismos y el posterior análisis para una gestión eficiente de los servicios focalizados en el ciudadano.
No obstante, las plataformas Smart Cities no son los únicos casos de aplicación basados en la geolocalización. En este sentido, englobando también el concepto de movilidad dentro del análisis de datos geolocalizados cobran especial relevancia los datos generados por las operadoras, procedentes del dispositivo más popular y más empleado en nuestros días, el terminal móvil. Hoy en día, resulta realista afirmar que es extraño quien no dispone de un dispositivo móvil con acceso a internet y aplicaciones instaladas en el mismo. Este hecho es el aprovechado por las operadoras para tener acceso a ciertos datos de sus usuarios. En concreto, algunos de estos datos son los siguientes: la geolocalización del usuario, resultante de la antena a través de la cual puede accede a la conectividad del terminal, las aplicaciones a las que tiene acceso, las condiciones de contratación del usuario, así como datos personales del mismo (edad, sexo, etc).
De tal forma, mediante el correcto procesamiento de los datos, resulta viable determinar tendencias de movilidad de los usuarios. Para ello, y con el objetivo de cumplir con la normativa vigente de Protección de Datos, como paso previo a su presentación y análisis, las operadoras se ven obligadas a llevar a ejecutar diversos y complejos algoritmos para la agrupación de los mismos según diversos criterios: procedencia, franja horaria, segmentación por edad, por poder adquisitivo o por sexo.
Una vez ejecutados los procesos de agrupación y el procesamiento de datos por parte de los departamentos de Ingeniería de Datos de las operadoras habilitarán a una serie de insights con importantes aplicaciones en diversidad de sectores, como el turístico, el del retail, o el de la gestión de eventos. En concreto, en lo que respecta al sector turístico, el análisis de estos datos permite conocer la tendencia de movilidad en las principales zonas de atracción turística de las ciudades en función de la edad, las franjas horarias, el sexo, o el país o ciudad de procedencia, distinguiendo entre turistas que pernoctan en la ciudad y aquellos que la visitan en el día. Por otro lado, en lo que respecta al sector del retail, el análisis de los datos de operador, permite a las tiendas y sucursales conocer las tendencias de movilidad por franjas horarias y perfil tanto de los actuales clientes como de los potenciales. Un análisis que permitirá objetivizar la toma de decisiones en lo que respecta, por ejemplo, a la estrategia de expansión de las tiendas. Por último, en lo que respecta a la gestión de eventos, los datos de operador permiten tomar decisiones para una gestión más sostenible de los eventos, incrementando así la experiencia del cliente final.
En definitiva, de forma adicional al servicio de conectividad y voz que las operadoras proveen a sus clientes, tanto personas físicas, como jurídicas y administraciones, en la actualidad estas compañías proveen de una serie de insights basados en los datos, anonimizados y agrupados, procedentes de los dispositivos móviles de los clientes, los cuales permiten extraer conclusiones objetivas sobre las tendencias de movilidad, un paso más allá en lo que respecta al análisis de datos geolocalizados.
Si quieres más información sobre nuestro master, puedes contactar con nosotros bien por teléfono al +34 910 91 28 42 o +34 630 88 13 53, por whatsapp directamente pinchando aquí o aquí, o mandando un mail con tus datos de contacto (nombre completo y teléfono) a: info@datahack.es