El problema del 100% (y un ensayo de solución)

Te encargan un modelo. Por ejemplo, relacionado con el uso de tarjetas de débito y crédito (aunque a lo que me referiré ocurre en mil otros contextos). Una variable que consideras importante es la proporción de veces que se usa para sacar dinero de cajeros (y no para pagar en establecimientos). Así que, para cada cliente, divides el número de retiradas por el número de veces que la tarjeta se ha usado y obtienes ese número entre el 0 y el 1 (o entre el 0% y el 100%).

Construyes tu modelo. Lo evalúas. Quieres ver cómo varían las predicciones en función del nivel de la variable que has creado. Efectivamente, la predicción crece con ella. No es para tirar cohetes, pero algo hay. Excepto que la predicción decrece en el extremo, en el 100%. Ahí pasan cosas raras.

(Todo lo anterior, supuesto que no uses algún tipo de modelo lineal. En tal caso, lo verías estudiando los errores en función de los niveles de la variable).

Si te ha pasado, te has topado con el ubicuo problema del 100%.

El motivo es simple y casi siempre el mismo: en ese extremo, en ese 100%, tienes cantidad de sujetos que solo han usado la tarjeta una vez. Y, fíjate, por casualidad casi seguro, la usaron para retirar dinero. Les has asignado un 100% y lo juro por mi madre cuando realmente no tienes ni idea sobre las preferencias de esos sujetos. El un perro maté y mataperros me llamaron no funciona aquí. No puedes confundir a esos sujetos con los que usaron la tarjeta 319 veces y 294 lo hicieron de la manera en cuestión.

Si tienes prisa y no quieres leer lo que sigue, en lugar de n/N haz \frac{n + 0.5}{N+1} y las cosas mejorarán, casi seguro.

Si tienes más tiempo, tómatelo para aprender sobre la distribución beta y en particular, sobre la inferencia bayesiana con prioris beta. En nada lo invertirás mejor.

3 comentarios sobre “El problema del 100% (y un ensayo de solución)

  1. Juan V. 6 octubre, 2014 10:52

    Hola Carlos,
    Quería preguntarte por PostgreSQL, es una BBDD sobre la que he oído cosas diversas y ando confundido. He leído que se trata de un SGBD relacional, basado en SQL, pero esto me choca con que sea muy potente para volúmenes altos y de aplicación en big data.
    Creo que paraleliza muy bien, pero aún así no entiendo que se utillice en big data donde se suele ir a sistemas No-relacionales, No-sql y en cambio PostreSQL (aceptado por mucha gente que le da al big data) sea sql y relacional. ¿Puede ser porque internamente tenga otro almacenamiento como almacenamiento columnar y soporte SQL?
    Yo vengo de BBDD tradicionales (Oracle, SQL Server, etc..) y me pierdo un poco con este tipo de BBDD como verás.
    Cualquier aclaración será bienvenida

  2. Carlos J. Gil Bellosta 8 octubre, 2014 20:16

    Aunque Postgres es mi SGDB preferido, hace años ya que ni lo uso ni lo administro. ¡Qué se le va a hacer! Lo que me consta es que se ha extendido en dos direcciones (dos direcciones pertinentes a tu pregunta, porque hay otras: PostGIS, etc.):

    1) Extendiéndolo en paralelo (como Teradata). Creo que EnterpriseDB, Netezza y algún otro tienen productos basados en esa idea.
    2) Permitiendo el uso de información no tabular o de estructura libre (noSQL, vamos). He oído de gente (muy forofa de Postgres) que las extensiones noSQL de Postgres son «lo mejor de ambos mundos», del relacional y del no relacional. Esencialmente, esas extensiones permiten guardar en «columnas» documentos de formato libre (¿JSON?). No obstante, sigues teniendo índices, etc.

    Pero no he trabajado con eso… ¡lo siento!

  3. Juan V. 13 octubre, 2014 10:45

    Muchas gracias por la aclaración

Los comentarios están desabilitados.