EN

En ocasiones, al modelar el funcionamiento de un proceso en el que participan diferentes variables, nos encontramos con que algunas de ellas dominan sobre las demás, es decir, ciertas variables ejercen mayor influencia que el resto. Supongamos, por ejemplo, procesos con dato declarativo en los que la variable a predecir es, a su vez, informada por el propio usuario. Un ejemplo de este caso podría ser un estimador del precio de una vivienda como una variable continua, esto es, que pueda tomar cualquier valor numérico, y solicitar a su vez esta información en un formulario como rangos de valores, por ejemplo un campo desplegable con diferentes opciones. En este caso cabe esperar que la información declarada describa casi la totalidad de la variable a predecir. El objetivo de utilizar un estimador sobre un dato ya conocido puede ser muy variado: hacer continua una variable discreta, suavizar una variable, detectar errores en la introducción de datos, refinar el dato declarativo para unificar criterios o, simplemente, cumplir con una regulación.

La importancia de una variable se puede calcular de diferentes formas dependiendo del tipo de modelo que se ajuste. Por ejemplo, en una regresión lineal o logística es habitual que esté relacionada con el peso (coeficiente) asociado a cada variable descriptora, mientras que en el caso de los árboles suele estar relacionada con la reducción de la métrica empleada para hacer las divisiones. También existen técnicas agnósticas del modelo; una de las más conocidas es Permutation Feature Importance1. Esta técnica se suele emplear en modelos ya entrenados, poco interpretables o altamente no lineales y se basa en romper aleatoriamente la relación entre la variable descriptora y la objetivo observando el consecuente decremento en el rendimiento del modelo. En cualquier caso, independientemente de cómo se mida la importancia de una variable en un modelo, el resultado de la medida representa de alguna manera la dependencia entre la salida del modelo y la variable en cuestión.

En un proceso industrializado en el que se utiliza la salida de un modelo para tomar decisiones no suele ser buena práctica depender mucho de pocas variables. Puede, por ejemplo, que esas variables dejen de informarse por fallos técnicos (o que se informen erróneamente) y, en estos casos, la predicción será más o menos fiable en función de la dependencia que tenga con dichas variables. Supongamos el ejemplo anterior, en el que el estimador del precio de la vivienda depende en gran medida del importe declarado. Si en una actualización del formulario se recoge mal dicha variable, por ejemplo por un cambio de formato o el tipo de dato, el estimador proporcionará salidas completamente erróneas.

Otro punto importante es que un modelo que depende altamente de una variable es fácilmente violable y esto puede suponer un problema en un proceso de admisión. Supongamos, sobre el ejemplo anterior, que esta vez el precio estimado de la vivienda proporciona acceso a crédito y que este estimador es altamente dependiente de los ingresos medios declarados por el usuario de forma que a mayor ingreso medio, mayor precio de la vivienda. Si se descubre dicha relación, sería muy sencillo engañar al estimador inflando el valor de ingresos medios, lo que daría lugar a accesos a crédito erróneos.

Por los motivos anteriores, diluir la importancia de las variables en un modelo le aporta robustez ante fallos y ataques. A cambio, generalmente, perdemos en términos de rendimiento.

En el caso de la regresión lineal es posible, en algunos casos, imponer restricciones duras sobre los coeficientes en el proceso de optimización2 , así como penalizaciones sobre la magnitud de los coeficientes. Sin embargo, en el caso de los árboles de decisión no se dispone de un procedimiento similar que aplique sobre el propio algoritmo de construcción del modelo.

Una alternativa habitual consiste en introducir ruido aleatorio sobre la variable dominante, tratando de encontrar el equilibrio entre el decremento del poder predictivo y la aportación de esa variable al modelo. También sería posible limitar aleatoriamente el subconjunto de variables candidatas en cada división del árbol, con la desventaja de que deja el ordenamiento de la selección, y por tanto la reducción de la métrica de error, en manos del azar. Otra alternativa sería ordenar esta selección haciendo uso de alguna métrica de error de manera que en los primeros pasos de la decisión solo se pudiesen seleccionar variables que no aportasen demasiado (limitando así las importancias), pero no es un procedimiento sencillo en la práctica porque implica saber desde el inicio cuánto reduce el error cada variable.

Esta última solución, no obstante, suena razonable ya que el hecho de que las variables más importantes entren en juego en las últimas fases de la decisión solventa los problemas mencionados al principio y el modelo resultante no sería tan dependiente de las mismas.

En nuestro caso de uso solo teníamos una variable altamente significativa (~90% en la reducción del error) y el resto de variables con una importancia más o menos balanceada. Así, decidimos aproximar la solución anterior con un procedimiento sencillo que denominamos ExtendedTrees. Consta de dos pasos: en primer lugar, ajustar un árbol de regresión con todas las variables excepto la de mayor importancia. A continuación, extender las hojas del árbol anterior utilizando únicamente la variable que quedó fuera en el paso anterior.

Figura 1: Esquema de funcionamiento del método ExtendedTrees. Los nodos naranjas son las hojas del primer árbol, entrenado con todas las variables excepto la variable proxy. Cada uno de estos nodos es, a su vez, extendido con nuevos árboles poco profundos que únicamente emplean la variable proxy. La estimación de salida se da en las hojas de los árboles de extensión (nodos turquesa)

El conjunto de hiperparámetros compuestos por la profundidad del primer árbol y las profundidades de las n extensiones (donde n es el número de hojas del primer árbol) permiten tener el control sobre la aportación de la variable cuya importancia se desea limitar.

Utilizando esta aproximación en nuestro problema conseguimos reducir la importancia de la variable proxy en un ~45% aumentando el error original en un 3%.

Ejercicio con la base de datos de California Housing

Con el objetivo de entender mejor este procedimiento, mostramos un ejemplo de aplicación sobre la base de datos de viviendas de California, (California Housing). Se construyó a partir del censo de viviendas y cada entrada se corresponde con un block group, la unidad geográfica más pequeña para la cual el censo de EE.UU publica información (típicamente engloba a una población de entre 600 y 3.000 personas, similar a la sección censal española).

En total el conjunto de datos consta de 20.640 observaciones, con 8 variables numéricas y la variable objetivo, que son: mediana de ingresos (MedInc), mediana de la antigüedad de las viviendas (HouseAge), media del número de habitaciones (AveRooms) y de dormitorios (AveBedrms), población, ocupación media de las viviendas (AveOccup), latitud y longitud. Así como la variable que queremos predecir, que es el valor mediano de las viviendas de un block group.

En la siguiente figura se muestra la importancia de cada variable descriptora tras entrenar un Decision Tree Regressor (DTR) de profundidad 4 (en azul) y un ExtendedTree (ExT) de profundidad inicial 3 y 2 para las extensiones (en naranja), con el objetivo de estimar el valor mediano de las viviendas de cada block group. En ambos casos se ha empleado la técnica de validación cruzada para obtener los resultados.

Figura 2: Distribución de importancias en un DecisionTreeRegressor (azul) vs ExtendedTree (naranja). En este caso se muestran normalizadas (suman 1) y se calculan como el decremento en el error que aporta cada una.

La métrica de error empleada es el Mean Squared Error (MSE), cuyo uso es muy común en la evaluación del rendimiento de modelos de regresión. En este caso, se han configurado ambos modelos de forma que la métrica de error sea lo más similar posible (0.66 ± 0.04 vs. 0.67 ± 0.05), esto es, intentando que ambos estimadores funcionen igual de bien al estimar el valor mediano de las viviendas a partir de las variables disponibles. Dicha configuración da lugar a un árbol de 31 nodos en el caso del DTR y un árbol de 61 nodos en el caso del ExT, es decir, el segundo es mucho más complejo que el primero a igualdad de error.

Si nos fijamos en la importancia de cada variable en cada modelo (representado por la altura de la barra) se observa que el DTR depende en ~80% de la variable MedInc, la siguiente más importante es AvgOccup con algo menos del 20% y el resto de variables apenas influyen en la estimación del modelo. En el caso de ExT, sin embargo, la variable más importante sigue siendo MedInc pero en poco más del 40%, quedando además la importancia más distribuida entre el resto de variables.

Merece la pena destacar el caso de las variables HouseAge, AveRooms y Population (población). Mientras que en el DTR apenas influyen, en el ExT su importancia no es despreciable, es decir, son variables que tienen valor para la estimación del precio pero en el caso del DTR se ven eclipsadas por MedInc. En definitiva, el ExT es capaz de explotar más uniformemente las variables disponibles manteniendo el error a cambio de generar una estructura más compleja.

En conclusión, dependiendo de la naturaleza de los datos, los ExtendedTrees pueden resultar una solución sencilla ante el problema de la alta dependencia en los modelos Decision Tree. Este mecanismo se puede aplicar también en el caso de clasificación. Además, los ExtendedTrees son fáciles de entender, la estructura de su salida es la misma que la de un Decision Tree y permiten controlar, dentro de las posibilidades y mediante las profundidades, la aportación de cada variable en un árbol. Aunque, eso sí, pueden aumentar el error o la complejidad.

En el ámbito de la tecnología, y especialmente en el desarrollo de soluciones basadas en Inteligencia Artificial, la experimentación y la innovación son tareas que forman parte fundamental de nuestro trabajo. Desde BBVA AI Factory apostamos por reservar bloques de tiempo específicos para experimentar con tecnología del estado del arte y trabajar en ideas y prototipos que más adelante podrían incorporarse al abanico de soluciones basadas en IA de BBVA. Son lo que llamamos los sprints de innovación.

En uno de estos sprints nos preguntamos cómo podríamos ayudar a los gestores en sus conversaciones con los clientes. Los gestores, que asesoran y ayudan a los clientes en la gestión de sus finanzas, en ocasiones hacen búsquedas manuales en repositorios de respuestas predefinidas para responder a las preguntas más sencillas y frecuentes. Esto nos confirmó el potencial de desarrollar un sistema de Inteligencia Artificial que sugiriera posibles respuestas a los gestores tras recibir una pregunta de un cliente, de tal forma que con un solo click pudieran responder. La idea detrás de este sistema consistiría en ahorrar tiempo a los gestores en escribir respuestas que no requieren de su conocimiento experto, permitiéndoles así centrarse en aquellas que aporten mayor valor al cliente.

Así que nos pusimos manos a la obra. Una vez definido el problema, pronto empezaron a surgir diferentes formas de abordarlo. Por un lado, pensamos en un sistema de búsqueda de la pregunta más similar dentro del histórico a la planteada por el cliente y, posteriormente, evaluar si la respuesta que se dió en su día es válida para la situación actual. Por otro lado, también probamos a clusterizar (agrupar) las preguntas y sugerir la respuesta canónica pre-establecida para el clúster (grupo) al que pertenece la pregunta. Sin embargo, estas soluciones requerían mucho tiempo de inferencia o eran muy manuales (clustering de preguntas).

Finalmente, la solución que nos resultó más eficiente desde el punto de vista de tiempo de inferencia y que además era capaz de sugerir respuestas automáticas a multitud de preguntas de diferentes temáticas, sin tener que hacer un previo clustering, fue la de los modelos sequence to sequence también conocidos por su abreviatura en inglés: seq2seq.

¿Qué es seq2seq?

Los modelos seq2seq toman una secuencia de ítems de un ámbito y generan otra secuencia de ítems de otro ámbito diferente. Uno de sus usos paradigmáticos es la traducción automática de textos; un modelo seq2seq entrenado permite transformar una secuencia de palabras escritas en un idioma en una secuencia de palabras que mantiene el mismo significado en otro idioma. La arquitectura básica de seq2seq consiste en dos redes recurrentes (decoder y encoder), llamadas Long-Short Term Memory (LSTM).

Figura 1. Redes recurrentes LSTM (encoder y decoder)

Las redes LSTM son un tipo de red neuronal en la que cada una de sus celdas (hidden units) procesa en orden un elemento de la secuencia (en este caso, la representación de una palabra). Lo peculiar de estas redes neuronales es que conservan la información relevante de la celda anterior, al mismo tiempo que descartan la información que no lo es para las siguientes celdas. De esta forma la red aprende no solo de datos aislados, sino también de la información inherente a la secuencia, que va acumulando celda a celda. Esta característica es especialmente significativa en texto, puesto que el orden de las palabras es importante para construir oraciones sintáctica y semánticamente correctas. Técnicamente, también implica una gran ventaja, ya que reduce considerablemente el coste computacional. Para conocer en más detalle las LSTM recomendamos la lectura de este post de Christopher Olah.

Para ilustrar este concepto pensemos en los modelos de lenguaje cuyo propósito es predecir cuál será la palabra siguiente más probable. Por ejemplo: “María ha nadado durante dos horas y está muy ____”. En este caso, algo importante a “recordar” (información que pasa de una celda a la siguiente) es el género del último sujeto mencionado, de forma que la red sea capaz de determinar que la palabra “cansada” tendrá mayor probabilidad de ser la palabra correcta que “cansado”.

Como hemos mencionado anteriormente, la arquitectura seq2seq se compone de dos redes LSTMs: encoder y decoder. Volviendo al caso de la traducción automática, la misión de la red encoder es aprender la estructura de las frases en inglés (secuencias de entrada), mientras que el decoder hace lo propio con las frases en español (secuencias de salida). El decoder, además, también aprende la relación que existe entre ambas secuencias. De esta forma, el resultado de la última celda del encoder es un vector, llamado thought vector, que almacena la información de las celdas anteriores y por tanto, es una representación matemática de la frase en inglés, -es decir, de la secuencia de entrada-. Finalmente, el decoder utiliza estos vectores junto con la respuesta también codificada en representación matemática para el entrenamiento. Durante el entrenamiento la red aprende los patrones que permiten asociar una secuencia de entrada y otra de salida.

Figura 2. Dibujo ilustrativo de arquitectura de una red seq2seq (entrenamiento e inferencia)

¿Cómo hemos aplicado seq2seq para construir nuestro sistema de sugerencia de respuestas?

Aunque la traducción es una de las aplicaciones más evidentes, la ventaja de estos modelos es que son muy versátiles. Trasladando su funcionamiento a nuestro caso, podríamos “alimentar” el encoder con las preguntas de los clientes (secuencia 1) y el decoder con las respuestas que en su día dieron los gestores (secuencia 2).

Y eso hicimos. Seleccionamos de nuestro histórico más de un millón de conversaciones cortas iniciadas por el cliente con su gestor (no más de cuatro mensajes). Con este conjunto de datos, realizamos un pre-procesado clásico (lowercase, eliminar signos de puntuación) y descartamos saludos y despedidas mediante expresiones regulares. Este paso es útil ya que uno de los hiper parámetros de las redes LSTM es la longitud de la secuencia a aprender y es por ello que, suprimiendo esta información no relevante, podemos aprovechar mejor la capacidad de aprendizaje del modelo para secuencias más diversas o variables, así como reducir el coste de computación que tendría aprender secuencias más largas. Previamente a la fase de preprocesamiento, aplicamos nuestra librería de NER (Named Entity Recognition) para enmascarar ciertas entidades como pueden ser importes, fechas o expresiones temporales para tratarlas de forma homogénea y que el modelo posteriormente creado les de la misma importancia.

Una vez entrenada la red utilizamos algunas preguntas de test (no incluidas en el entrenamiento) y evaluamos manualmente la sugerencia de nuestro sistema. Como vemos en el siguiente ejemplo, el modelo es capaz de sugerir una respuesta adecuada a preguntas de los clientes.

Figura 3. El modelo sugiere una respuesta correcta a la pregunta del cliente

Sin embargo, cuando la pregunta está relacionada con la situación particular de un cliente, la respuesta sugerida no es del todo satisfactoria. Esto es debido a que el modelo no tiene en cuenta el contexto específico de cada cliente.

Por ejemplo, en el caso que mostramos a continuación, el sistema propone una respuesta que podría ser correcta pero no tiene en cuenta si efectivamente la tarjeta ya se ha enviado al cliente. Esta información contextual actualmente no es contemplada por el modelo. Uno de los próximos pasos en esta investigación sería conseguir que el modelo aprendiese a generar el mensaje de respuesta conforme a la situación actual del cliente ante una casuística concreta.

Figura 4. El modelo sugiere una respuesta no suficientemente correcta (falta de contexto)

Finalmente, también existen algunos casos en los que la respuesta sugerida al gestor por el modelo no es correcta, ya que no tiene relación con la cuestión planteada por el cliente.

Figura 5. En ocasiones, el modelo ofrece respuestas incorrectas

¿Cómo validamos nuestro modelo seq2seq?

Evaluar el resultado de un texto generado automáticamente es una tarea compleja. Por un lado, resulta imposible evaluar manualmente un conjunto de test de preguntas y respuestas relativamente grande. Además, si quisiéramos optimizar el modelo, posteriormente necesitaríamos algún método para medir la calidad y adecuación de las respuestas sugeridas por el modelo de forma automática.

Sin embargo, sí podemos realizar una evaluación manual que nos permita obtener, con un conjunto pequeño de mensajes y según nuestro criterio como clientes1, qué respuestas son adecuadas y cuáles no, calculando posteriormente la correlación entre nuestra evaluación manual y la evaluación obtenida por conjuntos de métricas automáticas como Rouge, Blue, Meteor o Accuracy.

La siguiente figura representa la correlación entre la evaluación manual (false: respuesta incorrecta, true: respuesta correcta) y los valores de las métricas automáticas. En un primer análisis observamos que bleu_1, rouge_1 y especialmente rouge-L son las métricas que mejor se alinean con el criterio humano. Esto es importante de cara a optimizar la arquitectura de seq2seq y para la evaluación automática del sistema. Aunque este estudio requeriría más investigación, consideramos que es suficiente para esta fase de prototipado.

Figura 6. Boxplot agrupado por corectness (corrección)

Con estas primeras pruebas realizadas con seq2seq (hemos omitido algunos experimentos fallidos y otras decisiones tomadas en el camino), hemos podido demostrar el enorme potencial de esta técnica en el contexto de las comunicaciones cliente-gestor en BBVA. Un sistema basado en seq2seq es capaz de sugerir respuestas a preguntas sencillas de los clientes. Sin embargo, para otras muchas tareas, como dar respuesta a preguntas relacionadas con el contexto específico de un cliente, es mucho mejor optar por la relación directa con nuestros gestores BBVA.