Es algo viejo, pero vale la pena traerlo a estas páginas. Se trata de un manifiesto que comienza parejo a aquel otro ahora arrumbado: Un espectro recorre los mercados — el espectro de la falta de liquidez, la congelación del crédito y el fracaso de los modelos financieros.
Habla, sí, principalmente, de finanzas. Pero en gran medida desde la óptica de la modelización y de su responsabilidad en el caos que vivimos ahora. Y, aunque no tiene desperdicio, su colofón de es de universal aplicación y provecho para los modelizadores todos, incluidos los ajenos al mundo de las finanzas. Es una suerte de juramento hipocrático para modelizadores con las siguientes cinco promesas:
Tendré presente que el mundo no es obra mía y que no satisface mis ecuaciones.
Aunque utilizaré modelos para estimar valores, no me dejaré influenciar excesivamente por las matemáticas.
Nunca sacrificaré la realidad en aras de la elegancia sin explicar el motivo.
Tampoco crearé en los usuarios de los modelos falsas expectativas de precisión; en lugar de eso, haré explícitas las hipótesis y simplificaciones.
Entiendo que mi trabajo tiene un impacto profundo en la sociedad y la economía que, en gran medida, me es desconocido.
Un data scientist es un señor que sabe de varias cosas que no se enseñan ni juntas ni bien por separado en nuestras universidades. Y que, además, se desaprenden rápido en las oficinas y covachuelas donde acabamos ejerciendo. A no ser, claro está, que uno tenga la vocación y la capacidad para nadar contracorriente.
que indica cuáles son los tres elementos técnicos —obviando los pertenecientes a otras dimensiones— fundamentales de los que se nutre una carrera como científico de datos.
¿Cómo calificáis vuestras aptitudes en cada una de las tres grandes áreas? ¿Qué podríais hacer por mejorarlas?
La estrategia concierne a sucesos futuros. Por ser futuros, son inciertos. Y el artículo describe cuatro niveles distintos de incertidumbre a los que contrapone una serie de posibles estrategias. Los niveles son:
Un futuro suficientemente claro: las tendencias son muy claras y no se esperan sorpresas. En resumen, hay un único escenario posible y la estrategia adecuada consiste en adaptarse a él.
Varios futuros alternativos: existe un número concreto de alternativas o escenarios, cada uno de las cuales con su propia probabilidad de ocurrir. Por ejemplo, los bares barajaron recientemente dos posibles alternativas: la futura ley podría prohibir fumar taxativamente (como ocurrió) o permitir tal vicio en áreas específicas y adaptadas. A cada suceso puede asignársele una probabilidad discreta, diría un matemático.
Un rango de futuros: no existen escenarios discretos y concretos, pero sí un rango de opciones: la demanda puede ser cualquier cifra entre 0 y 1000, etc. Nuestro matemático entendería que este es un problema en el que rigen leyes de probabilidad continua.
Absoluta incertidumbre: ocurre cuando es imposible plantear cualquier tipo de función de probabilidad. No obstante, aunque el artículo recoge algunos casos, subraya también que este tipo de situaciones son inestables y suelen degenerar con el tiempo en alguna de las situaciones anteriores.
Las tres estrategias fundamentales consisten en:
Adaptarse a las circunstancias, receta especialmente indicada en los casos de falta de incertidumbre.
Anticiparse a ellas para tratar de capturar las ventajas de los escenarios más favorables, que es posible únicamente cuando se posee la capacidad para influir efectivamente en el devenir de los hechos.
Reservarse opciones en determinados escenarios posibles y favorables mientras se juega defensivamente en los adversos.
Una proyección de la población española plantea un rango de futuros. Existen muchas variables que pueden afectar al número final de habitantes que pueda haber en España en diez años. Además, muchas de ellas son perfectamente manipulables por los poderes públicos.
El estudio del INE —y especialmente de la forma fatalista en que fue recogido luego por los medios— parece situarnos en el nivel de incertidumbre equivocado. Y sugiere, al hilo de la discusión sobre las estragegias aplicables que no nos queda sino resignarnos a lo oscuro del pronóstico.
Tu proyecto de IT puede contener más riesgo del que piensas. De verdad. Dan fe de ello Bent Flyvbjerg y Alexander Budzier.
Los autores describen en el artículo que he enlazado encima varios proyectos que fracasaron estrepitosamente y proporcionan algunos consejos para evitar ese tipo de desenlaces. Sin embargo, para quienes siguen esta bitácora, la reflexión más interesante es la siguiente:
Al focalizarse en las medias en lugar de los casos extremos más dañiños, la mayor parte de los gestores y consultores han ignorado el verdadero problema.
Y es que el sobrecoste medio, el 27 % en la muestra estudiada por los autores, proporciona una visión mucho más optimista que la real:
Al representar gráficamente el sobrecoste, aparece una distribución de cola pesada, un gran número de sobrecostes enormes. Uno de cada seis proyectos estudiados era un cisne negro, con un sobrecoste medio del 200 % y un retraso de casi el 70 %.
De nuevo, las medias, tema sobre el que he escrito en más de una ocasión, nos juegan malas pasadas.
Codd desarrolló el modelo relacional —la base de casi todos los actuales sistemas de bases de datos— a finales de los años sesenta. El modelo relacional, basado en la lógica proposicional, suponía una ventaja sustancial con respecto a los métodos anteriores de almacenar información y bien implementado permite resolver una serie de problemas que afectaban a los sistemas anteriores:
Evita la redundancia de los datos.
Minimiza los problemas de actualización de los datos en las tablas.
Protege la integridad de los datos.
Etc.
Sin embargo, hay motivos por los que dicho esquema no es enteramente válido en contextos en los que se manejan datos grandes (para una definición sensata sobre lo que son “datos grandes”, léase este artículo).
La solución al problema de almacenar, procesar y acceder a conjuntos de datos grandes —implementada en diversas plataformas, tanto libres como propietarias— pasa por partirlos y distribuirlos en diversas máquinas y discos.
Pero partir plantea el problema adicional de decidir cuál es el criterio para distribuir la información entre las distintas máquinas. Los criterios a tener en cuenta son los siguientes:
Uniformidad: la distribución de la información por máquina debería ser (idealmente) uniforme: el uso de los recursos (CPU, disco, etc.) de cada máquina debería ser aproximadamente parejo. Piénsese que una operación distribuida de escritura o lectura no termina hasta que no lo hace la tarea asignada al último nodo, por lo que un nodo sobrecargado ralentizaría todo el sistema. Y que el espacio libre en disco se agota cuando se llena cualquiera de los discos.
Localidad: Por otro lado, información que se procese junta debería, idealmente, estar próxima, ser local. Si suelo sumar las ventas de todos mis establecimientos durante un mes, debería segmentar la información por mes. Si me interesa comparar la evolución de las ventas por establecimiento a lo largo del tiempo, segmentar por establecimiento. Las operaciones intranodo son mucho más económicas que las operaciones que involucran tráfico de datos entre nodos. De ahí que un criterio fundamental de diseño sea el de minimizar el tráfico de información entre nodos.
Existen segmentaciones naturales de datos: por punto de venta, por cliente, por persona, por periodo, etc. que, teóricamente, deberían satisfacer el criterio de localidad. Sin embargo, en los datos reales existen, se manifiestan, las llamadas leyes de potencias. Por motivos sobre los cuales estadísticos, sociólogos, físicos y muchos otros han escrito toneladas de papel, muchas distribuciones reales siguen las llamadas leyes de potencias (término que funciona en ocasiones como metáfora de la metáfora de cola larga o de cola gruesa).
Por ejemplo, la distribución del número de SMS enviados por persona: habrá quien mande diez al mes; otros mandarán treinta; algunos, ciento; pero seguro que hay números desde los que se mandan —posiblemente de manera automatizada— mil, diez mil o incluso, un millón. Igual pasa con el número de operaciones en bolsa, el número de billetes de avión adquiridos por cliente (¡los habrá corporativos!), número de visitas a la página por IP, etc.
En estas situaciones, la distribución que resulta ideal para la mayoría de los casos —los pequeños, los normales— es inadecuada en los atípicos: estos crean picos, saturan máquinas y discos, dan lugar a cuellos de botella.
Tradicionalmente, quienes diseñan bases de datos adoptan una visión vertical de las tablas: las columnas tienen su función, son clave primaria, forman parte de un índice secundario, son atributos o clave externa de otra tabla. Y esas propiedades se extienden a todos los registros de la tabla.
Estoy convencido de que los datos grandes exigen una visión no únicamente vertical sino también horizontal, más próxima al contenido, a los datos, que tenga en cuenta el número, significado y estructura de las filas olvidando soluciones de talla única.
Teniendo ese principio en mente, una solución no enteramente ortodoxa —bajo cierta definición de ortodoxia— al problema de las tablas distribuidas con datos de cola pesada puede pasar por
descomponer la tabla-relación (en nomenclatura, valga la redundancia, relacional) en dos o más tablas-objeto (no necesariamente relacionales)
distribuir cada uno de ellos de acuerdo de la manera más indicada a su contenido y
emplazar las filas de la tabla-relación original en las tablas-objeto más adecuadas a su naturaleza.
El acceso a los datos se realizaría de manera distinta según cuáles fuesen los que se necesitasen: cada objeto tendría sus propios índices, distribución, etc. Y el usuario final, si el esquema anterior se implementa y encapsula con cuidado, no necesitaría gestionar la complejidad subyacente. La distribución de cada tabla-objeto debería realizarse de manera que globalmente se satisfaciese el criterio de uniformidad y que el de localidad se cumpla para los más de los datos, los que, por otra parte, casi seguro, son de consulta más frecuente.
¿Nos motiva el dinero? ¿Hasta qué punto? ¿En todo tipo de tareas? El siguiente vídeo de Dan Pink, basado en su libro Drive: The Surprising Truth About What Motivates Us, subraya la importancia de otros factores —autonomía, maestría, propósito— como directores de nuestra actividad.
Aunque extraído de una discusión acerca de la conveniencia de pagar a los desarrolladores de R, los más agudos de mis lectores sabrán extrapolar sus enseñanzas a otras circunstancias cotidianas.
Entré a trabajar en una consultora hace un tiempo ―no diré si mucho o poco― y uno de mis primeros encargos fue el de supervisar el desarrollo e implementación de unos modelos que habían creado unos compañeros. Les eché un vistazo y me sorprendió que sin mayor miramiento habían eliminado aquellas observaciones cuya variable objetivo tomaba el 4% de los valores más altos y el 4% de los más pequeños.
Pregunté al responsable de la cosa, un recién licenciado con ínfulas, a qué se debía el filtro. No me dio razón alguna: simplemente me remitió a un documento oficial de la consultora ―con sus colores y logotipos― que era una especie de guía sobre cómo construir modelos de minería de datos. Le eché un vistazo y me sonó familiar. Tanto más familiar cuanto más lo leía. Demasiado familiar. ¡El documento lo había escrito yo años antes (para otra consultora distinta, claro)! Tenía muchos retoques y añadidos, pero secciones enteras seguían siendo tal cual las habría dejado yo escritas.
Obviamente, lo que el documento decía no era lo que el primíparo había interpretado. Y pasaron cosas poco amenas que no son el objeto de la discusión de hoy: el inciso no tiene otra intención que, si no ya justificar, al menos, excusar el uso que hago de información de una presentación comercial de dicha consultora sobre métodos de análisis clúster. No la cito ni pido permiso porque, conocidos los antecedentes (y el de la anécdota no es ni el único ni, os lo prometo, la más hilarante), ¡a saber quién es el autor original!
(Eso sin perjuicio de que si me contacta alguien que pueda justificarme que son suyos los materiales que reproduzco, se los atribuya convenientemente).
Mi entrada de hoy es un inciso que trataré que sea ilustrativo, acerca del uso real de las técnicas de clústering. Y aunque proceda de una presentación comercial, me consta que proviene de un proyecto que probablemente costó más que mi apartamento. Quiero que aterrice la discusión que he planteado acerca de los métodos de clústering para que nadie piense que estoy sobreteorizando.
Dice la consultora en su presentación (y no corrijo la redacción aunque duela a la vista) que
[l]a implantación de una Segmentación Corporativa en base a Valor y Ciclo de Vida permitió a esta aseguradora multiramo definir una diferenciada estrategia para cada segmento
Y acompaña el anterior párrafo del siguiente gráfico:
En él pueden los lectores ver los famosos clústers: el de los solteros, los apóstoles, los seniors, los multiproducto. Cada globo, entiendo, tiene un tamaño proporcional (¿en radio? ¿en volumen?) al tamaño del clúster que representa. Los ejes son la edad (horizontal) y el valor (vertical).
Comencemos con un experimento mental: ¿qué forma tendría el gráfico de dispersión de los clientes individuales sobre esos ejes? ¿Estarían concentrados alrededor de los globos verdes? ¿Es razonable esperar que un único punto represente a todos los seniors (jubilados)? ¿Entre los 30 y los 40 sólo existen familias jóvenes? ¿Todos los clientes en ese rango de edad tienen el mismo valor? ¿Sólo hay diferencias por valor en clientes entre 40 y 55 años? ¿Cuántos clientes no habrá en las zonas blancas del gráfico? ¿Y ninguno tiene un valor negativo?
Critico un ejemplo, sí, pero puede extenderse a muchas otras circunstancias análogas: píntense siete clústers sobre dos ejes y seguro que podrán plantearse preguntas similares: son inherentes a la sobresimplificación.
Aunque sea ya un asunto extraestadístico, cabe reseñar cómo una segmentación sobresimplificada y pueril sirve a nuestros consultores para diseñar una mal llamada estrategia ―consúltese este documento para distinguir estrategia de lista de cosas que uno desearía que ocurriesen― igualmente pueril: véanse las flechas que, menos mal, al menos, apuntan en la dirección de la edad creciente! Una presunta familia joven puede progresar (al cabo de 10 años) e incorporarse a cualquiera de los tres clústers siguientes: multiproducto, familia madura o bajo precio. Segmentos que se caracterizan (según la presentación) en función de si los clientes contratan dos, uno o ningún producto adicional. ¡La estrategia consiste en tratar de vender productos adicionales a los miembros del clúster!
¿Quién fue el segundo hombre en pisar la luna? ¿Y el tercero? Aunque a veces pareciese lo contrario, ¿sabe que hay futbolistas que no son ni Ronaldo ni Messi? ¿Y otros ciclistas además de Contador e Induráin? ¿Y que la Fórmula 1 no se reduce a un tal Alonso?
Diríase que por razones sicológicas, nuestro cerebro tiende a sobresimplificar, se siente cómodo con una representación escueta de la realidad, es reacio a los distingos y grises. Le pirran las etiquetas: dígame de qué partido político es Vd. y enseguida crearé mis propias certezas sobre su opinión acerca de la Guerra de Irak, la visita del Papa a Madrid y el bikini de Leire Pajín.
En esa tendencia a etiquetar y sobresimplificar se basa gran parte del éxito de las técnicas de clústering. Así, cuando a Quetelet le bastaba un único homme moyen hace casi doscientos años, nuestros estadísticos de hoy parecen encantados con media doceneja.
Pero Quetelet, en el fondo, estaba interesado en aquellas desviaciones de los individuos con respecto a su ideal homme moyen: si Quetelet estableció el índice de masa corporal no fue tanto para caracterizar las características antropométricas de su hombre medio sino para poder mejor detectar y cuantificar las desviaciones, tanto por exceso como por defecto, en individuos reales. Hoy en día estas distinciones les resultan odiosas. Al fin y al cabo, no es lo que los clientes de nuestros consultores quieren oír.
¿Prueba de lo anterior? Tómese cualquier presentación comercial/profesional en la que se describan los resultados de un análisis de este tipo. ¿Cómo se describen los clústers? Medias. Se resumen en listas de enunciados del tipo: la media de la variable X en el grupo Y es Z. A lo más, ofrecen una comparación entre la media de una variable dada en un grupo determinado y la media global de la población entera.
Traté en tiempos, cuando trabajaba en una consultora, de crear algún tipo de procedimiento honesto para visualizar clústers. Mi propuesta —manifiestamente perfectible por otro lado— quedó totalmente eclipsada por la de un colega que decidió que bastaba (y era cool) representar las medias de todos los grupos en un gráfico de araña con tantos radios como variables en el que cada clúster venía representado por un color distinto. ¡Nunca antes había visto la necesidad de usar la lupa —existe, ¿eh?— de Windows! Pero era un gráfico que escondía los indicios de sospecha y evitaba de antemano todo tipo de preguntas odiosas por parte de los clientes.
Pero, ¿y la variabilidad dentro de cada clúster? ¿Algún comentario sobre las zonas grises? ¿Cuáles son las observaciones que pertenecen al clúster A y no al B por un pelín de gato?
Hemos visto en una entrada anterior que los centros (o centroides) de los clústers son, habitualmente, irreproducibles. Que es decir poco menos que arbitrarios. Además, la asignación de los sujetos a cada uno de ellos, bien mirada, también es cuestionable.
El siguiente código —y supongo que las mejoras que a él realicen los lectores— permite cuantificar una serie de aspectos que uno nunca verá planteados ni en libros de investigación de mercados ni en los caveats de las consultoras. Permite ver cómo la distancia entre los sujetos de los grupos y sus centros crece al aumentar el número de variables. Es decir, cuantas más variables se utilicen para realizar un análisis clúster, mayor será la diferencia o distancia entre un sujeto y el individuo prototípico que lo representa.
av.dist <-function( n.dim, n.iter ){
a <- b <-rep(0, n.dim )
a[1]<-0.5
b[1]<--0.5
calcular.distancias <-function(){
x <-2*runif( n.dim )-1sqrt(c(sum(( x - a )^2),sum( x - b )^2))}
distancias <-replicate( n.iter, calcular.distancias())}
foo <-function( n.dim ){
tmp <- av.dist( n.dim,1000)median(pmin( tmp[,1], tmp[,2]))}
foo(2)
foo(20)
res <-sapply(1:100, foo )
Queda como ejercicio para mis lectores estimar el tamaño —en proporción del número total de sujetos— que quedan en la zona gris entre ambos centroides según aumenta el número de dimensiones.
En resumen, el éxito del llamado análisis clúster responde en muchos casos y aplicaciones a una inercia sicológica que empuja al ser humano a la sobresimplificación. Dejada aparte la irreproducibilidad, sus efectos distorsionadores aumentan con el número de variables. Y, finalmente, muchos profesionales que aplican este tipo de estudios hacen dejación de sus responsabilidades —o las ignoran— cuando soslayan la variabilidad de los sujetos alrededor de sus prototipos y pasan or encima del problema que suponen las zonas grises.
Un procedimiento de detección de clases automáticamente descubrió la distinción entre la leucemia mieloide aguda (AML) y la leucemia linfoblástica aguda (ALL) sin conocimiento previo de las clases. Después se construyó un predictor de clases…
En esencia, los autores tomaron (dicen) unos datos, aplicaron técnicas de clústering y encontraron dos clases. Supongo que validarían el experimento fehacientemente hasta tener cierta seguridad de que, efectivamente, había motivos para creer que los datos estaban escindidos en dos partes claramente diferenciadas. Y, posteriormente, fueron capaces de sustentar dichas diferencias utilizando información externa: efectivamente, los miembros de los grupos respondían a cuadros clínicos distintos.
Incluso en este caso, si los autores no sabían que en sus datos existían dos clases muy distintas, fue por que no preguntaron: la etiqueta se conocía desde el momento de la recopilación de los datos y las diferencias entre la leucemia mieloide y la linfoblástica son tan notorias (para un experto) como las que distinguen el día de la noche.
En todas las demás situaciones en las que he visto utilizar este tipo de métodos la situación ha sido muy distinta. (Salvo en los libros, claro. En los libros hacen trampa. En los libros plantean problemas de laboratorio absolutamente irreales: bidimensionales, con variables sin ningún tipo de problema, con grupos que se ven perfectamente a ojo, etc. ¡Ni los mencionaré en esta serie!)
En todas las demás situaciones de las que tengo noticia, incluso en las que he participado y llevan mi firma, por las que, en algunos casos, y por las que se han pagado decenas de miles de euros, el análisis no ha sido en absoluto riguroso. Quiero subrayar en esta serie de entradas tres características sospechosas que definen este tipo de estudios:
No replicabilidad
Dependencia de las hipótesis de partida y del preprocesamiento de los datos
Falta de rigor a la hora de analizar la validez de las clases obtenidas
En la entrada de hoy trataré la primera de ellas. Las dos preguntas que me sugiere el problema son las que dan título a las dos secciones siguientes de esta entrada.
Si los datos no tienen clases definidas, ¿las encontramos aun así?
Mala será la replicabilidad del método cuando uno es capaz de encontrar clases aun cuando no existen. Tomemos el siguiente pedazo de código, que crea un conjunto de datos con n.obs observaciones en un espacio de dimensión n.dim y busca n.clus clases en él:
¿Encuentra clases? ¿Se parecen a las que se obtienen al crear otro conjunto de datos con exactamente la misma distribución de partida?
Cierto que el paquete cluster proporciona herramientas para verificar hasta qué punto son buenas las clases obtenidas. Pero si habéis trabajado en el negocio, ¿las habéis utilizado alguna vez? ¿Habéis advertido a vuestros superiores (o clientes) de que vuestro clústering es sospechoso? En caso afirmativo, ¿qué os han respondido?
Si los datos tienen clases definidas, ¿las encuentra el algoritmo?
De nuevo, podemos hacer otro experimento con el siguiente trozo de código, que es una versión del anterior.
Esta vez hemos fabricado n.clus clases distintas que serán más o menos distintas en función del parámetro sigma. Aun conociendo de antemano el número de clases en vuestro conjunto de datos, ¿sois capaces de recuperar las clases iniciales? ¿Se parecen en algo los centros de las clases obtenidas a los preespecificados? ¿Cómo de grande tiene que ser sigma para obtener resultados razonables y consistentes? ¿Seríais capaces de deducir el valor del parámetro crítico n.clus si no supiéseis su valor al crear los datos?
Resumen
Los dos experimentos propuestos en esta entrada hacen referencia a dos elemenos de sospecha que me obligan a replantearme ―y entiendo que muchos otros compañeros de faena les ocurrirá igual― la validez de los métodos de clústering tal cual se usan en muchas aplicaciones: los resultados no son repetibles, incluso con los mismos (o una muestra de los mismos) datos.
Los resultados de un estudio de clústering tienen que ser (y temo repetirme):
Replicables bajo condiciones, submuestras e hipótesis diferentes.
Tiene que ser posible encontrar una causa extra-algorítmica del motivo por el que los sujetos se arraciman de esa manera y no de otra.
Y si no hay replicabilidad, si no se cumplen las dos condiciones anteriores, no hay ciencia. A lo más, charlatanismo.
