Análisis no parálisis…

… en varias ocasiones un líder de una compañía en donde trabaje me decía esa frase “Análisis no parálisis”, puedo asegurar que la primera vez que me lo dijo no lo entendí, tal vez hasta me ofendí, ¿es que no es importante saber la razón del problema y tomar las decisiones adecuadas a partir de dicho análisis? … ¿las decisiones que tomarás seguramente no son las mejores?

Para entender mejor, les voy a contar una situación real por la que pase: en una ocasión bajo mi cargo contaba con un miembro de mi equipo el cual su nivel de análisis era muy bueno, su talón de Aquiles era la impuntualidad y el manejo del tiempo.

Un día se le asignó un análisis referente a un producto de la empresa, se tenía que dar una recomendación sobre seguir o parar aquel producto basado en el desempeño del piloto. Se contaba con la información histórica suficiente para identificar su comportamiento en diferentes escenarios y tiempos. El detalle como en casi todos los ambientes de análisis para poder colocar el real desempeño del proyecto necesitas quitar factores que alteran los resultados, tales como otro producto corriendo en paralelo, zonas con muy buen o mal desempeño, etc.

El piloto era un requerimiento a nivel internacional, y por ello tenía un soporte financiero y una fecha de terminó. Dado lo anterior el board tenía que tomar una decisión en 3 semanas para poder preparar el lanzamiento general o la salida del mismo.

La primera semana, este analista me dijo estoy limpiando la base y pensando cómo hacerlo, mis respuesta fue platiquemos lo que has pensado, a lo cual solo expresó ideas difusas de su objetivo y sin una hipótesis a refutar o comprobar, final de la platica le dije cuida estos factores que meten ruido al piloto.

La segunda semana, me comentó que había encontrado una cantidad de factores que alteraban el resultado del piloto pero aún no sabía cómo quitarlos, buenas ideas pero eso ya parecía un reto no fácil de alcanzar por lo que le recomendé reducir el número de factores considerando el concepto de Pareto (80-20) basado en una plática que tuvimos con el equipo que operaba el producto. Para el ya era un reto intelectual, así que continuo y descartaba por completo la percepción que tenía el área operativa.

Tercera semana, considerando que para no limitar la creatividad del equipo permites que ellos manejen sus tiempos, pero por otro lado generas un plan B, correr un análisis más sencillos, considerando menos factores y ciertas situaciones operativas que daban un sustento no cualitativo pero real de producto. A dos días de la entrega el contaba con una gran cantidad de información, varios modelos y pronósticos, algunos que convergían en ciertas respuestas pero no concluyente, el tenía que unirlas y convertirla en formato beneficio-costó, algo que no le gusta del todo porque para él ver su análisis desde un punto financiero era quitarle importancia a otros indicadores que quería calcular.

El día de la toma de decisión, Se presentó el plan B, utilizando algunas salidas del análisis que generó el, así como la parte cualitativa por parte del área operativa y se agregó el impacto financiero, de esto la decisión fue no lanzar el producto, se veía un desempeño aceptable con un pequeño impacto positivo en los ingresos de la compañía, pero con varias fallas en la parte operativa debido a que no había la correcta aceptación por aspectos tecnológicos.

Una semana después el analista término, era una presentación impecable donde a regañadientes agregó la parte financiera y sus conclusión fue que el producto era muy rentable, pero este debería ser implementado un segmento muy específico. Al ser solo un segmento muy exclusivo aunque era muy rentable el impacto al negocio seguía siendo muy pequeño y requería incluso mayor complejidad de implementación.

De todas maneras se mandó el análisis con la etiqueta de “Deep analysis”, pero realmente pocos miembros del board lo leyeron, uno de ellos me preguntó: “¿si leo este documento tendremos que cambiar la decisión?, a lo que dije “No”, respuesta seguida de “ok, luego lo leo”, no creo que lo haya leído. El analista me acompañó y se dió cuenta del valor que tiene la información no solo por ser buena sino también por estar en el momento adecuado. (Las mejores enseñanzas no vienen del tutor, sino de entender los errores que cometes).

Años después el producto fue lanzado utilizando tecnología más reciente que hizo que mejorara la aceptación del área de operaciones cubriendo el segmento completo y con un impacto moderado en los ingresos.

Si se hubiera esperado una semana más se hubiera paralizado la toma de decisión, un costo para la compañía y con el mismo resultado, ya que la decisión de este producto mayormente dependía del aspecto operativo. Aunque hubiera sido un producto con fuerte impacto financiero al ser mal implementado y ejecutado podría generar un resultado contrario para la empresa. Hay factores simples y rápidos que definen el camino a seguir… el análisis con fuerte soporte en datos e indicadores no ayudará a cambiar la decisión resultante.

Si ves el cielo lleno de nubes oscuras, a lo lejos se escuchan truenos y te cae una gota, no tiene caso que te quedes parado en ese lugar esperando que cargue en tu celular el pronóstico de lluvia y menos que lo confirmes en varios sitios u otros análisis para estar seguro. Si lo haces seguramente te mojaras y el resultado será el mismo … la lluvia es eminente basado en pocos pero sencillos factores.

Otro ejemplo de parálisis, es el caso en donde por buenos análisis se han tomado buenas decisiones, y por ello los directores no quieren tomar decisiones sin un análisis previo, por lo cual se baja la instrucción de generar análisis por todo proceso o situación en la empresa … esto hará que haya una sobre carga en el equipo de análisis. Con base en anterior ejemplo si bien es claro la información debe estar en tiempo, pero no mal entendamos, un análisis requiere su tiempo para que tenga resultados adecuados. El hecho de que la planta directiva no tome decisiones hasta tener las prueba exhaustivas puede ser más perjudicial para la empresa que tomarlas con la información existente, tales como alarmas, indicadores y retroalimentación de expertos del tema… ¿te ha tocado verlo en tu empresa? … ¿Esto se mejora incrementando el equipo de análisis o mejorando el liderazgo?

Un problema similar, cuando a una organización le da la famosa juntitis por todo, en esas juntas todos van sin ganas, criticando todo pero sin alcanzar fácilmente el objetivo de definir acciones y funciones así como la asignación responsabilidades… esto se vuelve un gasto de recursos sin ser productivo….¿tu que opinas?… ¿Esto mejora incrementando las salas de juntas o se mejoran los procesos donde estén bien definidas las funciones y responsabilidades?

La imagen también cuenta para un Data Scientist

Recientemente se habla de la sustitución de la mano de obra humana por maquinas, en blogs anteriores se comentó sobre el futuro de las áreas de análisis, donde  la generación de modelos que utilizan técnicas de Machine Learning se sistematizará y de igual forma se automatizarán procesos como data mining, Information Management, reporting, etc. Dado lo anterior podría ponerse en duda la continuidad del rol de Data scientist, esto no debe ser preocupante, ya que sigue existiendo una área de oportunidad mientras la decisiones sigan del lado de los humanos, esta oportunidad sonará fuera de contexto, pero es la forma en que los científicos de datos presenten los análisis y soluciones a problemas.

Para muchos científicos de datos contar con un KPI (Key Performance Indicators) puesto en un reporte es suficiente para explicar el desempeño de un modelo o del comportamiento de algún aspecto del negocio. Me he topado con varias organizaciones donde esos KPIs solo los revisan los que los hacen, triste realidad pero cierto.

Otros consideran que un dashboard con gráficas dinámicas son la opción para presentar ante un consejo directivo. Un plus si dicho dashboard contine warnings que disparen alarmas al área operativa o comercial de la organización. Esto casi siempre son creados a solicitud de un director y más porque quiere presumirlos o por reacción a un problema que no fue detectado en tiempo.

Si observamos en el interior de una empresa, esta seguramente esta llena de KPIs, dashboards de cada departamento, los cuales tienen su tiempo de moda y se quedan produciendo por mucho tiempo sin que nadie los utilice. Como se dice tan malo es no tener información como tenerla en exceso.

Otro problema que viene de contar con KPIs es que cuando le preguntas a un gerente que sucede en su departamento/área la respuesta es me esta yendo mal en cierto indicador, pero no menciona la causa operativa y cuando le preguntas por su plan de mejora su respuesta es mejorar el indicador… con respuestas como estas se puede observar un claro desconocimiento de la relación entre el indicador y la parte operativa, ya que seguramente las instrucciones que serán derivadas a los subordinados será que mejoren dicho indicador y no un plan con acciones especificas a corto, mediano y largo plazo. Las instituciones están creando gerentes con mayor información del desempeño pero menor control de la situación.

Un científico de datos no es una persona que se dedica a hacer reportes y muchas veces se piensa que ese es su objetivo. Como lo mencione anteriormente, muchos aspectos serán automatizados, pero ¿Qué pasaría con los científicos de datos? … pues, continuar con el objetivo principal de resolver problemas con datos complejos mediante el empleo de una profunda experiencia en alguna disciplina científica, pero sobre todo hacer que el resultado obtenidos pasen de una solución teórica a acciones con impacto positivo en el desempeño/utilidades de la empresa.

Suena bonito, pero si tu eres un científico de datos o estas en camino a serlo, cuestiónate si  has sido actor activo de las tomas de decisiones, y no es valido mencionar que si, porque los indicadores de desempeño de tu modelo muestran un poder predictivo o poder de clasificación en buenos niveles y estable. Aclaro no subestimo la creación de un buen modelo, lo que quiero dar a entender es que esa parte en un futuro no estará en nuestra mano… lo que estará en nuestra mano es resolver problemas y cómo presentarlos, por ello pensemos en lo siguiente puntos que involucran la solución de un problema:

  • Síntoma. Usualmente lo observamos por indicadores, pueden tenerse alarmas, early warnings, tendencias, etc. que son observados en KPIs y/o Dashboards.
  • Identificación. Se trata de entender el impacto que tiene el problema, qué otros indicadores podrán ser afectados, es un problema general o esta focalizado, ya ha pasado un problema similar, etc.
  • Causa. Se dejan los indicadores y se habla de situaciones reales, causas internas o externas que están afectando los procedimientos o aspectos operativos.
  • Plan de acción. Se genera una solución Smart con objetivos claros y de sencillo entendimiento para equipo operativo, utilizando su lenguaje.
  • Seguimiento. Los objetivos trazados en el plan se convierten en indicadores al que se les estará dando seguimiento por medio de indicadores de desempeño a corto, mediano y largo plazo. También se debe hacer un análisis del impacto del plan generado.
  • Registro de buenas practicas. El plan con los resultados de análisis de impacto deben ser guardados para ser utilizados en un futuro, ya sea para implementarlo o evitar usar aquellos sin impacto positivo.

La solución debe tener un soporte técnico por parte del científico de datos que le sentido a cada punto,  seguramente se estará usando minería de datos, aplicar la estadística en análisis e interpretación de indicadores, investigaciones en campo como levantamiento de un muestreo, para identificar impactos se pueden generar modelos de elasticidad, pronósticos, etc.

Con todo lo anterior,  se debe generar un documento que contenga todo el sustento del análisis y una presentación ejecutiva para la toma de decisiones, en esta presentación se debe tener un guion claro de lo que se quiere contar y así como el efecto que debe causar en las personas que tomaran decisiones. Para ello, se necesita conocer que es lo que esperan ver en el documento, no siempre una tabla con números será la opción más adecuada y tendrás que colocar alguna imagen que mande tu mensaje de forma rápida y sencilla, la interpretación de los indicadores sin demasiado texto y de forma puntual harán que se reduzcan las preguntas, los números toman mayor credibilidad si son sustentados con aspectos operativos extraídos de la gente experimentada que esta involucrada en el tema, como cosas como lo anterior podemos mejorar la imagen de nuestra presentación (Aun hay más recomendaciones para realizar una presentación el cual serán explicadas en futuro blog) .

La forma en que se analiza un problema, como se interpreta y comunica la solución para otros humanos es la imagen que también cuenta para un data scientist y que le seguirá dando valor a pesar de la sistematización y automatización de muchos proceso. Digamos que el generar una buena imagen será el reto más difícil de copiar que tendrán las maquinas.

Hoy pañales … Mañana un monstruo sin nombre!!

He estado leyendo artículos colocando Machine Learning como el futuro que esta tocando nuestra puerta,  y sin duda creo que es un parte aguas de lo que actualmente conocemos con impacto en muchos áreas de nuestras vidas, sin embargo al analizar lo que tenemos creo que aun estamos en tiempos de pañales.

Machine Learning es un subconjunto de la Inteligencia Artificial  en el que se concentran varios algoritmos o técnicas; al crear un modelo tenemos 3 etapas principales (al post de documentación hay más detalle):

  • Data creation,
  • Model development,
  • Implementation and monitoring

Un algoritmo es usado en Model development dependiendo del problema, conocimiento del desarrollador y por ultimo por el resultado arrojado al compararlos. Los algoritmos no son nuevos y mucho menos el sustento estadístico, lo que ha ayudado mucho es el volumen de información y la forma de procesarlo, es decir los adelantos tecnológicos han colocado un catalizador para lo que viene.

tipos

evolu

Las imágenes que tome de otro blog me fueron de mucho interés porque sin duda me he topado con diferentes personas que eligen una tribu y como la evolución de los ha algoritmos continua, pero aun así hay otros aspectos más por ver que están en mi mente:

  1. Autoevaluación, capaz de trabajar con datos y metadatos para mejorar la misma forma de aprendizaje,
  2. Oportunidad de desaprender, que el modelo pueda rechazar un aprendizaje previo por uno nuevo, los humanos generamos ciertos paradigmas y con el tiempo podemos cambiarlos para reaprender.
  3. Independencia de selección de la data, un sistema que pueda explorar miles o millones de fuentes y aplicar el aprendizaje para seleccionar la data más adecuada para el modelo.
  4. Aprendizaje no supervisado y agregaría no limitado, es decir permitir experimentar algoritmos nuevos, incluso crear nuevos al combinarlos y romper limitantes iniciales.
  5. Seguimiento con alarmas que detonen acciones inmediatas que permiten automáticamente el rediseño del aprendizaje.
  6. Dejar el concepto de modelo con base de técnicas de Machine Learning a un sistema cognitivo

Consideremos la siguiente analogía:  Las clases típicas de un idioma pueden para persona no ser la mejor opción de aprendizaje ya que siente que no tiene avances, esta persona hace una autoevaluación (1) y toma decisiones de cambiar su aprendizaje, reprograma su base de como aprender y decide volver iniciar su aprendizaje de otra manera (2), para ello busca información de diferentes medios, incluso publica en la web que le envíen información (3), de ello selecciona recursos como clases online más grupos de conversación con nativos del idioma y en futuro esta explorando la idea de ir por un tiempo a un país donde se hable solo ese idioma (4). post el curso identificar si el aprendizaje va con su estilo de vida, pero sobre todo con el alcance de su objetivo de mejorar su nivel (5) y por ultimo poder identificar costos y otros factores que impactan para seguir o reiniciar el proceso de aprender un nuevo idioma (6).

Si lo pensamos muchos de los casos se hacen actualmente basado en que se hacen manualmente por un equipo o tribu  que da seguimiento a un modelo, ahora imagínate que es un sistema automatizado que lo hace constantemente, buscando optimizar los recurso y en si mismo el aprendizaje….para mi el futuro de Machine Learning aun no tiene nombre!!

 

Una humanidad organizada por algoritmos de machine learning

El día de hoy entro en mi cabeza la idea de tener una estructura social organizada mediante algoritmos de machine learning, puedes imaginarte que cada persona fuera seleccionada para tener una función en la sociedad, es decir un trabajo, ya sé te sonó a una película, a mi también pero veamos más conceptos que estarían envueltos en un modelo desarrollado e implementado para su uso en un país como México.

Para desarrollar dicho modelo tomemos en cuenta los siguientes aspectos que nos darían un mejor entendimiento del resultado del desarrollo:

  • Data creation
  • Reject inference
  • GBI definition
  • Vintage Analysis.
  • Segments
  • Selection of variables
  • Model outcome

Podríamos ocupar más y mayor detalle, pero si lo hiciéramos podríamos perder el enfoque de este post, que es dar una probada del problema y dejar que las ideas fluyan, así como los temas controversiales que se deriven.

Data Creation. Se tomaría la población de México considerando algunos siglos de información, se tendría que excluir aquellas personas con las que no se cuenta con información laboral y en algunos casos algunos trabajos que dejaron de utilizarse o aquellos que no aplicaran en la nueva organización de México.

Reject Inference. Usaremos información externa para algunos trabajo, ya que para estos podríamos tener poca información, por ejemplo funciones de gobierno donde  no contamos con los suficientes casos para identificar a los mejores empleados de gobierno…recuerda es un ejercicio y nuestra historia nos respalda.

GBI definition. Decir si un empleado ha tenido buen desempeño o no, es difícil de saberlo, pero supongamos que contamos con evaluaciones de los empleados de todas las empresas. Cuando se modela, usualmente el objetivo deseado se denomina “BAD”, por lo que las definiciones quedaría de la siguiente manera:

  • Good. Personas que tuvieron bajo desempeño en su trabajo
  • Bad.  Personas que tuvieron un desempeño sobresaliente en su trabajo.
  • Indeterminate. Personas del que no se tiene información precisa para definir cómo Good o Bad

Vintage AnalysisIdentificación de la edad adecuada para que una persona fuera asignada a una labor especifica, desde mi punto de vista este sería muy cercano a la edad que los jóvenes están entrando a la universidad.

Segments. Desde mi punto de vista tendríamos segmentos muy parecidos a la clasificación de trabajos a nivel general:  Agricultura, industria, gobierno, Servicios, etc.

Selection of variables.  Tendríamos un mundo de variables, desde quienes son nuestros padres y a que se dedicaron, como los gustos, desempeño escolar por materia, actividades físicas, etc.

Model outcome. Tendríamos una cantidad de segmentos y por cada segmento tendríamos un árbol de decisión donde los nodos serían un trabajo especifico y la salida del modelo final seria un score que indicará que tan viable seria la persona para ese trabajo.

Dada la anterior información nos encontramos que un joven saliendo de la preparatoria/bachiller tendrá que ser calificado con todos los modelos, dándole un abanico de trabajos y segmentos donde podría desempeñar de la mejor manera. Incluso si lo pensamos bien la parte de la universidad a partir de su selección sería manejada como una capacitación especializada para su futuro trabajo.

Todos iniciarían con un puesto bajo, tales como obrero, analista, chalan, etc y la parte de escalamiento (coordinador, gerente, head, director, etc.) en las funciones del trabajo dependería de la personas y con ellos también sus ingresos, posiblemente la salida de su score sería un parámetros para una promoción.

Puedes imaginarte que tendrías a los mejores y más honestos gobernantes, tendrías a las personas más capacitadas y con habilidades necesarias para que la productividad subiera, y teniendo esto posiblemente no se tendría que trabajar 8 horas, posiblemente se bajaría a 4 o menos, ya podríamos reducir por completo aquellas personas que no trabajan, más vida social para todos!

Suena bonito, un México con una estructura social bien organizada, donde con ellos la diferencia sociales se reduzcan al mínimo, pero que pasaría con aquellos muchos que no quieren trabajar “NINIs”, el ser ama de casa se consideraría un trabajo, y que hay de trabajos como futbolistas… y que me dicen sobre los niños que sueñan con ser bombero, desde pequeños se le diría, no  sueñes, cuando crezcas tu selección dependerá de tus padres y lo que hagas en los siguientes años… hay muchas preguntas que salen de esta idea, que parece ser futurista pero no imposible a ser aplicada, hay muchos temas de controversia desde muchos ángulos: Ético, legal, justicia, economía, etc.

¿Machine Learning sería una buena solución para organizar una sociedad?

Coloca tus comentarios…sería genial leer tus ideas sobre este tema.

Un futuro construido de dos mundos (SQL & NoSQL)

Un comentario por parte de un colega me llamo la atención sobre el futuro de las bases de datos:

“SQL será remplazado por NoSQL porque el primero no es practico”,

en ese momento no quise opinar para saber mas sobre sus argumentos, a lo mejor esta persona sabia algo que yo no sabia. En resumen su opinión se basaba en un limitado conocimiento del uso de bases de datos y por temas de moda donde equivocadamente se ha pensado que bigdata es igual NoSQL.

Me hizo recordar cuando estaba en la universidad, mi primer programa para un cliente potencial, yo tenia que almacenar y devolver información. Recuerdo que no sabía que era un manejador de bases de datos, tan solo sabia el lenguaje C (ambiente de consola) y tenia un archivo de texto el que llenaba con reglas construidas en mi mente y usaba pipes y saltos de línea para separar los datos y registros, aun así mi motor de búsqueda en mi mente se volvía complicado, pensaba en varios algoritmos que pudieran correr en  una Intel 40486, disco duro de un 528 Mb y por mucho una RAM con 500kb… puedes imaginarte lo anterior?, Este fue mi primer intento con NoSQL data base, ahorita ni el celular mas pequeño tiene tan poco poder.

Posteriormente después de haber tomado probabilidad y teoría de conjuntos, tome la clase de bases de datos, yo me imaginaba que me iban a explicar como trabajar con ellas sin embargo me dieron la teoría: como generar un diagrama entidad relación que explicará el problema a resolver, encontrar las relaciones (uno a uno, uno a muchos, muchos a muchos, etc.),  transformar las entidades o relaciones en tablas, generar llaves, normalizar, indexar etc. No aprendí SQL, entendí que era una base de datos y como crearla para sacar provecho de los recursos limitados, incluso entendí que era los metadatos.

Mi primer contacto con SQL no lo recuerdo, pero al ser un lenguaje muy sencillo de leer y al entender la base como una estructura bien organizada generar las consultas me resultaron fáciles… de aquí es donde la persona le parecía no practico, el solo quería colocar un “PROC MEANS” y obtener información de un data para un modelo.

Por lo anterior empecemos a analizar ambos términos:

SQL

El lenguaje de consulta estructurado o SQL se usa como un medio de comunicación con los sistemas de administración de bases de datos relacionales. Este lenguaje estandarizado ayuda a los analistas de datos a analizar, recuperar y actualizar datos o registros que están incluidos dentro de la base de datos. Además, esta herramienta se usa comúnmente para almacenar datos estructurados.

NoSQL

No existe una definición formal para NoSQL, pero debemos mencionar “No sólo SQL”, es decir esta enfocada mecanismos para el almacenamiento y recuperación de datos con un manejo diferente a las típicas bases relacionales, siendo el más destacado el que no usan SQL como lenguaje principal de consulta.

 Amazon, Google, Twitter y Facebook son las principales impulsoras ya que el enorme crecimiento del volumen de datos requería dar respuesta a la necesidad de proporcionar información a partir de tipos de datos, se necesitaba ser flexible y rápido.

Comparativa

Cuando trato de compararlos no veo uno mejor que otro, veo que se complementan, para mi SQL salió para optimizar el manejo de datos por recursos limitados y NoSQL tardo en salir porque no había los recursos suficientes. Las bases relacionales no evolucionaron tomando la parte de NoSQL porque se contrapone por definición, lo cual lo podemos ver en la siguiente figura que muestra las ventajas y desventajas:

V&D SQL

¿Cuál utilizar?

Con base a la figura anterior pensemos que tipo de base debes usar:

  • Requerimiento de ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) –> SQL
  • Largo volumen de Datos con flexibilidad de tipos de datos –> NoSQL
  • Almacenamiento y computo en la nube –> NoSQL
  • Datos estructurados y sin cambio –> SQL
  • Corto tiempo de desarrollo –> NoSQL

Conclusión

No sé que opinan ustedes, pero en todas las instituciones en las que he apoyado me he encontrado un zoológico de plataformas y tecnologías, así que no sería raro encontrarnos SQL y NoSQL corriendo al mismo tiempo con objetivos diferentes pero contribuyendo para proporcionar información. Pero esto sería el ultimo escalón de la evolución de las bases de datos, no lo creo … imaginemos que tuviéramos una base capaz de mantener el ACID en bases grandes y distribuidas en un entorno de nube con una estructura que indexe los diferentes tipos de datos, para ello creo que tendría que morir el lenguaje SQL y dar paso a uno nuevo en un ambiente amigable. Yo puedo ver un futuro construido con lo mejor de SQL y NoSQL.

 

 

 

 

 

 

El bueno, el malo y el feo

No es magia, es solo ciencia … y que da miedo!!!

El bueno …

Parece mágico como en Facebook nos llegan invitaciones de amigos a los que querías conectar o que si ves un video, los siguientes sean parecidos o con similar información. Es mágico como las empresas están acercándonos a nosotros con publicidad de algún producto del que andábamos buscando y como también se manejan las elecciones de nuestros gobernantes.

Suena que ya nos alcanzo el futuro cuando el robot Sofia tuvo una conversaciones divertida con Will Smith, para nuestros abuelos pensar en ello seria mágico.

El Malo …

El culpable de esa aparente magia es un termino que se vuelve cada vez más famoso y este es machine learning, y como parte de lo que entra en moda se crean leyendas como pensar que el “machine learning es como un sombrero de mago” al que se le meten datos y de este aparece lo que maravilla al publico en general.

El machine learning es una disciplina que crea sistemas que aprenden automáticamente, para ello se implementan ciertos algoritmos o técnicas soportadas estadísticamente para poder predecir comportamientos futuros.

Existen mucha teoría sobre el tipo de algoritmo (supervisado, no supervisado, etc), enfoque y diferentes técnicas a implementar, digamos que hay muchas formas de aprender, pero entre las técnicas más conocidas tenemos:

  • Regresión logística
  • Árboles de Decisión
  • Redes Neuronales
  • Support Vector Machine (SVM)

Lo anterior requiere conocimiento y estudio, esto no sé da al caer una manzana, todas estás técnicas tienen un sustento científico que para la mayorías de las personas les haría pasar un mal rato por las matemáticas y programación

El feo…

Este es el que da miedo, y también ha dado de que hablar recientemente… que pasa con tanta información moviéndose por toda la red, información de diferentes tipos: Personal, Gustos,  hábitos, Puntos de interés, relaciones, etc.

Cualquier individuo con un cierto conocimiento de hacking podría saber quién eres y dónde vives, qué te gusta… suena peligroso, pero esto no es todo, también existe la manipulación como sesgar tu preferencia en una elección política al atacar tus principales miedos…¿te suena conocido?.

Como parte de nuestros temas de controversia y análisis puedes imaginarte que..

“En un mundo futuro hubiera un algoritmo que te impusiera una sugerencia de pareja, porque cumple con tus gusto al 99.99% y que te diera todas las herramientas y consejos necesarios para conquistar a dicha persona asegurándote el 99.99% de éxito y del otro lado estuviera pasando la misma manipulación y exceso conocimiento de tu persona.”

… Dónde estaría la magia?… qué tantas cosas podrían cambiar? … hasta dónde llegaría la manipulación? …  tendremos información privada?

Documentar un modelo – Será aburrido pero muy útil

Recordando la sabiduría del puedo, se dice que el que: “Quien no conoce su historia está condenado a repetir sus errores”… y esto qué tiene que ver con documentar un modelo, pues mucho, ya que el documentarlos nos ayudará a que futuros desarrollos sean mejores en muchos aspectos que envuelven el crear un modelo.

En anteriores publicaciones hemos platicado que un Data Scientist debe cubrir varios puntos: la parte matemática, conocimiento del negocio y la tecnología… y al no documentar un modelo considerando lo anterior se cae en errores típicos de novatos.

Tomemos como ejemplo un modelo realizado con alguna técnica de machine learning y que devuelve un score como la probabilidad de un suceso o segmenta nuestra población para aplicar estrategias a cada segmento, pensemos también que la información con la que se hizo era parte interna y parte de un proveedor externo….si seguimos imaginando el querer describir nuestro modelo se volvería confuso y sin orden y seguramente perderíamos información valiosa.

Que puntos básicos debería llevar nuestra documentación:

  1. Resumen ejecutivo. Un recorrido rápido del modelo considerando todos puntos a continuación.

  2. Visión general

    • Descripción del producto/ portafolio/ población en donde se quiere aplicar el modelo.
    • Justificación basado en el punto anterior explicar como el modelo ayudará a alcanzar objetivos, utilizando indicadores generales/comerciales/etc y tendencias actuales. Importancia del modelo en la toma de decisiones de la empresa. colocar si será utilizado para cumplir una regulación.
    • Objetivo del modelo, cuál será el alcance del modelo
    • Descripción del modeloen que será utilizado desde un punto de la empresa y versiones del modelo. 
  3. Aspecto Técnico  – Origen de los Datos

    • Descripción del origen de datos – Internos o externos, para casos que no se cuenta con información suficiente se puede explicar procesos como Reject inference.
    • Descripción de los datos: Fecha de observación, periodo de observación, venta de desempeño, volumen de datos, etc.
    • Soporte del volumen de información comparando con Reportes oficiales.
    • Muestreo: Uso total de datos, una muestra, metodología de muestreo
    • Distribución de los datos: desarrollo, testing y validación.
    • Accesibilidad de los datos. Verificación de los datos usados, así como las accesibilidad a los datos, volumen de registros, campos, tipo de campo, tablas, bases de datos, permisos, etc .
    • Exclusiones. Datos que serán excluidos por aspectos de negocio o por acceso a datos, mostrar gráfica histórica para revisar estabilidad en la selección de las categorías de exclusión.
    • Observaciones en datos. Debilidades, limitaciones y alcances relacionado con el manejo de los datos.
  4. Aspecto Técnico – Fundamentos del modelo

    • Objetivo del modelo desde un punto técnico: salida del modelo Score, segmentación con su nivel esperado mencionado en indicadores de desempeño (KS, POD, FPR, accuracy, etc).
    • Metodología aplicable para el tipo de modelo. Descripción conceptual
    • Definición de GBI – Bueno, malo e indeterminado soportándolo la definición con una análisis para determinar el GBI, así como sus distribución histórica y de la muestra para evitar errores.
    • Definición de la ventana de desempeño, usualmente se utilizan análisis de vintage.
  5. Aspecto Técnico – Selección de variables

    • Descripción del proceso de selección de variables.
    • Descripción de las variables. Verificación de las variables usadas y de su integridad basado en estadística descriptiva de los datos, mising, avg, max, min, distribución histórica, etc.
    • Variable excluidas por experiencia de negocio. justificación
    • Analizando variables  – Multicolinealidad, Information value, WOE, R cuadrad, etc.
    • Input del modelo – Variable seleccionadas
  6. Aspecto Técnico – Desarrollo del modelo

    • Descripción del proceso de desarrollo del modelo
    • Descripción de las alternativas utilizadas en el modelaje
    • Cuadro comparativo de las alternativas exploradas
    • Detalle de la técnica utilizada en el modelo – Regresión logística, árbol de decisión, Random Forest, SVM, neural network, etc., cualquier técnica de machine learning o técnica utilizada.
    • Descripción de los parámetros utilizados en el modelo.
    • Output del modelo: Score, segmentación, etc.
    • Observaciones del desarrollo. Debilidades, limitaciones y alcance del modelo.
  7. Desempeño del modelo – Testing del modelo

    • Definición de las variables de desempeño aplicables para el modelo KS, Accuracy, ROC, Falso positivo, estabilidad de la población, etc.
    • Definición de alarmas de desempeño, niveles en los que se manda un mensaje de alarma del modelo.
    • Reporte de desempeño del modelo, métricas, tiempo de revisión, etc.
    • Desempeño con datos de desarrollo, testin y validación
    • Comparativa de indicadores entre las diferentes bases
    • Observaciones del desempeño. Debilidades, limitaciones y alcance del desempeño del modelo.
  8. Implementación del modelo

    • Plan de implementación e indicadores de éxito de implementación
    • Recursos necesarios para la implementación
    • Revisión de la implementación
    • Comunicación de la implementación.
  9. Post implementación

    • Establecimiento de validaciones del modelo por parte de un comité revisando:  funcionalidad, desempeño y  aspectos técnicos.
  10. Código y soporte

    • Descripción del lenguaje y herramientas utilizadas para el desarrollo, así como las versiones.
    • Código de exploración de datos
    • Código para manipulación de datos: Data cleasing, data quality, estadística descriptiva de las variables.
    • Código para el manejo de las exclusiones
    • Código del modelo
    • Código para generar el reporte de desempeño

 

Si llegaste hasta este comentario y no te has aburrido es que has considerado esta información útil para documentar tu modelo y seguramente ya tendrás algunas dudas o comentarios… lo cual te pido agregues y con gusto las podemos analizar para generar una mejor documentación.