Minería de datos y Sistemas Expertos

Dic 27, 2011   //   by jc.cantera   //   S.Expertos  //  2 Comments

En primer lugar, realizaremos un breve repaso de conceptos de minería de datos

¿Para qué sirve la minería de datos? Podemos necesitar información de:

  • Patrones de Consumos en Particulares
  • Patrones de Consumos en Empresas
  • Posibles Fugas y Alertas
  • ¿Dónde puedo optimizar mi oferta?
  • ¿Cómo puedo reducir mis costes?

Actualmente se disponen de grandes cantidades de datos, por lo que podríamos pensar que es fácil llegar a alguna conclusión respecto a las necesidades anteriores. Se inicia la búsqueda de datos, de secuencias, de hábitos, en archivos, en dispositivos, en informes, en internet…

Fuentes de datos

Con todo esto se forma un conjunto masivo de datos: Es necesario formar conjuntos coherentes, “normalizar” la información, especialmente si está en distintos soportes y las fuentes son heterogéneas.

Una vez hecho este esfuerzo inicial, el análisis tradicional se basa en realizar consultas con cuyos resultados se generan gráficos estadísticos, cubos, tablas dinámicas.
Esto nos lleva a un proceso cíclico en el que hay que seleccionar qué variables se utilizarán (p.e. cliente, producto, centro), qué umbrales para los valores, y cómo se determinan las reglas.

Tras la realización de estos estudios, vienen las posibles implementaciones: Configuradores de productos basados en las preferencias detectadas, venta guiada por internet, apoyo a la decisión en tiempo real, asistentes virtuales, en banca y seguros, por ejemplo.

¿Podría lograrse que:

  • La información relevante se extraiga sola del conjunto de datos
  • Se descubran patrones de comportamiento de forma automática
  • Se generen reglas de negocio con la misma facilidad que le aprieta un botón
  • Las reglas generadas puedan ejecutarse, lanzando alarmas en caso de anormalidad
  • El sistema aprenda con cada nueva transacción
  • Se puedan introducir nuevas reglas, de forma manual y colaborativa?

¿Cómo se puede hacer esto? Combinando técnicas de minería de datos con sistemas expertos.

La minería de datos constituye un conjunto de procedimientos para el descubrimiento del conocimiento, tales como:

  •  Segmentación
  •  Clasificación
  •  Predicción
  •  Obtención de reglas mediante algoritmos de asociación, análisis de series temporales

Con todo esto se obtiene conocimiento del negocio, como por ejemplo:

  •  Detección de hábitos de compra
  •  Detección de patrones de fuga
  •  Detección de fraude
  •  Segmentación de clientes y asignación de los productos más adecuados
  •  Campañas de marketing

Sistemas expertos. Algoritmo RETE

Para poder utlizar este conocimiento extraído mediante la minería de datos se hace necesario contar con una herramienta más, los sistemas expertos. Las reglas del negocio obtenidas presentan un índice de fiabilidad o relevancia por las que se ordenan, seleccionando solamente las más importantes.

Los sistemas expertos basados en reglas utilizan el algoritmo RETE.

Las reglas expresan relaciones del tipo Si Condición Entonces Consecuente. Tanto condición como Consecuente pueden estar compuestos de varios términos.

Ventajas del empleo de reglas:

  • Las reglas nos permiten indicar “qué es lo que hay que hacer”, no “cómo hacerlo”. En este sentido, es mucho más fácil expresar soluciones a problemas complejos y, por tanto, obtener soluciones verificadas.
  • Las reglas permiten resolver problemas de gran complejidad, proporcionando una explicación de cómo se ha llegado a la conclusción y por qué se ha tomado la decisión. Esto es algo que no puede ser hecho por una red neuronal, por ejemplo.
  • Una ventaja más de un motor de reglas es que permite separar la lógica de los datos. De esta forma, la lógica  puede se mucho más fácil de mantener respecto a cambios futuros.
  • También se dan ventajas en cuanto a la velocidad y escalabilidad. El algoritmo RETE, así como Leaps y sus descendientes Drools, proporcionan muchas formas eficientes de comparar patrones de reglas sobre los datos.
  • El conocimiento está centralizado. Se crea una base de reglas que es un base de datos de conocimiento. Además, las reglas son, idealmente, legibles y pueden servir como documentación.
  • Se integra el motor de reglas dentro de la herramienta de desarrollo de software que se está utilizando.
  • Ayuda para explicación, y reglas comprensibles. La ejecución de reglas puede generar un log que explica qué decisiones se han tomado y por qué. Las reglas pueden estar escritas de una forma muy parecida al lenguaje natural, lo que facilitará la comprensión del proceso.

¿Cuándo usar un motor de reglas?

  • El problema es demasiado complejo para una programación tradicional
  • El problema no tiene una solución basada en un algoritmo obvio
  • La lógica cambia a menudo. Puede que la lógica sea sencilla, pero cambia con frecuencia
  • Existen expertos en el dominio tratado, disponibles en el momento, pero no son técnicos. Suele ocurrir que se disponga de expertos con una vasto conocimiento del negocio y que, no siendo técnicos sí son muy lógicos. Las reglas les permiten expresarse en sus propios términos.

¿Cuándo no usar un motor de reglas?

  • Si se trata de ejecutar un flujo de trabajo o procesos, el motor de reglas no es la herramienta adecuada.

Otras alternativas al uso de un motor de reglas, están basadas en motores basados en scripts, que soportan el dinamismo para cambios “sobre la marcha”.
También existen motores de procesos, capaces de ejecutar flujos de trabajo, como jBPM, diseñados gráficamente, que describen pasos en un proceso; pasos que pueden implicar puntos de decisión en forma de regla. A menudo estos workflow y las reglas funcionan muy bien en conjunto.

Estructura de las reglas

La representación del conocimiento para un motor de reglas viene dada por una estructura de dos grandes partes, que llamaremos LHS (left hand side) y RHS  (right hand side), o parte izquierda y parte derecha. Adicionalmente, puede contener otros atributos, como la prioridad, el grupo de reglas al que pertenece, si se puede buclar, duración…

La parte izquierda consiste en elementos condicionales y columnas, construidos según lógica de primer orden. Los elementos condicionales son los operadores ‘and’, ‘or’, ‘not’, ‘exists’. Y las columnas determinan restricciones en los contenidos de los campos, de tipo ‘literal’, ‘límites’, ‘valor devuelto’.

La parte derecha (RHS) es parte de acción o consecuencia de una regla. Su propósito es quitar o añadir hechos en la memoria de trabajo, así como  invocar acciones arbitrarias en la aplicación. Es decir, es un bloque de código que se ejecuta cuando la regla se dispara.

Los hechos se “afirman” en la memoria de trabajo y son comparados con las restricciones determinadas por las reglas, que seleccionan a qué hechos afectan. Por ejemplo, si en una regla se encuentra la columna (restricción) Person.sex=”female”, equivaldría a una sentencia SQL del tipo: select * from PEOPLE where People.sex == “female”.

Algoritmo RETE

El algoritmo RETE fue inventado por el Dr. Charles Forgy y documentado en su tesis doctoral en 1978-79. Una versión simplificada se publicó en 1982:  http://citeseer.ist.psu.edu/context/505087/0
El nombre RETE viene del latín red. El algoritmo puede ser dividido en dos partes: en tiempo de compilación y el tiempo de ejecución.

La compilación del algoritmo describe cómo se genera una red eficiente de discriminación con las reglas en la memoria de producción. Es decir, la red se utiliza para filtrar los datos. La idea es filtrar los datos mientras se propagan a través de la red. Al principio hay muchos nodos que coinciden con el patrón, y según se avanza por la red, se van reduciendo las coincidencias. En la parte más profunda de la red están los nodos terminales. En el paper del Dr. Forgy de 1982 se describen 4 nodos básicos: raíz, 1-input, 2-input y terminal.

El nodo raíz es por el que todos los objetos entran en la red. Desde aquí, inmediatamente van al ObjectTypeNode, que tiene como propósito que el motor no realice más trabajo del necesario. Es decir, si tenemos dos objetos, Cuenta y Pedido, cuando se comparan propiedades objeto, sólo se procesan los nodos de tipo de objeto tratado.

Los nodos ObjectTypeNodes puedes propagarse hacia AlphaNodes, LeftInputAdapterNodes y BetaNodes.
Los AlphaNodes se usan para evaluar condiciones literales. En implementaciones posteriores se soportan otros tipos de operaciones. En Drools, por ejemplo, se optimiza la propagación mediante hashing.

Los BetaNodes se usan para comparar dos obejetos y sus campos, entre ellos. Los objetos pueden ser del mismo o diferente tipo. Son nodos con dos entradas (2-input nodes): JoinNode y NotNode. Por convención nos podemos referir a las dos entradas con izquierda y derecha. La entrada izquierda es, generalmente, una lista de objetos. La entrada derecha es un único objeto. La entrada izquierda es llamada Beta Memory y recuerda todas las tuplas entrantes. La derechas se llama Alpha Memory y recuerda los objetos entrantes. Si en algún momento se encuentra una relación entere los hechos (objeto) y las tuplas de la izquierda, el objeto se propagará hacia el siguiente nodo.

Los nodos Terminales se usan para indicar que en una regla se han cumplido todas sus condiciones. Si una regla contiene un ‘or’, se generan nodos terminales para cada rama lógica. Así pues, una regla puede tener múltiples nodos terminales.

Join Node

En Ibermatica hemos realizado con éxito aplicaciones utilizando motores de reglas, unidos a sistemas de minería de datos, tales como:

2 Comments