Inteligencia Artificial (laboratorio) CLIPS

1. Inteligencia Artificial (laboratorio)CLIPS Primavera 2009 profesor: Luigi Ceccaroni

2. ¿Por qué CLIPS? • ¿Qué relación hay entres los altibajos de la IA a finales de los 80s y principio de los 90s, y el tener que aprender un nuevo lenguaje en cuarto de carrera? • ¿Qué importancia tiene para mí el colapso del mercado de las máquinas Lisp del 1987?

3. The collapse of the Lisp machine market in 1987 • In the 1980s a form of AI program called an "expert system" was adopted by corporations around the world. • The first commercial expert system was XCON, developed at Carnegie Mellon for Digital Equipment Corporation, and it was an enormous success: • It was estimated to have saved the company 40 million dollars over just six years of operation.

4. The collapse of the Lisp machine market in 1987 • Corporations around the world began to develop and deploy expert systems and by 1985 they were spending over 1 billion dollars on AI, most of it to in-house AI departments. • An industry grew up to support them, including software companies and hardware companies like Lisp Machines Inc. who built specialized computers, called Lisp machines, that were optimized to process the programming language Lisp, the preferred language for AI.

5. The collapse of the Lisp machine market in 1987 • In 1987 (three years after Minsky and Schank's prediction) the market for specialized AI hardware collapsed. • Desktop computers with a simpler architecture, from Apple and IBM had been steadily gaining speed and power and in 1987 they became more powerful than the more expensive Lisp machines. • The desktop computers had rule-based engines such as CLIPS available which left no reason to buy a Lisp machine. • An entire industry worth half a billion dollars was demolished overnight.

6. The collapse of the Lisp machine market in 1987 • Commercially, many Lisp machine companies failed, like Lisp Machines Inc., Lucid Inc. • Other companies, like Texas Instruments and Xerox abandoned the field. • However, a number of customer companies (that is, companies using systems written in Lisp and developed on Lisp machine platforms) continued to maintain systems. • Other systems moved from Lisp to a C++ variant on the PC via object-oriented technology and helped establish the o-o technology.

7. The fall of expert systems • Eventually the earliest successful expert systems proved too expensive to maintain: • They were difficult to update. • They could not learn. • They were "brittle" (i.e., they could make grotesque mistakes when given unusual inputs). • They fell prey to problems that had been identified years earlier in research in nonmonotonic logic.

8. The fall of expert systems • Expert systems proved useful, but only in a few special contexts. • Another problem dealt with the computational hardness of truth maintenance efforts for general knowledge. • KEE used an assumption-based approach supporting multiple-world scenarios that was difficult to understand and apply

9. The fall of expert systems • The few remaining expert system shell companies were eventually forced to downsize and search for new markets and software paradigms, like: • case-based reasoning or • universal database access

10. Failure to adapt • The fall of the Lisp machine market and the failure of the fifth generation computers were cases of expensive advanced products being overtaken by simpler and cheaper alternatives. • This fits the definition of a low-end disruptive technology, with the Lisp machine makers being marginalized.

11. Failure to adapt • Expert systems were carried over to the new desktop computers by, for instance, CLIPS, so the fall of the Lisp machine market and the fall of expert systems are strictly speaking two separate events. • Still, the failure to adapt to such a change in the outside computing milieu is cited as one reason for the 80's AI winter.

12. El sistema CLIPS • CLIPS is a public domain software tool for building expert systems. • The name is an acronym for "C Language Integrated Production System“. • The first versions of CLIPS were developed starting in 1985 at NASA-Johnson Space Center. • The original name of the project was NASA's AI Language (NAIL).

13. El sistema CLIPS • CLIPS is probably the most widely used expert system tool because it is fast, efficient and free. • Although it is now in the public domain, it is still updated and supported by the original author, Gary Riley. • CLIPS incorporates a complete object-oriented language COOL for writing expert systems. • Though it is written in C, its interface more closely resembles that of the programming language LISP. • Extensions can be written in C, and CLIPS can be called from C.

14. El sistema CLIPS • CLIPS es un entorno para desarrollar sistemas expertos. • Define un lenguaje que permite la representación de: • conocimiento declarativo (marcos) • conocimiento procedimental (reglas de producción) • Su base es un motor de inferencias con razonamiento hacia adelante.

15. El lenguaje de CLIPS • Se trata de un lenguaje con notación prefija. • Los tipos de datos predefinidos que interesan son: • real • entero • cadena • símbolo • apuntador a hechos • nombre de instancia • apuntador a instancia • Los tipos habituales poseen los operadores comunes. • El lenguaje de CLIPS aúna tres paradigmas de programación: • lenguaje de reglas • lenguaje funcional • lenguaje orientado a objetos

16. Hechos • Los dos elementos que permiten representar problemas utilizando reglas de producción son los hechos y las reglas. • Los hechos en CLIPS pueden ser de dos tipos: • ordered facts • deftemplate facts • Los ordered facts tienen formato libre, por lo tanto no tienen una estructura predefinida, siguen el esquema general: (relación p1 p2 ... pn) • relación ha de ser un símbolo; el resto de parámetros puede ser de cualquier tipo, por ejemplo: (padre Juan Pedro) (num-hijos Juan 2)

17. Hechos • Los deftemplate facts tienen una estructura predefinida; pueden asimilarse a representaciones al estilo de las ontologías. • En estos hechos se define una serie de campos (slots) que enmarcan su estructura. Cada campo puede tener una serie de restricciones como: • tipo • cardinalidad • un valor por defecto que puede ser: • una constante • un función para calcularlo

18. Hechos • Sintaxis: (deftemplate nombre-template "comentario“ (slot nombre-slot1) (slot nombre-slot2)) • Por ejemplo: (deftemplate persona “persona humana / hombre” (slot nombre (type STRING)) (slot edad (type INTEGER) (default 0)))

19. Hechos • La creación de hechos se realiza mediante la sentencia assert (uno solo) o deffacts (un conjunto), por ejemplo: (assert (padre Pepe Juan)) (assert (persona (nombre "pedro") (edad 25))) (deffacts mis-hechos (casa roja) (pelota verde) (persona (nombre "luis”) (edad 33)))

20. Hechos • (facts) permite saber que hechos hay definidos. • (clear) borra todos los hechos definidos. • (retract <índice-hecho>) elimina el hecho identificado por el índice dado. • (get-deftemplate-list) retorna la lista de deftemplates definidos.

21. Reglas • Las reglas en CLIPS están formadas por: • Una parte izquierda (LHS) que define las condiciones a cumplir • Una parte derecha (RHS) que define las acciones a realizar • Sintaxis: (defrule nombre-regla "comentario" (condición-1) (condición-2) ... => (acción-1) (acción-2) ...)

22. Variables • Para poder establecer patrones en las condiciones de las reglas hacen falta variables • Las variables en CLIPS se denotan poniendo un interrogante delante del nombre (?variable) • Existen variables anónimas (no importa su valor) para un valor ? o para múltiples valores $? • Durante la ejecución de las reglas se buscan los valores que instancien las variables y permitan cumplir las condiciones • Las variables de las reglas son locales, si queremos definir variables globales debemos usar la construcción defglobal (las variables globales se denotan ?*variable*)

23. Notación • square brackets [...] • contents are optional: • (example [test]) • pointed brackets (less than / greater than signs) < ... > • replace contents by an instance of that type • (example <char>) • star * • replace with zero or more instances of the type • <char>* • plus + • replace with one or more instances of the type • <char>+ (is equivalent to <char> <char>* ) • vertical bar | • choice among a set of items: • true | false

24. Reglas de CLIPS: LHS • En la parte izquierda de una regla pueden aparecer diferentes tipos de condiciones: • Patrones constantes, con variables o con wildcards: se instancian directamente con hechos en la base de hechos. • Expresionesnot, and, or, exist y forall con patrones. • Tests de expresiones sobre las variables vinculadas. • Los patrones indican qué tipo de hechos deben instanciar las reglas y se establecen a través de restricciones sobre variables o valores constantes. • Estas restricciones se pueden combinar mediante conectivas lógicas: ~ (no) & (y) | (o) 24

25. Ejemplos de LHS • Personas de nombre juan o pedro: (persona (nombre juan|pedro)) • Personas con nombres diferentes: (persona (nombre ?x)) (persona (nombre ?y&~?x)) • Nadie se llama pedro: (not (persona (nombre pedro))) • Todo el mundo es mayor de edad: (forall (persona (nombre ?n) (edad ?x)) (test (> ?x 18))) 25

26. El lenguaje de reglas de CLIPS • En la parte derecha de las reglas (RHS) podemos poner cualquier sentencia válida en CLIPS (ver manual de referencia). • Podemos obtener la dirección de un hecho para usarlo en la RHS mediante el operador <-, por ejemplo: (defrule mi-regla ?x <- (persona (nombre juan)) => (retract ?x) ) 26

27. Reglas de CLIPS: módulos • Las reglas de CLIPS se pueden agrupan/organizar en módulos. • La ventaja principal es el poder estructurar el conocimiento y poder enfocar la ejecución de las reglas según su objetivo. • La definición de un módulo se realiza mediante la construcción: (defmodule <nombre> "comentario" <export-import>) • Nada de lo definido en un módulo es visible salvo que lo exportemos. • Para utilizar construcciones de otro módulo también tenemos que importarlas explícitamente. • Existe un módulo por defecto llamado MAIN al que pertenece todo lo no definido en otro módulo. 27

28. Reglas de CLIPS: módulos • Podemos definir construcciones pertenecientes a un módulo poniendo como prefijo de su nombre el nombre del módulo seguido de dobles dos puntos ::, por ejemplo: (deftemplate A::cubo (slot tamaño)) • La exportación de construcciones de un módulo se realiza incluyendo la sentencia export en su definición. Podemos exportar cualquier cosa que definamos, por ejemplo: (defmodule A (export deftemplate cubo)) (defmodule A (export deftemplate ?ALL)) • La importación de construcciones a un módulo se realiza incluyendo la sentencia import en su definición. Podemos importar cualquier cosa visible que esté definida en otro módulo, por ejemplo: (defmodule B (import A deftemplate cubo)) 28

29. Reglas de CLIPS: foco • Podemos restringir qué módulos se usan para la ejecución de reglas mediante la sentencia: (focus <modulo>*) • Esta sentencia se puede incluir en la parte derecha de una regla para poder cambiar explícitamente de módulo. • Se puede hacer que la ejecución se enfoque en el módulo de la última regla ejecutada declarando la propiedad auto-focus en una regla, por ejemplo: (defrule JUAN::mi-regla (persona (nombre juan)) => ... (declare (auto-focus TRUE)) 29

30. Estrategias de resolución de conflicto • El intérprete de reglas tiene predefinidas unas estrategias de resolución de conflicto • Profundidad: las nuevas activaciones pasan al principio. • Anchura: las nuevas activaciones pasan al final. • Simplicidad: se prefiere la regla menos específica (especificidad medida respecto a las condiciones). • Complejidad: tienen preferencia las reglas más específicas. • LEX: se asocia a cada hecho el tiempo en que fue creado y se da mayor prioridad a las reglas con un hecho más reciente. • MEA: se aplica la misma estrategia de LEX mirando sólo el primer patrón; si coincide se aplica LEX. • Aleatoria: se disparan las reglas en orden aleatorio. 30

31. El lenguaje de programación • CLIPS incluye un lenguaje de programación que permite definir nuevas funciones o programar las acciones a realizar en la parte derecha de las reglas. • Toda sentencia o estructura de control es una función que recibe unos parámetros y retorna un resultado (paradigma funcional). 31

32. Sentencias • Estas son las sentencias y estructuras de control mas utilizadas: • (bind <var> <valor>): Asignación a una variable; retorna el valor asignado. • (if <exp> then <acción>* [else <acción*>]): Sentencia alternativa; retorna el valor de la ´ultima acción evaluada. • (while <exp> do <acción>*): Bucle condicional; retorna falso, excepto si hay una sentencia de retorno que rompa el bucle. • (loop-for-count (<var> <val-i> <val-f>) do <acción>*): Bucle sobre un rango de valores; retorna falso, excepto si hay una sentencia de retorno. 32

33. Sentencias • Estas son las sentencias y estructuras de control mas utilizadas: • (progn <acción>*): Ejecuta un conjunto de sentencias secuencialmente; retorna el valor de la última. • (return <expr>): Rompe la ejecución de la estructura de control que la contiene retornando el valor de la expresión. • (break): Rompe la ejecución de una estructura de control. • (switch <expr> (case (<comp>) then <acción>*)* [(default <accion>*)]): Estructura alternativa caso; cada caso hace una comparación con el valor evaluado; retorna la última expresión evaluada o falso si ninguna sentencia caso se cumple. 33

34. Funciones • La construcción deffunction permite definir nuevas funciones (deffunction <nombre> "Comentario" (<?parámetro>* [<$?parámetro-W>]) <acción>*) • parámetro-W incluye en una lista el resto de parámetros opcionales. • La función retorna la última expresión evaluada. 34

35. Orientación a objetos en CLIPS • Aparte de poder importar una ontología creada en Protege, CLIPS define también una extensión orientada a objetos que complementa la capacidad de representar la estructura del conocimiento. • Se puede considerar como una extensión del constructor deftemplate que pretende completar la posibilidad de usar ontologías como herramienta de representación. • Se pueden definir clases como en los lenguajes orientados a objetos, con slots y métodos. • CLIPS tiene definido un conjunto inicial de clases que organizan los tipos predefinidos, estableciendo una jerarquía entre ellos. 35

36. Orientación a objetos en CLIPS • La sentencia que permite definir una clase es defclass. • Para definir una clase hay que especificar: • El nombre de la clase • Una lista de sus superclases (Heredará de estas sus slots y métodos.) • Declaración de si es una clase abstracta o no (En este último caso se permite definir instancias.) • Si se permite que instancias de la clase puedan vincularse a patrones en la LHS de una regla • Definición de los slots de la clase • Toda clase debe tener como mínimo una superclase. 36

37. Orientación a objetos en CLIPS Por ejemplo: (defclass ser-vivo (is-a USER) (role abstract) (pattern-match non-reactive) (slot respira (default si))) (defclass persona (is-a ser-vivo) (role concrete) (pattern-match reactive) (slot email)) 37

38. Orientación a objetos: slots • La definición de un slot incluye un conjunto de propiedades; algunas son: • (default ?DERIVE|?NONE|<exp>*) • (access read-write|read-only|initialize-only) • (propagation inherit|no-inherit) • (create-accessor ?NONE|read|write|read-write) • Evidentemente, también se puede (se debería) declarar el tipo, la cardinalidad... 38

39. Orientación a objetos: instancias • Para crear instancias de una clase se usa la sentencia make-instance. • Al crear una instancia debemos dar valor a los slots que posee, por ejemplo: (make-instance juan of persona (nombre "juan")) • Podemos crear conjuntos de instancias con la sentencia definstances, por ejemplo: (definstances personas (juan of persona (email "juan@upc.edu")) (maria of persona (email "maria@upc.edu")) ) 39

40. Orientación a objetos: mensajes • Toda la interacción con los objetos se realiza mediante mensajes. • Estos mensajes tienen manejadores (message handlers) que los procesan y realizan la tarea indicada. • Se definen mediante la sentencia defmessage-handler. • Su sintaxis es idéntica a la de las funciones: (defmessage-handler <clase> nombre <tipo-h> (<param>*) <expr>*) • Existen diferentes tipos de message handlers. • Es suficiente trabajar con los “primary”. 40

41. Orientación a objetos: mensajes • Por defecto toda clase tiene definidos un conjunto de message handlers, por ejemplo: init, delete, print. • Al definir create-accessor en un slot estamos creando mensajes del tipo get-nombreSlot, set-nombreSlot, para acceder y modificar el valor del slot. • El acceso a los slots del objeto dentro del cual un message handler está definido se realiza mediante la variable ?self, poniendo “:” delante del nombre del slot, por ejemplo: (defmessage-handler persona escribe-email () (printout t “email:" ?self:email crlf)) 41

42. Orientación a objetos: mensajes • El envío de mensajes a una instancia se realiza mediante la sentencia send. • El nombre de la instancia se pone entre corchetes, por ejemplo: (send [juan] escribe-email) (send [juan] set-email “juan@gmail.com") • Los message handlers se pueden redefinir en cada clase. • Las subclases pueden ejecutar los message handlers de sus superclases. • Si hay más de uno con el mismo nombre, por defecto se ejecuta el de la clase más específica. • Si se quiere ejecutar los de las superclases se ha de usar la sentencia call-next-handler. 42

43. Orientación a objetos: instancias y reglas • Para poder usar instancias en las reglas se utiliza la sentencia object, por ejemplo: (defrule regla-personas (object (is-a persona) (email ?x)) => ... ) • La clase se ha de haber declarado como utilizable en la LHS de las reglas. • La modificación de un slot de una instancia vuelve a permitir que se pueda volver a instanciar una regla con ella. 43

44. CLIPS: la aplicación

45. Manejo del intérprete de CLIPS • Ventanas: • intérprete • hechos (definidos y obtenidos durante la ejecución) • instancias (de las clases definidas) • variables globales (Globals) • foco (módulos en los que está el foco) • agenda (activaciones posibles) 45

46. Manejo del intérprete de CLIPS • A través de los menús se puede acceder a los comandos mas comunes (ejecución, parada, debugging, visualización de definiciones, configuración). 46

47. Manejo del intérprete de CLIPS: comandos • (facts) lista los hechos que hay en la base de hechos • (reset) borra todos los hechos que hay en la base de hechos • (clear) borra todos los hechos y las reglas • (rules) lista las reglas definidas • (load "nombre.clp") carga un fichero CLIPS • (save "nombre.clp") salva todos los deffacts, defrule y deffunction en un fichero 47

48. Manejo del intérprete de CLIPS: ejecución • (run [<entero>]) ejecuta el motor de inferencia, un número de pasos o hasta el final, si no se pasa ningún parámetro • (agenda [<modulo]>) muestra todas las posibles activaciones o sólo las de un módulo • (focus <modulo>+) pone el foco de ejecución en los módulos indicados • (halt), para la ejecución del motor de inferencias • (set-strategy <estrategia>) cambia la estrategia de resolución de conflictos 48

49. Manejo del intérprete de CLIPS: debugging • (watch <item>) informa sobre <item> durante la ejecución, donde <item> puede ser entre otros: • facts <hechos>*, informa sobre los hechos indicados • rules <regla>*, informa sobre las reglas indicadas • activations <regla>*, informa sobre la activación de las reglas indicadas • deffunctions <funcion>*, informa sobre las funciones indicadas • all, informa sobre todo • (unwatch <item>), elimina el watch correspondiente 49

50. Manejo del intérprete de CLIPS: debugging • (set-break <regla>), introduce un punto de ruptura de ejecución en la regla • (remove-break <regla>), elimina un punto de ruptura de ejecución en la regla • (show-breaks), muestra los puntos de ruptura definidos • (matches <regla>), indica las instanciaciones posibles para una regla • (dribble-on <fichero>) y (dribble-off), redirecciona la información de la traza a un fichero y elimina la redirección 50