sistema multiagente de negociación automática basada en
TRANSCRIPT
Universidad Nacional del Centro
de la Provincia de Buenos Aires
FACULTAD DE CS. EXACTAS
Sistema Multiagente de Negociación
Automática Basada en Diálogos Expresivos
para Compras en un Ámbito Municipal
Tesis de Grado en Ingeniería de Sistemas
Alumno
Leandro Martín Delgado
Director
Dr. Ariel Monteserin
Tandil, 2015
Resumen
En un ámbito municipal de gobierno, las compras de todo tipo de artículos son muy
habituales. En algunos casos, la adquisición de un producto no admite pérdida de tiempo ni
retrasos. La pregunta que nos hacemos es ¿cómo podemos mejorar dicho proceso a través
del uso de tecnología? Los portales de comercio electrónico tradicionales son cada vez más
utilizados. En ellos, el comprador, con un requerimiento de compra bien especificado,
selecciona manualmente, de las diferentes opciones, la que mejor se ajuste a sus
pretensiones. Este enfoque continua insumiendo un tiempo considerable, carece de
eficiencia y disponibilidad; todo esto consecuencia de la intervención humana en gran parte
del proceso.
En el presente trabajo proponemos un sistema de negociación automática basado en
restricciones difusas, aplicado a un contexto de compras en un gobierno municipal. En este
sentido, desarrollamos un estudio de los diferentes modelos de negociación, y los actores
involucrados, con el fin de obtener la mejor alternativa que cumpla con las características
planteadas. A sí mismo, experimentamos sobre la herramienta con el propósito de
comprobar su efectividad.
Tabla de contenido
Capítulo 1. Introducción ................................................................................................ 11
1.1 Motivación ............................................................................................................. 12
1.2 Solución propuesta ................................................................................................. 17
1.3 Esquema de la tesis ................................................................................................. 20
Capítulo 2. Comercio electrónico en un Municipio ...................................................... 23
2.1 Introducción ........................................................................................................... 23
2.2 Gobierno electrónico y sus tipos ............................................................................. 26
2.2.1 Modelo de Negocio a Gobierno ........................................................................ 27
2.3 Resumen general .................................................................................................... 29
Capítulo 3. Sistemas Multiagente y Modelos de Negociación ....................................... 32
3.1 Agentes Inteligentes y Sistemas Multiagente .......................................................... 32
3.1.1 Agentes inteligentes ......................................................................................... 32
3.1.1.1 Propiedades de los agentes inteligentes ...................................................... 35
3.1.1.2 Entorno de un agente ................................................................................. 36
3.1.2 Sistemas multiagente ........................................................................................ 37
3.1.3 Comunicación de agentes ................................................................................. 39
3.1.3.1 Lenguajes de comunicación ....................................................................... 40
3.1.4 Ontologías ........................................................................................................ 42
3.1.5 Plataformas de desarrollo de sistemas multiagente ............................................ 45
3.1.5.1 JADE (Java Agent DEvelopment Framework) ........................................... 45
3.1.5.2 JADEX ...................................................................................................... 45
3.1.5.3 JACK......................................................................................................... 46
3.1.5.4 ZEUS......................................................................................................... 47
3.2 Modelos de negociación ......................................................................................... 47
3.2.1 Componentes de un modelo de negociación ..................................................... 49
3.2.2 Teoría de juegos ............................................................................................... 51
3.2.3 Enfoques basados en heurísticas ....................................................................... 53
3.2.4 Enfoques basados en argumentación................................................................. 54
3.2.5 Enfoques basados en restricciones difusas ........................................................ 56
3.2.6 Resumen .......................................................................................................... 57
3.3 Resumen general .................................................................................................... 59
Capítulo 4. Modelo de negociación basado en restricciones difusas ............................ 63
4.1 Introducción ........................................................................................................... 63
4.2 Modelo de preferencias del comprador y vendedor ................................................. 68
4.3 Problemas de satisfacción de restricciones (CSP) .................................................... 70
4.4 Problema de satisfacción de restricciones difusas (FCSP) ....................................... 71
4.5 Conocimiento del dominio de los agentes ............................................................... 73
4.5.1 Conocimiento del dominio del agente comprador ............................................. 73
4.5.2 Conocimiento del dominio del agente vendedor ............................................... 77
4.6. Modelo de diálogo de alto nivel ............................................................................. 79
4.7 Mecanismos de decisión y locuciones ..................................................................... 81
4.7.1 Mecanismos de decisión del agente comprador ................................................ 81
4.7.2 Mecanismos de decisión del agente vendedor ................................................... 87
4.8 Resumen general .................................................................................................... 94
Capítulo 5. Instanciación del modelo de negociación ................................................... 97
5.1 Introducción ........................................................................................................... 97
5.2 Instanciación de los mecanismos de decisión del Sector de Compras ...................... 99
5.3 Instanciación de los mecanismos de decisión del Proveedor .................................. 104
5.4 Detalles de diseño ................................................................................................. 113
5.4.1 Arquitectura del sistema ................................................................................. 114
5.4.2 Diseño e implementación de la lógica de negociación .................................... 115
5.4.2.1 Implementación de agentes inteligentes y sus componentes ..................... 116
5.4.2.2 Agente municipal: Mecanismos de decisión ............................................. 117
5.4.2.3 Agente proveedor: Mecanismos de decisión ............................................. 121
5.5 Resumen general .................................................................................................. 123
Capítulo 6. Evaluación experimental .......................................................................... 125
6.1 Caso de estudio 1: Compra de una impresora ........................................................ 125
6.1.1 Introducción ................................................................................................... 125
6.1.2 Desarrollo del caso de estudio ........................................................................ 126
6.1.2.1 Apertura del diálogo ................................................................................ 127
6.1.2.2 Negociación ............................................................................................. 129
6.1.2.3 Confirmación y Cierre del Diálogo .......................................................... 141
6.1.3 Conclusión del caso de estudio ....................................................................... 142
6.2 Caso de estudio 2: Análisis de performance .......................................................... 143
6.2.1 Introducción ................................................................................................... 143
6.2.2 Diez productos ............................................................................................... 144
6.2.3 Cincuenta productos ....................................................................................... 146
6.2.4 Cien productos ............................................................................................... 148
6.2.5 Quinientos productos...................................................................................... 149
6.2.6 Atributos incrementales y no incrementales .................................................... 151
6.2.7 Conclusión del caso de estudio ....................................................................... 153
6.3 Conclusión ........................................................................................................... 154
Capítulo 7. Conclusiones .............................................................................................. 156
7.1 Contribuciones...................................................................................................... 156
7.2 Limitaciones encontradas ...................................................................................... 158
7.3 Trabajos futuros .................................................................................................... 160
Índice de figuras
Figura 1 Agente inteligente y su interacción con el entorno .............................................. 34
Figura 2 Entorno de un agente inteligente ........................................................................ 36
Figura 3 Evolución del grado de satisfacción para una entidad municipal ......................... 65
Figura 4 Catálogo del proveedor ...................................................................................... 65
Figura 5 Diálogo negociador ............................................................................................ 66
Figura 6 Diagrama de reglas de transición ........................................................................ 93
Figura 7 Vista de despliegue .......................................................................................... 114
Figura 8 Diagrama de clases para los mecanismos de decisión del agente municipal ...... 117
Figura 9 Diagrama de secuencia para la modificación de un requerimiento de compra ... 119
Figura 10 Diagrama de secuencia para la evaluación de una oferta ................................. 120
Figura 11 Diagrama de clases para los mecanismos de decisión del agente proveedor .... 121
Figura 12 Diagrama de secuencia para la generación de ofertas potenciales ................... 122
Figura 13 Selección del requerimiento de compra inicial ................................................ 128
Figura 14 Gráfico de líneas para un catálogo de 10 productos ........................................ 145
Figura 15 Gráfico de líneas para un catálogo de 50 productos ........................................ 147
Figura 16 Gráfico de líneas para un catálogo de 100 productos ...................................... 149
Figura 17 Gráfico de líneas para un catálogo de 500 productos ...................................... 150
Figura 18 Gráfico de barras para atributos incrementales y no incrementales ................. 153
Índice de tablas
Tabla 1 Ventajas y desventajas de los enfoques basados en teoría de juegos, heurística y
argumentación ................................................................................................................. 56
Tabla 2 Detalle de la locución L1: open_dialogue(.) ......................................................... 82
Tabla 3 Detalle de la locución L6: prefer_to_buy(.) ......................................................... 85
Tabla 4 Detalle de la locución L7: refuse_to_buy(.) ......................................................... 86
Tabla 5 Detalle de la locución L9: agree_to_buy(.) .......................................................... 86
Tabla 6 Detalle de la locución L11: withdraw_dialogue(.) ................................................ 87
Tabla 7 Detalle de la locución L2: enter_dialogue(.) ........................................................ 88
Tabla 8 Detalle de la locución L3: willing_to_sell(.) ........................................................ 88
Tabla 9 Detalle de la locución L5: prefer_to_sell(.) .......................................................... 90
Tabla 10 Detalle de la locución L8: refuse_to_sell(.) ........................................................ 91
Tabla 11 Detalle de la locución L10: agree_to_sell(.) ....................................................... 91
Tabla 12 Reglas de transición ........................................................................................... 92
Tabla 13 Atributos, intervalos difusos y niveles de corte para la categoría Impresora ..... 129
Tabla 14 Atributos de la impresora BROTHER HL-5450DN ......................................... 130
Tabla 15 Atributos de la impresora BROTHER HL-2270DW ........................................ 131
Tabla 16 Atributos de la impresora LEXMARK MS811dn ............................................ 132
Tabla 17 Porción de la negociación entre el agente proveedor y el municipal ................. 140
Tabla 18 Situación de la negociación en el tramo final ................................................... 140
Tabla 19 Duraciones, media y desviación estándar para un catálogo de 10 productos ..... 145
Tabla 20 Duraciones, media y desviación estándar para un catálogo de 50 productos ..... 147
Tabla 21 Duraciones, media y desviación estándar para un catálogo de 100 productos ... 148
Tabla 22 Duraciones, media y desviación estándar para un catálogo de 500 productos ... 150
Tabla 23 Duraciones, media y desviación estándar para atributos incrementales y no
incrementales ................................................................................................................. 152
Capítulo 1
Introducción
La Oficina de Compras de una entidad municipal de gobierno es la encargada del
suministro de todos los sectores municipales. Su función es de suma importancia y, en
algunos casos, puede ser crítica en el sentido de obtener los productos solicitados en tiempo
y forma. Sería inadmisible, por ejemplo, un retraso en la adquisición de un medicamento de
vital importancia para un paciente internado en el hospital municipal. Actualmente la
mecánica de funcionamiento de la Oficina consiste en recepcionar solicitudes de
adquisición de productos perfectamente especificados por parte de los sectores; para luego
contactar a los proveedores con el fin de recabar cotizaciones y realizar la compra al más
conveniente. Podemos mencionar algunas observaciones sobre esta metodología: la primera
es que la Oficina de Compras no evalúa alternativas igualmente convenientes a la solicitud
de compra recibida debido al desconocimiento sobre el rubro del producto en cuestión; la
segunda es que existe un horario operativo, es decir, salvo una situación crítica, la Oficina
funciona en un rango de seis horas como la gran mayoría de los sectores municipales; la
tercera es que la comunicación con los proveedores suele insumir un tiempo considerable
relacionado a la tardanza que puede implicar toda operatoria llevada a cabo por personas.
En este contexto planteamos el diseño e implementación de una herramienta
informática que mejore sustancialmente la operatoria de compra en un ámbito municipal.
Esta se basa en la teoría de negociación automática, es decir, con la mínima intervención
humana posible. Para ello hacemos un análisis de los diferentes modelos de negociación
con el fin de obtener la mejor alternativa que se ajuste a nuestro escenario. Concluimos que
los modelos de negociación automática basados en restricciones difusas cuentan con varias
ventajas por sobre el resto. A su vez, para lograr este automatismo, nos introducimos en el
concepto de agentes inteligentes, más precisamente en un conjunto de ellos con
capacidades de diálogo para lograr beneficiar al usuario que representan. Esto no es otra
cosa que un sistema multiagente.
1.1 Motivación
Aunque los gobiernos generalmente no venden productos o servicios a clientes,
realizan compras de diversos artículos para el normal funcionamiento de las instituciones,
las cuales pueden mejorarse mediante el uso del comercio electrónico. Los gobiernos
también realizan actividades de tipo empresarial; por ejemplo, emplean gente, compran
suministros a proveedores y distribuyen pagos de beneficios de muchos tipos. También
cobran una variedad de impuestos y tarifas. El uso del comercio electrónico por parte de los
gobiernos y agentes gubernamentales para realizar estas funciones a menudo se enmarca en
el área de gobierno electrónico (e-government) (Scheneider, 2004).
Cuando las empresas establecen relaciones legales o comerciales con las Entidades
Gubernamentales, suministrando productos y servicios a los gobiernos a través de la Web,
se está desarrollando un tipo de negociación denominado B2G (Empresas a Gobierno o
Bussines to Government). En negociaciones de tipo B2G las empresas venden productos y
servicios a gobiernos locales, estatales y federales. En general, el sector público ha sido
más lento en adoptar el comercio electrónico respecto al sector privado. Esto, sin embargo,
está cambiando lentamente como resultado de las iniciativas de gobierno electrónico
orientadas a adaptar las contrataciones públicas y otras actividades a un ámbito online
(Deborah Morley, 2009).
La negociación B2G básicamente consiste en optimizar los procesos de negociación
entre empresas y gobierno a través del uso de Internet. Proporciona transparencia en el
desarrollo de convocatorias y licitaciones con una mayor rapidez en el desarrollo de los
trámites, permitiéndole al gobierno encontrar los mejores precios y condiciones de pago. Es
un proceso simple y estandarizado el cual ayuda a las Administraciones Públicas a ahorrar
tiempo y dinero, accediendo eficientemente a la oferta de los proveedores, comparando
productos y realizando pedidos en un marco de mayor transparencia de mercado.
Generalmente se aplica a sitios o portales especializados en la relación con la
administración pública. En ellos las instituciones oficiales (hacienda, contrataciones
públicas, etc.) pueden ponerse en contacto con sus proveedores, y estos pueden agrupar
ofertas o servicios.
En una entidad municipal de gobierno, el Sector de Compras es una de las áreas más
sensibles. Esta afirmación se sustenta en tres aspectos importantes que dicho sector debe
considerar:
Por un lado la minimización del tiempo que transcurre desde que un determinado
sector efectúa el pedido de un producto en particular a la Oficina de Compras, hasta
el momento en que éste es adquirido y entregado a dicho sector. El pedido de un
producto (entiéndase elementos informáticos, insumos hospitalarios, mueblería,
etc.) implica que el sector solicitante tiene la necesidad de contar con él para
mantener un buen funcionamiento. Por lo tanto, un tiempo prolongado en su
adquisición puede repercutir directa o indirectamente en la correcta atención de las
necesidades de los ciudadanos.
Por otro lado la eficiencia en obtener el producto que se adapte a las necesidades del
sector solicitante, sin incurrir en elevados gastos que afecten a la contabilidad del
Municipio. Generalmente, una Oficina de Compras adquiere productos que se
ajusten exactamente a lo que se le pidió, luego de evaluar las ofertas de los
diferentes proveedores por su precio. Por desconocimiento sobre el producto
pedido, no se considera la posibilidad de negociar alternativas igualmente buenas,
ya sea en características, precio, tiempo de la garantía, etc. Esto a su vez afecta a los
proveedores limitando sus posibilidades de vender productos que le reporten un
mayor grado de utilidad (por ejemplo, un artículo cuyo fabricante premie de alguna
manera al proveedor que lo venda) sin que se alejen del requerimiento de compra
original.
Por último, otro aspecto importante es la disponibilidad. Existen compras urgentes
que deben realizarse en cualquier momento del día, e incluso en cualquier día del
año.
En este contexto, contar con una herramienta informática de negociación automática
B2G que logre optimizar considerablemente estos aspectos es una posibilidad inmejorable.
Además debe permitir la interoperabilidad entre los múltiples sistemas heterogéneos con
los que puedan contar los diferentes proveedores. Esto plantea desafíos que pueden ser
abordados con sistemas distribuidos que posibiliten llevar a cabo negociaciones entre las
partes.
Mientras que los primeros sistemas informáticos eran entidades aisladas, sólo para
la comunicación con sus operadores humanos, los sistemas informáticos actuales están
generalmente interconectados entre sí, a través de una red en sistemas distribuidos amplios.
Internet es el ejemplo obvio, y cada vez es más raro encontrar computadoras de uso
comercial o en ámbitos académicos que no tengan la capacidad para acceder a Internet.
Hasta hace poco tiempo, los sistemas distribuidos y concurrentes fueron vistos por
muchos como estructuras extrañas y complicadas que eran mejor ser evitadas. El rápido y
visible crecimiento de la Internet ha disipado esta creencia. Actualmente los sistemas
distribuidos y concurrentes son esencialmente la clave en la informática comercial e
industrial, y esto ha llevado a investigadores y profesionales a revisar los fundamentos
mismos de la informática, en busca de modelos teóricos que reflejen mejor la realidad de la
misma, principalmente como un proceso de interacción (Wooldridge M. , 2002).
Esta constante búsqueda de modelos teóricos ha llevado a obtener sistemas cada vez
más inteligentes. La tendencia creciente a la delegación e inteligencia implica la necesidad
de construir sistemas informáticos que puedan actuar con eficacia en nuestro nombre. Esto
a su vez involucra dos aspectos fundamentales. El primero es la capacidad de los sistemas
para operar de forma independiente, sin la intervención directa del hombre. El segundo es
la necesidad de que los sistemas informáticos puedan actuar de tal manera que representen
nuestros intereses mientras interactúan con otros seres humanos o con sistemas de la misma
índole.
Estas tendencias, sumadas a las de interconexión y distribución, plantea en la
ciencia de la computación convencional un desafío clave que ha llevado en las últimas tres
décadas a que gran parte de la energía de los intelectuales en la materia se concentrara en el
desarrollo de herramientas de software y mecanismos que permitan construir sistemas
distribuidos con mayor facilidad y fiabilidad. Sin embargo, cuando se combina con la
necesidad de que los sistemas puedan representar nuestros intereses, la distribución plantea
otro problema fundamental. Cuando un sistema informático que actúe en nuestro nombre
debe interactuar con otro sistema informático que representa los intereses de otro,
probablemente pueda ocurrir que los intereses no sean los mismos. Por lo tanto se vuelve
necesario dotar a estos sistemas con la capacidad de cooperar y llegar a acuerdos con otros
sistemas.
En conjunto, este estudio ha conducido a la aparición de un nuevo campo en la
ciencia de la computación: los sistemas multiagente. La idea de un sistema multiagente es
simple. Un agente es un sistema informático capaz de llevar a cabo una acción
independiente en nombre de un usuario o propietario. En otras palabras, un agente puede
averiguar por sí mismo lo que necesita hacer para satisfacer sus objetivos de diseño, en
lugar de que se les diga de forma explícita lo que debe hacer en cada momento. Un sistema
multiagente consiste de un número de agentes, que interactúan entre sí, típicamente por el
intercambio de mensajes a través de algún tipo de infraestructura de red informática.
Generalmente esta interacción se basa en objetivos y motivaciones muy diferentes. Por lo
tanto, se requiere de la capacidad de cooperar, coordinar y negociar mutuamente, de la
misma forma en que lo hacen las personas en la vida diaria.
En resumen, los sistemas multiagente son un conjunto de agentes autónomos con
tres características fundamentales: organización, coordinación y comunicación. La
organización establece una jerarquía social de los agentes. La coordinación puede ser por
cooperación y/o competición. La comunicación se realiza por medio de protocolos que
permiten estructurar la interacción entre agentes.
En este contexto, la negociación en interacciones humanas como medio para
alcanzar decisiones conjuntas, ha sido objeto de investigación durante muchos años. Sus
resultados han servido como base para la investigación de los procesos de negociación
automatizados, esto es, los llevados a cabo por componentes software. En general, la
negociación se puede ver como el proceso por el cual dos o más partes (negociación
bilateral y multilateral respectivamente) pueden obtener una decisión conjunta. En el
dominio del comercio electrónico, por ejemplo, se define negociación como el proceso por
el cual dos o más entidades regatean multilateralmente sobre recursos con el propósito de
alcanzar una ganancia conjunta (Beam & Segev, 1997). La negociación llevada a cabo por
humanos es relativamente lenta y sub-óptima (es decir, no se obtiene el mejor resultado
posible para todas las partes), de forma que la negociación automatizada cobra mayor
interés.
La negociación automática tiene lugar cuando la función de negociación la realizan
sistemas computarizados como, por ejemplo, los agentes inteligentes. El proceso de
negociación se puede entender como un tipo de interacción automática entre las distintas
partes que mantienen propósitos y objetivos diferentes (Jennings & Narayanan, 2005).
Aunque la negociación entre humanos es un proceso extremadamente complejo, los agentes
que se encuentren llevando a cabo este proceso en un entorno automatizado no deben de
incorporar dicha complejidad.
Ciertamente, la unión de diversos agentes “sencillos” puede llegar a constituir un
entorno que actúe de forma muy sofisticada (Beam & Segev, 1997). Fatima (Fatima, 2004)
propone una definición muy simple de negociación en entornos multiagente:
“La negociación es el medio por el cual los agentes se comunican y se
comprometen a alcanzar acuerdos mutuamente beneficiosos.”
En esta definición, se deja claro el hecho de que en los procesos de negociación se
debe buscar un acuerdo que satisfaga a todas las partes involucradas. Es posible llegar a una
situación en la que una negociación no tenga un final satisfactorio por el hecho de que
alguna de las partes no esté de acuerdo con ninguna de las propuestas realizadas. Sin
embargo, en la mayoría de los casos, esta es la situación menos deseada y, por tanto,
siempre se busca llegar a buen término el proceso de negociación por medio de concesiones
de las partes. Rahwan (Rahwan, 2004) plantea otra definición donde son resaltados otros
elementos importantes del proceso de negociación en sistemas multiagente:
“La negociación es una forma de interacción en la cual un grupo de agentes, con
intereses conflictivos y un deseo de cooperar, intentan llegar a un acuerdo
mutuamente aceptable en la división de recursos escasos.”
En esta definición, se destaca la necesidad de que los agentes tengan un deseo en
cooperar lo cual, tal y como se mencionó anteriormente, indica que el final menos deseado
es aquel en el que las partes no alcanzan un acuerdo. Por otro lado, se utiliza el término
recurso, en el sentido más amplio de la palabra, para identificar servicios, tiempo, dinero,
artículos, etc. En general, la necesidad de negociar surge cuando se tiene que compartir el
uso de uno de estos recursos.
En conclusión, es importante tener en cuenta que no existe una solución válida para
todos los problemas y dominios (Rahwan, 2004), sino que debe ser el diseñador quien,
dependiendo de las condiciones en las que el proceso de negociación se vaya a producir,
elija la técnica a aplicar en cada momento. Dada esta limitación y los requisitos a satisfacer
para el desarrollo con éxito del entorno multiagente, resulta manifiesta la necesidad de
encontrar una solución que permita a los agentes, dinámicamente y en tiempo de ejecución,
determinar el mecanismo de negociación más apropiado para cada interacción que deba de
producirse.
1.2 Solución propuesta
En la presente tesis proponemos desarrollar una herramienta de negociación
automática del tipo B2G, con la cual puedan satisfacerse los aspectos planteados en la
introducción: minimización de los tiempos, compras eficientes, disponibilidad e
interoperabilidad de los sistemas. A partir de esto, consideramos que un sistema
multiagente que permita la negociación automática es la solución más apropiada.
La solución propuesta se divide en dos partes: la primera consiste en la selección de
un sistema de negociación automática. Partiendo del modelo de negociación seleccionado,
se implementará un sistema multiagente donde los agentes representen al Sector de
Compras (Comprador) y a los proveedores del municipio (Vendedor). En términos
generales, el sistema se compondrá de una Web para la entidad Municipal, y un proceso
vendedor que representa a los proveedores. Cada parte implica la creación de un agente
inteligente el cual, a partir de su lógica de negociación, dialogará con la otra parte para
intentar llegar a un acuerdo en común.
Dada la necesidad de dotar a los agentes de la habilidad suficiente para dialogar y
modificar sus preferencias durante el propio proceso de negociación, se seleccionó un
modelo de negociación basado en restricciones difusas. Este mecanismo se basa en una
forma de argumentación de propuestas fundada en la declaración parcial de preferencias o
grados de satisfacción (López Carmona, 2006). En este sentido los modelos de preferencias
basados en restricciones difusas, se presentan como una alternativa muy adecuada para
solucionar el problema de la formalización y representación de preferencias. La solución
elegida se basa en el trabajo propuesto por López Carmona (López Carmona, 2006) y
consiste en estrategias de negociación automática basadas en restricciones difusas sobre
sistemas multiagente. Esto implica la codificación de distintos protocolos de negociación, y
las estrategias asociadas a los mismos, mediante el uso de ontologías, de forma que son los
agentes quienes, en el momento que necesiten llevar a cabo una interacción, decidan qué
mecanismo (esto es, qué protocolo y qué estrategia) desean utilizar.
La segunda parte de la tesis consiste en integrar el sistema multiagente desarrollado
en el ámbito de negociación entre una entidad municipal y sus proveedores. Para ello, se
contrasta la metodología de trabajo actual de un Sector de Compras de una determinada
municipalidad (entorno no negociado), con los beneficios que proporciona la utilización de
nuestro sistema.
Para la gestión de los agentes inteligentes se utilizará la plataforma multiagente de
libre distribución Java Agent DEvelopment (JADE)1 (Bellifemine, Poggi, & Rimassa,
2001). Todo el desarrollo se llevará a cabo en Java. La flexibilidad que proporciona la
plataforma JADE permite que cualquier proveedor que desee implementar su propio agente
negociador, pueda hacerlo previo acuerdo del protocolo a utilizar.
JADE es un entorno que simplifica la implementación de sistemas multiagente
mediante una capa de soporte (middle-ware) que respeta las especificaciones FIPA2 y con
un conjunto de herramientas para el desarrollo y debugging.
La plataforma JADE está escrita en el lenguaje Java y se compone de varios
paquetes, proporcionando a los programadores módulos funcionales ya desarrollados e
1 En la sección 3.1.5 se detallan algunas de las características de la plataforma JADE, como así también de otras popularmente conocidas. 2 La Foundation for Intelligent Physical Agents (FIPA) es un organismo para el desarrollo y establecimiento de estándares de software para agentes heterogéneos que interactúan y sistemas basados en agentes.
interfaces abstractas configurables. Java fue el lenguaje de programación elegido debido a
sus múltiples ventajas, como su paradigma orientado a objetos en entornos heterogéneos
distribuidos, la serialización de objetos y la invocación de métodos remotos (RMI), entre
otras.
El modelo que se implementa en la tesis emplea la noción de restricciones difusas
en su núcleo (en particular, para determinar qué oferta debe ser enviada, si una oferta es
aceptable, y que contra-oferta debe hacerse). De forma general, una restricción difusa
puede entenderse como un conjunto de valores de un atributo al que se le asigna un
determinado grado de satisfacción, de manera que este rango puede ser representado como
un conjunto de valores, o como un término lingüístico que representa de forma abstracta un
conjunto de valores (Xudong Luo, 2003).
La mayor parte de los modelos de negociación bilateral automática asumen que los
agentes tienen predefinidas las preferencias, y que éstas son estáticas. En otras palabras, los
agentes han decidido a priori qué necesitan de los otros, y cómo diferentes acuerdos
satisfacen estas necesidades. El problema se reduce entonces a una búsqueda que sea lo
suficientemente satisfactoria para todos los agentes. Sin embargo, los agentes pueden
empezar a negociar sin tener un conocimiento completo y preciso acerca de sus
preferencias por acuerdos concretos. Un caso preciso viene dado por la aparición o
desaparición de productos del catálogo de un proveedor, o por la evolución de las utilidades
asignadas a cada producto como consecuencia de la existencia de factores externos, como
por ejemplo el paso del tiempo. El objetivo es dotar a los agentes de la habilidad suficiente
para que sean capaces de dialogar, y que puedan modificar sus preferencias durante el
propio proceso de negociación. El mecanismo utilizado se basa por tanto en una forma de
argumentación de propuestas fundada en la declaración parcial de preferencias o grados de
satisfacción.
1.3 Esquema de la tesis
La presente tesis se estructura en 6 capítulos. A continuación describiremos
brevemente cada uno de ellos.
En el capítulo 1: se presentó el ámbito de la tesis. Se introdujeron en forma general
los conceptos que serán desarrollados en profundidad a los largo del trabajo. Tales son:
negociaciones B2G, sistemas multiagente y negociación.
En el capítulo 2: nos introducimos en los conceptos de negociaciones dentro de un
ámbito municipal de gobierno. Vemos los diferentes tipos de negoción y cómo lentamente
las entidades gubernamentales orientan su gestión hacia la utilización de tecnología.
En el capítulo 3: desarrollamos en profundidad dos de los grandes pilares en los
que se basa la presente tesis: sistemas multiagente y modelos de negociación. Los primeros
son los encargados de poner en funcionamiento el modelo de negociación elegido. Para
llegar a una correcta selección de un modelo adecuado para nuestro contexto, hacemos un
repaso de los diferentes enfoques, analizando sus ventajas y desventajas.
En el capítulo 4: nos enfocamos específicamente en el modelo de negociación
basado en restricciones difusas. Comenzamos a definir cada componente del modelo:
conocimientos del dominio para agente comprador y vendedor, mecanismos de decisión,
locuciones y transiciones.
En el capítulo 5: se aborda la instanciación del modelo elegido. Se explican los
diferentes algoritmos y funciones utilizadas para la implementación de un sistema de
negociación automática. A su vez, presentamos los detalles de diseño que derivaron en el
desarrollo del sistema.
En el capítulo 6: desarrollamos dos casos de estudio. El primero deja en evidencia
los beneficios de la utilización de un sistema de negociación automática en un ámbito
municipal de compra. El segundo caso presenta las diferentes variaciones en las duraciones
de las negociaciones a medida que modifican los parámetros que definen a una negociación
(cantidad de productos en el catálogo, número de atributos, etc.).
En el capítulo 7: presentamos las conclusiones. Cuenta con un resumen general de
toda la tesis, contribuciones, limitaciones y algunas propuestas para futuros trabajos.
Capítulo 2
Comercio electrónico en un Municipio
Todas las relaciones que se establecen entre una entidad de gobierno con su entorno
(empresas, contribuyentes, empleados, etc.) pueden ser potenciadas con la utilización de la
tecnología, orientando la gestión hacia un Gobierno Electrónico. Este nuevo paradigma
lentamente está siendo adoptado en la medida en que los participantes comprenden sus
amplios beneficios. En este capítulo presentaremos conceptos básicos sobre comercio
electrónico y su aplicación en un ámbito municipal.
2.1 Introducción
Una de las principales tendencias en las últimas décadas es la formación de una
sociedad moderna interconectada basada en la adopción definitiva de la tecnología de la
información y la comunicación (TIC). Los avances de la TIC se han percibido como uno de
los responsables más importante en el cambio estructural de la sociedad. Sistemas basados
en Internet, con un alto grado de estandarización y de bajo costo, han acelerado dicha
reestructuración, tanto dentro de las organizaciones como entre ellas mismas. Desde
motores de búsqueda web avanzados (por ejemplo, Google y Bing) a sistemas de gestión
del conocimiento (como Wikipedia), de comunidades personales y sociales en línea (por
ejemplo, blogs, Linked-in, Facebook y Twitter) a varias redes de comercio electrónico
(como ser, B2B, C2C, B2C, etc.), nuestra estructura social y los estilos de vida han
cambiado inevitablemente con el fin de hacer frente a los desafíos que las TIC e Internet
nos traen (Liu, 2010).
Organizaciones colaborativas e interconectadas pueden obtener beneficios que una
sola organización difícilmente puede lograr. Un claro ejemplo son las cadenas de
suministro modernas: la mayoría de las multinacionales e incluso algunas PYMES
(pequeñas y medianas empresas) son capaces de desarrollar su planificación
interrelacionando sistemas de recursos empresariales para hacer que la gestión de la cadena
de suministro sea más eficiente y eficaz.
Lento pero seguro, los gobiernos han estado participando en la reforma de la
revolución de las redes y tomando un papel activo sobre todo en la primera década del siglo
21. Este movimiento se simboliza mediante la creación de muchos proyectos/programas de
e-Government o Gobierno electrónico en los últimos años. El Gobierno electrónico se
define como "la transformación de las relaciones internas y externas del sector público a
través de las operaciones sobre redes, utilizando tecnología de la información y las
comunicaciones hasta optimizar la prestación de servicios del gobierno, la participación
electoral y la gobernabilidad". Además, el e-Government intenta tener centralizadas las
operaciones que se encuentran dispersas para maximizar la eficiencia, la productividad y la
prestación de servicios.
Dado que los gobiernos obviamente tienen un limitado conjunto de productos para
vender al público o empresas (comparado con el sector privado), podemos esperar ver más
aplicaciones de comercio electrónico en áreas donde se producen intercambios de fondos:
impuestos, licencias y permisos. Si bien la mayor parte de la actividad del sector privado en
el que se modelan estos nuevos esfuerzos implica la entrega de bienes y servicios de
“empresa a empresa”, su experiencia con actividades de “empresa a consumidor” puede ser
utilizada como un modelo para mejorar las acciones de “gobierno a ciudadano” del sector
público como así también el actual modelo dominante de “gobierno a empresa” y
“empresa a gobierno” (Abramson & Means, 2001).
Obviamente, una diferencia significativa entre los sectores público y privado es que
el sector público principalmente intercambia información y no siempre cobran por ella,
aunque también existen intercambios de bienes. Por tanto, la definición de comercio
electrónico en el sector público no sólo debe contemplar la transferencia de bienes y
servicios, sino que también debe incluir el intercambio de información.
Una "brecha digital" se ha desarrollado entre las jurisdicciones del sector público.
Las jurisdicciones más grandes (estados, las grandes ciudades) se están moviendo
rápidamente en aspectos tecnológicos llevando la delantera y se encuentran entre los más
innovadores, allanando el camino para los demás. Esto deja a las jurisdicciones más
pequeñas retrasadas en la carrera por la prestación de servicios en línea y aplicaciones de
comercio electrónico de gobierno.
Mientras que uno de los beneficios del comercio electrónico en el sector privado es
la posibilidad de extenderse más allá de las fronteras geográficas (para llegar a todo el
mundo), las jurisdicciones del sector público se limitan a sus propias fronteras geográficas.
Con un potencial mercado del cual beneficiarse, las empresas del sector privado son
capaces de tomar ventaja de las nuevas tecnologías. Pueden contar con personal para
mantener sus sitios web con la más reciente información, diseños, seguridad y
metodologías de transacción. Los gobiernos, sin embargo, sólo sirven a sus propios
ciudadanos y un área geográfica limitada. Excepto cuando las jurisdicciones son lo
suficientemente grandes (estados), esto hace que el comercio electrónico sea menos
eficiente que el de las empresas del sector privado. Es más difícil obtener beneficios a
mayor escala y sobre un gran número de clientes.
Los gobiernos también tienen restricciones adicionales. Estas incluyen la necesidad
absoluta de confidencialidad de la información de los clientes, la necesidad de rendir
cuentas a sus ciudadanos y la obligación de facilitar el acceso a todos ellos. Debido a estas
restricciones, los gobiernos se han orientado más lentamente hacia el comercio electrónico
que el sector privado, y es más probable que se encuentren transacciones de comercio
electrónico en sitios web de sectores público más grandes, como son las agencias federales,
los estados y las grandes ciudades. Pero aun así, en un período muy corto de tiempo,
algunas de estas agencias federales, estados y ciudades han desarrollado aplicaciones muy
innovadoras que proporcionan servicios útiles al público.
El e-business o e-commerce ha sido un tema de gran preocupación para los
gobiernos, empresas y ciudadanos por igual. Grandes cantidades de tiempo y esfuerzo se
invierten en el examen de la mejor manera de hacer este tipo de transacciones eficientes,
eficaces, y como un medio ampliamente aceptado de hacer negocios. Esto no es tarea fácil,
pues aunque se da a entender que el comercio electrónico es una parte esencial de los
desarrollos futuros de los negocios a nivel nacional e internacional, existe todavía poca
evidencia para sugerir que hay una amplia aceptación de los consumidores de estos modos
de realizar transacciones comerciales. La falta de confianza de los consumidores se ha
centrado en la práctica sobre operaciones de negocios, los problemas de seguridad, y las
dudas sobre qué leyes se aplican a las transacciones realizadas por vía electrónica a través
de Internet (Cyber Law in Australia, 2010).
2.2 Gobierno electrónico y sus tipos
Los gobiernos de todo el mundo están llevando a cabo una serie de iniciativas de
gobierno electrónico para mejorar la eficiencia y eficacia de las operaciones internas, la
comunicación con el público y la participación en los procesos transaccionales con los
componentes individuales y organizacionales. A diferencia de los procesos de gobierno
tradicionales, el gobierno electrónico está particularmente caracterizado por el uso
extensivo de la tecnología de la comunicación, la naturaleza impersonal del entorno en
línea, la facilidad con la que la información puede ser recolectada, procesada y utilizada por
varios sectores, por la incertidumbre implícita en el uso de una infraestructura de
tecnológica abierta y por lo novedoso del medio de comunicación. Los ciudadanos van a
interactuar con un sitio web del Gobierno por lo que la información personal puede ser
fácilmente recogida, manipulada y utilizada por múltiples sectores del mismo. La
utilización de aplicaciones de gobierno electrónico aumenta la separación espacial y
temporal entre los ciudadanos y el Gobierno.
Existen en general ocho modelos de aplicaciones de gobierno electrónico. El primer
tipo de Gobierno a Ciudadano (G2C) proporciona el impulso para poner los servicios
públicos en línea, en particular a través de la prestación de servicios electrónicos para
ofrecer información y comunicación. El tipo de Ciudadano a Gobierno (C2G) donde
nuevamente las aplicaciones proporcionarán el impulso de poner los servicios públicos en
línea, pero esta vez a través de la prestación de servicios electrónicos para el intercambio de
información y comunicación. El modelo de Gobierno a Negocio (G2B) impulsa iniciativas
de transacción tales como las contrataciones electrónicas y el desarrollo de mercados
electrónicos para las compras del Gobierno. El cuarto tipo denominado de Negocio a
Gobierno (B2G) es básicamente lo mismo que el modelo anterior, con el agregado de
actividades de transacciones electrónicas, poniendo el foco en la venta de bienes y servicios
por parte de las empresas. El modelo de Gobierno a Empleado (G2E) se embarca en
iniciativas que faciliten la gestión de la administración pública y la comunicación interna
con los empleados. El sexto modelo llamado de Gobierno a Gobierno (G2G) proporciona
cooperación y comunicación en línea entre los departamentos gubernamentales. Por último,
los modelos de Gobierno a Organizaciones no comerciales y viceversa (G2N y N2G)
proporcionan información y comunicación para organizaciones sin fines de lucro, partidos
políticos y organizaciones sociales.
Nuestro trabajo de negociación automática se enfoca en un modelo de Negocio a
Gobierno en un ámbito municipal, en donde las compras realizadas son directas. Es decir,
sin necesidad de llevar a cabos procesos licitatorios. En la sección 5.1 describimos el
proceso de compra directa.
2.2.1 Modelo de Negocio a Gobierno
Básicamente este modelo contempla las iniciativas de Gobierno Electrónico
destinadas a brindar servicios administrativos y de información a las empresas a través de
Internet. Es importante considerar el tipo de empresa y el sector al que se está atendiendo,
ya que la estrategia de desarrollo debe estar alineada con los intereses y las prioridades del
sector privado mayoritario. Los beneficios que aportan estas iniciativas a las empresas son
similares a los que consiguen los ciudadanos, en términos de ahorro de tiempo y dinero, y
flexibilidad, además se pueden alcanzar importantes ahorros en sus costos administrativos,
demostrar transparencia en la gestión pública, agilizar los procesos de licitaciones, entre
otros (Naser & Concha, 2011).
Las instituciones gubernamentales, que tienen como objetivo ofrecer servicios
(usando innovaciones en tecnologías de la información) útiles y eficientes en un entorno en
constante desarrollo, se enfrentan a un problema concreto relacionado con la
transformación y los cambios en el sistema. El aumento de las relaciones comerciales entre
las empresas nacionales e internacionales determina el fortalecimiento del papel del Estado
y de sus instituciones en los procesos de negocio. La comunicación entre gobiernos y
objetos de negocio es especialmente importante con el fin de garantizar la realización de los
intereses del Estado y de la legalidad de los procesos de negocio. El Gobierno, así como los
objetos de negocio que buscan una mayor eficiencia en su funcionamiento, utilizan
tecnologías de la información innovadoras: crean sitios web, donde están disponibles los
actos jurídicos y demás información relevante para los objetos de negocio. El modelo de
Negocios a Gobierno describe la cooperación entre las organizaciones empresariales y el
gobierno utilizando formas más comunes, como así también el uso de Internet.
Hoy en día, en la mayoría de los países, este campo se supone como muy
importante, ya que la declaración de los actos del Estado en Internet, enviando, recibiendo
y registrando los diversos documentos de negocios utilizando tecnologías electrónicas
permiten una comunicación más rápida, reduce los gastos de transacción y de coordinación
gubernamental. El uso del modelo de Negocios a Gobierno estimula el desarrollo de la
actividad de los estados en campos tan importantes para las empresas como la difusión de
información, los impuestos, y otros.
En la mayoría de los países los gobiernos coordinan sus actividades con las
empresas utilizando canales tradicionales. Internet se utiliza como un recurso adicional para
la difusión de información, pero en el futuro la mayoría de las instituciones deberían
conceder más posibilidades para los temas relacionados con los negocios.
Teniendo en cuenta el análisis de literatura académica, se pueden destacar las
siguientes ventajas del modelo de Negocio a Gobierno: una mejor calidad de los servicios
ofrecidos; eficacia de los gastos, mejorar las relaciones con representantes de las empresas
y otras partes interesadas. El objetivo principal de la implementación de este modelo es
conseguir la inmediata cooperación entre las empresas y el gobierno. En la red creada por el
gobierno, se destacan tres tipos de servicios: servicio de información, servicio de relaciones
y servicio de cooperación. El servicio de información se utiliza para conocer
indirectamente los requerimientos de una persona u organismo. El servicio de relaciones
está destinado a los mismos grupos de objetivos para proporcionar retroalimentación con
ellos. Los servicios de información o de cooperación son ofrecidos principalmente por las
instituciones del Estado. El servicio de cooperación permite a los representantes de las
empresas y a las personas cooperar con el Gobierno, mientras éste realiza diversas
operaciones oficiales (por ejemplo, informar acerca de posibles pérdidas ocurridas durante
el transporte de mercancías de un país a otro). Mientras se utilice el modelo de Negocios a
Gobierno, estas dos partes pueden comunicarse entre sí directamente, como así también con
el uso de Internet. Como la mayoría de los representantes de las empresas desean
comunicarse con el Gobierno utilizando Internet, esta forma de comunicación se torna
complicada. Las grandes empresas por lo general tienden a utilizar los recursos interactivos
y comunicativos creados por organizaciones estatales y aplicarlas a su sistema de negocio.
Sin embargo, tales conexiones entre sistemas heterogéneos deben ser regularizadas muy
bien para obtener el máximo beneficio.
En resumen, es posible llegar a la conclusión de que la realización del modelo de
Negocios a Gobierno está asociado a muchos aspectos: la base jurídica debe ser clara y
correctamente definida, los sistemas de información deben ser regularizados, los intereses
de las empresas asociadas deben estar constantemente coordinados. Sólo la aplicación
coherente de este modelo puede garantizar sus posibles ventajas y un trabajo eficiente
(Jovarauskienė & Pilinkienė, 2009).
2.3 Resumen general
En la actualidad se percibe un intento de acercamiento hacia la utilización de
tecnologías por parte de los gobiernos con el fin de obtener un mayor dinamismo en sus
funciones. Cada vez es más frecuente encontrar una entidad de gobierno que cuente con su
portal Web, en donde, en algunos casos, se permite efectuar una serie de trámites (emisión
de facturas de pago de impuestos, registro de proveedores, obtención de turnos para
determinadas atenciones, etc.). Esta “tecnologización” de la gestión pública de gobierno lo
acerca al concepto de Gobierno Electrónico, permitiendo optimizar la prestación de
servicios, la participación electoral y la gobernabilidad; y centralizando las operaciones
dispersas a fin de maximizar la eficiencia y la productividad.
Existen varios modelos de aplicaciones de gobierno electrónico. Nuestro interés se
centra en el tipo de Negocio (o Empresa) a Gobierno o B2G, el cual proporciona servicios
administrativos y de información a las empresas a través de Internet. Este enfoque aporta
ahorros significativos en tiempo y costos, flexibilidad, eficiencia y transparencia. Si a estos
beneficios les sumamos una alta disponibilidad, un mayor ahorro de tiempo y la posibilidad
de comprar eficientemente y de forma beneficiosa para ambas partes, nos encontramos con
que la implementación de un modelo B2G se convierte en una solución más que auspiciosa.
Este enriquecimiento del modelo se logra automatizando operaciones, y más precisamente,
las relacionadas con las compras.
En el siguiente capítulo nos introduciremos en los conceptos de sistemas
multiagente, los cuales permitirán llevar a cabo operaciones de compras en una entidad de
gobierno con una mínima intervención humana. En base al intercambio de mensajes, los
agentes inteligentes que componen el sistema efectuarán una negociación que maximice los
beneficios de ambas partes. Por lo tanto, es importante analizar los diferentes modelos de
negociación con el propósito de concluir en el que mejor se ajuste al contexto de compras
de una entidad de gobierno, más precisamente el de una entidad municipal.
Capítulo 3
Sistemas Multiagente y Modelos de Negociación
El comercio electrónico en un ámbito municipal podría desarrollarse con la
intervención humana a través del envío de correos electrónicos o la implementación de
formularios Web estáticos. Evidentemente este enfoque carece de beneficios como la
rapidez, disponibilidad y eficiencia que puede proporcionar la utilización de sistemas
multiagente. Al seleccionar un modelo de negociación que facilite la especificación de los
requerimientos de compra y obtenga resultados favorables para ambas partes, e
implementar un sistema multiagente que lo ponga en funcionamiento, se obtienen múltiples
beneficios operativos, como son la reducción de tiempo, compras eficientes, disponibilidad
e interoperabilidad entre sistemas heterogéneos.
3.1 Agentes Inteligentes y Sistemas Multiagente
A continuación abordaremos la teoría de dos componentes fundamentales en la
presente tesis: por un lado los Agentes Inteligentes, y por el otro el agrupamiento de estos
interaccionando entre sí, denominado Sistemas Multiagente.
3.1.1 Agentes inteligentes
No existe una definición consensuada del término agente ni un acuerdo en cuanto a
las propiedades que este tipo de entidades debe de presentar. El diseño de agentes
inteligentes es una rama del mundo de la Inteligencia Artificial. En este dominio, una de las
definiciones de agente más citadas es la establecida por Russell y Norvig (Russell &
Norvig, 2004):
“Un agente es cualquier cosa capaz de percibir su medioambiente con la ayuda de
sensores y actuar en ese medio utilizando actuadores.”
Esta definición se centra en el componente físico del término y en su interacción
con el mundo que le rodea. Acercándose más a la parte funcional del concepto, una
definición comúnmente aceptada es la propuesta por Wooldridge y Jennings (Wooldridge
& Jennings, 1995), posteriormente adaptada por Wooldridge (Wooldridge M. , 2002):
“Un agente es un sistema computarizado que está situado en algún entorno, y que
es capaz de actuar de forma autónoma en este entorno para satisfacer sus objetivos
de diseño.”
En esta definición, ya se destacan algunas de las propiedades comunes que debe de
poseer todo sistema compuesto por agentes, como son la autonomía y su localización en
algún medio con el que tiene que interactuar. En la siguiente definición, Jennings (Jennings
N. , 2001) señala otras características como la flexibilidad y la actuación en representación
de otros, además de enfatizar nuevamente la idea de que todo agente realiza las acciones
pertinentes con el único propósito de alcanzar objetivos predefinidos:
“Los agentes son programas software que actúan flexiblemente en representación
de sus propietarios para alcanzar objetivos particulares.”
Un agente inteligente es básicamente un sistema basado en conocimientos que
percibe su entorno (que puede ser el mundo físico, una persona a través de una interfaz
gráfica de usuario, una colección de agentes, Internet u otro entorno complejo); razona para
interpretar las percepciones, administrar interfaces, resolver problemas y determinar
acciones; y actúa sobre el medio ambiente para lograr un conjunto de metas o tareas para
las que fue diseñado. Interactúa con su entorno a través de algún tipo de lenguaje de
comunicación de agente y no puede obedecer ciegamente a comandos, pero puede tener la
capacidad de modificar la solicitud, hacer preguntas de aclaración, o incluso negarse a
cumplir ciertas peticiones. Puede aceptar solicitudes de alto nivel que indican lo que el
usuario quiere y decidir cómo satisfacer cada solicitud con un cierto grado de
independencia o autonomía, exhibiendo conductas dirigidas a objetivos y elegir
dinámicamente qué acciones tomar y en qué secuencia. Puede colaborar con el usuario para
mejorar el cumplimiento de su tarea o puede llevarlas a cabo en su nombre, empleando algo
del conocimiento o de la representación de los objetivos o deseos del usuario. Puede
controlar los eventos o procedimientos por el usuario, asesorarlo sobre los conocimientos
para llevar a cabo una tarea, o puede ayudar a los diferentes usuarios a colaborar (Tecuci,
1998).
Figura 1 Agente inteligente y su interacción con el entorno
La figura 1 proporciona una visión abstracta de un agente. En este diagrama, se
puede ver la acción de salida generada por el agente con el fin de afectar a su medio
ambiente. En la mayoría de los dominios de complejidad razonable, un agente no tendrá el
control total sobre su entorno. Contará en el mejor de los caso de un control parcial, y que
además podrá influir sobre él. Desde el punto de vista del agente, esto significa que la
misma acción realizada dos veces en circunstancias aparentemente idénticas pueden parecer
tener efectos completamente diferentes, y, en particular, no tener el resultado deseado. Así,
los agentes deben estar preparados para la posibilidad de fracaso en todos los ambientes,
pero más aún en aquellos que parecen triviales. Se puede resumir esta situación
formalmente diciendo que se asume que los entornos en general son no deterministas.
Normalmente, un agente tendrá un repertorio de acciones de las cuales dispone. Este
conjunto representa la capacidad efectiva del agente: su habilidad de modificar sus
entornos. Se debe tener en cuenta que no todas las acciones se pueden realizar en todas las
situaciones. Por ejemplo, la acción “comprar un Ferrari” producirá un error si los fondos
disponibles son insuficientes para ello. Las acciones por lo tanto tienen precondiciones
asociadas que definen las situaciones posibles en las que pueden ser aplicadas.
Agente
Medio ambiente
sensor deentrada
acción desalida
Aunque son similares, los agentes tienen características que no poseen los objetos
como la autonomía, la cooperación, la percepción y la proactividad. La principal diferencia
es que los objetos son pasivos, reaccionan a estímulos externos, pero no tienen metas que
direccionen su comportamiento, como los agentes. Otra diferencia es que los agentes usan
un lenguaje común entre todos los agentes, mientras que los mensajes entre los objetos
dependen de las clases (Ortiz, López Gallego, & Oviedo Carrascal, 2009).
3.1.1.1 Propiedades de los agentes inteligentes
Se pueden determinar cuatro propiedades fundamentales de los agentes inteligentes:
Autonomía: los agentes actúan en nombre de otras entidades en forma autónoma.
Ellos operan sin la intervención directa de los seres humanos u otros, y tienen
algún tipo de control sobre sus acciones y estado interno.
Habilidad social: los agentes utilizan un lenguaje de comunicación de agente para
interactuar con otros agentes.
Reactividad: los agentes perciben su entorno y responden de manera oportuna para
cumplir con los objetivos propuestos. El entorno puede ser el mundo físico, un
usuario, otros agentes, o la combinación de estas entidades. Klusch (Matthias
Klusch, 2000) llama a esta característica cooperación social. Los agentes son
capaces de cooperar en grupos con otros agentes y/o seres humanos cuando sea
necesario.
Pro-actividad: los agentes son capaces de exhibir comportamientos de iniciativa
orientada a objetivos en lugar de simplemente responder a su entorno.
Jennnings y Wooldridge (Wooldridge & Jennings, 1995) enriquecen estas
propiedades y clasifican a los agentes según una noción débil o fuerte de agencia. En la
noción débil de agencia, los agentes tienen voluntad propia (autonomía), pueden
interaccionar entre ellos (habilidad social), responder a estímulos (reactividad), y tomar la
iniciativa (pro-actividad). En la noción fuerte, se preservan las propiedades de agencia
débil, pero, además, los agentes pueden moverse alrededor de una red (movilidad), son
veraces (veracidad), hacen lo que se les dijo que hicieran (benevolencia) y consiguen
realizar los objetivos propuestos de manera óptima (racionalidad).
Por simplicidad se utilizará el término agente en el resto de la tesis, asumiendo su
carácter inteligente y autónomo, su habilidad para interactuar con otros agentes o humanos,
y su capacidad de percepción y actuación sobre su entorno.
3.1.1.2 Entorno de un agente
El entorno de un agente se caracteriza, como se muestra en la figura 2, por las
siguientes cuatro propiedades principales (Russell & Norvig, 2004):
Figura 2 Entorno de un agente inteligente
• No determinista
• Inaccesible
• Dinámico
• Continuo
Puesto que un agente no tiene el control total sobre su entorno, su influencia es sólo
parcial. Como se mencionó anteriormente, una acción realizada por un agente dentro de un
Entorno
No determinista
DinámicoContinuo
Inaccesible
entorno no tiene un efecto único garantizado y el estado resultante de esta acción es
incierto. Por esta razón, los entornos del agente se suponen que son no deterministas.
El entorno de Internet es cada vez menos accesible para los agentes a medida que
más y más información está disponible en línea. Es imposible para los agentes obtener
información precisa, completa y al día dentro de este entorno. Es cada vez más difícil
construir agentes que pueden operar efectivamente dentro de este conjunto de información
heterogénea. Por esta razón, la mayoría de los entornos reales son inaccesibles.
Un entorno dinámico es aquel que tiene otros procesos que operan sobre el mismo,
causando así su cambio de estado. Como resultado, este entorno está cambiando más allá
del control del agente. En contraste, un entorno estático se supone que cambia sólo por las
actuaciones del agente. La mayoría de los agentes se ubican en un entorno altamente
dinámico y que cambian continuamente, como es el caso de la Internet.
La distinción entre discreto y continuo se puede aplicar al estado del medio, a la
forma en la que se maneja el tiempo y a las percepciones y acciones del agente. Por
ejemplo, un juego de ajedrez es un medio con un número finito de estados, que lo
convierten en un entorno discreto para un agente jugador. Un vehículo que debe moverse
por un espacio compone un medio continuo, por contar con infinitas posibilidades. Puesto
que un conjunto discreto está contenido dentro de uno continuo, se definen a los entornos
como continuos.
3.1.2 Sistemas multiagente
Los agentes pueden ser útiles como entidades independientes en entornos aislados a
los que se les delegan ciertas tareas repetitivas y que se pueden automatizar en
representación de unos determinados usuarios. Sin embargo, en la mayoría de los casos, los
agentes se encuentran en entornos que contienen otros agentes constituyendo de este modo
un Sistema Multiagente, esto es, un sistema constituido por un grupo de agentes que pueden
interaccionar (Vlassis, 2003). Una definición más elaborada es la propuesta por el
Laboratorio de Agentes Software Inteligentes (2001):
“Un sistema multiagente es una red poco acoplada de agentes software que
interaccionan para resolver problemas que van más allá de las capacidades o
conocimiento individual de cada uno de los componentes que resuelven
problemas.”
Cuando un grupo de agentes individuales forma un sistema multiagente, surge la
necesidad de disponer de un mecanismo para coordinar dicho grupo de agentes y de un
lenguaje para permitir la comunicación entre ellos. Entre los mecanismos de coordinación,
se pueden distinguir los casos en los que los agentes tienen objetivos comunes y, por tanto
cooperan, de los casos en los que los agentes tienen intereses propios y que entran en
conflicto con el de los demás, para lo cual se hace necesario dotarlos de mecanismos de
negociación (Huhns, 1999). De forma análoga a esta clasificación, Wooldridge
(Wooldridge M. , 2009) distingue entre sistemas distribuidos de resolución de problemas
(constituidos por agentes diseñados explícitamente para conseguir de forma cooperativa un
objetivo dado) y sistemas abiertos (donde confluyen agentes elaborados por distintos
desarrolladores y que poseen posiblemente objetivos diferentes).
En el caso de agentes cooperativos, los mecanismos de cooperación más comunes
son las estructuras organizacionales, la planificación multiagente (centralizada y
distribuida), redes de contratos y cooperación funcionalmente exacta. Por otro lado, para el
caso de agentes competitivos, se hace necesario un mecanismo de negociación. Entre los
tipos de mecanismos de negociación más utilizados en la literatura se destacan la formación
de coaliciones, los mecanismos de mercados, la teoría del regateo, la votación, las subastas
y la asignación de tareas entre dos agentes.
Para que se pueda producir una comunicación efectiva entre los agentes, se han
elaborado diversos lenguajes. Estos lenguajes fueron diseñados bajo la influencia de la
Teoría de los actos del habla (Austin, 1962) (Searle, 1969). Esta teoría está basada,
fundamentalmente, en la existencia de los denominados actos del habla o performativas
(p.ej. solicitar, informar, prometer). Por tanto, las conversaciones se basan en estos actos
del habla y proporcionan el potencial necesario para la coordinación, la cooperación y la
negociación. La coordinación se puede definir como la manera en que los agentes se
comportan individual y socialmente para que se satisfagan los objetivos personales y los
globales. Por su parte, la cooperación puede verse como la actuación coordinada entre
agentes de tal manera que unos colaboran, interesada o desinteresadamente, en la
resolución de tareas de otros. Por último, la negociación es un proceso mediante el cual un
grupo de agentes llegan a un acuerdo mutuamente aceptable sobre algún asunto.
La construcción de sistemas multiagente integra tecnologías de distintas áreas de
conocimiento. Por un lado la Inteligencia Artificial se ha ocupado de dar comportamientos
inteligentes a los agentes basándose en actitudes como: racionalidad, coherencia y
capacidad de adaptación. Por otro lado la Ingeniería de Software ha apoyado el desarrollo
de metodologías orientadas a agentes por su relación tan cercana a la tecnología del objeto
y a las metodologías orientadas al objeto. El término adoptado para estas metodologías es
AOSE (Agent-Oriented Software Engineering). Las dos áreas mencionadas han dado gran
impulso al desarrollo de los sistemas multiagente, promoviendo un proceso de formación
de la computación orientada a agentes.
3.1.3 Comunicación de agentes
Como se mencionó anteriormente, la capacidad de comunicación de los agentes es
de vital importancia para que puedan llevar a cabo el fin para los cuales fueron diseñados.
Un sistema multiagente no sería tal si los agentes que lo componen no tuvieran esta
capacidad. Las partes con las que un agente puede desear comunicarse incluyen:
• Su entorno.
• Otros agentes.
• Los usuarios.
Los agentes se comunican con su entorno por diversos fines tales como determinar
los recursos o servicios existentes, acceder a los datos, transferir los resultados, determinar
la ubicación de otro agente, y otras razones similares.
La comunicación entre los agentes es de gran importancia para diversas situaciones,
como ser compartir información, realizar consultas a otros agentes, y para coordinar las
actividades entre ellos, lo que les permitirá trabajar en colaboración.
Los agentes deben tomar las peticiones de los usuarios y comunicarles los
resultados. Esta es una de las tareas principales de los agentes de interfaz. Otros agentes
pueden registrar sus datos con el agente de interfaz el cual entrega la información "tal cual
es" o pre-procesada. Esta información puede ser recogida de diversos agentes y organizada
en un formato que es conveniente para la visualización por parte del usuario.
3.1.3.1 Lenguajes de comunicación
Si dos o más agentes desean comunicarse entre sí, deben compartir un lenguaje
común. El lenguaje utilizado por los agentes en las comunicaciones se llama lenguaje de
comunicación del agente (ACL).
Las características deseables de los lenguajes de comunicación entre agente (Finin,
Labrou, & Mayfield, 1995) se relacionan con:
1) la forma
2) el contenido
3) la semántica
4) la aplicación
5) las redes
6) el entorno
7) la fiabilidad
La forma del lenguaje debería ser sencilla y lineal (o es conveniente que pueda ser
fácilmente traducida a una forma lineal) a causa del mecanismo de transporte utilizado. Un
lenguaje de comunicación entre agentes debe ser declarativo y legible por las personas. Su
sintaxis debe ser simple y extensible, ya que tiene que ser integrado en diversos sistemas.
El lenguaje de comunicación que expresa actos comunicativos tiene que ser
separado del lenguaje de contenido que expresa hechos sobre el dominio. Un enfoque de
capas que separe el lenguaje de comunicación del de contenido ayuda a lograr este
propósito, ya que permite la integración exitosa del lenguaje con las aplicaciones, y además
proporciona un marco conceptual para la comprensión del lenguaje. Independientemente de
la aplicación, por ejemplo una base de datos orientada a objetos o una base de
conocimientos, debe ser especificado un conjunto de primitivas que capturen la mayor parte
de los actos comunicativos. Este conjunto de primitivas de actos comunicativos necesita ser
extensible para permitir que el lenguaje sea utilizado por una variedad de sistemas.
Al igual que en cualquier otro lenguaje, la semántica de un lenguaje de
comunicación debe basarse en un marco teórico, ser clara y mostrarse en la forma canónica
(la similitud en un significado debe conducir a una similitud en la representación). A
medida que el lenguaje de comunicación permite la interacción entre aplicaciones dispersas
en un espacio, y esta interacción se extiende a lo largo del tiempo, el espacio y el tiempo
necesario deben ser abordados por la semántica de un lenguaje de comunicación. Las partes
que se comunican deben tener una comprensión compartida del lenguaje, y además, sus
primitivas y protocolos asociados deben ser formalmente descritos.
La implementación de un lenguaje de comunicación debe acoplarse bien a la
tecnología actual de software. La aplicación del lenguaje también tiene que ser eficiente. La
interfaz debe poder ser fácilmente utilizada por las capas de red que se encuentran por
debajo de los actos comunicativos primitivos que son ocultos para el usuario. Como
algunos agentes pueden requerir sólo un subconjunto de los actos comunicativos
primitivos, debería ser posible la aplicación parcial del lenguaje.
Un lenguaje de comunicación de agente debe actuar con eficiencia en un entorno
muy distribuido, heterogéneo y dinámico. Por otra parte, debería posibilitar la aplicación de
funciones tales como la interoperabilidad con otros lenguajes y protocolos, y permitir el
descubrimiento de conocimiento en redes de gran tamaño. Tiene que ser fácilmente
acoplable a los sistemas heredados existentes. Tiene que permitir una comunicación fiable
y segura. El lenguaje debe ser compatible con la autenticación de los agentes, así como
identificar y señalar los errores y las advertencias.
Los lenguajes de comunicación entre agentes más destacables son KQML
(Knowledge Query and Manipulation Language), KIF (Knowledge Interchange Format) y
FIPA-ACL (FIPA Agent Communication Language). KQML se ocupa de definir un
formato común para los mensajes sin meterse en el contenido de los mismos (Finin,
Labrou, & Mayfield, 1995). Cada mensaje en KQML está formado por una performativa
que define el tipo de mensaje y un conjunto de parámetros (p.ej. contenido, remitente,
receptor). KIF es un lenguaje que permite representar conocimiento sobre un determinado
dominio del discurso (Genesereth & Fikes, 1992). KIF es usado, principalmente, para
formar la parte del contenido de mensajes KQML. FIPA-ACL es similar a KQML en tanto
que define el formato de los mensajes sin preocuparse ni implicar el uso de un lenguaje
específico para el contenido de los mensajes (FIPA, 2002b).
3.1.4 Ontologías
Una de las cuestiones importantes de la que no hemos hablado hasta el momento ha
sido la de ontologías. El tema de las de ontologías surge por la siguiente razón. Si dos
agentes desean entablar una comunicación acerca de algún dominio, entonces es necesario
que se pongan de acuerdo sobre la terminología que utilizarán para describir este dominio.
Por ejemplo, supongamos el caso en que un agente está comprándole a otro agente un
artículo en particular, como ser una tuerca o tornillo: el comprador debe ser capaz de
especificar de forma inequívoca al vendedor las propiedades deseadas del elemento, tales
como su tamaño. Los agentes por tanto, necesitan ser capaces de ponerse de acuerdo tanto
en lo que significa "tamaño", como así también el significado de 'pulgadas' o 'centímetro'.
Una de las definiciones más citadas es la enunciada por Gruber (Gruber, 1993):
“Una ontología es una especificación explícita de una conceptualización.”
El autor considera que una conceptualización está compuesta por objetos, conceptos
y otras entidades que existen en una determinada área, y las relaciones que se dan entre
ellos. Por explícita, se entiende que los conceptos y las restricciones se definen de forma
explícita.
La definición de Gruber fue posteriormente refinada por Borst (Borst, 1997) de la
siguiente manera:
“Una ontología es una especificación formal de una conceptualización
compartida.”
En este contexto, formal se refiere a la necesidad de disponer de ontologías
comprensibles por las aplicaciones informáticas. Por otro lado, compartida enfatiza la
necesidad de consenso en la conceptualización, refiriéndose al tipo de conocimiento
contenido en las ontologías, esto es, conocimiento consensuado y público.
Studer y sus colegas (Studer, Benjamins, & Fensel, 1998) se encargaron de fusionar
las definiciones de Gruber y Borst, llegando a la siguiente conclusión:
“Una ontología es una especificación formal y explícita de una conceptualización
compartida.”
Cabe aclarar que no existe una definición consensuada de ontología, por lo tanto, se
puede entender a qué se refiere enumerando los elementos que la componen. En general, las
ontologías proporcionan un vocabulario común de un área y definen, a diferentes niveles de
formalismo, el significado de los términos y relaciones entre ellos. El conocimiento en
ontologías se formaliza principalmente usando seis tipos de componentes: clases, atributos,
relaciones, funciones, axiomas e instancias (Gruber, 1993):
Una clase puede ser algo sobre lo que se dice algo, como por ejemplo un tipo de
objeto, la descripción de una tarea, función, acción, estrategia, proceso de
razonamiento, etc. Las clases en la ontología se suelen organizar en taxonomías. En
todo caso, cabe destacar que ontología y taxonomía son dos elementos diferentes,
aunque algunas veces la noción de ontología se diluye en el sentido que las
taxonomías se consideran ontologías completas (Studer, Benjamins, & Fensel,
1998). Se suelen usar indistintamente los términos clase y concepto.
Los atributos representan la estructura interna de los conceptos. Atendiendo a su
origen, los atributos se clasifican en específicos y heredados. Los atributos
específicos son aquellos que son propios del concepto al que pertenecen, mientras
que los heredados vienen dados por las relaciones taxonómicas en las que el
concepto desempeña el rol de hijo y, por tanto, hereda los atributos del padre. Los
atributos vienen caracterizados por el dominio en el cual pueden tomar valor.
Las relaciones representan un tipo de interacción entre los conceptos del dominio.
Se definen formalmente como cualquier subconjunto de un producto de n conjuntos,
esto es: R: C1 x C2 x…x Cn. Entre los distintos tipos de relaciones posibles, se
encuentran las relaciones taxonómicas (“es_un”) y las mereológicas o partonómicas
(“parte_de”) como relaciones binarias más destacadas.
Las funciones son un tipo especial de relaciones en las que el n-ésimo elemento de
la relación es único para los n-1 precedentes. Formalmente, definimos las funciones
(F) como: F: C1 x C2 x…x Cn-1 → Cn. Como ejemplos, se pueden mencionar las
funciones “madre de” y “precio de un coche usado”.
Los axiomas son expresiones que son siempre ciertas. Pueden ser incluidas en una
ontología con muchos propósitos, tales como definir el significado de los
componentes ontológicos, definir restricciones complejas sobre los valores de los
atributos, argumentos de relaciones, etc., verificando la corrección de la
información especificada en la ontología o deduciendo nueva información.
Por último, las instancias son las ocurrencias en el mundo real de los conceptos. En
una instancia todos los atributos del concepto tienen asignado un valor concreto.
3.1.5 Plataformas de desarrollo de sistemas multiagente
Existen variedades de plataformas que difieren en el tipo de lenguaje utilizado
(FIPA y/o KQML), si soportan movilidad de código, en la arquitectura base de la
plataforma, los tipos de agentes soportados, el lenguaje de desarrollo, entre otros. A
continuación haremos un repaso de algunas de ellas.
3.1.5.1 JADE (Java Agent DEvelopment Framework)
Como mencionamos en el capítulo 1, JADE es un entorno que simplifica la
implementación de sistemas multiagente mediante una capa de soporte (middleware)
respetando las especificaciones FIPA. La plataforma puede ser distribuida en varias
máquinas (las cuales no necesitan compartir el mismo sistema operativo) y la
configuración, que puede ser controlada mediante una interface gráfica remota, incluso
puede ser cambiada en tiempo de ejecución (por ejemplo, moviendo agentes de una
máquina a otra, cuando es necesario). La arquitectura de comunicación ofrece mensajes
flexibles y eficientes. El modelo de comunicación de FIPA se ha implementado en forma
completa y sus componentes han sido claramente especificados y completamente
integrados: protocolos de interacción, ACL (Agent Communication Language), lenguaje de
contenido, esquemas de codificación, ontologías y finalmente protocolos de transporte.
Muchos de los protocolos de interacción de FIPA están disponibles y pueden ser
instanciados después de definir las dependencias de cada estado del protocolo. Cuenta con
soporte para lenguajes de contenido y ontologías definidas e implementadas por el usuario
que automáticamente son utilizadas por el Framework.
3.1.5.2 JADEX
El sistema de agentes JADEX es una extensión de JADE, enfocada en los
protocolos orientados a objetivos. JADEX tiene por objeto facilitar el desarrollo de
sistemas multiagente introduciendo nociones abstractas tales como creencias, metas y
planes. Proporciona una arquitectura estable y un Framework de programación para agentes
orientados a objetivos, que utilizan tecnologías ya consolidadas como XML y Java.
JADEX se basa en el modelo BDI. Son las siglas de creencias (Beliefs), deseos
(Desires) e intenciones (Intentions), que son componentes mentales presentes en muchas
arquitecturas de agentes. Las creencias representan el conocimiento del agente, los deseos
representan los objetivos y las intenciones otorgan deliberación al agente.
3.1.5.3 JACK
JACK provee un entorno de desarrollo orientado a agentes construido sobre Java y
completamente integrado con este lenguaje de programación. Incluye todas las
componentes del entorno de desarrollo de Java así como también ofrece extensiones
específicas para implementar el comportamiento de los agentes. La relación entre JACK y
Java es análoga a la relación entre los lenguajes C++ y C, JACK fue desarrollado para
proveer extensiones al lenguaje Java orientadas a agentes. El código JACK es primero
compilado a código Java regular antes de ser ejecutado.
El lenguaje JACK Agent hace más que extender la funcionalidad de Java, además
provee un entorno para soportar un nuevo paradigma de programación. Este lenguaje es
orientado a los agentes y es utilizado para implementar sistemas de software orientados a
agentes. Todas las formas en las que extiende a Java, son implementadas como plugins, lo
que permite que el lenguaje sea lo más extensible y flexible posible. Les extensiones son las
siguientes:
Define nuevas clases base, interfaces y métodos.
Provee extensiones a la sintaxis de Java para soportar clases orientadas a agentes.
Provee extensiones semánticas para soportar la ejecución del modelo.
3.1.5.4 ZEUS
El objetivo del proyecto ZEUS es facilitar el rápido desarrollo de nuevas
aplicaciones multiagente mediante la abstracción de los principios y componentes más
comunes a una herramienta. La idea es proveer una herramienta de propósito general y
personalizable, que permita la creación de agentes colaborativos y que pueda ser usada por
ingenieros de software con poca experiencia en tecnología de agentes para crear sistemas
multiagente. Para esto es necesario cumplir con los siguientes principios:
La herramienta debe permitir separar el problema de nivel de dominio y la
funcionalidad de nivel de agente.
La herramienta debe estar basada en el paradigma de programación visual.
La herramienta debe soportar un diseño abierto para asegurar que sea fácilmente
extensible.
Se debe utilizar tecnología “estandarizada” siempre que sea posible.
Los agentes deben ser deliberativos en el sentido de que deben explícitamente
razonar acerca de sus acciones en términos de qué metas seguir, cuándo considerar nuevas
metas y cuándo abandonar metas existentes. Es más, el requerimiento del comportamiento
dirigido por metas implica que el agente solo seleccionaría acciones que espera de alguna
manera lo acerque a la meta deseada. Sólo se descartan metas cuando, no son alcanzables o
las motivaciones para alcanzar dicha meta ya no se verifican.
3.2 Modelos de negociación
En las secciones anteriores señalamos que en un sistema multiagente debe existir
una comunicación efectiva entre sus integrantes. Esto llevó a la elaboración de diferentes
lenguajes diseñados en base a los actos del habla o performativas. Las conversaciones que
pueden producirse dentro de un sistema multiagente se basan en estos actos del habla y
permiten, entre otras cosas, llegar a un acuerdo mutuamente aceptable sobre algún asunto.
Esto último se denomina Negociación, y compone otro de los pilares fundamentales de la
presente tesis.
Partiendo de los principios de la teoría de negociación, haremos un estudio de los
diferentes conceptos y técnicas que nos llevará a la elección del mejor modelo que se
aplique a nuestro marco de negociación automática en el contexto de un ámbito municipal,
más precisamente en sus operaciones de compra. El diseño debe cumplir con una serie de
requerimientos. En primer lugar, las soluciones deben ser justas para ambas partes. En
segundo lugar, ambas partes deben tratar de maximizar su propia rentabilidad en el
transcurso de una negociación. Así, si el oponente no puede aceptar una oferta entonces el
que llevó a cabo la propuesta debe esforzarse por encontrar una alternativa que tenga el
mismo valor que la misma (por ejemplo, el agente puede variar los valores de los distintos
atributos de negociación). En otras palabras, un agente debe evitar hacer una concesión,
siempre que sea posible, ya que esto disminuye su rentabilidad en la operatoria. Por otra
parte, cuando un agente tiene que hacer una concesión debe ser lo mínima posible.
En tercer lugar, es importante que los agentes minimicen la cantidad de información
revelada sobre sus preferencias, ya que cualquier revelación puede debilitar su posición
negociadora.
Hay una gran diversidad de propuestas en cuanto a modelos y protocolos de
negociación se refiere, abarcando gran parte de los desafíos que plantea la negociación.
Estos modelos se pueden clasificar de acuerdo a diferentes criterios (Buttner, 2006), como
pueden ser su estructura, la dinámica del proceso de negociación, o las restricciones
temporales o de información del escenario. Haciendo una clasificación asentada en los
fundamentos teóricos del modelo, se pueden encontrar enfoques basados en teoría de
juegos, enfoques heurísticos y enfoques basados en argumentación. Los enfoques basados
en teoría de juegos tratan de encontrar soluciones óptimas desde el punto de vista analítico,
basándose en el análisis de condiciones de equilibrio (Nash, 1950). Estos modelos son
sólidos desde el punto de vista matemático, pero su uso práctico está muy restringido
debido a los supuestos de los que parte: recursos ilimitados, racionalidad perfecta e
información completa. En los enfoques basados en heurísticas estas suposiciones se relajan,
y los participantes tratan de encontrar una solución aproximada de acuerdo a los principios
de razonamiento limitado mediante el uso de técnicas de búsqueda y evaluación heurísticas.
En las negociaciones basadas en argumentación, se añade a los agentes la capacidad de
razonar sus posturas incluyendo un nivel de metainformación que permite utilizar
promesas, recompensas, amenazas y otras formas de incentivos (Rahwan, 2004).
3.2.1 Componentes de un modelo de negociación
Los cuatro componentes de un modelo de negociación son los siguientes:
1- El protocolo de negociación.
2- Las estrategias de negociación.
3- La información de estado de los agentes.
4- El equilibrio de la negociación.
El protocolo especifica las reglas para el encuentro de los participantes en la
negociación. Es decir, define las circunstancias en las que la interacción entre los agentes se
lleva a cabo, qué ofertas se pueden hacer y qué secuencias de ofertas están permitidas. En
general, los agentes deben alcanzar un acuerdo sobre el protocolo de negociación a ser
utilizado antes que la negociación propiamente dicha comience. Un protocolo de
negociación se puede diseñar para el manejo de uno o múltiples atributos. Para las
negociaciones de múltiples atributos, se puede disponer de protocolos que negocian cada
uno de ellos a la vez o todos juntos.
Una estrategia de negociación para un agente es una especificación de la secuencia de
acciones (por lo general ofertas o respuestas) que este tiene previsto realizar durante la
negociación. Normalmente habrá muchas estrategias que son compatibles con un protocolo
en particular, cada uno de los cuales puede producir un resultado diferente. Por ejemplo, un
agente podría conceder en la primera ronda o negociar muy duramente a lo largo de la
negociación hasta que el tiempo de finalización sea alcanzado. De ello se deduce que la
estrategia de negociación que emplea un agente es fundamental para el resultado de la
negociación. También debe quedar en claro que las estrategias que funcionan bien con
ciertos protocolos no necesariamente lo hacen con otros. La elección de una estrategia a
utilizar es por tanto una función no sólo de las características específicas del escenario de
negociación, sino también del protocolo en uso.
La información de estado de un agente describe el conocimiento que este tiene sobre las
bases de la negociación tal como si fuera una partida o juego entre sus participantes. Von
Neumann y Morgenstern (von Neuman & Morgenstern, 1944) introdujeron una
clasificación fundamental para estos juegos: de información completa y de información
incompleta. La primera categoría es básica. En estos juegos se supone que los jugadores
conocen toda la información relevante acerca de las reglas del juego y las preferencias de
los jugadores (representadas por funciones de utilidad). En la segunda categoría, la
información puede carecer de una variedad de factores para el problema de negociación.
Así, cada jugador puede tener alguna información privada acerca de su propia situación que
no está disponible para los demás jugadores, y a su vez sólo contar con datos
probabilísticos sobre la información privada de los demás. Harsanyi (Harsanyi, 1968)
propuso que los modelos de juegos de información incompleta partan del supuesto de que
todos los jugadores empiezan con la misma distribución de probabilidad sobre esta
información privada y que estos antecedentes son de conocimiento común. Así, los
jugadores no sólo tienen antecedentes sobre la información privada de los demás, también
saben lo que a priori los otros participantes conocen acerca de su propia información
privada. Los modelos estratégicos de información incompleta incluyen por lo tanto un
mayor nivel de detalle, ya que no solo se especifican las acciones y la información
disponible a los otros jugadores en el transcurso de la negociación, sino también sus
distribuciones de probabilidad e información antes del inicio de la misma.
Un mecanismo de negociación consiste en un protocolo de negociación junto con las
estrategias de negociación de los agentes implicados. Tiene que ser estable (es decir, un
perfil estratégico debe constituir un equilibrio), y el concepto más cercano para tal
propósito es el de equilibrio de Nash para juegos de ofertas simultáneas. Dos estrategias se
encuentran en equilibrio de Nash si la estrategia de cada agente es la mejor respuesta a la
estrategia de su oponente. Esta es una condición necesaria para la estabilidad del sistema
donde ambos agentes actúan estratégicamente. Para protocolos de ofertas secuenciales, el
concepto de equilibrio de Nash se ve fortalecido en varias formas, al exigir que las
estrategias mantengan el equilibrio a cada paso del juego. En resumen, la racionalidad en
un mecanismo de negociación requiere que cada agente va a seleccionar una estrategia de
equilibrio cuando se elige de forma independiente. Ante esto, se establecen los siguientes
criterios principales para evaluar el resultado de equilibrio:
1- Unicidad. Si la solución del juego de negociación es única, entonces se puede
identificar de manera inequívoca.
2- Eficiencia. Un acuerdo es eficiente si no hay pérdida de utilidad (es decir, el
acuerdo es Pareto-óptimo). Un resultado es Pareto-eficiente si no hay otro resultado
que mejore la rentabilidad de un agente sin hacer que empeore la de otro agente.
Todas las soluciones Pareto-eficientes son preferibles a aquellas que no lo son.
3- Simetría. Un mecanismo de negociación se dice que es simétrico si no trata de
manera diferente a los jugadores sobre la base de criterios inapropiados.
Puntualmente lo que constituye a los criterios no apropiados depende del dominio
específico. Por ejemplo, si el resultado de la negociación sigue siendo el mismo
independientemente de qué jugador comienza el proceso de negociación, entonces
se dice que es simétrico con respecto a la identidad del primer jugador.
4- Distribución. Esta propiedad está relacionada con la cuestión de cómo los
beneficios del comercio se reparten entre los jugadores, ¿el resultado debe surgir de
dividir las ganancias por igual entre los comerciantes o tiene que favorecer a un
agente más que a otro?
3.2.2 Teoría de juegos
La teoría de juegos es una rama de la economía que estudia las interacciones
estratégicas entre agentes egoístas (Osborne & Rubinstein, 1994). La palabra agente se
emplea aquí en su sentido más amplio, y puede referirse tanto a un agente económico (por
ejemplo un comprador) como a un agente software. Por interacciones estratégicas se
entiende que son aquellas en que el éxito de la toma de decisiones de un agente depende
también de las decisiones que tomen el resto de los agentes implicados. Los agentes se
consideran egoístas cuando buscan maximizar su propio interés. El trabajo teórico
fundamental sobre teoría de juegos se origina en el campo de la economía por parte de
Neuman y Morgenstern (von Neuman & Morgenstern, 1944), si bien la primera aplicación
de este trabajo teórico al estudio de las interacciones estratégicas entre agentes se puede
encontrar en (Rosenschein & Zlotkin, 1994).
De forma general, y para el marco de la negociación automática, la teoría de juegos
puede aplicarse a dos problemas bien diferenciados: el diseño de protocolos de interacción
entre agentes y el diseño de estrategias para los agentes. El diseño de protocolos (también
llamados mecanismos de interacción) abarca la definición de las reglas de encuentro entre
agentes, es decir, el conjunto de reglas que gobiernan la interacción. El objetivo es
encontrar mecanismos que satisfagan una serie de propiedades, como pueden ser la garantía
de éxito, la estabilidad, la incentivo-compatibilidad (incentive compatibility) o la
simplicidad (Sandholm, 1999). Por otro lado, el diseño de estrategias (también llamadas
mecanismos de decisión) se refiere a la especificación de las acciones que debe llevar a
cabo un agente ante cada una de las situaciones que pueden darse en el transcurso de la
negociación. La propiedad deseable en el caso de las estrategias es la optimalidad (por
ejemplo que el agente en cada caso lleve a cabo la acción que le lleva a maximizar su
propio beneficio). Esta optimalidad en la definición de estrategias se delimita mediante
distintos tipos de equilibrio, como son las estrategias dominantes, el equilibrio Nash y el
equilibrio perfecto en subjuegos (Kraus, 2001b).
El uso de teoría de juegos para la resolución de problemas de negociación tiene
indudables ventajas, como son la solidez matemática y el carácter analítico de sus
propuestas y resultados. No obstante, algunos de los supuestos de los que parte la teoría de
juegos limitan su aplicabilidad a problemas de negociación reales (Jennings, Sycara, &
Wooldridge, 1998b). En primer lugar, los modelos de teoría de juegos asumen que los
agentes tienen racionalidad ilimitada, esto es, que no existen costes computacionales
asociados a la búsqueda de acuerdos. Esta suposición es evidentemente inalcanzable en
entornos de computación real. Por otro lado, los enfoques basados en teoría de juegos
también suelen asumir que el espacio de soluciones es completamente conocido para los
agentes, así como que cada agente conoce la utilidad que le proporciona cada posible
solución. En escenarios de negociación complejos, donde el número de atributos que se
negocian es elevado y cada atributo toma valores de un conjunto de cardinalidad elevada o
incluso infinita, la evaluación de todos los posibles acuerdos puede ser un problema
computacionalmente intratable. Otra suposición general es la de información completa, que
alude al hecho de que las preferencias de cada agente son conocidas por el resto de agentes
implicados en la negociación. En entornos reales competitivos, es usual que los agentes
participantes no deseen revelar completamente su información de preferencias al resto de
los negociadores, por lo que esta suposición también es inadecuada para muchos entornos.
Por último, la teoría de juegos busca estrategias óptimas bajo la suposición de que todos los
demás agentes actúan racionalmente (tratando de maximizar su utilidad de la manera más
óptima posible). En escenarios reales, con agentes heterogéneos, esta suposición tampoco
es necesariamente cierta. Estas limitaciones hacen que la teoría de juegos no sea un enfoque
adecuado para la resolución de problemas de negociación en determinados escenarios, para
los que será necesario emplear aproximaciones alternativas.
3.2.3 Enfoques basados en heurísticas
Los enfoques basados en heurísticas surgen como un modo de afrontar las
limitaciones concernientes a los enfoques basados en teoría de juegos (Jennings N. , 2001).
En entornos reales, existe un coste asociado a la computación y a la toma de decisiones, y
por ello la búsqueda exhaustiva de soluciones hasta encontrar una solución óptima no es
factible. Los enfoques heurísticos tienen como objetivo, por tanto, la consecución de
soluciones suficientemente buenas. Los mecanismos que se emplean dentro de los enfoques
heurísticos son muy variados, aunque suelen ser aproximaciones de los métodos de teoría
de juegos o implementaciones de modelos de negociación humanos (Raiffa, 1982) (Faratin,
2000).
Existen diferentes enfoques heurísticos al problema de la negociación en la
literatura. Sandip Sen (Sen, 1997) aplica un enfoque de negociación heurística al escenario
de la planificación de reuniones. Faratin, Sierra y Jennings proponen una serie de métodos
heurísticos para un escenario de negociación bilateral multiatributo. El protocolo de
negociación es un intercambio posicional, en el que los agentes se envían mutuamente
posibles soluciones al problema. Los sucesivos envíos de propuestas se controlan mediante
heurísticas, que modulan las exigencias de los agentes en función del tiempo, de la
disponibilidad de recursos o del comportamiento del oponente (Faratin, Sierra, & Jennings,
1998). Asimismo, definen mecanismos para la búsqueda de soluciones de compensaciones
(trade-offs) basados en criterios de similaridad entre ofertas.
La principal ventaja de los enfoques basados en heurísticas al problema de la
negociación radica en que los modelos heurísticos se basan en suposiciones realistas en
cuanto al coste computacional y a la disponibilidad de información se refiere, por lo que
pueden aplicarse en escenarios en los que la teoría de juegos no es adecuada. No obstante,
es necesario tener en cuenta que, debido a que los enfoques heurísticos no exploran el
espacio completo de soluciones, con esto se obtienen a menudo soluciones subóptimas. Por
otro lado, los modelos basados en heurísticas carecen de la elegancia y de la solidez
matemática de la teoría de juegos, por lo que la justificación de dichos modelos debe
efectuarse por medio de evaluaciones extensivas de carácter empírico.
Otra limitación de los enfoques heurísticos es que, como en la teoría de juegos, se
asume que los agentes conocen o saben lo que quieren. En otras palabras, los agentes tienen
una forma correcta y precisa de calcular la calidad de los resultados o soluciones de una
negociación, normalmente mediante el uso de funciones numéricas de utilidad. Este
requerimiento no puede ser siempre satisfecho, en cuyo caso se necesitan técnicas
alternativas.
3.2.4 Enfoques basados en argumentación
Los diferentes enfoques al problema de la negociación citados anteriormente se
basan en un intercambio de propuestas. Estas propuestas en general denotan un único punto
dentro del espacio de soluciones, y la única realimentación que un agente recibe con
respecto a una propuesta que ha hecho es la aceptación, el rechazo o una contrapropuesta
(Jennings, Faratin, Lomuscio, Parsons, Sierra, & Wooldridge, 2001). Los enfoques basados
en argumentación buscan añadir flexibilidad al proceso de negociación permitiendo a los
agentes intercambiar metainformación que justifique o razone sus posturas dentro de la
negociación. Esta metainformación se denomina argumento, y puede ir orientada tanto a
justificar la postura del agente que lo emite como a influir en la postura del agente que lo
recibe (Jennings, Parsons, Noriega, & Sierra, 1998a). Por ejemplo, ante una determinada
propuesta de un agente A, un agente B puede decidir rechazarla y justificar su rechazo
alegando que un atributo supera un determinado umbral. Este argumento puede hacer que el
agente A busque nuevas soluciones que satisfagan el umbral impuesto por B (reduciendo de
este modo el espacio de búsqueda). Por el contrario, puede ser que A decida hacer una
nueva propuesta que tampoco satisfaga el umbral de B, pero añadiendo a esta propuesta un
argumento con la esperanza de hacerla más atractiva para A. Los argumentos pueden ser de
muy diversos tipos (Sycara, 1989) (Kraus, Sycara, & Evenchick, 1998), pero en general
encajan en tres categorías: amenazas, recompensas y alegaciones.
La principal ventaja de la negociación basada en argumentación es la posibilidad de
que los agentes alteren sus puntos de vista como resultado de los argumentos recibidos.
Este hecho, unido al efecto reductor del espacio de búsqueda que tiene el intercambio de
metainformación, hace que se incremente la probabilidad de alcanzar un acuerdo, así como
la calidad del mismo (Buttner, 2006).
Los marcos de negociación basados en argumentación son cada vez más populares,
debido a su capacidad potencial de generar diálogos flexibles con los que definir procesos
de negociación más eficientes. El gran inconveniente sin duda alguna de estos enfoques
radica en su tremenda complejidad, mucho mayor normalmente que otros enfoques.
Requiere el diseño de complejos protocolos y lenguajes de comunicación, lenguajes de
dominio muy sofisticados, y la implementación de procesos de evaluación y generación de
argumentos que por definición son tareas que presentan gran dificultad. La implementación
práctica en escenarios de comercio electrónico reales queda todavía muy lejos, aunque se
vislumbra un gran potencial a más corto plazo en la aplicación de formas de argumentación
más básicas, como las basadas en la declaración de preferencias.
Enfoques Ventajas Desventajas
Basados en Teoría de
juegos
Solidez matemática y un carácter
analítico de sus propuestas y
resultados. Busca soluciones óptimas.
Complejidad para ser aplicada en
escenarios de negociación reales.
Asume que el espacio de soluciones
es conocido. Altos costes
computacionales.
Basados en heurística Aplicable a escenarios de negociación
reales. Bajo costes computacionales.
Soluciones subóptimas al no
explorar el espacio completo de
soluciones. Modelos carentes de
solidez matemática basados en
evaluaciones empíricas.
Basados en
argumentación
Añaden flexibilidad al proceso de
negociación permitiendo a los agentes
intercambiar información adicional
para justificar su postura o influenciar
la del otro.
Alta complejidad: protocolos y
lenguajes de comunicación
sofisticados. Dificultad en la
implementación de procesos de
evaluación y generación de
argumentos.
Tabla 1 Ventajas y desventajas de los enfoques basados en teoría de juegos, heurística y argumentación
3.2.5 Enfoques basados en restricciones difusas
Independientemente del escenario de aplicación o del tipo de técnica utilizada, el
modelado de preferencias, utilidades, o grados de satisfacción, es una componente
fundamental en cualquier sistema de negociación automática. Dado que los participantes en
una negociación desean maximizar de alguna manera su beneficio, la especificación de un
modelo de preferencias que permita interoperar con los mecanismos de decisión de los
agentes de forma eficiente es un aspecto clave (López Carmona, 2006). En este sentido los
modelos de preferencias basados en restricciones difusas se presentan como una alternativa
muy adecuada para solucionar los problemas de la formalización y representación de
preferencias. En el modelo propuesto por López Carmona (López Carmona, 2006) se
emplea la noción de restricciones difusas en su núcleo (en particular, para determinar qué
oferta debe ser enviada, si una oferta es aceptable, y que contra-oferta debe hacerse).
3.2.6 Resumen
Luego de analizar los diferentes enfoques de negociación detalladamente, optamos por
utilizar el modelo de negociación automática basado en restricciones difusas para un
ámbito municipal de compras. Esta decisión se sustenta en las siguientes razones:
1) En muchos casos, los compradores desconocen los detalles exactos del producto que
desean comprar, y más aún en un ámbito municipal donde la Oficina de Compras no
conoce sobre todas las posibles categorías de productos que le pueden ser
solicitados. Por lo tanto, sus necesidades se expresan a menudo como restricciones
sobre múltiples atributos. Por ejemplo, consideremos el caso de una solicitud a la
Oficina de Compras para la adquisición de un televisor para la visualización de
turnos en la guardia pediátrica del Hospital Municipal. Ya que el sector no es
experto en tecnología de televisores no puede comunicarle a un determinado
proveedor qué es exactamente lo que quiere, pero, naturalmente, puede expresar sus
necesidades a través de algunas restricciones (por ejemplo, un televisor de gran
tamaño, de bajo costo, y en lo posible con buena calidad de imagen).
2) Cuando los compradores y vendedores negocian, no es común el caso de que una
oferta sea completamente aceptable o completamente inconsistente con sus
respectivas restricciones. Más bien, por lo general una oferta satisface una parte de
las restricciones del comprador. Por ejemplo, una oferta del proveedor, un televisor
de 24 pulgadas a $2500, en parte puede satisfacer el requerimiento de compra,
porque aunque su tamaño no es grande, su bajo precio se ajusta a lo que se destinó
para dicha compra y hace que la oferta siga siendo igual de aceptable.
Evidentemente un televisor más grande sería más aceptable aún. Las restricciones
difusas son ideales para la captura de las limitaciones de este tipo debido a que
pueden ser parcialmente satisfechas o insatisfechas. De hecho, las limitaciones del
Sector de Compras son restricciones difusas.
3) Para un solo atributo del producto deseado, un comprador podría preferir ciertos
valores por encima de otros (por ejemplo, para el tipo de televisor, se prefiere uno
con tecnología “LED” por sobre un “LCD”). Tal preferencia se puede expresar
como una restricción difusa sobre un solo atributo, y el nivel de preferencia a un
determinado valor del atributo es el grado de satisfacción de la restricción para ese
valor. Del mismo modo, para los productos de múltiples atributos, un comprador
podría preferir ciertas combinaciones de valores por sobre otros (por ejemplo, para
el tamaño y precio de un televisor, se prefiere “grande y barato” por sobre “pequeño
y caro”). Tal preferencia se puede expresar como una restricción difusa sobre ambos
atributos, y el nivel de preferencia a un valor de cierta combinación de estos
atributos determinarse con el grado de satisfacción de la restricción para el valor de
combinación.
4) Una de las cuestiones fundamentales de la negociación es la de representar las
compensaciones (trade-offs o balances) entre los diferentes valores posibles para los
atributos. Las preferencias del comprador sobre el balance entre los diferentes
atributos del producto deseado pueden ser modeladas por restricciones difusas. Por
ejemplo, consideremos la compensación de un agente que surge de decidir si
prefiere obtener exactamente el valor deseado de un atributo que es muy importante
o un conjunto de valores no tan buenos para atributos que son menos importantes
para él. Esta compensación puede ser modelada por una restricción difusa. Por
ejemplo, volviendo al escenario de la compra de un televisor, supongamos que el
tamaño es lo más importante, haciendo que el precio y la calidad de imagen sean
atributos más flexibles. Supongamos ahora que el tamaño ideal es de 42 pulgadas, y
que el costo de $9000 y una calidad de imagen media son aceptables. Sin embargo,
si el tamaño fuera de 32 pulgadas, el precio de $4000 y una calidad de imagen muy
alta, este televisor sería todavía aceptable. Para estas combinaciones de valores de
atributos, simplemente se asigna el mismo grado de satisfacción (la restricción
difusa es sobre los atributos tamaño, el valor y la calidad de imagen). Si hay alguna
otra compensación, la preferencia de la Oficina de Compras para estos casos puede
ser modelada mediante la asignación de diferentes grados de satisfacción (el valor
más grande para el más preferible).
3.3 Resumen general
Los sistemas multiagente son una gran herramienta para el desarrollo de
negociaciones sin la intervención humana. Cada agente que compone el sistema percibe su
entorno, que para nuestro contexto de B2G puede ser la escases de algún artículo en
particular, y en base a su capacidad pro-activa poder iniciar una negociación sin recibir
orden alguna.
Cada agente inteligente componiendo un sistema multiagente debe disponer de un
mecanismo para su coordinación, y de un lenguaje que permita la comunicación entre ellos.
Existen diversos lenguajes comunicación diseñados en base a la Teoría de los actos del
habla, particularmente en las performativas (por ejemplo, informar, confirmar, prometer).
El utilizado por los agentes en las comunicaciones se llama lenguaje de comunicación del
agente (ACL). Otro componente importante para la comunicación de agentes son las
ontologías, que no son otra cosa que un acuerdo dentro de un sistema multiagente acerca de
la especificación de los conceptos utilizados. Por ejemplo, la negociación de una impresora
implica que las partes sepan qué atributos la definen, y a su vez, conocer que las páginas
por minuto se definen en unidades y el consumo eléctrico en vatios.
La plataforma elegida para implementar el sistema multiagente es JADE y sus
principales características (Bellifemine, Poggi, & Rimassa, Developing multi-agent systems
with a FIPA-compliant agent framework, Software - Practice and Experience, 31, 2001)
que motivaron su utilización son:
Plataforma de agentes distribuida. La plataforma de agentes se puede dividir
entre varios hosts. Cada uno de ellos puede ejecutar una sola aplicación Java, y
por lo tanto, una sola máquina virtual de Java. Los agentes se implementan
como hilos (threads) Java y son alojados dentro de los Contenedores de
Agentes los cuales proporcionan el soporte necesario para la ejecución de cada
agente.
Interfaz gráfica de usuario para gestionar varios agentes y contenedores desde
un host remoto.
Suporte para la ejecución de múltiples actividades de los agentes en forma
concurrente a través del modelo de comportamiento.
Plataforma de agentes compatible con el estándar FIPA, que incluye el AMS
(Sistema de Gestión de Agente), el DF (Facilitador de Directorio), y el ACC
(Canal de Comunicación de Agente). Todos estos tres componentes se activan
automáticamente en el arranque de la plataforma.
Transporte eficiente de mensajes ACL dentro de la misma plataforma de
agentes. De hecho, los mensajes se transfieren codificados como objetos Java,
en lugar de cadenas de texto, con el fin de evitar la implementación de
procedimientos de clasificación de mensajes. Al traspasar los límites de la
plataforma, el mensaje es convertido automáticamente a sintaxis compatible
con FIPA, con su codificación y su protocolo de transporte. Esta conversión es
transparente para los desarrolladores que sólo necesitan trabajar con objetos
Java.
Soporte para la definición de lenguajes de ontologías y contenido que se ajusten
a la aplicación que se está desarrollando.
El otro componente importante en la presente tesis es el modelo de negociación,
base fundamental para definir el protocolo, las estrategias, la información de estado y
equilibrio de la negociación llevada a cabo por cada agente dentro del sistema. Existen
diferentes tipos de modelos, basados en algún enfoque particular. Los modelos de
negociación basados en teoría de juegos, definidos bajo sólidos conceptos matemáticos,
busca soluciones óptimas, tornándolos complejos para su aplicación en escenarios reales.
Los basados en enfoques heurísticos son más simples de aplicar en contextos reales, pero
dejan fuera de consideración soluciones de la negociación debido al intento por reducir los
costes computacionales, por lo que el resultado final es una solución alejada de la óptima.
Los modelos de negociación basados en argumentación son una buena alternativa, ya que
su funcionamiento se sustenta en los actos del habla al intercambiar información adicional
para justificar la postura de los participantes, aportándole flexibilidad; lamentablemente
esto conlleva a una alta complejidad en la definición de los protocolos y los lenguajes de
comunicación, como así también la evaluación y generación de argumentos.
En este punto aparece un cuarto tipo de modelo basado en restricciones difusas, las
cuales se emplean para determinar qué oferta enviar, si una oferta es aceptable y que
contra-oferta efectuar. Obtiene las ventajas de los enfoques argumentados, pero
potenciándolas con la flexibilidad que aporta la utilización de restricciones difusas. En el
siguiente capítulo analizaremos en profundidad los modelos de negociación basados en
restricciones difusas.
Capítulo 4
Modelo de negociación basado en restricciones
difusas
Como mencionamos en el capítulo anterior, los modelos de negociación basados en
restricciones difusas resultan ventajosos en un ámbito de gobierno donde la definición de
los requerimientos de compra recae en personas ajenas a la especialidad del artículo a
comprar. Sumado a los beneficios de contar con negociaciones más cercanas a lo que
podría ser un diálogo real entre el Municipio y las empresas. Esto conlleva a la definición
formal del modelo y a dotar a los agentes inteligentes de una mayor capacidad expresiva.
4.1 Introducción
En el capítulo anterior analizamos los diferentes enfoques al problema de la
negociación automática y determinamos que los basados en teoría de juegos, heurística y
argumentación carecen de las virtudes necesarias para ser aplicados en un dominio de
compras en un ámbito municipal. Eso derivó en inferir como una buena opción la
utilización de un modelo de negociación automática basado en un enfoque de restricciones
difusas.
Para ejemplificar la utilización del modelo, planteamos un escenario de negociación
bilateral entre un municipio y un proveedor. Estos entablan un diálogo negociador sobre la
compra de una impresora, definida a partir de características o atributos los cuales serán
negociados a través del diálogo. La entidad compradora, en este caso el municipio, no
conoce con exactitud lo que quiere, solo tiene una idea aproximada sobre los valores de los
atributos, por lo que resulta práctica la utilización de restricciones difusas para expresar
formalmente de una manera más natural sus necesidades. El comprador expresa su deseo de
compra indicando que “quiere adquirir una impresora de alta calidad, con un alto número
de páginas por minuto impresas (PPM) y a un precio muy bajo”3. Los atributos negociables
son la calidad, el número de páginas por minuto y el precio; y a su vez, están acotados bajo
restricciones difusas, lo que implica que no existe un intervalo específico para cada uno de
ellos que determina el cumplimiento o no de las restricciones. Por contraposición, una
formulación de preferencias de compra mediante restricciones estrictas o duras (crip) sería
del tipo: “deseo una impresora con un nivel de calidad de 8 sobre 10, un valor de PPM de
entre 15 y 25, y un precio entre $400 y $800”. Para este caso se observa que una posible
negociación tendría un final por lo menos rápido, ya que las restricciones se cumplen o no.
Pero se pierde la flexibilidad que proporciona una negociación real.
El proveedor cuenta con una definición del catálogo de productos perfectamente
especificados. Dicho catálogo es flexible en el sentido de que puede ir variando tanto la
disponibilidad de los productos como sus atributos durante la negociación.
En la figura 3 se presentan las preferencias de compra del municipio. En el eje
vertical se observan los tres atributos negociables, cada uno de ellos dividido en una escala
que mide el valor difuso del atributo a través de un término lingüístico. En el eje horizontal
se determina el nivel de satisfacción que le reporta cada asignación de valores difusos a los
atributos. Así por ejemplo, partiendo de la asignación que mayor satisfacción le reporta al
comprador, en una posible concesión los atributos afectados serían la calidad y/o la
cantidad de PPM (disminuyendo en menor medida el grado de satisfacción, que si se
relajase el precio).
3 Evidentemente debe haber un acuerdo entre las partes para entender, por ejemplo, cuándo un precio es
bajo. A pesar de que las restricciones difusas están definidas por términos lingüísticos, debe existir un consenso sobre los valores aproximados que definen dicho intervalo difuso.
Figura 3 Evolución del grado de satisfacción para una entidad municipal
En la figura 4 puede observarse el catálogo de productos con que cuenta el
proveedor. Cada fila determina un producto, con los valores de sus atributos declarados
como intervalos difusos, y las utilidades que el proveedor consigue a partir de la venta de
cada uno de ellos
Figura 4 Catálogo del proveedor
Productos Calidad PPM Precio Utilidad
Impresora 3
Impresora 2
Impresora 4
Impresora 1 Muy bajoAlto
Medio
Bajo
Muy altoAltoMedio
Alto
Bajo Muy bajo
BajoMedio Alto
Bajo
Alto
Medio
A continuación se ejemplifica el funcionamiento del modelo a partir de un posible
diálogo negociador entre el municipio y el proveedor.
Figura 5 Diálogo negociador
En el diálogo, desplegado en la figura 5, observamos dos características importantes
del modelo: en primer lugar el comprador no solamente tiene capacidad de emisión de
requerimientos en forma de restricciones, sino que además, dichas restricciones se pueden
valorar de forma subjetiva; en segundo lugar el vendedor tiene la capacidad de matizar su
rechazo a ofrecer un producto, haciendo uso de locuciones que expresan preferencias de
relajación explícitas al respecto de las restricciones emitidas por el comprador. En lugar de
enfocar el proceso de negociación según la forma tradicional mediante la defensa de
posiciones, es decir, adoptando una determinada posición negociadora, se negocia sobre la
Comprador Vendedor
Quiero:
PPM Precio
Muy altoMuy alto Muy bajo
Calidad
Más importante
¿Puede relajar la calidad o el PPM?
Quiero:
PPM Precio
AltoMuy alto Muy bajo
Calidad
Más importante
¿Nuevamente puede relajar la calidad o el PPM?
Quiero:
PPM Precio
AltoAlto Muy bajo
Calidad
Más importante
¿Puede relajar el PPM o el precio?
Más importante
Quiero:
PPM Precio
AltoAlto Bajo
Calidad
¿Puede relajar el PPM?
Más importante
Quiero:
PPM Precio
MedioAlto Bajo
Calidad
Le vendo la Impresora 2
Más importante
1
2
3
4
Atributo degradado
Atributo más importante
base de los intereses de las partes, intereses que subyacen a las posiciones que las mismas
suelen adoptar en el proceso de negociación (López Carmona, 2006). Analicemos ahora el
curso del diálogo.
1. La primera propuesta del comprador es la que subjetivamente le podría reportar
mayor satisfacción. La propuesta está definida como un conjunto de restricciones
duras extraídas del requerimiento original del comprador en donde se expresa como
restricciones difusas. La restricción Muy bajo para el precio remite una importancia
debido a que una relajación del mismo provoca un mayor decremento en el grado de
satisfacción para el comprador. Esto se puede observar en la figura 3 en donde
decrementar la calidad o el PPM no tienen el mismo impacto en el nivel de
satisfacción como lo tiene el precio. A partir del catálogo del vendedor vemos que
no cuenta con un producto que satisfaga todas las restricciones. Sin embargo,
argumenta el rechazo con una contra propuesta basada en preferencias.
Evidentemente el vendedor no conoce cuál es el o los atributos más importantes
para el comprador, por lo tanto su propuesta de relajación se basa en criterios como
podría ser la “cercanía” de la propuesta de compra a algún producto con el que
cuente, entre otros criterios.
2. La segunda propuesta del comprador ha implicado la relajación de la restricción de
PPM. Dado que el vendedor no tenía una preferencia expresa porque se relajase una
restricción más que otra, el comprador opta por relajar una de las restricciones que
menor pérdida de satisfacción comporta (calidad o PPM) de forma aleatoria. La
restricción precio sigue siendo la más importante por el mismo motivo que en el
caso anterior: una relajación de Muy bajo a Bajo produce una baja considerable en
el nivel de satisfacción para el comprador. El vendedor de acuerdo a sus
preferencias vuelve a solicitarle la relajación de una de las restricciones de calidad o
PPM.
3. En la tercera parte del diálogo el comprador relaja la restricción de calidad. Esta
nueva propuesta determina un razonamiento por parte del vendedor que vale la pena
analizar. Como puede observarse en el catálogo existen dos productos que se
acercan a los requerimientos de la propuesta: la impresora 1 y 2. Ambos reportan
utilidades aceptables. Para lograr un mayor acercamiento, la restricción a relajar
debería ser la de PPM o la de precio.
4. En la cuarta propuesta del comprador la restricción relajada fue la de precio, y
resulta lógico debido a que la de PPM era una de las restricciones importantes junto
con la de calidad. En este punto el vendedor determina una gran proximidad a la
impresora 2, por lo tanto rechaza la propuesta solicitando una relajación de la
restricción de PPM.
5. El comprador, tras recibir la propuesta de relajación, se encuentra con que a priori,
no tendría inconveniente en relajar la restricción de PPM. El vendedor dispone de
un producto que sí cumple los requisitos actuales: la impresora 2. La negociación
termina satisfactoriamente.
Una vez analizado el ejemplo, intuimos que la utilidad de este tipo de aproximación
al problema de la negociación bilateral puede encontrarse también de forma muy concreta
en escenarios de comercio electrónico dinámicos, donde los modelos de preferencias de
compradores y vendedores se vean modificados incluso durante el propio curso de la
negociación. El hecho de incluir en la comunicación metainformación referente a las
preferencias parciales de los participantes, puede permitir que en el transcurso de la
negociación, ésta se pueda reconducir hacia zonas del espacio de negociación donde
aparezcan las nuevas intersecciones.
4.2 Modelo de preferencias del comprador y vendedor
Según la teoría de marketing la preferencia de un comprador por un producto será
función del valor que tome cada uno de sus atributos, y evidentemente, de la interpretación
subjetiva que el comprador haga de ese valor. Además, cada consumidor asignará una
importancia relativa a cada uno de los atributos. La decisión de compra de un consumidor
puede ser modelada por tanto como una función de diferentes combinaciones de atributos
(Keeny & Raiffa, 1976).
Los modelos de toma de decisiones de compra asumen que el proceso exhaustivo de
evaluación de productos se lleva a cabo sobre un subconjunto reducido denominado
conjunto de consideración (Hauser & Wernerfelt, 1990). Este conjunto de consideración se
entiende como aquel conjunto de productos que superan los umbrales predefinidos para uno
o más atributos. Estos umbrales son los mínimos requisitos que todo producto debe cumplir
para que sea tenido en consideración a la hora de pasar a la fase de selección del producto
preferido. Estos atributos que tienen definidos unos umbrales mínimos para la inclusión en
el conjunto de consideración se denominan no compensatorios. Esto significa que un valor
por debajo del umbral no puede compensarse con valores de otros atributos.
Se distinguen dos enfoques fundamentales en la definición de un modelo de
preferencias para un comprador: por un lado la división del proceso de extracción de
preferencias en dos fases, una de inclusión y otra de selección, y por el otro la fusión de las
dos fases en una mediante la adaptación de los umbrales de inclusión en el modelo de
decisión compensatorio. El primero requeriría de un diálogo previo que estableciese los
criterios de inclusión de forma explícita. De esta forma el diálogo excluiría
automáticamente aquellos productos no pertenecientes al conjunto de consideración. El
segundo enfoque no requiere de un diálogo previo porque los criterios de inclusión están
implícitos en el modelo de preferencias único, y son aplicables durante todo el proceso
negociador. En el modelo de negociación utilizado se optó por aplicar este segundo enfoque
en base a que la primera alternativa es trivial en cuanto a la declaración explícita de
criterios de inclusión; y además porque utilizar argumentación permite que la valoración
subjetiva de los atributos sea declarada de forma explícita, lo que puede permitir que un
atributo sea tenido en cuenta por el vendedor como un criterio de inclusión.
El modelo de decisión del vendedor es más sencillo que el modelo del comprador, a
efectos de declaración de preferencias. Cada agente vendedor dispone de un conjunto
variable de productos que desea vender. Cada uno de los productos está definido por un
conjunto de atributos, separados en atributos visibles y no visibles. Un atributo es visible si
es negociable, es decir, pertenece al espacio de negociación. Un atributo es no visible, si no
es negociable. Tanto los atributos visibles como los no visibles pueden influir en la
percepción del vendedor acerca de la preferencia que tenga por realizar una venta concreta
en un determinado momento. Esta preferencia se va a modelar como una función de
utilidad que no tiene por qué ser invariable ni en el tiempo ni para cada producto. Esto
último significa que de forma determinista el vendedor podría asignar a un producto una
cierta utilidad independientemente de las utilidades de otros productos atendiendo a
cualquier criterio. La idea de aplicar estas suposiciones es permitir la definición de un
catálogo tan flexible como se quiera. Por último hay que dejar claro que el precio no tiene
por qué ser el único criterio de utilidad, es decir, la venta de un producto muy caro no tiene
por qué implicar una utilidad mayor. Incluso la utilidad no tiene por qué estar asociada a los
atributos del producto.
4.3 Problemas de satisfacción de restricciones (CSP)
El núcleo de los modelos de preferencias del comprador y vendedor consta de
definiciones formales que permiten describir su funcionamiento. A continuación
describimos los problemas de satisfacción de restricciones (CSP) como un paso previo a la
definición de los problemas de satisfacción de restricciones difusas (FCSP).
Definición 4.3.1. Un problema de satisfacción de restricciones o constraint satisfaction
problem (CSP) (Yokoo, 2001) es una tupla (X, D, C), donde:
1. nixX i ,...,1 es un conjunto finito de variables.
2. nidD i ,...,1 es un conjunto de dominios. Cada dominio di es un conjunto
finito que contiene los posibles valores para las correspondientes variables xi en X.
3.
)Rvar(x jii
ij
m,...,i,dRRC 1 es un conjunto de restricciones. En este caso
var(Ri) define el conjunto de variables incluidas en una determinada restricción Ri:
Xx,...,xRvar '
k
'
iiR 1
Definición 4.3.2. Una etiqueta de una variable x es una asignación de un valor a la
variable, llamada vx. Una etiqueta compuesta vX´ de todas las variables del conjunto
Xx,...,xX '
n
'' 1 es una asignación simultánea de valores a todas las variables del
conjunto X´:
''1
,...,'
nxxX vvv
Definición 4.3.3. En un CSP(X, D, C), la función característica de Ri C,
1,0:
var ij Rx
jRi d , se define como:
.restoel
,Rvsiv
i)Rvar(
)Rvar(R
i
ii 0
1
Una solución al CSP(X, D, C) es una etiqueta compuesta vX = (vx1,..., vxn) de todas
las variables en X tal que:
1 )Rvar(Ri iiv,CR
En definitiva, una restricción sólo permite dos posibilidades, que esta se cumpla o
que no se cumpla. Una solución debe satisfacer todas las restricciones. Sin embargo, esta
representación de restricciones es excesivamente rígida. Este es el motivo por el que se
introduce el CSP difuso (Dubois, Fargier, & Prade, 1994).
4.4 Problema de satisfacción de restricciones difusas (FCSP)
Como mencionamos en la sección anterior, un problema de satisfacción de
restricciones es un enfoque muy rígido, en el sentido de que una solución debe cumplir
todas las restricciones. Para flexibilizar esta representación aparece el concepto de
problemas de satisfacción de restricciones difusas (FCSP). A continuación presentamos su
definición.
Definición 4.4.1. Un problema de satisfacción de restricciones difusas o fuzzy
constraint satisfaction problem (FCSP) es una tupla (X,D,Cf), donde X y D son los mismos
que para el caso de los CSP, y Cf es un conjunto de restricciones difusas:
midRC fiji
f
Rx jRi
f ,...,1,1,0:)var(
f
donde )var( f
iR designa el conjunto de variables incluidas en f
iR.
Utilizando una técnica de corte de matemática difusa (Klir & Yuan, 1995), una
restricción difusa puede incluir una restricción dura.
Definición 4.4.2 (Nivel de corte y extracción de una restricción dura) Dado un
nivel de corte 1,0 , la extracción de una restricción dura Rc a partir de una restricción
difusa Rf implica que:
.restoel
,Rvarsiv
f
R
)Rvar(R
f
fc
0
1
Este nivel de corte no es más por tanto que un umbral. Si el nivel de satisfacción
sobrepasa este umbral, la solución es satisfactoria.
Finalmente es necesario definir una medida de satisfacción global de las
restricciones, dada una etiqueta compuesta.
4.4.3 Definición (Grado de satisfacción global) El grado de satisfacción global de
una etiqueta compuesta vX se define como:
ff
XRX CRvv f )(
donde es un operador de agregación de [0,1]n a [0,1].
El operador que hemos utilizado en la presente tesis es min.
4.5 Conocimiento del dominio de los agentes
A continuación se presentan las conceptualizaciones de los agentes comprador y
vendedor basadas en la definición de un conjunto de requerimientos genéricos que se van a
plasmar en un modelo de requerimientos. Este desarrollo se fundamenta a partir de la tesis
doctoral de López Carmona (López Carmona, 2006). En dicho trabajo, a modo
experimental, introduce el concepto de perfil del agente. Agentes comprador y vendedor
cuentan con dicho perfil, que a su vez se divide en perfil expresivo y perfil receptivo. La
configuración de estos perfiles permite observar la contribución de un marco de
negociación automática basado en argumentación, respecto del no argumentado (o
inexpresivo). No intentaremos desarrollar un estudio exhaustivo sobre ambos modelos, por
lo tanto optamos por instanciar un marco de negociación automática expresivo. De todas
formas, en la presentación de los conceptos subsiguientes, se mencionan dichos perfiles a
modo de demostrar la flexibilidad del modelo.
4.5.1 Conocimiento del dominio del agente comprador
Como se mencionó en gran parte de la tesis, es de suma importancia la extracción
de preferencias de los agentes negociadores, y la formalización de dichas preferencias. Esto
concluyó en que un modelo de definición de preferencias basado en restricciones difusas
era muy conveniente para el caso de un agente comprador. En este sentido, uno de los
aspectos fundamentales en la definición de un modelo de requerimientos es el que trata la
descripción de preferencias, teniendo en cuenta que en base a esas preferencias el agente
comprador interacciona conforme a una estrategia para conseguir los objetivos,
normalmente la maximización de sus preferencias. Al mismo tiempo se extiende el
concepto de preferencia al ámbito de la actitud frente al oponente, con el objeto de
conseguir un modelo de negociación más general. Se define a continuación el ámbito de
conocimiento básico de un agente comprador, como un modelo de requerimientos basado
en un modelo de preferencias sobre los atributos de productos, y un modelo de actitud o
perfil negociador.
Definición 4.5.1.1 (Modelo de requerimientos de un comprador) El modelo de
requerimientos de un comprador es definido como Breq = (F,Nb), donde F = (X, D, Cf) es un
FCSP que describe el modelo de preferencias sobre los atributos de productos, tal que X es
un conjunto de atributos de un producto, D es el conjunto de dominios de los atributos, y Cf
es un conjunto de restricciones difusas que expresan los requerimientos sobre los atributos.
,Nb es el perfil negociador del comprador mencionado anteriormente, donde
10, representa el perfil expresivo (argumenta o no las propuestas emitidas) del agente,
y 10, representa el perfil receptivo (modula la importancia que van a tener en los
procesos de decisión los argumentos del vendedor). A fin de otorgarle al agente comprador
la mayor expresividad posible, ambos valores toman un valor de 1.
La funcionalidad del modelo de preferencias es doble, por una parte permite
calcular la satisfacción que le reporta a un comprador la adquisición de un determinado
producto, y por otra permite disponer de una fuente de información a partir de la cual
generar peticiones de compra basadas en la maximización de la utilidad subjetiva. En base
a esta funcionalidad, por otra parte imprescindible en un agente de compra, se presentarán
una serie de definiciones derivadas que son piezas clave en el ámbito operativo del agente.
En primer lugar vamos a formalizar la evaluación del grado de satisfacción que obtiene un
comprador con un producto, y en segundo lugar se señalará el concepto de requerimiento
de compra y la evaluación del grado de satisfacción que puede obtener un comprador a
partir de un requerimiento de compra.
Definición 4.5.1.2. (Grado de satisfacción global para un producto) Dado un
modelo de preferencias F de un comprador, el grado de satisfacción global para un
producto pk = (a1,..., an), donde aj representa el valor del atributo j, viene dado por la
ecuación descrita en la definición 4.4.3 del cálculo del grado de satisfacción global de una
etiqueta compuesta.
ff
XRX CRvv f )(
En este caso el producto pk es equivalente a la etiqueta compuesta, de manera que el
grado de satisfacción global será función del grado de cumplimiento de las funciones
características de cada una de las restricciones definidas en F. Como mencionamos
anteriormente, el operador utilizado para la presente tesis es min, por lo tanto, de todos esos
grados de cumplimientos generados, el grado de satisfacción global será definido por aquel
cuyo valor sea mínimo.
Definición 4.5.1.3. (Requerimiento de compra) Sea ic
iR una restricción dura
extraída a partir de la restricción difusa m...,,iCR ff
i 1 a un nivel de corte i , un
requerimiento de compra se define como una proposición:
m...,,kCR...,,R j
fc
k
c
kBik
i
k
req11
1
Esto significa que un requerimiento de compra es una proposición que enlaza un
conjunto de restricciones duras mediante operadores lógicos4. Estas restricciones duras se
extraen de sus correspondientes restricciones difusas a niveles de corte independientes. El
requerimiento de compra podrá estar formado por un subconjunto o por el conjunto de
restricciones difusas definidas en el modelo de preferencias.
Definición 4.5.1.4. (Grado de satisfacción global potencial de un requerimiento
de compra) Dado un requerimiento de comprareqB , el grado de satisfacción global que un
comprador puede alcanzar si dicho requerimiento es satisfecho por el vendedor, es el
denominado grado de satisfacción global potencial, que se define como:
m...,,iireqB
1
4 Cabe aclarar que aunque el operador definido es una “y lógica”, también sería factible por ejemplo la aplicación de una “o lógica” , o una combinación de operadores lógicos distintos. La selección de un operador u otro debe ser función del operador utilizado en el cálculo de satisfacción global (ver ecuación de la definición 4.4.3).
donde el operador es el operador utilizado en la ecuación descripta en la definición 4.4.3
para el cálculo del grado de satisfacción global, y i representa el nivel de corte aplicado a
la restricción f
iR para la generación del requerimiento de compra. El operador aplicado es
min, por lo que el grado de satisfacción global potencial representa el mínimo valor de corte
aplicado a la restricción f
iR .
Es importante puntualizar que mientras un requerimiento de compra no tiene por
qué incluir un extracto de todas las restricciones difusas, el cálculo de la satisfacción
potencial de un requerimiento de compra requiere el cálculo del grado de cumplimiento de
todas las restricciones. Recordemos que un requerimiento de compra está formado por
restricciones duras que se extraen de un subconjunto o el conjunto completo de las
restricciones difusas definidas, es decir, un comprador puede enviar un requerimiento muy
vago donde sólo se envíe información al respecto de una o dos restricciones por ejemplo.
Sin embargo, independientemente de la emisión del requerimiento y en definitiva de lo que
se haya querido expresar en la locución enviada a un vendedor, un producto ofertado por el
vendedor debe satisfacer no sólo las restricciones enviadas, sino todas aquellas que
localmente determinan el grado de satisfacción deseado. Esto significa que deben tenerse
en cuenta los cortes aplicados a las restricciones difusas, aunque dichas restricciones no
sean incluidas en el requerimiento de compra.
Definición 4.5.1.5. (Valoración de requerimiento de compra) Dado un requerimiento de
compra reqB , se define la valoración de un requerimiento de compra como un vector:
m...,,k,,vv...,,vv jkkkB jireq110
1
donde jkv expresa la preferencia que el comprador tiene por que la restricción kj sea
satisfecha. 1jkv define el mayor grado de preferencia, y 0
jkv el menor.
Cabe aclarar que con esta definición, no se asume que una expresión de preferencia
tenga que ser verdadera. Es decir, el agente comprador puede mentir acerca de sus
preferencias reales.
Con las herramientas definidas hasta este punto, un agente comprador sería capaz de
describir la sintaxis de un requerimiento de compra, de evaluar una oferta concreta de un
vendedor y calcular el grado de satisfacción que obtendría con la compra, de calcular el
grado de satisfacción que obtendría con una oferta que se ajustase a un requerimiento de
compra concreto y, por último, de valorar requerimientos de compra.
4.5.2 Conocimiento del dominio del agente vendedor
El ámbito de conocimiento básico de un agente vendedor es el modelo de
requerimientos que se define a continuación:
Definición 4.5.2.1. (Modelo de requerimientos de un vendedor) El modelo de
requerimientos de un vendedor se define como Sreq = (S,Ns), donde S representa el catálogo
de productos del vendedor, y Ns define el perfil negociador del vendedor. El catálogo de
productos se especifica de la siguiente manera:
kjaapupssSnjjjjjjj 0,...,,,,
1
donde sj representa una entrada en el catálogo de productos, pj es un vector de atributos del
producto, y uj asigna un valor de utilidad a la venta de un producto pj . k define el número
total de productos en el catálogo. El perfil negociador del vendedor es definido por la tupla:
tSN ,,
donde 1,0 representa el perfil expresivo (argumenta o no las propuestas emitidas) del
agente, y 1,0 representa el perfil receptivo (modula la importancia que van a tener en
los procesos de decisión los argumentos procedentes de un comprador). De igual modo que
en el comprador, a fin de otorgarle al agente vendedor la mayor expresividad posible,
ambos valores toman un valor de 1. t representa el conjunto de creencias del agente
vendedor. Este conjunto se define como:
mit
i
t
i
t ...,,1,,
donde t
i representa la creencia en el instante t acerca de la estrategia de relajación utilizada
por el comprador al respecto de la restricción difusa Ri, y 1,0t
i , es el grado de
certidumbre acerca de la creencia t
i .
El catálogo de productos del vendedor es dinámico en un doble sentido. En primer
lugar se asume que el número de productos del catálogo no es estático, es decir, incluso
durante una negociación pueden aparecer o desaparecer productos. En segundo lugar, para
un conjunto definido de productos, las utilidades asignadas uj pueden verse modificadas por
factores externos.
Con las herramientas definidas hasta este punto, un agente vendedor sería capaz de
describir la sintaxis de una oferta:
Definición 4.5.2.2. (Oferta de venta) Una oferta de venta está definida por un
producto pj del catálogo sj.
Podría además evaluar el grado de satisfacción que obtendría con la venta, a partir
de la utilidad asignada uj. Sin embargo, cubriendo solamente estos aspectos, no se está
habilitando al vendedor para que pueda expresar su valoración acerca de la no
disponibilidad de una oferta adecuada, conforme a un requerimiento de compra recibido. Es
decir, el único tipo de diálogo que podría entablar sería inexpresivo. Para dotar a un agente
vendedor de la capacidad expresiva suficiente para valorar la no disponibilidad de ofertas,
se define a continuación el concepto de requerimiento de relajación:
Definición 4.5.2.3. (Requerimiento de relajación) Dado un requerimiento de compra
reqB , se define un requerimiento de relajación como un vector:
mkrrr jkkkB jireq...,,1,1,0...,,
1
donde jkr expresa la preferencia que el vendedor tiene por que la restricción kj sea relajada.
1jkr define el mayor grado de preferencia, y 0
jkr el menor.
Al igual que en la valoración de un requerimiento de compra, con esta definición,
no se asume que una expresión de preferencia tenga que ser verdadera, y la graduación de
preferencias sigue siendo arbitraria. Por último, esta definición tampoco entra en aspectos
tales como qué criterios aplica el vendedor para valorar los requerimientos de relajación,
que entrarían dentro de la definición de los mecanismos de decisión.
4.6. Modelo de diálogo de alto nivel
Habiendo hecho una introducción a los conceptos que definen el modelo de
negociación basado en restricciones difusas, expondremos los mecanismos de decisión de
ambos agentes.
A continuación se presenta el modelo de alto nivel para los diálogos de negociación
entre compradores y vendedores en una transacción de compraventa. Todo diálogo está
restringido a dos agentes, uno comprador (en nuestro caso el Municipio) y otro vendedor
(un proveedor en particular), de manera que los diálogos son exclusivamente bilaterales.
Esto no significa que ambos agentes no puedan mantener en paralelo diálogos con otros
compradores y vendedores, pero serán en cualquier caso diálogos diferentes.
Un diálogo está estructurado en fases según la siguiente lista:
1. Apertura del diálogo: el diálogo comienza.
2. Negociación: esta fase está definida por una secuencia de interacciones. Dichas
interacciones se enumeran a continuación:
Un comprador:
o Emite requerimientos de compra.
o Emite valoraciones de requerimientos de compra.
o Rechaza ofertas de venta.
Un vendedor:
o Emite ofertas de venta.
o Rechaza requerimientos de compra.
o Propone la relajación de los requerimientos de compra.
o Rechaza compromisos de compra.
3. Confirmación: los participantes comprometen y confirman un acuerdo.
4. Cierre del diálogo: el diálogo termina.
Cabe señalar que dicho diálogo está sujeto a las siguientes reglas:
La primera fase en todo diálogo es Apertura del diálogo.
Las fases Apertura y Cierre del diálogo sólo pueden ocurrir una vez en todo
diálogo.
Las únicas fases que deben aparecer en todo diálogo que termina normalmente son
Apertura y Cierre del diálogo.
La fase de Confirmación requiere que previamente se haya pasado por la fase de
Negociación.
La última fase de todo diálogo que termina normalmente es Cierre del diálogo.
Los participantes pueden conmutar entre las fases de Negociación y Confirmación,
sujetos sólo a las reglas y restricciones definidas por las reglas de combinación de
locuciones.
4.7 Mecanismos de decisión y locuciones
Es imprescindible equipar a cada participante con los mecanismos que permitan
invocar determinadas locuciones en el momento adecuado, como respuesta a locuciones
pasadas, o como anticipo de futuras locuciones. A este tipo de mecanismos se los denomina
mecanismos de decisión semánticos. A continuación presentamos una lista completa de
todos los mecanismos de decisión semánticos que van a permitir la generación de diálogos
automáticos entre un comprador y un vendedor, con el objeto negociar la compra de un
producto de categoría , conforme al conjunto de locuciones definidas. Los mecanismos se
van a agrupar en función del rol de participante: Comprador (B) o Vendedor (S). Para cada
mecanismo se van a describir sus directrices generales, y a continuación se van a detallar
sus funcionalidades específicas. Además, se especifican las salidas generadas por el
mecanismo. La información relativa al número de veces que un producto ha sido ofertado
se encuentra en el Almacén de información del vendedor AI(Ps).
4.7.1 Mecanismos de decisión del agente comprador
B1: Recognize Need
Permite que un agente comprador reconozca la necesidad de adquirir un producto.
Dicho reconocimiento es consecuencia de la iniciativa explícita de un usuario el cual a
través de una interfaz da la orden a su agente personal de su intención de adquirir un
producto5. El propósito final del mecanismo es la inicialización de un diálogo negociador
con un vendedor. Sin embargo, el reconocimiento de una necesidad de compra no significa
que el proceso de negociación pueda llevarse a cabo inmediatamente, por ejemplo, porque
no haya vendedores adecuados con los que ponerse en contacto. En este último caso el
mecanismo indica que se encuentra en un estado de espera o wait. Cuando se identifica la
necesidad, y además se interpreta que la inicialización de un diálogo es factible, la salida
del mecanismo es have_need( ).
Salidas: wait, have_need( ), donde define una categoría de producto.
Este mecanismo emite la locución L1: open_dialogue(.).
L1: open_dialogue(.)
Locución open_dialogue(Pb, Ps, )
Precondiciones Esta locución no debe haber sido emitida previamente. El comprador Pb debe
tener la necesidad de adquirir un producto en la categoría .
Significado El comprador Pb sugiere la apertura de un diálogo negociador con el vendedor
Ps sobre productos de la categoría . Un diálogo siempre debe comenzar con
esta locución. Se asume que la identidad del vendedor Ps es conocida, por lo
que esta locución no implica una búsqueda de un destinatario.
Respuesta El vendedor Ps debe responder con enter_dialogue(Ps, Pb, ) si desea
participar en dicho diálogo.
Actualización AI No se produce actualización.
Tabla 2 Detalle de la locución L1: open_dialogue(.)
B2: Generate Purchase Requirement
Este mecanismo responde a la necesidad de un agente comprador de generar
requerimientos de compra. Cualquier requerimiento de compra es compatible con la
locución prefer_to_buy(.). El mecanismo además prevé la imposibilidad de generar el
requerimiento. Así, se identifican dos posibles salidas, la que describe la imposibilidad de
5 También podría reconocerse a partir de un proceso basado en umbrales que se dispare automáticamente (p.ej. cuando un agente personal detecta que se encuentra en las cercanías de un mercado electrónico que ofrece un determinado tipo de productos, y dichos productos se encuentran dentro de las preferencias del usuario propietario del agente personal)
generar un requerimiento, y la que especifica un requerimiento concreto generado. La
imposibilidad se formaliza mediante un conjunto vacío o empty_set .
Salidas: empty_set , reqB
Según el modelo de preferencias del comprador descrito en la definición 4.5.1.1, un
FCSP modela dichas preferencias. Un requerimiento de compra (ver definición 4.5.1.3) se
define como una proposición formada por un conjunto de restricciones duras unidas por
operadores lógicos, extraídas del FCSP a determinados niveles de corte. Se especifica
además que un requerimiento de compra no tiene por qué incluir todas las restricciones
difusas definidas en el FCSP, de manera que el agente comprador puede extraer dichas
restricciones de forma estratégica. La estrategia de extracción de restricciones duras tiene
por tanto una implicación directa en la forma que toma el requerimiento de compra, y de
manera indirecta, en la satisfacción global potencial (ver definición 4.5.1.4) que espera
como mínimo obtener el comprador. Teniendo en cuenta que un agente racional intentará
maximizar su utilidad, la o las estrategias del comprador al respecto de la generación de
requerimientos de compra estarán centradas en la gestión adecuada del grado de
satisfacción global potencial.
Existen dos formas de composición de un nuevo requerimiento de compra:
1. Incorporación de una nueva restricción difusa, mediante la extracción de la
correspondiente restricción dura. Está pensada para dos situaciones concretas: el
inicio de la negociación, cuando se debe preparar el primer requerimiento de
compra, y durante la negociación, tras una oferta de venta que no satisface las
restricciones duras no incluidas en el requerimiento de compra. Este proceso de
reenvío de requerimientos repetidos estará limitado por un umbral predeterminado.
Una vez superado el umbral se deberá seleccionar aleatoriamente una restricción de
entre aquellas no incluidas en el requerimiento de compra y que no han sido
satisfechas por las ofertas de venta. El objetivo es conducir al vendedor hacia una
oferta de venta correcta, pero minimizando la cantidad de información revelada.
2. Modificación del requerimiento de compra previo sin incorporación de nuevas
restricciones difusas. Está pensada para una situación concreta: la emisión durante
la negociación por parte del vendedor de las locuciones prefer_to_sell(.) o
refuse_to_sell(.), destinadas a expresar su rechazo a satisfacer el requerimiento del
comprador.
B3: Generate Purchase Requirement Valuation
Este mecanismo permite generar un argumento de valoración de un requerimiento
de compra todavía no enviado, es decir, una valoración de requerimiento de compra reqBv .
Ésta podrá ser comunicada mediante la locución prefer_to_buy(.).
Salidas: reqBv
Como se introdujo en la definición 4.5.1.5, una valoración de requerimiento de
compra pretende ser una expresión de la importancia relativa que tiene para el comprador el
cumplimiento de cada una de las restricciones que componen un requerimiento de compra,
o cuando menos, es lo que el comprador quiere hacer creer. Indirectamente el comprador
está indicando qué restricciones preferiría relajar, que serán evidentemente aquellas menos
prioritarias. Aparentemente, el vendedor podría actuar estratégicamente y esperar a que el
comprador relajase más sus requerimientos, teniendo en cuenta que están priorizados e
indican una disposición del comprador por relajar. Sin embargo, nada le garantiza al
vendedor que el comprador consiga una solución satisfactoria con otro vendedor
(suponiendo que existe algún mecanismo externo que es capaz de garantizar esto).
Este mecanismo emite la locución L6: prefer_to_buy(.).
L6: prefer_to_buy(.)
Locución prefer_to_buy(Pb, Ps, reqB ,
reqBv ).
Precondiciones No hay precondiciones.
Significado El agente comprador Pb le indica al vendedor Ps, su deseo de adquirir un
producto que satisfaga el requerimiento de compra reqB , y expresa sus
preferencias en cuanto a la importancia relativa que tienen las restricciones
incluidas en el requerimiento de compra mediante la valoración de
requerimiento de comprareqBv .
Respuesta No se requiere.
Actualización AI Se almacena en un registro el requerimiento de compra reqB .
Tabla 3 Detalle de la locución L6: prefer_to_buy(.)
B4: Consider Offers
Este mecanismo responde a la necesidad que tiene un agente comprador de decidir
en un determinado momento si: aceptar la oferta de venta propuesta por un agente
vendedor, rechazar la oferta de venta propuesta, o generar un nuevo requerimiento de
compra. Enviado un requerimiento de compra t
Breq , un agente comprador acepta una oferta
de venta pj cuando el grado de satisfacción global )( jp (ver definición 4.5.1.2) es mayor
o igual que el grado de satisfacción global potencial del requerimiento de compra 1t
Breq . Esto
es así porque desde que se emite un requerimiento, hasta que se recibe una oferta de venta,
pueden verse modificadas las preferencias del vendedor, de manera que 1t
Breq va a capturar
las necesidades reales actuales del agente comprador. En este caso el mecanismo retorna
accept_offer(pj). La aceptación de una oferta desemboca en una fase de diálogo de
confirmación de la oferta. Si una oferta de venta no se puede aceptar, y dicha oferta no
satisface las restricciones enviadas en t
Breq , el mecanismo retorna reject_offer(pj) indicando
que se debe generar una expresión de rechazo. Finalmente, si la oferta de venta no puede
ser aceptada, pero satisface las restricciones enviadas en t
Breq , el mecanismo retorna
generate_purchase_requirement(pj), indicando que se debe generar un nuevo requerimiento
de compra.
Salidas: accept_offer(pj), reject_offer (pj), generate_purchase_requirement(pj), donde pj es
una oferta de venta.
Las locuciones que emite este mecanismo son L7: refuse_to_buy(.) y L9:
agree_to_buy(.).
L7: refuse_to_buy(.)
Locución refuse_to_buy(Pb, Ps, pj)
Precondiciones No puede ser emitida tras agree_to_buy (Pb, Ps, pj).
Significado El agente comprador Pb expresa su rechazo a la compra de un producto
pj.
Respuesta No se requiere.
Actualización AI No se actualiza.
Tabla 4 Detalle de la locución L7: refuse_to_buy(.)
L9: agree_to_buy(.)
Locución agree_to_buy(Pb, Ps, pj).
Precondiciones Esta locución es siempre una respuesta a willing_to_sell(Ps, Pb, pj).
Significado El agente comprador Pb dirigiéndose al agente vendedor Ps se compromete a
comprar el producto pj.
Respuesta Si el agente vendedor Ps desea vender el producto pj, puede responder con la
locución agree_to_sell(Ps, Pb, pj).
Actualización AI Se almacena en un registro el compromiso de compra pj.
Tabla 5 Detalle de la locución L9: agree_to_buy(.)
B5: Consider Withdrawal
Este mecanismo responde a la necesidad que tiene un agente comprador de decidir
en un determinado momento si debe finalizar el diálogo con un vendedor. El mecanismo
puede permanecer en estado de espera, retornará entonces wait, o indicar que se debe
abandonar el diálogo, en cuyo caso retornará withdraw( ).
Salidas: wait, withdraw( )
La locución emitida por el mecanismo es L11: withdraw_dialogue(.).
L11: withdraw_dialogue(.)
Locución withdraw_dialogue(Px, Py, _), donde Px and Py son participantes con
diferentes roles, es decir, compradores o vendedores.
Precondiciones Esta locución puede emitirse en cualquier momento tras la apertura del diálogo.
Significado Un agente Px anuncia al agente Py que abandona el diálogo de negociación de
compra de productos de la categoría .
Respuesta No se requiere.
Actualización AI No se actualiza.
Tabla 6 Detalle de la locución L11: withdraw_dialogue(.)
4.7.2 Mecanismos de decisión del agente vendedor
S1: Recognize Category
Permite que un agente comprador reconozca la necesidad de vender un producto. El
mecanismo simplemente asegura que el agente vendedor dispone de productos de la
categoría en su catálogo. Si se dispone de productos el mecanismo retorna
wish_to_enter( ), y si no wish_not_to_enter( ). El mecanismo puede permanecer a la
espera, retornando entonces wait.
Salidas: wait, wish_to_enter( ), wish_not_to_enter( )
La locución emitida por este mecanismo es L2: enter_dialogue(.).
L2: enter_dialogue(.)
Locución enter_dialogue(Ps, Pb, ).
Precondiciones El comprador Pb debe haber emitido open_dialogue(Pb, Ps, ). Ps debe tener
la necesidad de vender productos de la categoría especificada .
Significado El agente vendedor Ps indica su deseo de incorporarse a un diálogo de
negociación de compra sobre productos de la categoría con el comprador Pb.
Respuesta No se requiere.
Actualización AI No se produce actualización.
Tabla 7 Detalle de la locución L2: enter_dialogue(.)
S2: Assess Purchase_Requirement
Este mecanismo responde a la necesidad del agente vendedor de valorar
requerimientos de compra. El objetivo central de una valoración será detectar la existencia
de productos en el catálogo que satisfagan dichos requerimientos de compra. Si no se
encuentran productos, el mecanismo decidirá argumentar el rechazo al requerimiento de
compra recibido. Cuando existe una oferta de venta el mecanismo retorna sale_offer(pj), en
caso contrario se argumenta el requerimiento de compra devolviendo
purchase_requirement( t
Breq ).
Salidas: purchase_requirement( t
Breq ), sale_offer(pj)
La locución que emite este mecanismo es L3: willing_to_sell(.).
L3: willing_to_sell(.)
Locución willing_to_sell(Ps, Pb, pj).
Precondiciones Un comprador debe emitir una locución prefer_to_buy (Pb, Ps,reqB ,
reqBv )
donde pj debe satisfacer el requerimiento de compra reqB .
Significado El vendedor Ps le indica al comprador Pb su deseo de vender un producto pj que
satisface el requerimiento de compra reqB recibido anteriormente mediante la
locución prefer_to_buy (Pb, Ps,reqB ,
reqBv ).
Respuesta No se requiere.
Actualización AI Se almacena en un registro la oferta de venta pj.
Tabla 8 Detalle de la locución L3: willing_to_sell(.)
S3: Generate Potential Sale-Offers
Este mecanismo de generación de ofertas de venta potenciales responde a la
necesidad que tiene un agente vendedor de analizar mediante introspección, qué productos
del catálogo pueden considerarse como buenas ofertas de venta en un determinado
momento. Estas ofertas se denominan ofertas de venta potenciales porque el propósito no
es el de ser enviadas inmediatamente al comprador, sino el de servir como guía en un
proceso de argumentación del rechazo a un requerimiento de compra. Se podría decir que
es un mecanismo que estima qué productos del catálogo son buenos candidatos para futuras
ofertas de venta. Este mecanismo retorna el conjunto de productos del catálogo S que se
consideran buenas opciones para una futura oferta al comprador.
Salidas: Sp, que describe el conjunto de productos que el agente vendedor considera como
buenas opciones para una oferta futura.
Este mecanismo constituye el núcleo del sistema de argumentación del vendedor.
Cuando un agente vendedor no puede satisfacer un requerimiento de compra, puede
estimular al comprador para que cambie sus preferencias, y en consecuencia sus propuestas
o requerimientos de compra. En un esquema no argumental, el vendedor tiene como única
herramienta el rechazo, sin embargo esto no permite reconducir la negociación hacia
posiciones favorables para el vendedor, y mucho menos permite llegar a soluciones
compensadas win-to-win. Es evidente que definir un espacio de búsqueda compatible es
clave para alcanzar soluciones satisfactorias.
S4: Generate Relax Requirement
Este mecanismo responde a la necesidad del vendedor de componer un
requerimiento de relajación reqB . Conforma la segunda fase del proceso de generación de
requerimientos de relajación descrito en el mecanismo S3. Dado un conjunto de ofertas de
venta potenciales SP, este mecanismo compone un requerimiento de relajación con el objeto
de conducir al comprador hacia uno de los productos contenidos en SP. El mecanismo
retorna un requerimiento de relajación reqB .
Salidas: reqB
El principio básico de composición del requerimiento de relajación es el de
conseguir que el comprador relaje aquellas restricciones del requerimiento de compra que
no son satisfechas por los productos contenidos en SP.
El mecanismo emite la locución L5: prefer_to_sell(.).
L5: prefer_to_sell(.)
Locución prefer_to_sell(Ps, Pb, reqB ,
reqB ).
Precondiciones Pb debe emitir una locución prefer_to_buy(Pb, Ps, reqB ,
reqB ).
Significado El agente vendedor Ps le indica al comprador Pb, que debería relajar el
requerimiento de compra reqB recibido a través de la locución
prefer_to_buy(Pb, Ps, reqB ,
reqBv ), y expresa su preferencia por la relajación
de restricciones específicas del requerimiento de compra mediante el
requerimiento de relajación reqB .
Respuesta No se requiere.
Actualización AI No se actualiza.
Tabla 9 Detalle de la locución L5: prefer_to_sell(.)
S5: Accept or Reject Offer
Este mecanismo responde a la necesidad del agente vendedor de decidir en un
determinado momento si se debe o no aceptar una oferta de compra del producto pj emitida
por un agente comprador mediante una locución agree_to_buy(.). Sólo existen dos posibles
valores de retorno, accept(pj) si se acepta la oferta, y reject(pj) si se rechaza la oferta.
Salidas: accept(pj), reject(pj)
Las locuciones que emite este mecanismo son L8: refuse_to_sell(.) y L10:
agree_to_sell(.).
L8: refuse_to_sell(.)
Locución refuse_to_sell(Ps, Pb, pj) ó refuse_to_sell(Ps, Pb, reqB ).
Precondiciones La locución refuse_to_sell(Pb, Ps, pj) no puede emitirse tras una emisión válida
de agree_to_sell(Ps, Pb, pj), siendo válida únicamente tras la recepción de
agree_to_buy(Pb, Ps, pj). Un comprador Pb debe emitir prefer_to_buy(Pb, Ps,
reqB ,reqBv ) para que refuse_to_sell(Ps, Pb,
reqB ) sea válida.
Significado El agente vendedor Ps expresa su rechazo a vender el producto pj o a vender un
producto que satisfaga el requerimiento de comprareqB .
Respuesta No se requiere.
Actualización AI No se actualiza.
Tabla 10 Detalle de la locución L8: refuse_to_sell(.)
L10: agree_to_sell(.)
Locución agree_to_sell(Ps, Pb, pj).
Precondiciones Debe haberse recibido una locución agree_to_buy(Pb, Ps, pj).
Significado El agente vendedor Ps, dirigiéndose al agente comprador Pb, se compromete a
vender el producto pj.
Respuesta No se requiere.
Actualización AI Se almacena en un registro el compromiso de venta pj.
Tabla 11 Detalle de la locución L10: agree_to_sell(.)
S6: Consider Withdrawal
Este mecanismo responde a la necesidad que tiene un agente vendedor de decidir en
un determinado momento si debe finalizar el diálogo con un comprador. El mecanismo
puede permanecer en estado de espera, retornará entonces wait, o indicar que se debe
abandonar el diálogo, en cuyo caso retornará withdraw( ).
Salidas: wait, withdraw( )
Este mecanismo emite la locución L11: withdraw_dialogue(.) descripta en el mecanismo
B5: Consider Withdrawal.
En la figura 6 podemos observar el diagrama de transición. En él aparecen estados
delegadores (delegator) cuya función es la de ordenar las transiciones y proporcionarle una
secuencialidad a las mismas.
A continuación mostramos un listado con las reglas de transición y qué locuciones
se envían en cada cambio de estado. Una tupla <Px, K, s> describe el mecanismo de
decisión K del agente Px cuando se genera una salida s. Cabe señalar que las transiciones
TR9 y TR11 no fueron tenidas en cuenta por involucrar aspectos no expresivos de los
agentes.
.,1,)(_,1,:1 1 SPneedhaveBPTR s
L
b
waitBPneednohaveBPTR sb ,1,)(__,1,:2
waitSPentertonotwishSPTR ss ,1,)(___,1,:3
.,2,)(__,1,:4 2 BPentertowishSPTR b
L
s
.,5,,2,:5 BPBPTR bb
.,6,)(,5,:6 11 SPwithdrawBPTR s
L
b
.,5,)(,6,:7 11 BPwithdrawSPTR b
L
s
.,3,,2,:8 BPBPTR bBb req
.,2,,3,:10 6 SPvBPTR s
L
Bb req
.,4,)(_,2,:12 3 BPpoffersaleSPTR b
L
js
.,3,)(_,2,:13 SPtrequiremenpurchaseSPTR s
t
Bs req
.,4,,3,:14 SPSSPTR sPs
.,2,,4,:15 5 BPSPTR b
L
Bs req
.,2,)(__,4,:16 BPptrequiremenpurchasegenerateBPTR bjb
.,5,)(_,4,:17 9 SPpofferacceptBPTR s
L
jb
.,2,)(_,4,:18 7 SPpofferrejectBPTR s
L
jb
.,5,)(,5,:19 10 BPpacceptSPTR b
L
js
.,2,)(,5,:20 8 BPprejectSPTR b
L
js
Tabla 12 Reglas de transición
Figura 6 Diagrama de reglas de transición
4.8 Resumen general
Los modelos de negociación basados en restricciones difusas aportan un mayor
grado de flexibilidad y eficiencia respecto a otros modelos, los cuales se enfocan en la
defensa de posiciones. Este modelo se acerca más a los procesos de negociación en
escenarios reales donde se negocia sobre la base de los intereses de las partes involucradas.
El comprador, en nuestro caso un Municipio, cuenta con la capacidad de emitir
requerimientos de compra en forma de restricciones difusas, valoradas en forma subjetiva.
Los proveedores pueden optar por no ofrecer un determinado producto utilizando
locuciones que manifiestan explícitamente un deseo de relajación sobre el requerimiento de
compra recibido. En definitiva, ambas partes cuentan con las herramientas necesarias para
orientar la negociación hacia el beneficio de sus propios intereses, pero sin dejar de lado los
intereses de la otra parte. Este enfoque permite que el transcurso de la negociación se dirija
hacia zonas del espacio de soluciones donde los resultados son beneficiosos para las partes
(resultados del tipo win-to-win).
El modelo de diálogo de alto nivel para un agente Municipal y otro proveedor se
compone de tres fases: la primera es la apertura del diálogo en donde las partes acuerdan
comenzar una negociación. La segunda es la negociación propiamente dicha; en ella el
agente Municipal emite requerimientos de compras en forma de restricciones difusas,
valora sugestivamente los requerimientos de compra y se lo comunica al proveedor, y por
último rechaza ofertas de venta que no le resultan convenientes; el proveedor emite ofertas
de ventas que se acerquen al requerimiento de compra recibido y que le resulten
beneficiosas para él, rechaza requerimientos de compras argumentando su decisión con
pedidos de relajación, y emite rechazos de compromisos de compra por no contar con un
producto que se ajuste al requerimiento. La tercera fase es la confirmación que ocurre
cuando ambas partes llegan a un acuerdo. Y por último, la cuarta fase se refiere al cierre del
diálogo. Cada una de las acciones llevada a cabo por los agentes dentro de las fases se
basan en mecanismos de decisión y locuciones. Los agentes están equipados con estos
mecanismos, llamados mecanismos de decisión semánticos, que le permiten invocar
determinadas locuciones en el momento adecuado, como respuesta a locuciones pasadas, o
como anticipo de futuras locuciones.
Evidentemente lo expuesto en este capítulo es una visión teórica de los mecanismos,
es decir, no hemos profundizado en cada uno de ellos, solo fueron mencionados. En el
siguiente capítulo presentaremos una instanciación del mismo con el fin de acercarnos aún
más a la lógica del funcionamiento de nuestro sistema.
Capítulo 5
Instanciación del modelo de negociación
El objetivo de este capítulo es el de presentar una instanciación del modelo de
negociación exhibido anteriormente, basándonos en la teoría propuesta por López Carmona
(López Carmona, 2006). Todo el proceso de instanciación recae en presentar la definición
detallada de los mecanismos de decisión del Sector de Compras y proveedor.
5.1 Introducción
Antes de presentar la instanciación del modelo de negociación haremos una breve
descripción del contexto donde lo aplicaremos, a fin de no perder de vista el ámbito de será
utilizado. Toda negociación llevada a cabo en la presente tesis será del tipo B2G (Empresas
a Gobierno o Bussines to Government) en un ámbito municipal. Todos los procesos de
compra de los municipios de la provincia de Buenos Aires están regulados por las Ley
Orgánica de las Municipalidades de la provincia. La misma establece tres artículos que
reglamentan la estructura de una Oficina de Compras:
ARTICULO 197°: Cada Municipalidad organizará una Oficina de Compras, cuyas
funciones serán reglamentadas por el Departamento Ejecutivo.
ARTICULO 198°: El Jefe de la Oficina de Compras, con asesoramiento de las
reparticiones técnicas en los casos necesarios, tendrá a su cargo y bajo su
responsabilidad, el diligenciamiento de los suministros que deban efectuarse a la
Municipalidad con arreglo a las normas establecidas para la adquisición directa, el
concurso de precios y las licitaciones públicas y privadas.
ARTICULO 199°: Es obligación del Jefe de Compras comprobar y certificar la
efectiva recepción de los artículos adquiridos por la Municipalidad. Será
personalmente responsable de los perjuicios que se produzcan a consecuencia de los
ingresos que certifique sin estar fundado en la verdad de los hechos.
Estos tres artículos evidencian la gran responsabilidad que recae sobre el Jefe de
Compras en el desarrollo de sus funciones. Dicha responsabilidad se traslada a toda
herramienta que la oficina utilice, como podría ser un sistema de negociación automática.
Dependiendo del monto del bien a adquirir existen cuatro tipos de procesos:
Compra directa: Son las compras básicas donde el monto no supera los $37000. El
proceso carece de regularización y no remite demasiada complejidad: el jefe de la
Oficina de Compras solicita a diversos proveedores inscriptos en el registro de
proveedores el envío de cotizaciones del bien en cuestión, y es él mismo el que
decide a quién efectuarle la compra. No existe una fecha de apertura (fecha en la
que el Municipio deja de recibir cotizaciones, para así comenzar a evaluarlas), salvo
contadas excepciones.
Concurso de precios: Son las compras donde los montos van de $37000 a
$170000. Deben efectuarse enviando pedidos de cotización formales a tres
proveedores registrados como mínimo. Existe una fecha de apertura donde el
Municipio comienza a evaluar las ofertas recibidas.
Licitación privada: Para montos que van de $170000 a $650000. Al igual que en el
concurso de precios, se realiza por invitación, pero para este caso el mínimo de
proveedores registrados a invitar son 5.
Licitación pública: Este proceso se inicia cuando una obra, bien o servicio excede
los $650000. El pedido de cotización se efectúa a través de medios públicos:
diarios, televisión, boletín oficial, etc. Debe ser obligatorio contar con más de una
oferta, en caso contrario se realiza una nueva licitación. Si nuevamente se recibe
una sola cotización será el Honorable Concejo Deliberante el que decida los pasos a
seguir. En la fecha de apertura estipulada se celebra un acto de apertura de sobres
donde los proveedores registrados pueden estar presentes si lo desean (incluso se
asientan en un acta).
Como mencionamos anteriormente, el marco de aplicación de la presente tesis se
desarrolla sobre un proceso de compra directa donde las restricciones y regulaciones están
más relajadas. Cada proveedor registrado contará con su agente vendedor que negociará
con el agente comprador de un determinado Municipio, consultando constantemente en su
catálogo dinámico.
A continuación presentaremos la instanciación del modelo de negociación
considerando el contexto antes mencionado. Para nuestro caso contamos con dos entidades:
una compradora (Sector de Compras) y una vendedora (proveedor). En el resto del capítulo
utilizaremos los términos Sector de Compras y proveedor para referirnos exclusivamente a
sus respectivos agentes inteligentes.
5.2 Instanciación de los mecanismos de decisión del Sector de Compras
En esta sección se desarrolla la propuesta detallada de cada uno de los mecanismos
de decisión del agente que representa al Sector de Compras.
B1: Recognize Need
El mecanismo ya fue especificado en el capítulo anterior. La necesidad de iniciar un
diálogo se lleva a cabo a través de una interfaz. Una vez que el encargado de las compras
del Municipio declara la categoría del producto y las restricciones difusas sobre sus
atributos, el sistema crea un agente negociador comprador que será el responsable de
entablar el dialogo con el agente proveedor. Por lo tanto este mecanismo es el receptor del
requerimiento de compra del sector.
B2: Generate Purchase Requirement
El mecanismo aborda el problema de la generación de requerimientos de compra. Son
tres las estrategias que se especifican a continuación:
la incorporación de nuevas restricciones difusas a un requerimiento de compra t
Breq
para generar un nuevo 1t
Breq ;
la incorporación de la primera o primeras restricciones a un t
Breq ;
la definición de una función llamada función de modificación de requerimiento de
compra o ,,:reqreqreq BBBfmrc para la modificación de requerimientos de
compra, con el objeto de generar también un nuevo 1t
Breq sin añadir nuevas
restricciones.
Algoritmo (Modificación de requerimientos de compra)
1) Dado un requerimiento de compra t
Breq , se obtiene un vector con los grados de
satisfacción global potencial para todos los posibles requerimientos de compra
ficticios, resultantes de relajar cada vez sólo una de las restricciones contenidas en
t
Breq :
ikt
reqB
kt
reqB
11
1
...
donde
xkt
reqB
1
representa el grado de satisfacción global potencial que se obtiene si la
restricción f
k xR es relajada lo mínimo posible. Las restricciones que no pueden ser relajadas
más se eliminan del vector. Si no es posible relajar ninguna restricción la función retorna .
2) Se calcula el máximo del vector anterior:
ikt
reqB
kt
reqB
maxt
max
11
1
...1
3) Se genera un nuevo vector en el que se incluyen únicamente los elementos que
satisfacen la siguiente igualdad:
xkt
reqBt
max
1
1
que se denominará
1t
max
4) Finalmente se aplica la siguiente función:
x
xkt
reqB
kttr
máx
)1(
max
1
max ,
arg
donde t
max es un requerimiento de relajación del proveedor en el que sólo se tienen en
cuenta los requerimientos que se corresponden con las restricciones incluidas en el vector
creado en el paso 3). Si no existe requerimiento de relajación, xkr tomará siempre valor 0.
Esta función selecciona la o las restricciones que maximizan la suma de la satisfacción
global potencial que inducen si son relajadas.
5) Una vez seleccionada la o las restricciones con opción a ser relajadas, se elige una
aleatoriamente y se compone el nuevo requerimiento de compra 1t
Breq , en el que se
modifica únicamente la restricción elegida.
Las tres primeras fases del algoritmo se centran en la búsqueda de aquellas
restricciones del requerimiento de compra 1t
Breq que si se relajan comportan la menor
pérdida de satisfacción global potencial posible. Una vez detectadas estas restricciones, la
fase 4) tiene en cuenta sólo estas restricciones, y si existe un requerimiento de relajación,
las preferencias que tiene el proveedor por la relajación de éstas. Se está teniendo en cuenta
por tanto no sólo el criterio local de minimización de pérdida de satisfacción, sino también
el argumento de rechazo del proveedor.
B3: Generate Purchase Requirement Valuation
El mecanismo aborda el problema de la valoración de requerimientos de compra.
Sólo se activa internamente en la regla de transición TR8 tras la generación de un
requerimiento de compra. En este caso, se utiliza la función de valoración de
requerimientos de compra reqreq BB vfvrc : .
Algoritmo (Valoración de requerimiento de compra)
1) Dado un requerimiento de compra a enviar 1t
Breq , se obtiene un vector con los
grados de satisfacción global potencial para todos los posibles requerimientos de
compra ficticios, resultantes de relajar cada vez sólo una de las restricciones en 1t
Breq .
Los grados de satisfacción global potencial de aquellas restricciones no relajables
toman valor 0:
ikt
reqB
kt
reqB
21
2
...
2) Se toman los elementos del vector anterior y se define un nuevo vector normalizado
que representa la valoración del requerimiento de compra:
ikt
req
kt
req
ikt
req
kt
req
reqsumvB
21
221
2
1,...,11,...,1
El mecanismo define la estrategia de valoración de requerimientos de compra como
una estrategia basada en los grados de satisfacción potenciales. Maticemos de qué grados
de satisfacción potencial estamos hablando, describiendo para ello un proceso normal de
valoración. Cuando se ejecuta el mecanismo B2: Generate Purchase Requirement, se
genera un requerimiento de compra 1t
Breq , a partir de un requerimiento ya enviado antes
denominado t
Breq . Para la generación de 1t
Breq se han utilizado los grados de satisfacción
potencial ficticios de t
Breq . En cambio, en la generación de valoración se están generando
los grados de satisfacción potencial ficticios de la propuesta 1t
Breq , que todavía no se ha
enviado. En definitiva, se están estimando los grados de satisfacción potencial que se
podrían conseguir si el Sector de Compras vuelve a solicitar un nuevo requerimiento.
B4: Consider Offers
Este mecanismo está completamente especificado. Se activa únicamente cuando se
recibe una oferta de venta (ver TR12). La consideración de la oferta está representada en
las reglas de transición TR16, TR17 y TR18. La regla TR16 se dispara cuando la oferta de
venta recibida no cumple el requerimiento de compra al completo, mientras la regla TR17
se activa cuando se acepta la oferta. La regla TR18 representa un rechazo frontal de la
oferta de venta.
B5: Consider Withdrawal
El mecanismo identifica una necesidad de abandono de un diálogo de negociación.
El mecanismo se activa en tres supuestos: en la transición TR5 cuando el Sector de
Compras no puede relajar más sus requerimientos de compra; en la transición TR7 cuando
se recibe un aviso de abandono asíncrono del proveedor mediante la locución L11:
withdraw_dialogue(.); y finalmente en la transición TR19 (pasando por el delegador)
cuando el proveedor emite un compromiso de venta que completa la transacción. Vemos
por tanto que la única tarea explícita de este mecanismo es emitir la locución L11:
withdraw_dialogue(.), y que la identificación de la necesidad de abandono está implícita
en las reglas de transición.
5.3 Instanciación de los mecanismos de decisión del Proveedor
En esta sección se explica la propuesta detallada de cada uno de los mecanismos de
decisión del proveedor.
S1: Recognize Category
Este mecanismo está completamente especificado. Sólo se activa cuando se recibe
una petición de inicio de diálogo (ver TR1). Si se encuentran productos sobre los que
negociar se emite la locución L2: enter_dialogue(.) para confirmar la participación (ver
TR4), y si no se encuentran se entra en estado de espera (ver TR3).
S2: Assess Purchase_Requirement
Cabe recordar que el objetivo de este mecanismo es buscar productos que satisfagan
los requerimientos de compra, y si existen, seleccionar los más adecuados. Si no hay
productos, se activa la regla de transición TR13, la cual transfiere el requerimiento de
compra para ser utilizado como entrada a los procedimientos de generación de argumentos.
Cuando existen productos se selecciona sólo uno de ellos mediante la función de selección
de ofertas de ventas SSfsovreqB ,: . Dicha función toma como entrada el requerimiento
de compra que se está analizando, y el subconjunto de productos del catálogo que
satisfacen dicho requerimiento. La función retorna el producto que se va a utilizar como
oferta de venta. Dicha función se basa en dos criterios fundamentales: la utilidad uj que
reporta la venta del producto, y el número de veces que dicho producto ha sido ofertado
durante el transcurso del diálogo. Según esta estrategia, cuando un proveedor tiene que
seleccionar un producto para formar parte de una oferta de venta, en primer lugar tiene que
satisfacer las necesidades expresadas por el Sector de Compras. Dado que pueden aparecer
en el catálogo múltiples productos que satisfagan un requerimiento de compra, la decisión
final tendrá que ser función de los dos únicos criterios existentes, la utilidad que le reporte
al proveedor ofrecer el producto, y el número de veces que se haya ofertado un producto.
Hay que tener en cuenta que un producto que inicialmente sea rechazado, no tiene por qué
ser descartado en iteraciones futuras del diálogo por una razón fundamental: el Sector de
Compras podría realizar concesiones.
A continuación se detalla el algoritmo para implementar esta función.
Algoritmo (Selección de ofertas de venta)
1) Por cada producto se aplica la fórmula:
envíosdecantidadutilidadaceptación 1
Se seleccionan los productos cuyo nivel de aceptación sea igual al máximo.
2) De los productos seleccionados en 2) se elige uno aleatoriamente. Este producto es
el que retorna la función.
3) Se actualiza el almacén de información AI(Ps) del proveedor, incrementando el
número de envíos asociado al producto elegido en 2).
El elegir el producto de mayor utilidad es consecuente con la racionalidad del
agente al respecto de la maximización de la utilidad. Seleccionar el producto menos veces
enviado responde al razonamiento lógico de estimar que si un producto no ha sido aceptado
antes, probablemente tampoco será aceptado ahora, y es mejor probar por tanto con otro
producto que dando la misma utilidad, no haya sido enviado todavía.
S3: Generate Potential Sale-Offers
La generación de ofertas de venta potenciales constituye el núcleo del sistema de
argumentación del proveedor. Tiene un único punto de activación en la regla de transición
TR13, cuando el mecanismo S2: Assess Purchase Requirement de análisis de
requerimiento de compra solicita que se haga un rechazo argumentado. La única salida del
mecanismo (una lista con ofertas de venta potenciales) activa internamente en la transición
TR14 el mecanismo S4: Generate Relax Requirement para la composición de un
requerimiento de relajación.
Se define un único marco estratégico acotado por la función
SvSfgovpreqreq BB ,,: de generación de ofertas de venta potenciales. Las entradas de la
función son un requerimiento de compra t
Breq sobre el que se quiere argumentar un rechazo,
el catálogo de productos del proveedor S del que se tienen que extraer los productos
candidatos o preferidos, y una valoración reqBv del requerimiento de compra. La función
devuelve como resultado una lista SP con los productos que el proveedor considera deben
ser tomados como referencia para generar requerimientos de relajación. En la
especificación del mecanismo son dos los criterios que el autor tuvo en cuenta: la utilidad y
la viabilidad. En función de todos estos datos desarrollamos la implementación de fgovp.
Implementación de fgovp
Teniendo en cuenta que la función debe discriminar productos para ser incluidos en
una lista de ofertas de venta potenciales, se define en primer lugar una función prefer(sj)
que asigna un valor de preferencia a cada uno de los productos del catálogo. Esta función se
llama tantas veces como productos tenga el catálogo S. Dado que los dos criterios tenidos
en cuenta son los de utilidad y viabilidad, el primero interno, y el segundo externo, se
define una constante que cuantifica el perfil receptivo del proveedor modulando la
importancia que van a tener los argumentos procedentes del Sector de Compras. Por lo
tanto la función prefer queda definida de la siguiente manera:
reqreq B
t
Bjjj vpviabilityusprefer ,,1)(
Puede verificarse que el valor controla en qué medida se tienen en cuenta los
factores internos y externos, a la hora de decidir la preferencia que tiene el agente
proveedor porque una entrada del catálogo se constituya como oferta de venta. En un
extremo, si 1 , la función queda como jj usprefer )( , mientras que si 0 la
función queda como reqreq B
t
Bjj vpviabilitysprefer ,,)( . El primer caso no tiene en cuenta
ni el requerimiento de compra recibido, ni su posible valoración, de manera que el criterio
de selección recae únicamente en la utilidad local. El segundo caso no tiene en cuenta la
utilidad, por lo que el criterio de selección de productos se basa únicamente en la viabilidad
estimada de la venta. Basándonos en las pruebas llevadas a cabo por el autor fijamos el
valor de la constante en 0.5 para contar con proporciones iguales de ambos criterios.
Una vez que se han calculado los valores de preferencia con la función prefer para
todos los productos del catálogo, es posible generar la lista de ofertas de venta potenciales
mediante un filtrado por umbral de dichos valores. A continuación se desarrolla el
algoritmo para el filtrado de valores de preferencia para la obtención de ofertas de venta
potenciales.
Algoritmo. (Filtrado de valores de preferencia para la obtención de ofertas de venta
potenciales)
1) Se selecciona aquella entrada del catálogo cuyo valor de preferencia calculado
sea el mayor. Estas entradas constituyen la salida SP de la función fgovp.
Hasta aquí, toda la funcionalidad de fgovp está descrita, a excepción del cálculo o
estimación de la viabilidad que desarrollamos a continuación, y que constituye sin duda la
parte más compleja del mecanismo.
Definición de la estimación de viabilidad viability
La estimación de viabilidad de venta de un producto pj se basa conforme a la
descripción del mecanismo en: el grado de similitud entre el producto pj y el requerimiento
de compra t
Breq ; y una estimación de la valoración que hará el Sector de Compras sobre el
producto en cuestión si se ofrece para la venta. Estos aspectos se condensan en la siguiente
definición de estimación de viabilidad:
reqreq Bbv
t
Bj vEpsimviability ,
El primer término representa una estimación de la similaridad entre el producto pj y
el requerimiento de compra t
Breq . El segundo término define la estimación de la valoración
del Sector de Compras como una función de estimación que depende del producto pj, y de
la valoración del requerimiento de compra emitida por este. El operador tiene la función
de ponderar ambos términos (este operador se describe más abajo). Abordamos ahora cada
término por separado.
Similaridad
La similaridad se define como una función de la distancia de la siguiente forma:
),(1, t
Bj
t
Bj reqreqpdistpsim
donde ),( t
Bj reqpdist representa la estimación de la distancia normalizada existente
entre un producto pj y un requerimiento de compra t
Breq . Para estimar la distancia se utiliza
una medida basada en la distancia euclídea.
nadistsqrtpdistn
i
it
Bij
t
Bj reqreq/,),(
1
2,
donde ),( ,it
Bji reqadist representa la distancia del atributo aji del producto pj al conjunto de
restricciones incluidas en t
Breq que hacen referencia a dicho atributo. Esto significa que en
primer lugar se deben calcular las distancias del atributo a cada una de estas restricciones.
Este cálculo es una medida de la distancia al límite estimado más cercano que delimita la
restricción dura correspondiente. Sin embargo, esta medida de distancia entre un atributo y
un límite de una restricción dura es una medida absoluta que tiene que ser normalizada. Es
necesaria la definición de los siguientes valores: el valor de reserva estimado res
ia para cada
uno de los atributos; el límite más lejano a cada uno de los atributos aji, que se obtiene
mediante la función )( ,it
Breqboundary ; la velocidad de relajación estimada para cada
atributo aji que se denomina ),0( t
i ; y por último, el grado de certidumbre de la
estimación de distancia de un atributo aji llamado ],0[ t
i . Los valores de reserva, de
velocidad de relajación y el grado de certidumbre forman parte del modelo de
requerimientos del proveedor, en concreto del conjunto de creencias
}...,,1),,{( mit
i
t
i
t , donde ),( t
i
res
i
t
i a .
Comentamos a continuación cada uno de estos valores.
El valor de reserva res
ia expresa la creencia del proveedor al respecto de cuál es el
valor de relajación límite que estaría dispuesto a asumir el Sector de Compra para un
determinado atributo. En nuestro caso tomamos el valor promedio de cada atributo teniendo
en cuenta todos los productos del catálogo. De esta creencia parcial no se tiene por qué
inducir la creencia de que el Sector de Compras estaría dispuesto a relajar todas las
restricciones hasta estos valores de reserva simultáneamente. Si esto fuese así, el proveedor
podría sencillamente rechazar todas las propuestas hasta que el Sector de Compras relajase
todas las restricciones. Sin embargo, en un entorno de múltiples vendedores, la utilización
por parte del proveedor de una estrategia de este tipo está también condicionada por la
aversión al riesgo de perder una venta.
El límite más lejano requiere en primer lugar el cálculo de los límites que definen
las restricciones duras que restringen un atributo aji. Se asume que estos límites son los más
cercanos al atributo. Una vez que se tienen los límites se pueden calcular las distancias
absolutas al atributo. El límite más lejano será el límite que genera la mayor de estas
distancias. Es decir, la distancia absoluta del atributo aji a un requerimiento de compra, será
la mayor de las distancias de dicho atributo a las restricciones duras que restringen dicho
atributo.
La velocidad de relajación estimada es una estimación de la predisposición del
Sector de Compras a relajar las restricciones sobre un determinado atributo. En este caso no
se estima el valor de reserva, sino la velocidad con que se estima se va a llegar al valor de
reserva. La idea es que una distancia calculada sobre un atributo para el que se estima una
relajación rápida, debe interpretarse como una distancia menor en relación con una
distancia igual calculada sobre un atributo para el que se estima una relajación lenta.
El grado de certidumbre t
i es una medida de la certidumbre que tiene el Sector de
Compras al respecto de la medida de distancia realizada para el atributo aji.
Finalmente presentamos a continuación la función ),( ,it
Bji reqadist que aglutina todos
estos conceptos.
resto
a
boundaryaaboundarya
boundaryaabs
adist it
Bji
it
B
res
iji
t
iit
B
res
i
it
Bji
it
Bji req
req
ti
req
req
req
1
0
))(,[1*1))(
)((
),( ,
,
1
,
,
,
Esta estimación de distancia tiene las siguientes propiedades:
1- La distancia está normalizada a 1 en todos los casos.
2- Los valores de atributo que sobrepasan los valores de reserva estimados se fijan a
distancia 1.
3- Si el atributo satisface las restricciones la distancia es 0.
4- Si el atributo se encuentra entre el valor de reserva y el límite de las restricciones, la
distancia es función de la lejanía a las restricciones, y está normalizada por la
distancia entre el valor de reserva y el límite de las restricciones.
Es importante señalar que en nuestro caso los valores de los parámetros fueron
prefijados en base a los resultados de las experiencias llevadas a cabo por el autor. En el
caso del grado de certidumbre se verifica que a medida que éste se hace menor a 1, la
distancia estimada se hace mayor. Por lo que resulta óptimo un valor de 1 para dicho
parámetro. En el caso de la velocidad de relajación, el estudio demuestra que un valor de 1
converge más rápidamente a la distancia estimada.
Estimación de la valoración del Sector de Compras
La estimación de la valoración que el Sector de Compras haría de una oferta de
venta está directamente relacionada con la valoración explícita que éste puede hacer sobre
un requerimiento de compra, es decir, de reqBv . Esta valoración, siguiendo un razonamiento
parecido al que nos llevaba a definir la velocidad de relajación t
i y el grado de certidumbre
t
i , va a influir en la estimación de distancia de la siguiente manera. Si las restricciones
sobre un atributo aji son muy valoradas, significa que la predisposición del Sector de
Compras a relajar dichas restricciones es baja, con lo que la medida de distancia debe
ponderarse al alza. Así, cuando el Sector de Compras emite valoraciones de compra el autor
propone la siguiente función de viabilidad que implementa el operador :
)/)),(((1 2
)(1
,, nvadistsqrtviability it
reqBreq boundary
n
i
it
Bji
donde )( ,it
reqBboundary
v
representa la preferencia que el Sector de Compras tiene porque la
restricción más lejana al atributo aji sea satisfecha.
La función prefer queda finalmente como:
))/)),(((1()1()( 2
)(1
,, nvadistsqrtusprefer it
reqBreq boundary
n
i
it
Bjijj
S4: Generate Relax Requirement
La generación de requerimientos de relajación se activa en la regla de transición
TR14, cuando el mecanismo S3: Generate Potential Sale-Offers ha generado la lista de
ofertas de venta potenciales SP. La ejecución de este mecanismo activa la regla de
transición TR15, que emite un requerimiento de relajación mediante la locución L5:
prefer_to_sell(.). El marco estratégico que se define en este mecanismo es el de la
composición de requerimiento de relajación, especificado mediante la función
reqreq BPB Sfcrr ,: de composición de requerimiento de relajación. Dicha función
recibe como parámetros de entrada: el requerimiento de compra reqB cuyo rechazo se
quiere argumentar, y la lista de ofertas de venta potenciales SP. La salida de la función es el
requerimiento de relajación reqB . Se especifica además que la estrategia debe estar basada
en la generación de un mapa de distribución de frecuencias de cumplimiento de
restricciones en reqB por parte de los productos en SP. En cualquier caso la función fcrr
debe basar su estrategia en cómo tratar el no cumplimiento de restricciones por parte de los
productos. Para no sobrecargar la técnica de generación del requerimiento de relajación con
excesivos matices se aplica el siguiente algoritmo de composición de requerimiento de
relajación:
Algoritmo. (Composición de requerimiento de relajación)
1) Se compone el requerimiento de relajación como un vector ikk rr ...,,
1, donde
1xkr indica que la restricción
xkR no es satisfecha por producto alguno, y 0xkr
indica que la restricción xkR es satisfecha por lo menos por un producto.
Por ejemplo, el requerimiento de relajación del tipo (0,0,0) para 3 atributos indica
que todas las restricciones son satisfechas individualmente (no hace falta que sea
simultáneamente) por al menos un producto. Es decir, el proveedor no tiene una preferencia
especial porque una restricción sea relajada, porque cualquier relajación puede conducir a
la venta de un producto en SP.
S5: Accept or Reject Offer
Este mecanismo está completamente especificado. Sólo se activa cuando se recibe
una locución L9: agree_to_buy(.) del Sector de Compras con un compromiso explícito de
compra (ver TR17). Si se acepta el compromiso de compra se activa la regla de transición
TR19, de forma que el proveedor emite la locución L10: agree_to_sell(.) confirmando la
transacción. Si no se acepta el compromiso de compra se activa la regla de transición
TR20, donde el proveedor emite la locución L8: refuse_to_sell(.) en la que se rechaza la
propuesta.
S6: Consider Withdrawal
El mecanismo identifica una necesidad de abandono de un diálogo de negociación.
El mecanismo se activa en la transición TR6 cuando el agente Sector de Compras informa
del abandono del diálogo mediante la locución L11: withdraw_dialogue(.). La única tarea
explícita de este mecanismo es emitir la locución L11: withdraw_dialogue(.). En
definitiva, el proveedor sólo considera el abandono del diálogo cuando el Sector de
Compras decide abandonar.
5.4 Detalles de diseño
En esta sección mostramos detalles del diseño e implementación del sistema de
negociación automática que incorpora los conceptos hasta el momento desarrollados.
La implementación en general de divide en dos ámbitos fundamentales: uno que se
ocupa de la comunicación entre agentes y la gestión de los mismos; y el otro que abarca
toda la lógica de negociación, es decir, la implementación de los agentes, sus
comportamientos y transiciones, las locuciones, las ontologías y los mecanismos de
decisión. El primer ámbito lo abordamos utilizando la plataforma JADE, como ya hemos
mencionado. Por lo tanto, contamos con un servidor de agentes el cual los contiene y los
comunica, liberándonos de dichas tareas en el proceso de diseño e implementación. Para el
segundo ámbito, es decir, la lógica de negociación, utilizamos el lenguaje Java. Todo el
desarrollo podría funcionar en un solo servidor, pero evidentemente este sería un entorno
no distribuido. Como ya hemos mencionado, una de las ventajas del sistema de negociación
radica en la posibilidad de distribuirlo y así integrar sistemas heterogéneos. Un proveedor
que cuenta con el apoyo de un desarrollador calificado puede implementar su agente
negociador sin ningún inconveniente, conociendo el protocolo de negociación.
5.4.1 Arquitectura del sistema
En la figura 7 presentamos la vista de despliegue de todo el sistema.
Figura 7 Vista de despliegue
En la vista podemos observar la distribución completa del sistema, aunque como
mencionamos anteriormente, todos los módulos podrían funcionar en una sola máquina.
Cabe señalar que toda conexión entre los módulos puede producirse a través de la Web por
accesos públicos. El envío de e-mail se produce con el fin de informar el resultado de una
negociación; aunque no está contemplado en el diagrama, este correo se envía a través de la
Web utilizando el servidor de correos de Gmail.
Podemos ver que los servidores Municipalidad y proveedor tienen diferencias
sustanciales, ligadas a los modos en que se ejecutan sus respectivas lógicas. El servidor
Municipalidad tiene corriendo un contenedor Web Tomcat que le permite al titular de la
Oficina de Compras ejecutar la aplicación por medio de un navegador Web. Cada inicio de
negociación por parte del usuario, determina en el servidor una comunicación con el
Contenedor Principal JADE para solicitar la creación de un agente negociador municipal.
A su vez, este mismo servidor se encarga de la búsqueda de servicios de venta en el DF
(Directory Facilitator), la ejecución de los mecanismos de decisión y de la notificación por
correo electrónico al usuario de los resultados de la negociación. El servidor proveedor, en
cambio, ejecuta un proceso en Java (a través de la JVM o Máquina Virtual de Java) el cual
le solicita al Contenedor Principal JADE la creación del agente correspondiente con todos
los comportamientos necesarios para llevar a cabo una negociación. Además, publica su
servicio de vendedor en el DF y, una vez iniciada una negociación, efectúa constantes
accesos a la base de datos que contiene los productos y el AI (Almacén de información).
Luego de concluirse la negociación, envía un correo electrónico al proveedor para
notificarlo del resultado de la misma. Se diseñó de esta manera porque no es necesario que
un proveedor ejecute constantemente instancias del sistema, con tener un proceso a la
espera de una solicitud de compra por parte de la Municipalidad es suficiente. En contra
parte, el director de la Oficina de Compras debe ejecutar nuevas instancias por cada
requerimiento de compra que arribe a su Oficina. Cada ejecución implica el establecimiento
de nuevos parámetros de negociación (producto deseado y valores difusos para sus
atributos), por lo que una interfaz de usuario es de suma importancia.
5.4.2 Diseño e implementación de la lógica de negociación
Como mencionamos anteriormente, la lógica de negociación se compone de los
agentes inteligentes, los comportamientos y las transiciones entre ellos, las locuciones, las
ontologías y los mecanismos de decisión.
En secciones anteriores indicamos que JADE es un framework de desarrollo de
software destinado a desarrollar sistemas multiagente y aplicaciones que se ajusten a las
normas FIPA para agentes inteligentes. Incluye dos productos principales: una plataforma
de agentes compatibles con FIPA y un paquete para desarrollar agentes en Java. JADE ha
sido codificado totalmente en Java, por lo que, un desarrollador, a fin de aprovechar el
framework, debe codificar sus agentes en Java extendiendo clases o creando instancias del
mismo (Bellifemine, Caire, Trucco, & Rimassa, 2005).
5.4.2.1 Implementación de agentes inteligentes y sus componentes
El framework JADE cuenta con una clase de agente (Agent) que representa la base
común para la implementación de los agentes definidos por el usuario. Por lo tanto, desde
el punto de vista del programador, un agente JADE es simplemente una instancia de una
clase definida por el usuario en Java que extiende la clase Agent. Esto implica la herencia
de características para llevar a cabo las interacciones básicas con la plataforma de agentes
(registro, configuración, administración remota, etc.) y un conjunto básico de métodos que
pueden ser redefinidos para implementar el comportamiento personalizado del agente (por
ejemplo, envío y recepción de mensajes, utilización de protocolos de interacción estándar,
etc.). La clase Agent cuenta con el método setup() que es el punto donde se inicia cualquier
actividad del agente. Por lo tanto, para inicializar los agentes, implementamos el método
setup(). Esta inicialización consiste en la registración en la plataforma, la instanciación de
los comportamientos y la creación de la máquina de estados que ejecutará cada
comportamiento.
Para que los agentes lleven a cabo tareas específicas definimos subclases de la clase
Behaviour (Comportamiento): creamos instancias de ellas y las agregamos a sus respectivas
máquinas de estados, las cuales permiten establecer los órdenes de ejecución entre los
comportamientos de acuerdo a cómo hayan finalizado cada uno de ellos. Cada subclase de
Behaviour hereda sus métodos, pero nuestro interés se enfocó particularmente en la
implementación de tres de ellos: el método action() que es el encargado de llevar a cabo la
tarea del comportamiento, done() es el método que se invoca cuando la tarea finalizó y
onEnd() permite retornar un número entero que será el que determine el próximo
comportamiento a ejecutar en la máquina de estados.
En lo que respecta a locuciones FIPA/ACL, las cuatro que hemos utilizado para
agrupar las originales necesarias para el sistema, son: inform, propose, accept-proposal y
refuse.
La estructura de la ontología define dos clases abstractas, Concept y Predicate, y
dos clases derivadas de Concept: AID (Agent Identifier) y AgentAction. Las clases que
representen una acción, deben ubicarse bajo AgenteAction. AID es una clase predefinida
que especifica el identificador de un agente, es decir, su nombre en la plataforma. El resto
de las clases definidas, constituyen realmente la ontología del sistema. Para facilitar la
implementación de las clases que componen toda la ontología del sistema, se ut ilizó el
software Protégé, el cual es un editor de ontología, gratuito y de código abierto. Este
programa tiene un gran soporte por parte de la comunidad académica, gubernamental, y
usuarios corporativos.
5.4.2.2 Agente municipal: Mecanismos de decisión
En esta sección nos enfocaremos en el diseño e implementación de los mecanismos
de decisión del agente negociador que representa a la Municipalidad. A continuación
podemos observar el diagrama de clases de los módulos que le permiten al agente llevar a
cabo una negociación.
Figura 8 Diagrama de clases para los mecanismos de decisión del agente municipal
La clase Buyer_Decision_Logic representa el núcleo de la unidad de negociación
del agente municipal. Esta clase es instanciada en el instante en que la negociación es
iniciada y el agente es creado en la plataforma. Cada comportamiento agregado a la
máquina de estados tiene la posibilidad de utilizarla en caso de que sea necesario. Entre sus
atributos podemos mencionar dos que remiten cierta utilizada: el identificador del agente
proveedor (seller:AID) para enviarle mensajes en cualquier parte del código y el
identificador de conversación (conversationid:String) para mantener un control de las
conversaciones a fin de evitar inconvenientes en negociaciones concurrentes.
Otro atributo importante de Buyer_Decision_Logic es un arreglo de instancias de la
clase NegotiationElement, la cual representa cada restricción difusa que constituye las
preferencias del agente municipal. Contiene entre otras cosas, las diferentes etiquetas
difusas con sus respectivos niveles de cortes (instancias de la clase EtiquetaDifusa), un
valor booleano que indica si el atributo del producto es incremental o no6, y métodos
necesarios para operar con dicha restricción difusa (relajarla, obtener la restricción dura al
nivel de corte actual, verificar si un determinado valor se encuentra dentro de ella, calcular
su valoración y el grado de pertenencia).
Los métodos de la clase Buyer_Decision_Logic son los encargados de poner en
funcionamiento los mecanismos de decisión del agente municipal. La gran mayoría son
invocados desde los comportamientos del agente y en muchos casos determinan el próximo
comportamiento hacia donde seguirá la ejecución en la máquina de estados. De las
funciones que posee la clase, podemos destacar las dos más importantes: la modificación de
un requerimiento de compra y la evaluación de una oferta de venta. En el siguiente
diagrama de secuencia observamos la primera función.
6 Un atributo es incremental cuando la pérdida de satisfacción global se produce elevando el valor del límite superior en caso de una relajación. El atributo precio es un ejemplo, ya que es menos conveniente aceptar valores altos respecto a los valores bajos. Un atributo no incremental es el caso contrario, como puede ser la calidad de un producto, ya que son menos convenientes valores bajos del mismo.
Figura 9 Diagrama de secuencia para la modificación de un requerimiento de compra
En el comportamiento B2: Generate Purchase Requirement se genera el primer
requerimiento o se modifica uno ya existente. Por lo tanto, desde dicho comportamiento se
invoca el método generatePurchaseRequirement(ACLMessage msg): boolean. El booleano
que retorna determina la siguiente ejecución: si es verdadero significa que se pudo generar
un requerimiento de compra, por lo que la ejecución continua en el comportamiento B3:
GeneratePurchaseRequirementValuation; si es falso nos encontramos en el caso contrario
donde se debe abandonar la negociación, es decir, la ejecución continuará en B5: Consider
Withdrawal. El mensaje ACL, parámetro del método, permite obtener el contenido del
mismo para ser procesado, y a su vez, de acuerdo al tipo de locución, determinar si se debe
generar el primer requerimiento de compra (seleccionando una restricción al azar) o si se
debe modificar (agregando una restricción aleatoriamente de las no enviadas o relajando
una ya enviada). El diagrama de secuencia muestra el caso en que el requerimiento de
compra debe ser modificado relajando algún atributo.
Para el caso de la evaluación de una oferta de venta, la ejecución puede ser
visualizada en el siguiente diagrama de secuencia.
Figura 10 Diagrama de secuencia para la evaluación de una oferta
El comportamiento B4: Consider Offers recibe la oferta de venta a través de una
locución willing_to_sell. Desde este comportamiento se invoca el método
considerOffers(Willing_to_sell willing):int de la clase Buyer_Decision_Logic para ser
evaluada. El número entero que retorna el método determina la continuidad de la ejecución
de acuerdo al resultado de la evaluación: puede aceptar o rechazar la oferta, continuando en
el estado Delegator, o puede generar una contra oferta lo que implica continuar en B2:
Generate Purchase Requirement. El parámetro willing permite obtener toda la información
necesaria para ser procesada por el método. Internamente la primera evaluación verifica si
todas las restricciones enviadas fueron cumplidas, en caso contrario se rechaza la oferta. La
segunda evaluación consiste en verificar el cumplimiento de las restricciones no enviadas,
si alguna no se cumple se deberá generar un nuevo requerimiento de compra. La tercera
implica el cálculo de los grados de satisfacción global y potencial para compararlos; si el
grado de satisfacción global supera o iguala al potencial, la oferta se acepta; en caso
contrario la oferta se rechaza.
5.4.2.3 Agente proveedor: Mecanismos de decisión
De igual modo que en la implementación de los mecanismos de decisión del agente
municipal, la clase Seller_Decision_Logic representa la unidad funcional que le permite al
agente proveedor llevar a cabo una negociación. Esta clase también se instancia en el
momento en que una negociación es iniciada, pero en este caso el agente se crea en la
plataforma cuando el proceso Java es ejecutado. Sus atributos son similares a los del agente
municipal: el identificador del agente municipal (buyer: AID) como un acceso directo para
el envío de mensajes, y el identificador de conversación (conversationid:String) para el
control de conversaciones.
Figura 11 Diagrama de clases para los mecanismos de decisión del agente proveedor
La clase NegotiationElement es un concepto diferente para este caso. En el agente
municipal representa una restricción difusa, en el agente proveedor está asociado al
concepto producto. Cuenta con métodos para determinar el cumplimiento de restricciones
duras y para el cálculo de preferencia, entre otros.
Indudablemente, entre las funciones que tiene la Seller_Decision_Logic, la más
importante es la generación de ofertas potenciales. El método encargado de dicha tarea es
generatePotencialSaleOffers(); a continuación podemos observar su diagrama de
secuencia.
Figura 12 Diagrama de secuencia para la generación de ofertas potenciales
Cuando en el transcurso de la negociación se llega al comportamiento S3: Generate
Potencial Sale-Offers (clase S3_GeneratePSOffers) debe generarse una oferta potencial
debido a que el agente proveedor no pudo obtener de entre sus productos uno que se ajuste
exactamente al requerimiento del agente municipal. El comportamiento invoca al método
generatePotencialSaleOffers() para obtener dicha oferta. El requerimiento de compra actual
se almacena como un atributo dentro de la misma clase Seller_Decision_Logic. Como
mencionamos en capítulos anteriores, para obtener la oferta potencial es necesario calcular
el valor de preferencia de cada producto y quedarnos con aquel cuyo cálculo sea el mayor.
La clase NegotiationElement es la que lleva adelante este cálculo con el método getPrefer.
Interiormente se realizan otras operaciones anidadas, es decir, la preferencia necesita del
valor de viabilidad, que a su vez necesita de la sumatoria de operaciones con la distancia
entre el valor del atributo del producto y la restricción dura, que a su vez necesita del valor
de reserva y el boundary.
5.5 Resumen general
Anteriormente hemos introducido los conceptos del modelo de negociación
utilizado en la presente tesis y sus mecanismos. En este capítulo presentamos la
instanciación del mismo, es decir, se detalló cada una de las posibles formas de llevar a
cabo las tareas que deben realizar los mecanismos descriptos.
Cada uno de los participantes del modelo, Municipalidad y proveedor, poseen en
sus mecanismos estrategias y algoritmos que insumen un mayor grado de análisis. En el
caso del agente comprador o Municipal, las principales estrategias radican en la generación
de los requerimientos de compra y en la valoración de los mismos. Ambas estrategias se
basan en el cálculo del grado de satisfacción global potencial, y son parte fundamental de
las herramientas de argumentación con las que cuenta el agente. Por un lado permiten
plasmar el requerimiento de compra establecido por el usuario (el titular de la Oficina de
Compras) y la importancia de que ciertos atributos sean satisfechos, en términos que sean
entendidos por los agentes; y por otro establece los criterios con los que el agente puede
evaluar una oferta. La estrategia fundamental y que compone el núcleo del sistema de
argumentación del proveedor es sin duda la generación de ofertas potenciales. De esta
forma el agente puede conducir la negociación hacia espacios de soluciones que le resulten
más beneficiosos, teniendo en cuenta en la evaluación factores internos (el valor de
utilidad) y externos (la cercanía de un producto al requerimiento de compra recibido).
Estos mecanismos fueron implementados en el sistema de negociación que
acompaña a la tesis. En los siguientes capítulos desarrollamos dos casos de estudios para
presentar los resultados y verificar que el modelo de negociación funciona correctamente y
es sin dudas una herramienta importante para facilitar los procesos de compras en un
ámbito municipal.
Capítulo 6
Evaluación experimental
En el presente capítulo hacemos un análisis sobre dos casos de estudios basados en
la utilización del sistema de negociación automática desarrollado y que agrupa todos los
conceptos expuestos en la presente tesis. El primero de ellos presenta una situación de
negociación entre un Municipio y un proveedor con el fin de verificar los beneficios que
proporciona el sistema. El segundo caso de estudio evalúa la incidencia en la duración de
una negociación cuando se varían los diferentes parámetros que la componen (cantidad de
productos, número de atributos por producto, etc.).
6.1 Caso de estudio 1: Compra de una impresora
El primer caso de estudio consiste en entablar una negociación bilateral entre el
Municipio y un proveedor determinado para la adquisición de una impresora que se ajuste
(o se acerque) a las necesidades del comprador. La intención de este caso de estudio es
presentar el modelo y la implementación del sistema multiagente en forma práctica,
haciendo un análisis de cada paso de la negociación: el diálogo que se produce, los
diferentes cálculos llevados a cabo, las transiciones entre estados, etc. Además se
expondrán las conclusiones contrastándolas con un ámbito real.
6.1.1 Introducción
El caso contempla la necesidad de compra de una impresora para el área de Rentas.
El principal uso que se le pretendía dar era el de imprimir grandes lotes de recibos de tasas
municipales para ser repartidas entre los ciudadanos, por lo que debía ser una impresora
potente, rápida y de buena calidad.
La tarea de encontrar un modelo de impresora que se adapte a los atributos
indicados fue encomendada al área de Sistemas por considerarse más idónea. En el
transcurso de 2 horas se determinó que una buena opción era la impresora Lexmark
MS811dn. Los pedidos de cotización fueron entregados a cuatro proveedores registrados de
la Municipalidad. Dos de ellos no contaban con el producto en cuestión por lo que no
respondieron al pedido. De los dos restantes se optó por el de menor precio. Cabe señalar
que hasta la llegada de la última cotización se invirtieron 2 días para determinar el
proveedor al que finalmente se le efectuó la compra.
6.1.2 Desarrollo del caso de estudio
Este caso consiste de una negociación bilateral por lo que sólo contaremos con la
ejecución de dos agentes inteligentes, uno para cada parte. El vendedor dispone de un
catálogo de 78 impresoras, especificadas en atributos valorizados, los cuales son: precio (en
pesos), páginas por minuto (PPM), capacidad de entrada estándar (medido en hojas), ciclo
mensual de trabajo máximo (medido en hojas), consumo eléctrico (medido en vatios) y un
valor de calidad. Los valores para cada atributo fueron extraídos de un catálogo en la Web
(www.pixmania.es), a excepción de la calidad la cual es un valor arbitrario.
El catálogo contiene a la impresora Lexmark MS811dn con una utilidad de 0.99
sobre 1. La elección de este valor surge de la intención de verificar que la negociación será
conducida hacia dicho producto, por ser conveniente para el vendedor y por contar con
atributos aceptables para el comprador. Las características de esta impresora en términos de
lenguaje difuso son:
Precio: MEDIO
Páginas por minuto: MUY ALTO
Capacidad de entrada estándar: MEDIO
Ciclo mensual de trabajo máximo: MUY ALTO
Consumo eléctrico: MEDIO
Calidad: MUY ALTA
Es importante señalar que estas expresiones lingüísticas que definen los intervalos
difusos se consensuan entre las partes. Para facilitar este acuerdo, se establecen valores
máximos y mínimos a cada atributo. Luego, el intervalo formado entre ambos valores se
divide en subintervalos de iguales dimensiones los cuales se corresponden con cada término
lingüístico. Como ejemplo tomamos el atributo precio; establecemos un valor mínimo de
500 y un máximo de 18000. A este rango lo dividimos por cinco que es la cantidad de
términos lingüísticos que hemos utilizado (muy bajo, bajo, medio, alto y muy alto).
(18000 – 500) / 5 = 17500 / 5 = 3500
Esto significa que cada intervalo difuso para el atributo precio tiene una dimensión
de 3500 unidades. Por lo tanto, tenemos que para un precio muy alto su intervalo difuso se
compone de 18000 para el límite superior, y 18000 – 3500 = 14500 para el límite inferior.
En realidad el intervalo es [14501 – 18000], porque el valor 14500 representa el límite
superior para un precio alto.
Evidentemente el caso ideal a priori comprendería un precio y un consumo eléctrico
muy bajos y valores de PPM, capacidad de entrada estándar, ciclo mensual de trabajo
máximo y calidad muy altas. Aquí radica el desafío del presente caso de estudio: partiendo
de un requerimiento ideal por parte del comprador, la negociación debería ser conducida
hacia un producto real que sea igualmente satisfactorio para ambas partes.
6.1.2.1 Apertura del diálogo
Para la primera fase contamos con un agente vendedor ejecutándose en un servidor
y cuyo servicio de venta se encuentra registrado en las páginas amarillas de la plataforma
JADE. El servicio registrado sólo sirve de nexo entre agentes vendedores y compradores,
no indica ni las categorías ni los productos del catálogo con los que cuentan los vendedores.
A través de un navegador Web ingresamos a la página del comprador en la cual
especificamos la categoría (para este caso Impresora) y el requerimiento de compra a partir
de restricciones difusas. Como mencionamos anteriormente, planteamos el caso ideal para
el requerimiento de compra inicial, como puede observarse en la figura 13. Al momento de
indicar el inicio de la negociación (presionando el botón “Negociar!”), internamente se crea
un agente comprador en la misma plataforma del vendedor con toda la información
necesaria para desarrollar la negociación.
Figura 13 Selección del requerimiento de compra inicial
Cuando el agente comprador encuentra un servicio de venta en las páginas amarillas
contacta al vendedor enviándole la locución L1: open_dialogue generada por el mecanismo
B1: Recognize Need. En salida de este mecanismo (have_need) se especifica la categoría
Impresora que es el interés del comprador. El vendedor verifica la existencia de productos
en esa categoría, y al contar con los mismo responde con la locución L2: enter_dialogue
desde el mecanismo S1: Recognize Category dado que la salida generada fue un
wish_to_enter.
Aquí termina la fase de apertura del diálogo y comienza la de negociación.
Internamente ambos agentes cargan sus comportamientos y en particular el comprador
genera las restricciones difusas con las que negociará. En la tabla 13 se listan los atributos
de la categoría Impresora con sus intervalos difusos en forma de rangos de valores y sus
niveles de corte.
Niv. de corte
Precio PPM Capacidad de
entrada
estándar
Ciclo mensual de
trabajo máximo
Consumo
eléctrico
Calidad
1 [501, 4000] [60, 70] [941, 1150] [240161, 300100] [81, 364] [81, 100]
0.8 [4001, 7500] [49, 59] [731, 940] [180221, 240160] [365, 648] [61, 80]
0.6 [7501, 11000] [38, 48] [521, 730] [120281, 180220] [649, 932] [41, 60]
0.4 [11000, 14500] [27, 37] [311, 520] [60341, 120280] [933, 1216] [21, 40]
0.2 [14501, 18000] [16, 26] [101, 310] [401, 60340] [1217, 1500] [1, 20]
0 0 0 0 0 0 0
Tabla 13 Atributos, intervalos difusos y niveles de corte para la categoría Impresora
Se puede observar que los rangos de valores para el precio y el consumo eléctrico
difieren del resto, en el sentido de que a menor nivel de corte, los rangos crecen. Esto se
debe a que la penalización de relajar un atributo puede variar. Por ejemplo, un comprador
va a preferir un precio muy bajo a uno muy alto, pero va a querer una calidad muy alta a
una muy baja. Relajar el precio implica aceptar productos más caros, pero en el caso de la
calidad significa permitir un decrecimiento de la misma.
6.1.2.2 Negociación
La fase de negociación se inicia cuando el comprador emite su primer requerimiento
de compra. El agente a partir del mecanismo B2: Generate Purchase Requirement y
aplicando la estrategia de incorporación de nuevas restricciones selecciona la primera
restricción en forma aleatoria. Obtiene el atributo precio al azar y aplicando el nivel de
corte máximo, que para el caso inicial es de uno, se obtiene la restricción dura [501, 4000].
El agente conmuta al comportamiento que permite valorar el requerimiento aplicando el
mecanismo B3: Generate Purchase Requirement Valuation. Ejecutando el algoritmo de
valoración de requerimiento de compra presentado en la sección 5.2 obtenemos:
12.02.08.018.01 sumpreciovreqB
El valor de 0.8 es el grado de satisfacción global potencial para el precio, luego de
relajarlo una vez. Obtenido el primer requerimiento de compra reqB y su valoración, se
envían al vendedor a través de la locución L6: prefer_to_buy y se efectúa una transición al
comportamiento B: Delegator, que funciona como un conmutador donde, dependiendo el
mensaje recibido, delega en el comportamiento adecuado.
El agente vendedor, que luego de confirmar el inicio de la negociación se encuentra
en el estado S: Delegator, recibe prefer_to_buy por lo que conmuta al mecanismo S2:
Assess Purchase Requirement donde analizará la posibilidad de satisfacer el requerimiento
recibido con algún producto del catálogo. Aplicando el algoritmo de la sección 5.3 con su
función de selección de ofertas de venta (fsov) se obtiene la impresora BROTHER HL-
5450DN con los siguientes atributos:
Atributos Valor Valor difuso
Precio 2967.38 MUY BAJO
PPM 38 MEDIO
Capacidad de entrada estándar 150 MUY BAJO
Ciclo mensual de trabajo máximo 25000 MUY BAJO
Consumo eléctrico 665 MEDIO
Calidad 58 MEDIO
Tabla 14 Atributos de la impresora BROTHER HL-5450DN
El producto conseguido consta de un nivel de aceptación de uno (de un máximo de
uno) y fue el mayor obtenido. Esto se deprende de la aplicación de la función fsov, por lo
que:
10111 envíosdecantidadutilidadaceptación
Se observa que la utilidad del producto es de uno (de un máximo de uno) y la
cantidad de envíos es cero. Una vez obtenido el producto lo envía al comprador a través de
la locución L3: willing_to_sell y conmuta al comportamiento S: Delegator.
El comprador que se encuentra en B: Delgator al recibir la oferta conmuta al
comportamiento que contiene el mecanismo B4: Consider Offers. El producto cumple con
la restricción enviada, pero no cumple con las no enviadas por lo que la rechazará. Esto
implica que el comprador selecciona una nueva restricción aleatoriamente, que para este
caso resultó ser la calidad. Aplicando el máximo nivel de corte, que en este caso es de uno,
extrae la restricción dura [81, 100]. Luego conmuta al estado que contiene el mecanismo
B2: Generate Purchase Requirement donde extrae esta nueva restricción para luego valorar
el requerimiento de compra con B3: Generate Purchase Requirement Valuation. Aplicando
el mismo algoritmo presentado anteriormente obtenemos:
5.0,5.0
4.0
2.0,2.0
8.018.01
8.01,8.01,
sumcalidadpreciov
reqB
Se observa que las valoraciones son de 0.5 para ambas restricciones. Es decir, de la
valoración absoluta de 1 obtenida para el precio en el primer cálculo del algoritmo, ahora se
distribuye igualmente para ambas partes. Todo lo obtenido es enviado por L6:
prefer_to_buy y conmuta a B: Delegator.
Aquí el vendedor se comporta del mismo modo que en la primera recepción de
requerimiento: De S: Delegator conmuta a S2: Assess Purchase Requeriment para obtener
los productos que cumplan con el nuevo requerimiento enviado en L6. Son dos los
productos, ambos con utilidad de 0.99, mismo valor para el nivel de aceptación,
considerando que la cantidad de envíos es cero para los dos casos. Se obtiene uno
aleatoriamente, que resulta ser la BROTHER Impresora láser monócromo HL-2270DW
red.
Atributos Valor Valor difuso
Precio 1760.879 MUY BAJO
PPM 26 MUY BAJO
Capacidad de entrada estándar 250 MUY BAJO
Ciclo mensual de trabajo máximo 6000 MUY BAJO
Consumo eléctrico 495 BAJO
Calidad 94 MUY ALTO
Tabla 15 Atributos de la impresora BROTHER HL-2270DW
Luego es enviado al comprador a través de la locución L3: willing_to_sell y
conmuta al comportamiento S: Delegator.
El comprador recibe con L3: willing_to_sell la oferta y conmuta a B4: Consider
Offers para evaluarla. No la acepta por lo mismo que anteriormente: no cumple con
restricciones no enviadas. Selecciona una nueva restricción al azar que resulta ser páginas
por minutos (PPM). La restricción dura que se extrae de aplicar el máximo nivel de corte es
[60, 70]. Conmuta a B2 para extraerla y luego a B3 para valorarla. La valoración resulta en
el siguiente cálculo:
33.0,33.0,33.0
6.0
2.0,2.0,2.0
8.018.018.01
8.01,8.01,8.01,,
sumcalidadPPMpreciov
reqB
El requerimiento con su valoración es enviado por L6: prefer_to_buy y conmuta a
B: Delegator.
El vendedor recibe el mensaje y conmuta a S2. Busca en su catálogo un producto
que cumpla con el requerimiento recibido y en este punto descubre que no cuenta con uno,
por lo que ingresa al mecanismo S3: Generate Potencial Sale-Offers para seleccionar una
oferta potencialmente buena hacia donde conducir la negociación. Como mencionamos
anteriormente, este mecanismo constituye el núcleo del sistema de argumentación del
vendedor, por lo que cabe detallar su funcionamiento. La impresora seleccionada por el
mecanismo es Lexmark MS811dn cuyos atributos son:
Atributos Valor Valor difuso
Precio 8267.08 MEDIO
PPM 63 MUY ALTO
Capacidad de entrada estándar 650 MEDIO
Ciclo mensual de trabajo máximo 275000 MUY ALTO
Consumo eléctrico 770 MEDIO
Calidad 90 MUY ALTO
Tabla 16 Atributos de la impresora LEXMARK MS811dn
La función que rige la elección de una oferta potencial es prefer presentada en la
sección 5.3. La iremos desmembrando para explicar los resultados obtenidos. Recordemos
que:
reqreq B
t
Bjjj vpviabilityusprefer ,,1)(
Reemplazando las variables por sus valores, y teniendo en cuenta que la utilidad del
producto es de 0.99 y que = 0.5, el resultado obtenido es:
0.89975 0.80955.099.05.0)( jsprefer
Ahora analizaremos la función de viabilidad. Como mencionamos en la sección 5.3,
la viabilidad depende del grado de similitud entre cada producto del catálogo y el
requerimiento de compra, y de la valoración que el comprador calculó para dicho
requerimiento. Es decir, la viabilidad aglutina los conceptos de similaridad (entre productos
y requerimiento) y estimación de la valoración del comprador. Haber obtenido en esta
primera instancia un producto muy próximo a la necesidad del comprador demuestra la
efectividad de la función de viabilidad.
Las entradas para esta función son:
El requerimiento en forma de restricciones duras. En este punto de la negociación
contamos con [501, 4000] para el precio, [60, 70] para páginas por minuto y [81,
100] para la calidad.
La valoración del requerimiento que en nuestro caso es:
33.0,33.0,33.0,, calidadPPMpreciovreqB
El producto que se está evaluando, concretamente sus atributos. Solo
consideraremos el que finalmente fue el que obtuvo la mayor preferencia.
De la función de viabilidad presentada en la sección 5.3, nos enfocaremos en la
expresión )/)),(( 2
)(1
,, nvadist it
reqBreq boundary
n
i
it
Bji
. Comenzaremos con el precio para el
cálculo de la distancia. El producto tiene un precio de 8267.08, es un valor fuera de la
restricción dura [501, 4000] por lo que la distancia no es de cero. En este punto debemos
calcular los valores de reserva res
ia (hasta dónde podría relajar el comprador) y el límite
más lejano (boundary). El primero lo definimos arbitrariamente como el promedio de todos
los valores del atributo para todos los productos que componen el catálogo. El precio
promedio es de 4569.18 y es por tanto el valor de reserva. El límite más lejano es un tanto
más complejo. A partir de la restricción dura, debemos obtener uno de los dos valores que
definen el rango cuya distancia al atributo del producto es la más lejana. Para este caso
tenemos que 501 (límite menor de la restricción) se encuentra a 7766.08 unidades de
8267.08 (valor del atributo), y que 4000 (límite mayor) se encuentra a 4267.08 unidades,
por lo que el valor de boundary es 501. El próximo paso es verificar si el valor del atributo
se encuentra dentro del intervalo formado por el valor de reserva y el límite más lejano, es
decir, comprobar si 8267.08 está dentro de [501, 4569.18]. Claramente no lo está, entonces
la distancia es de 1, la máxima posible. Por lo tanto, aplicando la expresión antes
mencionada, tenemos que para la primera iteración de la sumatoria, considerando el precio
y n = 3 (cantidad de atributos hasta el momento):
0363.03/33.0*1)/),(22
)(
,, nvadist it
reqBreq boundary
it
Bji
Ahora analizaremos las páginas por minuto o PPM. El valor del atributo para el
producto es de 63, y teniendo en cuenta que la restricción dura enviada por el comprador es
de [60, 70], podemos decir que la distancia es de cero por encontrarse dentro del intervalo.
Esto no afecta a la iteración de la sumatoria.
Con la calidad ocurre algo similar. El valor para el atributo es de 90 y la restricción
dura es [81, 100], por lo que nuevamente la distancia es cero y tampoco afecta a la
sumatoria.
Finalmente podemos determinar el valor de viabilidad reemplazando su función
(sección 5.3):
8095.0)0363.0(1 sqrtviability
El valor de preferencia de 0.89975 es el máximo obtenido entre todos los productos
y nos indica que el vendedor cuenta con una opción igualmente beneficiosa para ambas
partes: se acerca al requerimiento del comprador y a su vez le reporta una utilidad más que
aceptable. Luego de esto, el vendedor conmuta al mecanismo S4: Generate Relax
Requirement para indicarle al comprador cuáles restricciones deberían ser relejadas.
El algoritmo del mecanismo analiza cuáles restricciones del requerimiento de
compra son satisfechas y cuáles no por el producto seleccionado anteriormente.
Observando los valores, el único atributo no satisfecho es el precio, por lo que el
mecanismo retorna el vector (1, 0, 0) para (precio, PPM, calidad). Este requerimiento de
relajación reqB es enviado al comprador en la locución L5: prefer_to_sell, y luego
conmuta al estado S: Delegator.
El comprador, que se encontraba en B: Delegator, conmuta a B2: Generate
Purchase Requirement luego de recibir el mensaje del vendedor. Nuevamente se debe
aplicar la función de modificación de requerimiento de compra, puntualmente el algoritmo
de la sección 5.2 que la define, pero con una diferencia importante: existe un requerimiento
de relajación que debe ser tenido en cuenta.
El primer paso es obtener un vector con los grados de satisfacción global potencial
que surgen de relajar cada restricción una vez, y cuyo grado es igual al máximo.
Recordemos que ninguna de las tres restricciones fue relajada aun, por lo que el
nivel de corte para cada una de ellas se encuentra en 1 (el máximo posible).
Relajando cada una y obteniendo el valor máximo nos queda un grado de
satisfacción global potencial de 0.8, y un vector con las tres restricciones.
Finalmente aplicamos la última función del algoritmo:
x
xkt
reqB
kttr
máx
)1(
max
1
max ,
arg
Teniendo en cuenta que 1xkr solamente para el precio, tenemos que el valor
máximo de la función anterior es 0.8 + 1 = 1.8 y por consiguiente es este atributo el único
que se corresponde con dicho valor, por lo que es el elegido para ser relajado. Su nivel de
corte pasa a ser 0.8 y la restricción dura que se obtiene de él es [501, 7500]. El próximo
paso es valorar el requerimiento en B3: Generate Purchase Requirement Valuation.
Aplicando el mismo principio del algoritmo explicado anteriormente tenemos que:
25.0,25.0,5.08.0
2.0,2.0,4.0
8.018.016.01
8.01,8.01,6.01,,
sumcalidadPPMpreciov
reqB
El requerimiento junto con su valuación es enviado al vendedor a través de la
locución L6: prefer_to_buy y conmuta a B: Delegator.
Hasta este punto hemos demostrado el funcionamiento de los mecanismos que
componen la fase de negociación. El resto se desarrolla de forma similar por lo que nos
limitaremos a presentar en forma resumida el paso a paso de la negociación.
Comprador Vendedor
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene el producto BROTHER Impresora láser monocromo
HL-2270DW red (utilidad: 0.99) cuyas características son:
Precio: 1760.879 (MUY BAJO)
PPM: 26 (MUY BAJO)
Capacidad: 250 (MUY BAJO)
Ciclo: 6000 (MUY BAJO)
Consumo: 495 (BAJO)
Calidad: 94 (MUY ALTO)
Preferencia: 0.92283
Viabilidad: 0.8556
Cálculo:
- Precio: se cumple. La distancia es 0.
- PPM: Valor de reserva=32.307; boundary=70; Distancia=1.
- Calidad: se cumple. La distancia es 0.
Sumatoria: 02083
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (0, 1, 0) para (precio, PPM,
calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta
a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.8
- El vector con cálculos máximos se compone solo de PPM,
por lo que será relajado.
- Corte de PPM: 0.8.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 7500] al corte de 0.8. Valoración: 0.4
- PPM: [49, 70] al corte de 0.8. Valoración: 0.4
- Calidad: [81, 100] al corte de 1. Valoración: 0.2
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene el producto BROTHER HL-5450DN (utilidad: 1) cuyas
características son:
Precio: 2967.38 (MUY BAJO)
PPM: 38 (MEDIO)
Capacidad: 150 (MUY BAJO)
Ciclo: 25000 (MUY BAJO)
Consumo: 665 (MEDIO)
Calidad: 58 (MEDIO)
Preferencia: 0.8862
Viabilidad: 0.7724
Cálculo:
- Precio: se cumple. La distancia es 0.
- PPM: VR=32.307; boundary=70; Dist.= 0.85.
- Calidad: VR=60.295; boundary=100; Dist.= 1.
Sumatoria: 0.05177
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (0, 1, 1) para (precio, PPM,
calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta
a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.8
- El vector con cálculos máximos se compone solo de Calidad,
por lo que será relajada.
- Corte de Calidad: 0.8.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 7500] al corte de 0.8. Valoración: 0.33
- PPM: [49, 70] al corte de 0.8. Valoración: 0.33
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.33
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene el producto Lexmark MS811dn (utilidad: 0.99) cuyas
características se encuentran en la tabla 16:
Preferencia: 0.8988
Viabilidad: 0.80754
Cálculo:
- Precio: VR=4569.1825; boundary=501; Dist.=1.
- PPM: se cumple. La distancia es 0.
- Calidad: se cumple. La distancia es 0.
Sumatoria: 0.05177
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (1, 0, 0) para (precio, PPM,
calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta
a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.6
- El vector con cálculos máximos se compone solo de Precio,
por lo que será relajado.
- Corte de Precio: 0.6.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 11000] al corte de 0.6. Valoración: 0.4285
- PPM: [49, 70] al corte de 0.8. Valoración: 0.2857
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.2857
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 obtuvo el producto Lexmark MS811dn (utilidad: 0.99) con un
nivel de aceptación de 0.33.
Aumenta la cantidad de envíos del producto. Lo envía a través de L3:
willing_to_sell. Conmuta a S: Delgator.
En B: Delegator recibe L3: willing_to_sell. Conmuta a B4 para
evaluar la oferta.
En B4 determina que cumple con las restricciones enviadas. Pero
hay restricciones no enviadas que no fueron cumplidas. Por lo tanto
no acepta la oferta. Selecciona al azar una nueva restricción que
resultó ser Consumo eléctrico. Conmuta a B2.
En B2 extrae el requerimiento y conmuta a B3.
En B3 valoriza el requerimiento
Restricciones y valoraciones a enviar:
- Precio: [501, 7500] al corte de 0.8. Valoración: 0.375
- PPM: [49, 70] al corte de 0.8. Valoración: 0.25
- Consumo: [81, 364] al corte de 1. Valoración: 0.125
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.25
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad:
0.99):
Preferencia: 0.96375
Viabilidad: 0.9375
Cálculo:
- Precio: se cumple. La distancia es 0.
- PPM: se cumple. La distancia es 0.
- Consumo: VR=604.359; boundary=81; Dist.=1.
- Calidad: se cumple. La distancia es 0.
Sumatoria: 0.00391
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (0, 0, 1, 0) para (precio, PPM,
consumo, calidad). Lo envía a través de la locución L5: prefer_to_sell.
Conmuta a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.8
- El vector con cálculos máximos se compone solo de
Consumo, por lo que será relajado.
- Corte de Consumo: 0.8.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 11000] al corte de 0.6. Valoración: 0.33
- PPM: [49, 70] al corte de 0.8. Valoración: 0.22
- Consumo: [81, 648] al corte de 0.8. Valoración: 0.22
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.22
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad:
0.99):
Preferencia: 0.9395
Viabilidad: 0.88
Cálculo:
- Precio: se cumple. La distancia es 0.
- PPM: se cumple. La distancia es 0.
- Consumo: VR=604.359; boundary=81; Dist.=1.
- Calidad: se cumple. La distancia es 0.
Sumatoria: 0.01235
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (0, 0, 1, 0) para (precio, PPM,
consumo, calidad). Lo envía a través de la locución L5: prefer_to_sell.
Conmuta a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.6
- El vector con cálculos máximos se compone solo de
Consumo, por lo que será relajado.
- Corte de Consumo: 0.6.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 11000] al corte de 0.6. Valoración: 0.3
- PPM: [49, 70] al corte de 0.8. Valoración: 0.3
- Consumo: [81, 932] al corte de 0.6. Valoración: 0.3
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.2
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 obtuvo el producto Lexmark MS811dn (utilidad: 0.99) con un
nivel de aceptación de 0.25.
Aumenta la cantidad de envíos del producto. Lo envía a través de L3:
willing_to_sell. Conmuta a S: Delgator.
En B: Delegator recibe L3: willing_to_sell. Conmuta a B4 para
evaluar la oferta.
En B4 determina que cumple con las restricciones enviadas. Pero
hay restricciones no enviadas que no fueron cumplidas. Por lo tanto
no acepta la oferta. Selecciona al azar una nueva restricción que
resultó ser Capacidad de entrada estándar. Conmuta a B2.
En B2 extrae el requerimiento y conmuta a B3.
En B3 valoriza el requerimiento
Restricciones y valoraciones a enviar:
- Precio: [501, 11000] al corte de 0.6. Valoración: 0.2727
- PPM: [49, 70] al corte de 0.8. Valoración: 0.1818
- Capacidad: [941, 1150] al corte de 1. Valoración: 0.0909
- Consumo: [81, 932] al corte de 0.6. Valoración: 0.2727
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.1818
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad:
0.99):
Preferencia: 0.9823
Viabilidad: 0.9746
Cálculo:
- Precio: se cumple. La distancia es 0.
- PPM: se cumple. La distancia es 0.
- Capacidad: VR=350.5641; boundary=1150; Dist.= 0.62544.
- Consumo: se cumple. La distancia es 0.
- Calidad: se cumple. La distancia es 0.
Sumatoria: 0.0006466
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (0, 0, 1, 0, 0) para (precio,
PPM, capacidad, consumo, calidad). Lo envía a través de la locución
L5: prefer_to_sell. Conmuta a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.8
- El vector con cálculos máximos se compone solo de
Capacidad, por lo que será relajada.
- Corte de Capacidad: 0.8.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 11000] al corte de 0.6. Valoración: 0.25
- PPM: [49, 70] al corte de 0.8. Valoración: 0.166
- Capacidad: [731, 1150] al corte de 0.8. Valoración: 0.166
- Consumo: [81, 932] al corte de 0.6. Valoración: 0.25
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.166
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 no obtuvo ningún producto que cumple con el requerimiento.
Conmuta a S3.
En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad:
0.99):
Preferencia: 0.9717
Viabilidad: 0.9534
Cálculo:
- Precio: se cumple. La distancia es 0.
- PPM: se cumple. La distancia es 0.
- Capacidad: VR=350.5641; boundary=1150; Dist.= 0.62544.
- Consumo: se cumple. La distancia es 0.
- Calidad: se cumple. La distancia es 0.
Sumatoria: 0.0021732
Una vez obtenido el producto conmuta a S4.
En S4 genera el vector de relajamiento (0, 0, 1, 0, 0) para (precio,
PPM, capacidad, consumo, calidad). Lo envía a través de la locución
L5: prefer_to_sell. Conmuta a S: Delegator.
En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2.
Estando en B2 se obtiene:
- Máx. Grado de Satisfacción Global Potencial: 0.6
- El vector con cálculos máximos se compone solo de
Capacidad, por lo que será relajada.
- Corte de Capacidad: 0.6.
Conmuta a B3 para valorar el requerimiento.
Restricciones y valoraciones a enviar:
- Precio: [501, 11000] al corte de 0.6. Valoración: 0.2308
- PPM: [49, 70] al corte de 0.8. Valoración: 0.15385
- Capacidad: [521, 1150] al corte de 0.6. Valoración: 0.2308
- Consumo: [81, 932] al corte de 0.6. Valoración: 0.2308
- Calidad: [61, 100] al corte de 0.8. Valoración: 0.15385
Envía L6: prefer_to_buy y conmuta a B: Delegator.
En S: Delegator.
En B:Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2.
En S2 obtuvo el producto Lexmark MS811dn (utilidad: 0.99) con un
nivel de aceptación de 0.11.
Aumenta la cantidad de envíos del producto. Lo envía a través de L3:
willing_to_sell. Conmuta a S: Delgator.
Tabla 17 Porción de la negociación entre el agente proveedor y el municipal
Nos detenemos en este punto de la negociación en que el comprador evaluará la
oferta en el mecanismo B4: Consider Offers. Verifica el cumplimiento de las restricciones y
determina que las enviadas y las no enviadas fueron satisfechas por la oferta recibida. Por
lo que queda calcular los grados de satisfacción para inferir si la oferta es aceptable o no.
Recordemos que una oferta es aceptable si el grado de satisfacción global Xv es
mayor o igual al grado de satisfacción global potencial reqB del requerimiento de compra
reqB . El grado de satisfacción global se compone del mínimo grado de pertenencia. Para
decirlo de una manera sencilla, de cada valor de los atributos del producto se determina el
intervalo difuso en el que está contenido. Ese intervalo tiene asociado un grado de
pertenencia que no es otra cosa que el nivel de corte del intervalo. Analizando el producto
recibido tenemos que:
Atributos Valor Intervalo difuso al que
pertenece
Grado de pertenencia
Precio 8267.08 [7501, 11000] 0.6
PPM 63 [60, 70] 1
Capacidad de entrada estándar 650 [521, 730] 0.6
Ciclo mensual de trabajo máximo 275000 [240161, 300100] 1
Consumo eléctrico 770 [649, 932] 0.6
Calidad 90 [81, 100] 1
Tabla 18 Situación de la negociación en el tramo final
Observando la tabla vemos que el menor grado de pertenencia es 0.6, por lo que este
es el grado de satisfacción global.
El grado de satisfacción global potencial es el mínimo nivel de corte utilizado para
extraer las restricciones duras que compusieron el último requerimiento de compra enviado.
Para nuestro caso este valor es 0.6. En conclusión, ambos grados de satisfacción son
equivalentes por lo que la oferta debe ser aceptada. En este punto se inicia la fase de
confirmación.
6.1.2.3 Confirmación y Cierre del Diálogo
En este punto nos encontramos que el comprador, a partir del mecanismo B4:
Consider Offers determina que la oferta es satisfactoria y por lo tanto la acepta. El agente
emite la locución L9: agree_to_buy y conmuta al mecanismo B: Delegator. El vendedor
que se encontraba en S: Delegator, al recibir la confirmación del comprador cambia al
estado S5: Accept or Reject Offer. Cabe señalar que el agente vendedor tiene un
comportamiento no estratégico, es decir, no especula con relajaciones por parte del
comprador aun contando con el producto que satisface su requerimiento, a fin de mejorar
sus beneficios. El agente cuenta con el producto por lo tanto emite la aceptación de la
confirmación a partir de la locución L10: agree_to_sell.
El cierre del diálogo se produce luego del envío de la locución L11:
withdraw_dialogue por parte de ambos agentes. Luego de esto, el comprador se destruye y
el vendedor sigue su ejecución a la espera de nuevas aperturas de diálogos7.
7 Es importante destacar que los agentes comprador y vendedor tienen comportamientos concurrentes, es decir, pueden llevar adelante diferentes negociaciones sin inconvenientes. El comprador es destruido porque cada vez que se inicia una negociación desde la interface de usuario, se crea un nuevo agente, por lo que nunca se darán negociaciones paralelas. Esto no ocurre con el vendedor el cual puede recepcionar en cualquier instante la apertura de un nuevo diálogo.
6.1.3 Conclusión del caso de estudio
El primer caso de estudio demuestra la efectividad del marco de negociación
automática que elegimos como base para la presente tesis. En el experimento se
establecieron condiciones iniciales con las que podían evidenciarse un producto ganador. El
desafío pasó por demostrar que el algoritmo tendiera a negociar dicho producto, y así lo
fue. Podemos inferir que bajo condiciones reales, una negociación será conducida hacía la
mejor opción para ambas partes.
Haciendo un seguimiento de la ejecución pudimos observar también la flexibilidad
del sistema para adaptarse a posibles cambios en el catálogo. En los mecanismo S2: Assess
Purchase Requirement y S3: Generate Potencial Sale-Offers el proveedor “interactúa” con
su catálogo el cual pudo haber sido modificado previamente. Para el primer caso, el agente
debe obtener un producto que cumpla con el requerimiento del comprador. Si uno de ellos
es eliminado del catálogo o alguno de sus atributos es modificado, no será considerado en
este mecanismo o bien no cumplirá con el requerimiento de compra (aun cuando
posiblemente se haya tenido en cuenta previamente en la negociación). Lo mismo ocurre
para el mecanismo S3 en donde, cualquier cambio en los valores de los atributos afectará
directamente a la función de preferencia relegando algún producto que anteriormente pudo
ser una oferta potencial. Evidentemente un producto eliminado tampoco será contemplado
en este mecanismo.
Un atributo destacable del sistema es su buena usabilidad, potenciada por el uso de
restricciones difusas para la definición de los requerimientos. En un ámbito real, la Oficina
de Compras (la cual no tiene por qué saber de impresoras) establece las condiciones
iniciales en el sistema de una forma fácil e intuitiva de acuerdo a las necesidades de compra
de algún sector municipal (en este caso el área de Rentas).
Indudablemente el aspecto más importante que evidencia los beneficios de utilizar
un marco de negociación automática respecto a un ámbito de compra real es la
minimización del tiempo que transcurre desde el momento que se plantea la necesidad
hasta que se acuerda con un proveedor la adquisición del producto. Como mencionamos en
la introducción del capítulo, el tiempo real que se invirtió en determinar la mejor opción de
compra a un determinado proveedor fue de 2 días, considerando el tiempo insumido en el
pedido y recepción de cotizaciones, y la selección de la impresora a comprar. La
negociación automática insumió un tiempo considerablemente menor: desde el momento en
que se inició la negociación hasta su finalización satisfactoria transcurrieron
aproximadamente 4 minutos. Vale aclarar que este tiempo puede variar en diferentes
negociaciones, aun estableciendo iguales condiciones iniciales, debido a que en ciertos
puntos existen decisiones aleatorias que pueden prolongar o acortar el tiempo transcurrido.
En este sentido, en el caso de estudio 2 se analizará la performance del sistema cuando se
negocia varias veces sobre un mismo catálogo, como así también, cuando se varía la
cantidad de productos y de atributos por producto del catálogo con el que cuenta el
proveedor.
6.2 Caso de estudio 2: Análisis de performance
La intención de este caso de estudio es llevar a cabo un análisis de las variaciones
en los tiempos que insume una negociación cuando se modifican la cantidad de productos
con los que cuenta el proveedor en su catálogo, y el número de atributos para cada uno de
ellos. Incluso, como mencionamos en la conclusión del caso de estudio anterior,
expondremos la variación del tiempo para una determinada cantidad de negociaciones
sobre un mismo catálogo.
6.2.1 Introducción
Para el análisis de las duraciones de las negociaciones, implementamos un proceso
generador de catálogos. Indicando la cantidad de productos y de atributos para cada uno de
ellos, se crearon diferentes catálogos que demostrarán la variabilidad de los tiempos. Con el
fin de brindar transparencia al caso de estudio, se determinaron valores en forma aleatoria,
como ser: la utilidad de cada producto (un número entre 0 y 1), los valores para los
atributos (entre 0 y 1000), y si cada uno de los atributos es incremental o no.
Se generaron catálogos de 10, 50, 100 y 500 productos; con 2, 5 y 10 atributos por
producto, lo que da como resultado 12 catálogos diferentes. A su vez, con el propósito de
evaluar la incidencia en el tiempo de negociación por parte de los atributos incrementales
sobre los no incrementales, agregamos dos catálogos de 50 productos cada uno, con 5
atributos incrementales para uno de ellos y 5 no incrementales para el otro.
Se llevaron a cabo 20 negociaciones por cada catálogo utilizando el portal de
compras, como lo haría el Sector de Compras. Luego, por cada escenario se calcularon la
media y la desviación estándar de los tiempos insumidos en todas las negociaciones para
cada análisis. Además, se estableció un valor difuso MEDIO para todos los atributos en los
requerimientos de compra.
6.2.2 Diez productos
A continuación presentamos los tiempos insumidos en cada negociación para un
catálogo de diez productos. En las dos últimas filas se observan los cálculos de la media y
la desviación estándar para cada conjunto de atributos.
Número de
ejecución
2 atributos 5 atributos 10 atributos
1 0:00:38 0:01:17 0:01:38
2 0:00:40 0:01:34 0:03:09
3 0:00:36 0:01:37 0:02:02
4 0:00:36 0:01:56 0:02:02
5 0:00:37 0:01:38 0:03:10
6 0:00:38 0:01:39 0:02:36
7 0:00:36 0:01:45 0:02:48
8 0:00:37 0:01:41 0:03:31
9 0:00:39 0:01:57 0:03:14
10 0:00:37 0:01:15 0:03:49
11 0:00:38 0:01:41 0:02:40
12 0:00:37 0:01:38 0:02:38
13 0:00:36 0:01:22 0:01:27
14 0:00:38 0:02:04 0:01:34
15 0:00:38 0:01:11 0:02:09
16 0:00:39 0:01:52 0:02:04
17 0:00:39 0:01:49 0:02:15
18 0:00:38 0:01:38 0:02:56
19 0:00:39 0:01:22 0:02:02
20 0:00:40 0:01:40 0:01:41
Media: 00:00:38 00:01:38 00:02:28
Desv. Estándar: 0,0000148 0,0001675 0,0004754
Tabla 19 Duraciones, media y desviación estándar para un catálogo de 10 productos
En la tabla 19 podemos observar, que para un catálogo pequeño las negociaciones
son de poca duración. De los valores de desviación estándar también podemos apreciar que
no existen grandes variaciones entre los tiempos respecto de las medias.
Para los catálogos generados aleatoriamente, se logró llegar a resultados
satisfactorios en los casos de 2 y 5 atributos en donde siempre se obtuvo el mismo producto
para todas las negociaciones. No fue el mismo caso para 10 atributos donde en todas las
negociaciones los participantes se retiraron sin llegar a un acuerdo. Evidentemente, es más
probable llegar a un acuerdo cuando la cantidad de atributos a negociar es poca.
Con el fin de visualizar los resultados obtenidos, más precisamente los valores de
las medias, en forma gráfica, presentamos en la figura 14 una representación en gráfico de
líneas. El eje X se relaciona a la cantidad de atributos y el eje Y a las duraciones en
promedio de cada negociación.
Figura 14 Gráfico de líneas para un catálogo de 10 productos
La representación gráfica muestra que entre 2 y 5 atributos hay un mayor
crecimiento en relación a los atributos 5 y 10. El tiempo insumido por los productos de 5
atributos es 2,6 veces mayor que el de 2 atributos. En cambio el de 10 atributos es 1,51
veces el tiempo que insumió la negociación para 5 atributos. Esto indica que con un número
pequeño de productos en el catálogo, a mayor cantidad de atributos la negociación no
durará mucho más que las anteriores. La causa es que la negociación se trunca porque el
proveedor no puede obtener productos candidatos debido a su corto catálogo, esto dispara
solicitudes de relajación de las restricciones del requerimiento de compra. El agente que
representa al Municipio llega a un punto donde ya no pueda relajar sus restricciones por lo
que se retira de la negociación. Esta situación no variará demasiado aumentando la cantidad
de atributos. En cambio, aumentando el tamaño del catálogo, se obtienen productos
candidatos, aún avanzada la negociación, por lo que implicará más intercambio de mensajes
entre los agentes y un aumento en la duración.
6.2.3 Cincuenta productos
En la tabla 20 observamos las duraciones de las negociaciones, la media y la
desviación estándar para un catálogo de 50 productos.
Número de
ejecución
2 atributos 5 atributos 10 atributos
1 00:00:48 00:06:32 00:19:00
2 00:00:48 00:06:16 00:18:28
3 00:00:48 00:08:01 00:24:06
4 00:00:49 00:05:55 00:25:58
5 00:00:48 00:05:40 00:15:47
6 00:00:50 00:05:46 00:26:54
7 00:00:48 00:06:28 00:25:05
8 00:00:49 00:08:05 00:15:47
9 00:00:48 00:05:30 00:16:17
10 00:00:49 00:06:22 00:18:55
11 00:00:52 00:06:16 00:25:48
12 00:00:52 00:06:30 00:19:16
13 00:00:48 00:05:34 00:24:13
14 00:00:50 00:05:52 00:24:58
15 00:00:49 00:06:21 00:22:55
16 00:00:51 00:06:13 00:19:18
17 00:00:50 00:05:49 00:19:11
18 00:00:48 00:05:29 00:20:28
19 00:00:50 00:05:45 00:23:50
20 00:00:50 00:06:20 00:24:23
Media: 00:00:49 00:06:14 00:21:32
Desv. Estándar: 0,0000154 0,0004933 0,0025356
Tabla 20 Duraciones, media y desviación estándar para un catálogo de 50 productos
Observamos tiempos mayores en la duración de las negociaciones. Las desviaciones
de los valores respecto de las medias no son significativas. Al igual que el catálogo de 10
productos, los casos de 2 y 5 atributos obtuvieron un mismo producto como resultado de la
negociación para cada caso; en cambio para 10 atributos no hubo acuerdo. A continuación,
en la figura 15, presentamos el gráfico de líneas.
Figura 15 Gráfico de líneas para un catálogo de 50 productos
A simple vista se aprecia un mayor crecimiento en la duración para el catálogo de
10 atributos. Cuando son pocos los atributos negociables, es más probable que el proveedor
cuente con productos que se acerquen al requerimiento de compra, por lo que a priori la
duración de la negociación será corta y en la mayoría de los casos se llegará a un acuerdo.
Con 10 atributos por negociar y un catálogo un poco más nutrido que el caso anterior, el
proveedor contará con productos que orienten la negociación a buen puerto. Pero a medida
que el agente municipal le entregue nuevas restricciones, el proveedor deberá reconducir la
negociación hacia nuevas alternativas. Sumado a la posibilidad de no contar con productos
que se ajusten al requerimiento de compra en varios puntos de la negociación, se alargará la
duración y, como en este caso, se concluirá sin llegar a un acuerdo.
6.2.4 Cien productos
Al igual que los casos anteriores, presentamos la tabla 21 con los valores resultantes
de las pruebas.
Número de
ejecución
2 atributos 5 atributos 10 atributos
1 00:01:34 00:22:28 00:54:58
2 00:01:42 00:20:34 00:45:28
3 00:01:33 00:19:34 00:53:17
4 00:01:39 00:20:44 00:39:31
5 00:01:33 00:22:03 00:54:22
6 00:01:40 00:20:49 00:56:18
7 00:01:35 00:22:30 00:54:47
8 00:01:39 00:21:18 00:44:57
9 00:01:40 00:22:00 00:57:04
10 00:01:39 00:22:35 00:46:49
11 00:01:32 00:19:55 00:54:30
12 00:01:38 00:19:22 00:50:22
13 00:01:47 00:20:36 00:56:25
14 00:01:35 00:22:14 00:57:07
15 00:01:34 00:20:37 00:55:38
16 00:01:36 00:19:52 00:53:12
17 00:01:39 00:19:52 00:45:17
18 00:01:48 00:20:56 00:42:27
19 00:01:42 00:19:49 00:54:22
20 00:01:35 00:19:33 00:48:54
Media: 00:01:38 00:20:52 00:51:17
Desv. Estándar: 0,0000514 0,0007614 0,0037487
Tabla 21 Duraciones, media y desviación estándar para un catálogo de 100 productos
Como era de esperarse, las duraciones son mayores respecto a los casos anteriores.
Las desviaciones estándar siguen siendo mínimas para los tres casos. Todas las
negociaciones terminaron en acuerdos, pero ocurrieron algunas particularidades: para 2
atributos, al igual que las pruebas anteriores, se obtuvo un único producto; pero para los
casos de 5 y 10 atributos se acordaron la compra de 4 y 2 productos respectivamente
distribuidos entre las diferentes negociaciones. Esta peculiaridad se debe a dos factores: por
un lado, a ciertas similitudes entre productos que se encuentran en los catálogos generados;
y por el otro, la aleatoriedad con que el agente municipal entrega las restricciones del
requerimiento de compra al proveedor. Cada vez que se deben proporcionar nuevas
restricciones, se selecciona en forma aleatoria un de ellas del conjunto de restricciones
difusas que componen el requerimiento de compra. Esta nueva restricción, sumado al hecho
de contar en el catálogo con productos similares en características, provoca que el
proveedor conduzca la negociación hacia una alternativa u otra. Estos quiebres en el
proceso de negociación determinan acuerdos donde el producto final varía respecto a otras
ejecuciones.
Figura 16 Gráfico de líneas para un catálogo de 100 productos
En el gráfico de líneas de la figura 16 observamos que no hay un crecimiento muy
pronunciado entre los diferentes valores de atributos; incluso se puede decir que el aumento
en las duraciones, a medida que se agregan atributos, es prácticamente lineal. Aunque el
crecimiento entre 2 y 5 atributos es levemente superior al de 5 y 10 atributos, no es un caso
comparable al catálogo de 10 productos donde este último crecimiento cae abruptamente.
Esto significa que, aumentando la cantidad de atributos, la duración de la negociación es
mayor aun superando los 10 atributos, pero sin producirse un “achatamiento” en los
tiempos por los motivos mencionados en las pruebas con 10 productos.
6.2.5 Quinientos productos
En la tabla 22, observamos los resultados obtenidos de las diferentes negociaciones.
Número de
ejecución
2 atributos 5 atributos 10 atributos
1 00:05:07 00:25:07 04:19:56
2 00:05:09 00:24:54 03:02:39
3 00:05:28 00:43:20 04:12:55
4 00:04:57 00:37:30 04:18:13
5 00:05:13 00:25:53 04:33:57
6 00:05:11 00:29:01 02:44:28
7 00:05:07 00:38:21 04:35:56
8 00:05:05 00:41:33 03:24:26
9 00:05:01 00:36:25 03:14:31
10 00:05:06 00:42:05 03:16:32
11 00:05:07 00:24:25 04:27:34
12 00:05:05 00:44:46 04:29:32
13 00:05:15 00:56:14 03:29:55
14 00:05:23 00:58:38 04:33:59
15 00:05:32 00:40:10 04:26:41
16 00:05:21 00:27:25 03:14:13
17 00:05:12 01:01:06 02:47:12
18 00:05:38 01:03:58 03:29:22
19 00:05:23 00:41:29 03:35:01
20 00:05:12 00:27:45 03:06:09
Media: 00:05:14 00:39:30 03:46:10
Desv. Estándar: 0,0001239 0,0087417 0,0275890
Tabla 22 Duraciones, media y desviación estándar para un catálogo de 500 productos
Evidentemente las duraciones son mucho mayores, en el orden de horas para 10
atributos. Todas las negociaciones terminaron en acuerdo; para los casos de 2 y 5 atributos
se obtuvieron un único producto, en cambio para el catálogo de 10 atributos fueron 4 los
productos obtenidos en diferentes negociaciones. Como en el catálogo de 100 productos, la
similitud en los productos y la aleatoriedad en la selección de restricciones provocan esta
variación en los productos resultantes.
Figura 17 Gráfico de líneas para un catálogo de 500 productos
Se observa en el gráfico de líneas que el aumento en el crecimiento de la duración
en las negociaciones aumenta considerablemente para el catálogo de 10 atributos respecto a
los otros casos. Contar con un gran número de productos y atributos para cada uno de ellos
tiene dos consecuencias importantes en el aumento desmedido del tiempo:
Por un lado, cuando el agente municipal recibe una oferta por parte del proveedor,
el producto que la compone debe cumplir con todas las restricciones sobre los 10
atributos que lo definen. Muchas ofertas son rechazadas por este motivo provocando
que la llegada a un acuerdo se prolongue.
Por otro lado, aunque el proveedor posea un gran catálogo, existen situaciones
donde no cuente con un producto que se ajuste a los requerimientos del agente
municipal. Esto determina el cálculo de preferencia para cada uno de los 500
productos que componen el catálogo con el fin de obtener un producto candidato
hacia donde orientar la negociación.
6.2.6 Atributos incrementales y no incrementales
La última prueba que desarrollamos tiene como objetivo determinar la influencia de
los atributos incrementales y no incrementales en la duración de una negociación.
Recordemos que un atributo es incremental cuando la pérdida de satisfacción global se
produce elevando el valor del límite superior en caso de una relajación (por ejemplo, el
precio, ya que es menos conveniente elevar las restricciones sobre él). Un atributo no
incremental es el caso contrario (por ejemplo, la calidad de un producto, debido a que son
menos convenientes valores bajos del mismo).
La intención es determinar la influencia del tipo de atributo en la duración de
negociación sobre un mismo catálogo. Es decir, utilizando el catálogo para los
experimentos con 50 productos y 5 atributos, planteamos dos escenarios: uno en que todos
los atributos son incrementales y otro donde son todos no incrementales. A continuación,
podemos observar los tiempos obtenidos para ambos casos.
Número de ejecución Incrementales No incrementales
1 00:06:58 00:03:41
2 00:07:01 00:03:43
3 00:08:28 00:03:02
4 00:09:33 00:03:53
5 00:08:44 00:04:27
6 00:10:00 00:07:02
7 00:08:42 00:03:17
8 00:07:48 00:04:26
9 00:10:02 00:03:14
10 00:08:25 00:03:21
11 00:07:21 00:03:51
12 00:05:43 00:03:07
13 00:07:49 00:05:57
14 00:08:07 00:03:25
15 00:06:58 00:05:34
16 00:08:30 00:06:22
17 00:07:38 00:05:51
18 00:08:31 00:04:29
19 00:06:22 00:03:41
20 00:07:40 00:04:01
Media: 00:08:01 00:04:19
Desv. Estándar: 0,0007838 0,0008271
Tabla 23 Duraciones, media y desviación estándar para atributos incrementales y no incrementales
En la tabla 23 se observa claramente la influencia de un tipo sobre otro. Los
atributos incrementales duplican el tiempo de duración de la negociación respecto de los
incrementales. Esto significa que para los diferentes experimentos, las cantidades de
atributos de un tipo y de otro inciden sobre las duraciones. Por esta razón, fue de suma
importancia la generación de catálogos en forma aleatoria incluso en los tipos de atributos,
con el fin de no incidir en los tiempos de las pruebas. Evidentemente los valores de los
atributos para cada producto y la selección de las restricciones iniciales para el
requerimiento de compra (como ya mencionamos, en todos los casos fue de un intervalo
difuso MEDIO) también impacta en la duración. Por ejemplo, un catálogo cuyos atributos
contienen en mayor medida valores bajos, estableciendo requerimientos iniciales como
MUY ALTO provocará que la negociación dure más respecto a aquella en la que se
establecieron valores iniciales como MUY BAJO.
En el siguiente gráfico de barras observamos la gran diferencia entre las duraciones
de las negociaciones. Por muy poco, el caso de atributos incrementales casi duplica al de
los atributos no incrementales.
Figura 18 Gráfico de barras para atributos incrementales y no incrementales
6.2.7 Conclusión del caso de estudio
Indudablemente, la duración de una negociación está relacionada en gran medida a
diversos parámetros iniciales. La cantidad de productos con los que cuenta el catálogo
incide sobre el tiempo, particularmente en situaciones donde el proveedor no cuente con un
producto que se ajuste al requerimiento del agente municipal y deba obtener un producto
candidato a través de los cálculos de preferencia en todo el catálogo. Pero el mayor impacto
se produce cuando aumenta el número de atributos negociables, salvo en los casos en que la
cantidad de productos es escasa. Cada nueva restricción que recibe el proveedor implica
determinar el mejor producto para él que se ajuste al requerimiento del agente municipal.
En el peor de los casos, no encontrarlo involucra diversos cálculos para obtener una opción
cercana a dicho requerimiento, como hemos mencionado. Aun encontrando el producto que
se ajuste a cada restricción, falta determinar el cumplimiento del resto de los atributos que
el agente municipal todavía no envió. Si la cantidad de atributos es grande, probablemente
no se satisfagan todas las restricciones no enviadas, por lo que se producirá un rechazo y
nuevos diálogos para acordar hacia dónde seguir.
00:00:00
00:01:26
00:02:53
00:04:19
00:05:46
00:07:12
00:08:38
Incrementales No incrementales
Los valores y tipo de cada atributo, la utilidad de los productos y los requerimientos
de compra iniciales también inciden en los tiempos. Supongamos un caso en donde se
presenta la necesidad de comprar un televisor LED. Estos artículos generalmente son caros,
por lo que plantear como restricción de compra inicial sobre el precio un valor MUY BAJO
provocará que la negociación se prolongue. Más aún si el proveedor tiene valores de
utilidad mínimos para los televisores de precios muy bajos.
6.3 Conclusión
Con los casos de estudio planteados se demostraron el cumplimiento de los
beneficios que proporciona el marco de negociación automática basado en restricciones
difusas respecto a un ámbito de compras real. Los tiempos fueron ampliamente reducidos,
al punto de durar minutos lo que en la realidad tarda días. De todas formas se comprobó la
incidencia en los tiempos cuando el catálogo es alterado en su contenido. Pero aun así, las
duraciones de las negociaciones son insignificantes en comparación con un escenario real.
La eficiencia es otro aspecto que quedó de manifiesto en el primer caso de estudio, al
momento de acordar la adquisición del mejor producto del catálogo del proveedor. Además
el sistema cuenta con una buena usabilidad, permitiendo al usuario iniciar una compra sin
conocer en detalle el dominio del producto que se desea adquirir.
Capítulo 7
Conclusiones
En este último capítulo presentamos las contribuciones y conclusiones del trabajo,
haciendo foco en los puntos más destacados. A su vez, describimos las limitaciones, que no
son otra cosa que aspectos no contemplados en la presente tesis. Por último presentamos
algunas ideas para extender la herramienta en trabajos futuros.
7.1 Contribuciones
Una herramienta de negociación automática que lleve a cabo un comercio
electrónico entre varias partes es de gran utilidad en cualquier escenario. Si le sumamos la
posibilidad de definir el requerimiento de compra a partir de restricciones difusas, los
beneficios son aún mayores. Particularmente una entidad municipal, a través de su Oficina
de Compras, es un ámbito donde se potencia su utilización. La modernización en la gestión
pública nos abre una puerta para el estudio de nuevas tecnologías, que, en nuestro caso, lo
enfocamos en un aspecto crítico para las entidades gubernamentales, y más
específicamente, los gobiernos municipales: las compras de suministros en forma eficiente.
El propósito de nuestro trabajo fue el de desarrollar dicha herramienta, la cual
cuenta con una serie de atributos que la convierten en una mejora sustancial respecto a la
metodología clásica de compra. Por un lado, minimiza considerablemente los tiempos que
se invierten desde el momento en que un sector notifica la necesidad de abastecimiento,
hasta la determinación del producto y del proveedor al que se le efectuará la compra. El
producto acordado en cada negociación se ajusta lo máximo posible al requerimiento de
compra de la entidad de gobierno. Posee una disponibilidad absoluta que permite el inicio
de negociaciones en cualquier momento. Por su carácter de sistema informático, permite la
interoperabilidad con otros sistemas con el fin de que cada proveedor implemente su propia
herramienta como lo desee. Además, un aspecto importante con el que cuenta, es una fácil
utilización de la misma que posibilita a cualquier usuario definir requerimientos de compra
sin necesidad de conocer por completo el dominio sobre el que se negociará.
En este sentido, estudiamos los diferentes conceptos que nos condujeron al
desarrollo de la herramienta. Por un lado, presentamos a los representantes de cada
participante en una negociación; así llegamos al concepto de agente inteligente; más
precisamente a un número de ellos interactuando, es decir, un sistema multiagente.
Utilizamos la plataforma JADE para la coordinación de los agentes; la cual, a su vez,
proporciona el soporte para comunicarlos, el Facilitador de Directorio, y la ejecución
concurrente de comportamientos, en otras tantas virtudes.
Por otra parte, se definió un modelo de negociación que se ajustó de la mejor forma
posible a las pretensiones funcionales de la herramienta. En este sentido, desarrollamos un
estudio sobre los diferentes modelos basados en enfoques particulares, determinando los
pros y las contras de cada uno. Así fue que concluimos en que la mejor opción son los
modelos basados en restricciones difusas, las cuales se emplean para determinar qué oferta
enviar, si una oferta es aceptable y que contra-oferta efectuar. Proporciona métodos para
argumentar la postura de cada participante, pero se potencia con la flexibilidad que otorga
el empleo de lógica difusa. A su vez, contar con la posibilidad de definir los requerimientos
de compra a partir de restricciones difusas tiene un valor agregado en la facilidad de uso de
la herramienta, siendo esto un aspecto importante para nuestro contexto. Posteriormente,
estudiamos en profundidad el modelo de negociación automática basado en restricciones
difusas, ejemplificándolo con una situación en la que un agente municipal y un proveedor
desean negociar entre sí.
Con el fin de comprobar, con el sistema desarrollado, el cumplimiento de los
objetivos que nos fijamos en el presente trabajo, planteamos dos casos de estudios. El
primero de ellos consistió en utilizar la herramienta en un ámbito de negociación entre un
Municipio y un proveedor para la adquisición de una impresora. El segundo tuvo como
propósito, analizar la performance del sistema cuando se varían los escenarios. Las
conclusiones obtenidas de ambos casos determinaron el cumplimiento de los beneficios que
proporciona el marco de negociación automática basado en restricciones difusas.
Se produjo una considerable minimización del tiempo respecto a un marco de
negociación real. Demostramos que, aunque la duración de las negociaciones es
mínima, está fuertemente relacionada con diversos parámetros como ser la cantidad
de productos en el catálogo, el número, tipo y valores de cada atributo, los valores
de utilidad y las restricciones difusas iniciales establecidas por la Oficina de
Compras.
La eficiencia quedó en evidencia al momento de establecer una negociación en
donde el catálogo del proveedor contenía un producto conveniente para él, que se
acercaba a los requerimientos del Municipio. La negociación fue conducida a un
acuerdo de venta de dicho producto, por lo que resultó eficiente su utilización.
No se verificó la disponibilidad del sistema aunque este aspecto quedó implícito en
el primer caso de estudio. El agente proveedor se encuentra disponible en cualquier
momento, ya que su servicio es publicado en el Directory Facilitator. La Oficina de
Compras, en el momento que lo desee, puede iniciar una negociación.
Tampoco se verificó la interoperabilidad. Esta característica es propia de los
sistemas multiagente. Cualquier proveedor puede desarrollar su agente y este
operará sin ningún inconveniente con el agente municipal implementado. Siempre y
cuando respete los protocolos definidos en la presente tesis.
La usabilidad del sistema es una virtud que cabe destacar. El usuario del sistema es
totalmente ajeno al dominio sobre el que se negocia. A partir de términos lingüísticos
fácilmente entendibles, cualquier persona puede especificar un requerimiento de compra.
7.2 Limitaciones encontradas
Las limitaciones que surgen del presente trabajo se relacionan principalmente con la
adaptación de la herramienta a un contexto real de compras en una entidad municipal de
gobierno. Como mencionamos en el capítulo 5, el sistema es de utilidad para los casos de
compra directa, donde cada proveedor se debe encontrar registrado en el municipio para
poder participar. No existen trabas legales para implementar la herramienta bajo este marco
(siempre que se considere que los precios de los productos no superen los $37000 que
permite la compra directa), pero indudablemente la adaptación implica que cada proveedor
cuente con un catálogo de sus productos, cada uno de ellos especificado con sus atributos,
lo cuales serán negociados. Este requerimiento para que los proveedores participen puede
resultarles engorroso, y provocar un efecto reticente en la utilización de la herramienta por
parte de ellos.
Todo lo expuesto en este trabajo se aplica en negociaciones bilaterales, entre un
municipio y un proveedor en particular. Cada vez que el Sector de Compras especifica un
requerimiento de compra en el sistema, y comienza el proceso de búsqueda de proveedores,
cada negociación que se inicia es bilateral, independiente de las demás. El sector debe
comprarle a un único proveedor, aunque se haya negociado con varios al mismo tiempo,
sobre un mismo requerimiento de compra. El sistema no contempla esta situación final, por
lo que es una limitación a ser resuelta. A su vez, esta independencia en las negociaciones
imposibilita que puedan compararse determinados atributos dentro del protocolo entre los
proveedores participantes, como sí puede hacerse en un ámbito real. Por ejemplo, el Sector
de Compras puede estar particularmente interesado en los precios de los productos
ofrecidos; cuando se recibe una oferta de venta, se podría querer comparar su precio con el
de otras ofertas recibidas en el resto de las negociaciones.
Otro aspecto no contemplado en el estudio de la presente tesis es la proactividad del
sistema ante situaciones de escases de determinados productos. La disponibilidad que
brinda la herramienta y que permite iniciar una negociación en cualquier momento, puede
ser potenciada si, además, se define una situación crítica en donde se torne imperioso
negociar un producto con pocas unidades en el stock municipal. En forma automática, se
puede detectar esta escases y comenzar una negociación utilizando un requerimiento de
compra pre fijado con anterioridad.
7.3 Trabajos futuros
Partiendo desde las limitaciones mencionadas en la sección anterior, una posibilidad
de ampliar la funcionalidad de la herramienta en trabajos futuros es resolver dichas
limitaciones. Señalamos lo engorroso que puede resultarle a un proveedor generar una base
de datos con todos los productos con los que cuenta, detallados a partir de sus atributos;
todo esto con el fin de poder participar en negociaciones automáticas. Una solución es que
el municipio proporcione a cada proveedor un gran catálogo general bien definido, para que
luego cada uno de ellos especifique las unidades con las que cuenta (que puede ser 0 si es
que no trabaja con una determinada firma) y el valor de utilidad que le reporta vender cada
uno de esos productos. Con esta propuesta se facilitaría en gran medida el proceso de
adaptación.
Otra limitación a resolver es la de a qué proveedor comprarle luego de entablar
varias negociaciones sobre un mismo requerimiento de compra. Una posibilidad es
implementar un proceso de resolución de compra en el que, de todas las negociaciones que
llegaron a un acuerdo, nos quedamos con el proveedor cuyo producto reportó un mayor
grado de satisfacción global respecto a los demás. Se puede refinar el proceso indicando la
preferencia de uno a más atributos por sobre otros, al momento de definir al proveedor
ganador. Por ejemplo, la Oficina de Compras puede especificar que al momento de definir
al ganador, se tome en cuenta el precio más bajo y la calidad más alta. Esta preferencia es
independiente de la valoración de los atributos en el requerimiento de compra, y solo tiene
un propósito final que es la de obtener un solo producto entre los acordados en las
diferentes negociaciones.
El modelo de negociación que utilizamos como referencia, se basa, en su mayoría,
en la idea de que el agente comprador revele la mínima información posible respecto de sus
pretensiones. Esta característica está orientada a negociaciones bilaterales en donde la
revelación de información por parte del comprador puede provocar una actitud especulativa
en el agente vendedor. Por este motivo, nuestro agente municipal envía cada restricción del
requerimiento de compra en la medida que lo crea necesario y el proveedor se lo solicite.
Al momento de llevar a cabo el segundo caso de estudio, con el fin de analizar la
performance del sistema, notamos algunas situaciones en donde el producto que se obtuvo
luego de haber negociado un determinado tiempo, se ajustaba exactamente al requerimiento
de compras inicial del agente municipal. Evidentemente la duración hubiera sido mínima si
el requerimiento de compra hubiera sido enviado completamente desde el inicio de la
negociación. El agente municipal mantendría en reserva todo lo que se refiera a la
valoración de cada producto recibido, y el agente proveedor solicitaría relajaciones en
forma conveniente, siempre y cuando no cuente con un producto que se ajuste al
requerimiento. Claramente, esta propuesta se contrapone con la idea de no revelar
información; pero podemos considerar que en nuestro contexto, donde contamos con varias
negociaciones bilaterales, no le resulta conveniente a un proveedor tomar una actitud
especulativa, porque puede hacerle perder una venta en manos de otro que ofrezca un
producto que se ajuste mejor al requerimiento de compra. Puede ser interesante el análisis
de este nuevo enfoque en futuros trabajos.
En otro sentido, cuando hablamos de las características que tiene la herramienta,
mencionamos la posibilidad de integrar sistemas heterogéneos. Esto permite a cada
proveedor implementar su propio agente inteligente negociador que, a su vez, cuente con
sus propios mecanismos de decisión. El requisito principal es que debe respetarse el
protocolo que hemos definido en la presente tesis. El resultado de esto es un sistema
multiagente altamente extensible, que irá creciendo en la medida que los proveedores vayan
sumándose al mismo.
Bibliografía
Abramson, M. A., & Means, G. (2001). E-government 2001. Rowman & Littlefield
Publishers, Inc.
Austin, J. L. (1962). How To Do Things With Words. Oxford University Press, Oxford.
Beam, C., & Segev, A. (1997). Automated Negotiations: A Survey of the State of the Art.
Wirtschaftsinformatik.
Bellifemine, F., Caire, G., Trucco, T., & Rimassa, G. (2005). JADE Programmer's Guide.
Bellifemine, F., Poggi, A., & Rimassa, G. (2001). Developing multi-agent systems with a
FIPA-compliant agent framework, Software - Practice and Experience, 31. 103-128.
Borst, W. (1997). Construction of Engineering Ontologies for Knowledge Sharing and
Reuse. University of Twente. Enschede, The Netherlands.
Buttner, R. (2006). A classification structure for automated negotiations. In WI-IATW ’06:
Proceedings of the 2006 IEEE/WIC/ACM international conference on Web
Intelligence and Intelligent Agent Technology. Washington, DC, USA.
Cyber Law in Australia. (2010). Kluwer Law International.
Deborah Morley, C. S. (2009). Understanding Computers: Today & Tomorrow. Course
Technology Cengage Learning.
Dubois, D., Fargier, H., & Prade, H. (1994). Propagation and satisfaction of flexible
constraints. Fuzzy Sets, Neural Networks and Soft Computing.
Elamy, A. H. (2005). Perspectives in Agent-Based Technology. AgentLink News.
Faratin, P. (2000). Automated Service Negotiation Between Autonomous Computational
Agents. University of London, Queen Mary and Westfield College Department of
Electronic Engineering.
Faratin, P., Sierra, C., & Jennings, N. R. (1998). Negotiation decision functions for
autonomous agents. Robotics and Autonomous Systems.
Fatima, S. S. (2004). An agenda-based framework for multi-issue negotiation.
Finin, T., Labrou, Y., & Mayfield, J. (1995). KQML as an Agent Communication
Language. In Proc. of the 3rd International Conference on Information and
Knowledge Management.
FIPA. (2002b). FIPA ACL Message Structure Specification. Obtenido de FIPA Standard
Specification 00061: http://www.fipa.org/specs/fipa00061/SC00061G.pdf
Genesereth, M., & Fikes, R. (1992). Knowledge Interchange Format, Version 3.0
Reference Manual. Technical report logic. Computer Science Department, Stanford
University.
Gruber, T. R. (1993). A translation approach to portable ontology specifications.
Knowledge Acquisition.
Harsanyi, J. C. (1968). Games with Incomplete Information Played by ‘Bayesian' Players.
Management Science.
Hauser, J. R., & Wernerfelt, B. (1990). An evaluation cost model of considerations sets.
Journal of Consumer Research.
Huhns, M. N. (1999). Multiagent Systems and Societies of Agents, in G. Weiss (ed.),
Multiagent Systems: A Modern Approach to Distributed Artificial Itelligence.
Cambridge, MA: The MIT Press.
Jennings, N. (2001). An Agent-Based Approach for building Complex Software Systems.
Communications of the ACM.
Jennings, N. R., & Narayanan, V. (2005). An adaptive bilateral negotiation model for e-
commerce settings. In Proc. of the 7th IEEE International Conference on E-
Commerce Technology (CEC 2005).
Jennings, N. R., Faratin, P., Lomuscio, A. R., Parsons, S., Sierra, C., & Wooldridge, M.
(2001). Automated negotiation: Prospects, methods and challenges. International
Journal of Group Decision and Negotiation.
Jennings, N. R., Parsons, S., Noriega, P., & Sierra, C. (1998a). On argumentation-based
negotiation. Dedham, USA: In Proceedings of International Workshop on Multi-
Agent.
Jennings, N. R., Sycara, K., & Wooldridge, M. (1998b). A roadmap for agent research and
development. Autonomous Agents and Multi-Agent Systems.
Jovarauskienė, D., & Pilinkienė, V. (2009). E-Business or E-Technology? COMMERCE
OF ENGINEERING DECISIONS. ISSN 1392-2785 ENGINEERING
ECONOMICS. 2009. No 1 (61).
Keeny, R., & Raiffa, H. (1976). Decisions with Multiple Objectives: Preferences and Value
Tradeoffs. John Wiley and Sons.
Klir, G. J., & Yuan, B. (1995). Fuzzy Sets and Fuzzy Logic: Theory and Applications.
Prentice-Hall.
Kraus, S. (2001b). Strategic Negotiation in Multiagent Environments. Mit Press.
Kraus, S., Sycara, K., & Evenchick, A. (1998). Reaching agreements through
argumentation: A logical model and implementation. Artificial Intelligence.
Laboratorio de Agentes Software Inteligentes. (2001). Multi-Agent Systems. Universidad
de Carnegie Mellon.
Liu, J. W. (2010). Breaking the ice between Government and business: From IT-Enabled
Control Procedure Redesign to truested relationship building.
López Carmona, M. A. (2006). Estrategias de Negociación Automática Basadas en
Restricciones Difusas sobre Sistemas Multiagente. Alcalá de Henares.
Matthias Klusch, L. K. (2000). Cooperative Information Agents IV - The Future of
Information Agents in Cyberspace. Springer.
Naser, A., & Concha, G. (Abril de 2011). El gobierno electrónico en la gestión pública.
Santiago de Chile, Chile: Instituto Latinoamerica y del Caribe de Planificación
Económica y Social (ILPES).
Nash, J. (1950). The bargaining problem. Econometrica.
Ortiz, S., López Gallego, C., & Oviedo Carrascal, A. I. (2009). Sistema multiagente para el
apoyo a la gestion de inventarios en itil mediante el monitoreo distribuido de
software y hardware en una red corporativa. Avances en Sistemas e Informática.
Osborne, M. J., & Rubinstein, A. (1994). A Course in Game Theory. MIT Press,
Cambridge, Massachusetts.
Rahwan, I. R. (2004). Argumentation-based negotiation. The knowledge Engineering
Review.
Raiffa, H. (1982). The Art and Science of Negotiation. Harvard University Press.
Rosenschein, J. S., & Zlotkin, G. (1994). Rules of Encounter. MIT Press, Cambridge MA,
USA.
Russell, S., & Norvig, P. (2004). Inteligencia Artificial. Un Enfoque Moderno. Segunda
edición. Pearson Prentice.
Sandholm, T. W. (1999). Distributed rational decision making.
Scheneider, G. P. (2004). Comercio Electrónico - Tercera edición. Thomson.
Searle, J. R. (1969). Speech Acts: an Essay in the Philosophy of Language. Cambridge
University Press, Cambridge.
Sen, S. (1997). Developing an automated distributed meeting scheduler. IEEE Intelligent
Systems.
Studer, R., Benjamins, R., & Fensel, D. (1998). Knowledge Engineering: Principles and
Methods. Data and Knowledge Engineering.
Sycara, K. (1989). Argumentation: Planning other agent's plans. In Proceedings of the 11th
International Joint Conference on Artificial Intelligence.
Tecuci, G. (1998). Building Intelligents Agents (An Apprenticeship Multistrategy Learning
Theory, Methodology, Tool and Case Studies).
Vlassis, N. (2003). A Concise Introduction to Multiagent Systems and Distributed AI.
von Neuman, J., & Morgenstern, O. (1944). The Theory of Games and Economic
Behaviour. Princeton University Press, Princeton NJ, USA.
Wooldridge, M. (2002). An Introduction to Multiagent Systems. John Wiley & Sons.
Wooldridge, M. (2009). An Introduction to MultiAgent Systems - Second Edition. John
Wiley & Sons.
Wooldridge, M., & Jennings, N. R. (1995). Intelligent Agents: theory and practice. The
Knowledge Engineering Review.
Xudong Luo, J. H.-m.-f. (2003). Prioritised Fuzzy Constraint Satisfaction Problems:
Axioms, Instantiation and Validation.
Yokoo, M. (2001). Distributed Constraint Satisfaction. Springer Verlag.