Claudio Gutiérrez y José Arrieta
Claudio Gutiérrez y José Arrieta
AISA es un proyecto de investigación cuyo objetivo es el desarrollo de una contraparte computacional inteligente para un ejecutivo de negocios o administrador. Una estación de trabajo de AISA rodea al trabajador de oficina, ofreciéndole todo el apoyo necesario para las funciones asociadas con su puesto.
El sistema AISA se ocupa de un área de aplicación de creciente importancia, a saber, la de la cooperación y comunicación eficientes entre varios agentes en el dominio administrativo.
La sociedad hombre/máquina es vista como un acoplamiento sinérgico en el cual las computadoras digitales ofrecen objetividad, memoria confiable y velocidad, mientras que los agentes humanos proveen sentido común, creatividad y responsabilidad ética.
La telaraña administrativa es entendida como un conjunto de interacciones complejas de encomienda y compromiso entre estaciones de trabajo, el cual subsume al correo electrónico convencional en un medio muy rico de expectativas y obligaciones que representa las responsabilidades compartidas y solidaridad mutua de trabajadores dentro de una comunidad organizativa.
Como programa que funciona continuamente, AISA puede considerarse como un agente autónomo, con iniciativas independientes, continuidad temporal y capacidad de aprendizaje.
AISA está escrito en Common Lisp y GOAL, un lenguaje de programación lógica diseñado por Claudio Gutiérrez e inspirado en HCPRVR de Daniel Chester. GOAL apoya bases de conocimientos múltiples y permite dar experticia a AISA en forma declarativa, de acuerdo al paradigma de la lógica de predicados. GOAL permite completo acceso al subyacente lenguaje Common Lisp. El sistema está montado en una máquina INTEL 80386/7 con 8 mbs. de memoria, y provisto de una interfaz tipo ventanas muy amigable.
AISA puede, en su presente versión, ser usada como un organizador de escritorio muy confortable y como un eficiente asistente personal. Sin embargo, su propósito original es servir de modelo para la organización administrativa. Deberá normalmente correr simultáneamente en varias estaciones de trabajo, como ejemplares independientes del mismo programa, adaptado por sus interacciones con usuarios particulares.
De acuerdo con la filosofía AISA, las transacciones entre los miembros de la organización toman normalmente la forma de una estación de trabajo que encomienda una cierta tarea a otra estación, donde esta última asume un compromiso con respecto a esa tarea. Se entiende "encomienda" como un denominador común lógico de todos los tipos de mensaje que piden a alguien hacer algo que el agente no puede por alguna razón hacer directamente; las diferencias entre las partes implicadas se pasan desapercibidas de manera sistemática, de conformidad con la filosofía administrativa de "red inclusiva".
AISA representa las acciones administrativas dentro de un paradigma de planificación. Ve cada pieza informativa de la administración como un plan en un estado u otro de preparación o realización: las propuestas son planes que no han sido validados todavía, los informes son planes que han sido parcial o totalmente ejecutados, las quejas son (tristes) historias de planes que no llegaron a fructificar o que lo hicieron mal. Cada plan consiste de un conjunto de tareas parcialmente ordenado. Con la excepción del plan (o planes) supremos, cada plan es parte de un plan superior y, –excepto los planes básicos– se puede descomponer en subplanes. Asociado a cada tarea no básica podrá haber un plan que establezca cómo esa tarea puede ser realizada. Una tarea puede ser vista como un plan en sí misma, puesto que puede EXPANDIRse en una colección de subtareas.
Dentro de una estación de trabajo determinada, un plan tiene la forma de un grafo de tareas jerárquicamente organizadas. Entre estaciones, el plan toma la forma de un documento –plan durmiente– que viaja de un escritorio a otro.
De acuerdo a la disciplina encomienda/compromiso, un plan particular puede abarcar tareas que reposan en varios escritorios dentro de la organización.
Una tarea pasa a estado durmiente –se transforma en un documento para efectos de viaje– cuando el dueño del escritorio decide ENCOMENDAR la tarea y ENVIAR la correspondiente carta de encomienda. Conversamente, los planes durmientes –documentos– se despiertan en su escritorio de destino, cuando el dueño de ese escritorio se llega a COMPROMETER con la satisfacción de la tarea.
Un documento existe en el escritorio en una de dos modalidades: entrante o saliente. Así, las actividades básicas en el escritorio resultan del interjuego entre tres contextos claramente distinguibles: LEER, donde yacen los documentos entrantes; TRAMITAR, donde residen los planes despiertos o tareas; y ESCRIBIR, donde los documentos salientes esperan ser enviados. Consecuentemente, cada contexto constituye una base de conocimientos separada, asociada a una cola con la correspondiente clase de ítemes.
El contexto TRAMITAR es el ambiente donde ocurren las deliberaciones y donde tienen lugar las interacciones más interesantes entre el usuario y la máquina. Es ahí donde se mantienen los planes pendientes, donde se solucionan problemas y donde se realizan las tareas relacionadas con las responsabilidades que se han asumido.
Es tradicional en la literatura clasificar así las estrategias de resolución de problemas:
Reducción de problemas (expandir un problema como un conjunto de subproblemas más fáciles de solucionar que el problema original).
Resolución oportunista (mezcla de la solución de un problema diferente en la solución del que se tiene bajo consideración).
Consideramos estas dos estrategias como complementarias: nuestros análisis sugieren que la resolución de problemas administrativos puede modelarse de la manera más exitosa con una combinación de las dos estrategias. Los administradores típicamente dividen una tarea grande en sus partes componentes y están siempre avizores para interacciones favorables entre problemas (en el mejor caso, los problemas pueden cancelarse recíprocamente). Consecuentemente, AISA representa las tareas (problemas) de tal manera que ambas estrategias pueden ser empleadas convenientemente, sin que ninguna de ellas impida la aplicación de la otra. Esto se hace poniendo cada tarea individual en dos estructuras diferentes: un plan específico en el que la tarea es un elemento jerárquico, y la cola contextual donde las tareas pueden ser barajadas a voluntad del usuario, como uno haría con hojas de papel.
El sistema ofrece una batería de instrucciones de navegación que permite inspeccionar una tarea tanto como elemento de un plan (una jerarquía de tareas interconectadas) o como miembro de una cola (un surtido aleatorio de tareas individuales). Así pues, el usuario puede enfocar las tareas sea jerárquica u oportunísticamente, de acuerdo con su conveniencia o inspiración.
La expansión de tareas en subtareas requerida por la resolución jerárquica de problemas se hace en AISA de acuerdo con alguno de los siguientes tipos:
PARTES (conjuntivas y paralelas).
Las tareas se expanden usando la instrucción EXPANDIR. Una vez que una tarea ha sido completamente expandida, el usuario puede resolver el problema original navegando el árbol del plan hasta sus hojas y declarando CUMPLIDAs todas o algunas de ellas, de acuerdo con la naturaleza proposicional de las tareas –siguiendo el orden de ejecución en el caso de las tareas seriales–.
El usuario tiene también la opción de ENCOMENDAR una tarea particular a otra estación de trabajo: en este caso, el usuario espera hasta que venga un informe de CUMPLIDA del encomendado, para asignar el correspondiente atributo a la tarea encomendada. Es también posible declarar una tarea INOPERANTE, lo que simplifica el árbol en el caso de expansiones disyuntivas o propaga el fallo en el caso de las conjuntivas. En todo caso, todas las relaciones lógicas atinentes son tomadas en cuenta automáticamente por AISA. El sistema también sigue la pista de las encomiendas y de sus relaciones con tareas particulares, como un "contabilista no-numérico" para el administrador.
La instrucción EXPANDIR puede producir expansiones automáticamente, en subdominios donde haya conocimiento experto al efecto. Ese conocimiento experto viene en la forma de bases de conocimiento en cláusulas Horn nota. Cuando está en modo automático, la instrucción puede sugerir conjuntos de subtareas que sean expansiones plausibles para la tarea en foco. Presenta al usuario –en sucesión, si hay más de un conjunto– y –cuándo y si el usuario queda satisfecho— produce la expansión según se requiera. Por otra parte, si el usuario prefiere hacer la expansión manualmente, AISA asegurará la congruencia del árbol resultante, y mirará "por encima del hombro" para aprender un nuevo esquema generalizado de expansión automática para aplicaciones futuras.
Cada subdominio de experticia se define por una colección de verbos que corresponden a acciones administrativas específicas que caracterizan al subdominio. Los conjuntos de reglas de expansión de tareas en un subdominio constituyen una base de conocimiento para la experticia administrativa en ese subdominio. Como las reglas están escritas en cláusulas Horn, nuestro intérprete de programación lógica y la instrucción EXPANDIR pueden entenderlas directamente.
Los verbos del subdominio, con su correspondiente sintaxis, se coleccionan como taxonomía de posibles acciones que son parte del conocimiento del sistema. Por el momento, esa taxonomía puede considerarse como poco más que una lista de verbos para el beneficio del módulo de AYUDA; ilustra al usuario sobre cuáles acciones están disponibles para expansión automática en un subdominio particular, y demuestra su sintaxis. Eventualmente, sin embargo, puede convertirse en una jerarquía de tipos de acciones, que sería usable por el apareador interno del algoritmo de resolución de GOAL con el fin de mejorar la eficiencia de las deducciones. Tal jerarquía puede entenderse como una representación sistemática del conocimiento en el subdominio, que significa una contribución de la inteligencia artificial a las ciencias administrativas.
Las reglas de expansión constituyen el cuerpo de conocimientos en el sistema. Representan la manera en que los administradores solucionan problemas por descomposición jerárquica. Esta experticia administrativa se guarda en bases de conocimiento separadas, de acuerdo con subdominios, como conjuntos de cláusulas Horn, declarativas y de carácter modular. Pueden insertarse en el sistema de manera incremental, o bien manualmente por el usuario (de acuerdo con la estrategia de "aprender de oídas") o bien automáticamente por el programa (de acuerdo con las estrategias de "aprender de ejemplos" y "aprender por inducción").
La mayoría de las reglas son esquemas de expansión (estáticos o computables dinámicamente). Junto con algunos hechos y reglas generales sobre, el dominio administrativo –y algunos utilitarios para apoyar la computación dinámica de esquemas– efectúan la deducción de expansiones plausibles, para el beneficio de la instrucción EXPANDIR.
AISA tiene, por el momento, solamente un cuerpo de conocimientos, cuyas reglas de expansión constituyen la base de una experticia para una posición administrativa similar a la de rector de una universidad. Hace algunos años, el presidente de una universidad latinoamericana grande decidió registrar cuidadosamente, en un código informal especialmente acordado con su secretaria ejecutiva, todas las interacciones oficiales entre ellos. La premisa era que casi todos los asuntos importantes que un alto ejecutivo maneja tienen que usar ese canal. El propósito era crear un material que pudiera servir a los científicos para el estudio y mejoramiento de los métodos administrativos. Los respectivos protocolos –que están en nuestras manos– abarcan un período de intensa actividad durante los años académicos 1980 y 1981.
Durante los últimos dos años nos hemos ocupado de descodificar esos protocolos y tratar de articular, con base en su contenido, reglas de expansión para conformar el conocimiento de AISA. En el proceso de hacerlo, desarrollamos una metodología que puede usarse regular y confortablemente para expandir los conocimientos del sistema.
La base de conocimientos para gobierno universitario contiene no más de cien reglas diferentes. Es sorprendente que tan pequeño número de reglas permita explicar y replicar la mayor parte de las acciones de un presidente, reconocido como eficiente, durante un período de nueve meses. El tipo de acciones involucrado va desde la inauguración de edificios hasta la extracción de fondos de los supremos poderes y agencias financiadoras privadas, pasando por problemas con profesores que no cumplían sus deberes, dificultades con el sindicato de empleados y líos estudiantiles.
Como un subproducto del proceso de extracción de reglas, se desarrolló una taxonomía de acciones típicas de un ejecutivo, que contiene como trescientos ítemes. Esta taxonomía se usa por el momento –en pruebas de simulación del programa– para dar al usuario un repertorio de acciones posibles en el momento crítico de describir una nueva tarea al tratar de solucionar un problema. Hemos producido así una especie de diccionario de tareas administrativas que indudablemente puede suministrar material para trabajo en teoría y práctica de la administración.
Un resultado importante de nuestro esfuerzo por formalizar la experticia en el dominio del gobierno universitario ha sido la obligación en que nos hemos visto de desarrollar un sistema de representación para las políticas, las cuales hemos acomodado en el sistema como clases especiales de tareas. Difieren de las tareas ordinarias por llevar adosados demonios, o sea procedimientos vigilantes encargados de realizar las respectivas funciones. Tales funciones se definen como constreñimientos de la acción administrativa o como estímulos al administrador para realizar una tarea específica, a veces repetitiva.
Así, llegamos a identificar dos clases de políticas: constreñimientos y generadores. Los constreñimientos son políticas cuyos demonios filtran la producción de tareas: actúan en el momento de creación de tareas, para abortar la producción de ciertos tipos de estas. Los generadores, por su parte, pueden ser políticas condicionales o políticas iterativas. Los demonios de las políticas condicionales generan tareas específicas en circunstancias particulares; los demonios de políticas iterativas generan tareas específicas en momentos particulares (por ejemplo, una vez al año, al cerrarse el presupuesto). Implantamos un constreñimiento que prohíbe dedicar un edificio u otra instalación a una persona viva, y un constreñimiento que restringe el otorgamiento de permisos a los directivos sindicales, de conformidad con la convención colectiva. Implantamos generadores que promueven la verificación de las condiciones de seguridad de un nuevo edificio tan pronto como este se termine, o la renovación de pólizas de seguros a la fecha de su vencimiento; y muchos otros más de carácter parecido a estos.
Encontramos que la expansión de tareas con ayuda de reglas descansa grandemente en consideraciones sobre el estado presente del mundo. Por ejemplo, escribir un informe anual al superior requiere saber quién es el superior en este momento. Por otra parte, incluso si la información está disponible, en la forma de cláusulas Horn de la forma P, puede no estar completamente al día. Llegamos a la conclusión de que era una buena idea hacer que el sistema pregunte al usuario sobre los hechos vigentes, cada vez que necesite usar uno de ellos, tanto cuando la información está disponible ("Desea usted retractar el hecho tal y cual?") como cuando no lo está ("Desea usted aseverar el hecho tal y cual?"). La carga para el usuario de tales consultas no resultó pesada, gracias a un paquete dialógico diseñado por uno de nosotros, sumamente amigable. Ha llegado a ser el instrumento principal para incrementar y poner al día el conocimiento de AISA. La rutina está implantada de una manera muy elegante, con una relación COMPRUEBA-MUNDO, que queda invocada cada vez que se necesita alguna información sobre hechos.
Hemos implantado una rutina que hace que AISA supervise las expansiones no automáticas realizadas por el usuario, a fin de aprender por medio del ejemplo. En los casos simples –tareas repetitivas– el sistema simplemente registra el patrón de expansión, y lo reproduce en forma idéntica cuando se le pide que lo haga. Sin embargo, la mayor parte de las veces el patrón se presta a ser parametrizado, y AISA puede realizar un modicum de inducción para decidir cuáles elementos del patrón deben convertirse en variables. De ahí en adelante, el sistema puede realizar la expansión en todos los casos de la misma clase....
La disponibilidad de esta base de conocimientos ha hecho posible conducir experimentos en solución jerárquica y oportunista de problemas. Suponiendo un uso disciplinado del léxico prescrito, a fin de evitar formulaciones diferentes de la canónica, el sistema fue capaz de encontrar interacciones útiles entre diferentes grafos de tareas, en el momento de expandir un plan particular. En esos casos, la expansión pedida se ejecutó, pero no se creó una tarea que unificaba con una preexistente; en cambio, la tarea preexistente recibió nuevas conexiones para hacerla parte del árbol recién creado, producto de la expansión del momento.
En cuanto a solución jerárquica de problemas, AISA puede ahora, gracias a su módico
conocimiento, asignar valores a algunas variables libres presentes en tareas anteriores.....
................
Nota
de los editores:
Las cláusulas Horn son cláusulas de la lógica de predicados con un
formato proposicional
especial, a saber o bien
P
o bien
P si Q.
Ejemplo del primer tipo sería
(hermanas ana maría)
donde se establece un simple hecho, a saber que Ana y María son hermanas.
Ejemplo del segundo tipo sería
(hermanas X Y) si (hermanas Y X)
que es una regla deductiva que permite inferir del hecho de que Ana está en el relación
de fraternidad femenina
con María, que María también lo está con respecto a Ana.