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.

Errores al escoger una pareja … Errores al hacer un modelo!

Leyendo sobre los típicos errores que se cometen al modelar, me topé con varios que están relacionados con el manejo de los datos. Si te encuentras con alguien que diga “yo no me equivoco”, seguramente no ha generado un modelo confiable y menos escogido a la pareja perfecta.

Hablando del desarrollo de modelos, los errores tienen una razón de ser y caer en ellos nos permite avanzar… recuerdo muchas experiencias, mías y de compañeros donde se celebraba un buen resultado, pero al momento de revisarlo por un pequeño detalle se cae toda la validez del modelo.

Suena raro pensar que los errores en generar un modelo puedan verse como elegir un pareja, pero podemos comparar estos errores por lo que los causa prejuiciosos, nos dejamos llevar o nunca quisimos ver como era la personas.

Así  que si estas realizando un modelo sería bueno que leas los siguientes errores y ahorrarte unos malos momentos.

Fácil de identificar – Tiempo del prejuicio

Seguramente al inicio del desarrollo y por ganas de obtener un buen resultado hemos caído en ciertos errores basado en un prejuicio o manipulado por el deseo de otros. Es como escoger una pareja por como deseamos que sea,  la primera impresión o chismes.

  1. Tomar resultados que se ajustan a tus necesidades y desechar los que no te gustan. (Ver solo lo que quieres ver).
  2. Extraer conclusiones de un conjunto incompleto de datos, ya que los datos han “sobrevivido” algunos criterios de selección (Prejuicio de supervivencia).
  3. Sacar conclusiones de un conjunto de datos que no son representativos de la población objetivo (Sesgo de muestreo).
  4. Manipular los límites geográficos utilizados para agrupar datos con el fin de cambiar el resultado.
  5. Distorsionar la realidad por resultados de investigaciones publicadas (Sesgo de publicación).

 

Cometemos al modelar … nos dejamos llevar  

En estos errores se generan cuando ya estamos desarrollando el modelo y tenemos algunos resultados en el proceso pero no hemos terminado. Pensemos que ya andamos con la pareja y porque nos tomó de la mano y nos sonríe podemos intuir que quiere algo más que un beso, nos dejamos llevar por nuestros ideas y en algunos casos hasta una cachetada nos ganamos.

  1. Asumir que dos variables están relacionados por parecer que una tiene efecto en la otra (Falsa Causalidad).
  2. Creer que debido a que algo ha sucedido con mayor o menor frecuencia de lo habitual, será menos probable que suceda en el futuro. (Falacia del jugador).
  3. Cuando algo sucede que es inusualmente bueno o malo se volverá la norma con el tiempo (Falacia de regresión).
  4. Cuando una tendencia aparece en diferentes subconjuntos de datos, pero desaparece o se revierte cuando los grupos se combinan (Paradoja de Simpson).
  5. Establecer un incentivo que produce accidentalmente el resultado opuesto al que se pretende (Efecto cobra o incentivo perverso).
  6. Hacer varias pruebas de hipótesis a una misma data, sin considerar que la mayoría de las correlaciones serán resultado de la casualidad.

 

Terminamos – Nunca quisimos ver

En este tipo de errores ya tenemos un modelo del cual seguramente el resultado no es el adecuado. Hemos terminado con la pareja y sabemos que no fue la mejor pero seguimos sufriendo y pensando que era la perfecta para nosotros.

  1. Crear un modelo que explica muy bien datos de desarrollo y tomarlo como bueno para todos los datos (Overfitting).
  2. El acto de supervisar algo puede afectar su comportamiento, conduciendo a resultados falsos (Efecto Hawthorne o del observador).
  3. Tomar métricas generales/sumarizadas y olvidar que se puede encontrar mayor información en los datos crudos.
  4. Depender únicamente de métricas en situaciones complejas y perder de vista el panorama más amplio. (Falacia de Mcnamara).

Como en todo con la experiencia se pueden evitar los errores y a diferencia de con las parejas al realizar un modelo se cuentan con muchas herramientas estadísticas que nos pueden dar información prevenir o detectar si estamos cometiendo algún tipo de error.

Espero te haya sido de utilidad estos errores y me compartas tus experiencias al desarrollar un modelo y como has identificado y solucionado ciertos errores.

Posdata. Suerte al escoger una pareja!!!

Qué difícil es decidir … Data Science o Big Data

Dos temas de moda que han abierto un mundo de oportunidades a las empresas y ofertas de trabajo principalmente para aquellos que nos enfocamos en el análisis, explotación y modelación a partir de datos, pero como profesionista: ¿puedo aplicar o ser los dos conceptos al mismo tiempo? y como empresa:  ¿Hacia dónde debo moverme? o ¿a quién debo contratar a un Científico de Datos o a un experto en Big Data?.

En algunos artículos se habla de un fuerte crecimiento de la demanda de posiciones relacionadas a estos dos temas (75% en los últimos 3 años), para México esto ya es palpable a pesar de que tiene pocos años de haberse puesto de moda. Los datos es el factor común, sin embargo el uso de datos tiene una larga historia, el cambio esta en la historia reciente donde el volumen de datos esta creciendo aceleradamente debido a los avances tecnológicos.

¿Cuál es la diferencia entre Data Science y Big Data? … empecemos describiendo de forma sencilla cada uno:

Data Science

Es un conjunto de practicas basadas en métodos científicos, procesos, algoritmo y sistemas para extraer conocimiento de una data (SQL or No SQL). La mayoría lo divide en 3 partes, pero lo importante es la relación entre ellas  tal como se muestra en la imagen:

Data scienceBig Data

Refiere a una cantidad muy elevada de datos en una variedad de formatos que no puede ser procesada efectivamente con las aplicaciones tradicionales.

La importancia de este concepto radica que permite obtener respuestas a miles de preguntas esenciales a una velocidad que sería imposible por medio del trabajo humano o almacenarlo y procesarla con una sola maquina.

Igualmente podemos describirla con aspectos que son “las 3 Vs del Big Data”:

Big Data

Aplicación de ambos conceptos

Para poder hablar de este tema, me puse de tarea leer que concepto sería mejor para algún tipo de industria, sin embargo me encontré ideas contradictorias como decir “big data es para la industria financiera y data science no lo era”, cuando los bancos en estos momentos están buscando explotar toda la información en la big data para agregar más información a sus modelos, pero al mismo tiempo están generando áreas llamadas Data science o contratando data scientist para generar dichos modelos.

Si analizamos lo anterior, esto aplicaría a todas las industrias, es decir Data Science y Big Data son conceptos que no se excluyen y su aplicación en una empresa dependerá del apetito o necesidad de la misma empresa.

10 preguntas para saber a quién contratar

Puedes hacer un ejercicio muy sencillo, ordena las preguntas por prioridad para tu empresa y ve que figura esta más enfocado a tus prioridades:

  1. ¿Quiero saber tendencias globales para obtener mas clientes?  Experto en Big Data
  2. ¿Quiero que mi sistemas se enfoquen en clientes/productos más rentables? Data Scientist
  3. ¿Qué problema clave debo resolver, es normal o pasa algo (fraudes, averías, etc)? Data Scientist
  4. ¿Dónde  puedo obtener o recolectar datos? Experto en Big data
  5. ¿Cómo procesarlo datos para analizarlos y generar información? Ambos
  6. ¿Qué investigar e identificar mi empresa ante la competencia? Experto en Big Data
  7. ¿Cómo puedo tomar decisiones rápidas y agiles?  Experto en Big Data
  8. ¿Puedo clasificar/segmentar mis productos/clientes para poder sacar mayor provecho? Data Scientist
  9. ¿Hay forma de prevenir actividades o aspectos no deseables? Data Scientist
  10. ¿Cómo puedo pronosticar mis ventas, ingresos, etc? Data Scientist

Posiblemente tu decisión se vaya a experto en big data, lo cual es muy bueno porque estas buscando nuevos horizontes para tu empresa, y seguramente lo obtendrás. Si fue para un data science seguramente hay varias áreas de oportunidad que quieres explotar. Lo genial sería contar con ambas figuras en tu empresa, seguramente tendrías más información que te ayudarían en la toma decisiones sobre el rumbo de tu empresa con impacto en corto y largo tiempo.

Ahora si me preguntas que perfil es más completo, mi respuesta se mueve hacia el científico de datos, sin embargo es muy complicado que una persona llegue a cubrir los 3 aspectos mencionados en la definición, usualmente hay diferentes tipos de científicos de datos:

  • Tipo matemático. Es muy bueno en matemáticas, estadística y modelos, su nivel de programación es alto en lenguajes estadísticos y  medio en lenguajes de uso general; ellos basan el entendimiento del negocio en indicadores y valores numéricos, por ello usualmente no seles considera muy sensible a ciertos aspectos del negocio que dependen de factores humanos. (usualmente son matemáticos,  actuarios o economistas).
  • Tipo tecnológico. Conoce sobre bases de datos y los diferentes tipos de ellas,  sabe y puede aprender varios lenguajes de programación rápidamente (SAS, R, Python, Java, Spark, etc), lo cual lo vuelve muy fuerte para big data, sin embargo ve el negocio desde una forma sistemática o de bases de datos,  y requiere repasar su nivel de estadística y técnicas como machine learning para generar buenos análisis y modelos. (Ciencias de la computación, ingeniero en sistemas, etc).
  • Experto del negocio. Este perfil es de una persona que tiene tiempo en la empresa lo cual le ha dado el conocimiento para identificar y entender las causas operativas del comportamiento de indicadores, son los mejores para interpretas números, pero su perfil es bajo en programación y aspectos matemáticos (diversas profesiones).

Basado en lo anterior puede haber un científico de datos que trabaje con la big data, la respuesta es si, principalmente si tiene una formación que proviene de IT o un fuerte conocimiento de minería de datos. Por otro lado, un experto en big data puede hacer lo de un científico de datos, también es posible pero requiere que tenga conocimientos de estadística y machine learning.

Finalmente, al ser un perfil más completo el de data science, su valor salarial promedio es cercano al doble de lo que gana un experto en big data, pero este perfil representa un reto muy grande que no es cubierto fácilmente porque no hay un equilibrio en los 3 componentes que conforman Data Science, de esto se tiene que en muchos casos hay personas que se cuelgan el titulo, pero aun le faltan desarrollar muchas habilidades.

Por cuestiones de aburrimiento se colocaron breves descripciones de los temas, pero en futuras publicaciones se estará dando por separado mayor detalle de cada uno de los temas.

Espero les haya gustado y espero sus comentarios!!!

Atole con el dedo en modelos de ortorgamiento de crédito

Siendo esto lo primero que escribo en mi página personal, me gustaría comentar que este blog estará enfocado a platicar de temas relacionados con la Ciencia de Datos. En algunos casos analizaremos aspectos técnicos (Machine Learning, Data mining, Big data, etc) y en otros casos expondré situaciones o controversias de interés enfocadas a conceptos de negocio o presentación de resultados. Por ello mi primer escrito les platicaré sobre como La Regulación en el otorgamiento de créditos personales está cambiando: “Por ley en los modelos de crédito no se podrá utilizar variables que discriminan a una persona, por ejemplo edad, género, preferencia religiosa, política, etc.”.

La mayoría de los modelos actuales en el sector financiero utilizan variables socioeconómicas para dar un préstamo, entre las principales tenemos edad y género, es sabido que una mujer es mejor pagador que un hombre y también que una persona menor a 21 años tiende a no cumplir con su responsabilidad crediticia, con esto podrás contestarte el porque te negaron un préstamo por el simple hecho de ser un chavo, y esto se entiende como una injusticia de género y edad… ¿Qué tan injusto es para ti?.

Sin duda, se estarán preguntando y que tiene que ver con el título “Atole con el dedo” , pues ya entrados en el tema, el no usar estas variables significaría para muchas instituciones financieras el no poder  distinguir entre clientes que Pagan y de quienes no… ¿Qué puede hacer la industria de préstamos sin no usa las variables?.

Si estos cambios en la regulación hubieran sido en tiempo de nuestros padres, o mejor dicho hace unos 10 años seguramente los bancos y financieras terminarían buscando un amparo,  y aunque no lo creo probable a nivel banca relajarían sus políticas de crédito para generar más préstamos, pero como en todo siempre hay un pelo en la sopa, para poder garantizar que no hubiera mayor pérdidas en sus ganancias tendrían que subir sus tasas de interés, de allí es que actualmente hay financieras que otorgan créditos que los bancos no dan pero  suelen utilizar tasas de interés más altas, a mayor riesgo el cliente termina pagando más por su crédito.

Si lo anterior ya no aplica, entonces hacia dónde vamos;  pues gracias a todo el poder que nos da la información en internet y de aquellos programas que amablemente la han estado recolectando , existe algo llamado Big Data con información de nuestras preferencias, estilo de vida, etc.

Pensemos, si en lugar de tomar una variable de género utilizamos variables como compra en tiendas con nichos de mercado específicos (no necesariamente digan para la mujer) o que lean ciertas revistas (algo así como de conejitas) podríamos identificar el género y la edad… Se cumple con la regulación, se tiene igual o mejor identificación de potenciales no pagadores, los modelos serán más robustos y se verán más como una caja negra… pero si tú eres un chavo joven y sin historial crediticio probablemente serás rechazado –> Atole con el dedo en el otorgamiento de crédito.