Optimisation sous contraintes distribuée

De testwiki
Aller à la navigation Aller à la recherche

L'optimisation sous contraintes distribuées (en anglais Distributed Constraint Optimization Problem, DCOP ou DisCOP) est l'alter ego distribué de l'optimisation sous contraintes. Un DCOP est un problème dans lequel un groupe d'agents doit choisir de manière décentralisée des valeurs pour un ensemble de variables de manière à minimiser une fonction de coût ou à maximiser une fonction d'utilité.

La Satisfaction de Contraintes Distribuée (parfois appelée Distributed Constraint Satisfaction Problem, DCSP ou DisCSP) est une formalisation permettant d'écrire un problème en termes de contraintes qui sont connues et doivent être respectées par les participants (agents). Les contraintes s'appliquent à certaines variables, notamment à travers la définition de domaines prédéfinis en dehors desquelles les variables ne sont pas définies.

Les problèmes définis dans ce formalisme peuvent être résolus par n'importe lequel des algorithmes qui lui sont associés.

Définitions

DCOP

Un DCOP peut être défini comme un tuple A,V,𝔇,f,α,η, où:

  • A est un ensemble d' agents ;
  • V est un ensemble de variables, {v1,v2,,v|V|} ;
  • 𝔇 est un ensemble des domaines, {D1,D2,,D|V|}, où chaque D𝔇 est un ensemble fini contenant les valeurs qui peuvent être affectées à la variable vi associée au domaine Di;
  • f est une fonction [1]Modèle:,[2]
    f:S𝔓(V)viS({vi}×Di){}
    qui associe chaque affectation de variable possible à un coût ou une utilité. Cette fonction peut également être considérée comme définissant des contraintes entre les variables, mais les variables ne doivent pas être hermitiennes;
  • α est une fonction α:VA qui associe les variables à l'agent qui leur est associé. α(vi)aj implique que l'agent aj a la responsabilité d'attribuer sa valeur à la variable vi . Notez qu'il n'est pas forcément vrai que α est une injection ou une surjection (i.e. un agent peut être responsable de plusieurs variables, ou d'aucune mais une variable n'est sous la responsabilité que d'un seul agent); et
  • η est un opérateur qui agrège l'ensemble des fonctions f de coût ou d'utilité pour toutes les valeurs possibles (i.e. respectant leurs domaines) des variables. Cette fonction est généralement une somme:
    η(f)sS𝔓(V)viS({vi}×Di)f(s) .

L'objectif d'un DCOP est que chaque agent attribue des valeurs aux variables qui lui sont associées afin que l'affectation globale de l'ensemble des variables minimise (ou de maximise dans le cas des fonctions d'utilité) η(f).

Contexte

Un contexte est une affectation d'une variable dans un DCOP. Il peut être considéré comme une fonction associant les variables du DCOP à leurs valeurs actuelles:

t:V(D𝔇){}.

Notons qu'un contexte est essentiellement une solution partielle et n'a pas besoin de contenir des valeurs pour chaque variable du problème; on note donc

t(vi)

lorsque l'agent

α(vi)

n'a pas encore attribué de valeur à la variable

vi

. Compte tenu de cette représentation, le "domaine" (c'est-à-dire l'ensemble des valeurs d'entrée) de la fonction

f

peut être considéré comme l'ensemble de tous les contextes possibles pour le DCOP. Par conséquent, dans le reste de cet article, on utilisera la notion de contexte (c'est-à-dire la fonction

t

) comme entrée de la fonction

f

.

Exemples de problèmes

Coloration de graphique distribuée

Le problème de coloration de graphe est le suivant: étant donné un graphe G=N,E et un ensemble de couleurs C, on cherche à attribuer à chaque sommet du graphe nN, une couleur, cC de manière que le nombre de sommets adjacents de même couleur soit minimisé.

Dans la formalisation DCOP du problème, on considère qu'il y a un agent par sommet, et qu'il a la responsabilité de décider de la couleur associée à ce sommet. Chaque agent a une seule variable (le sommet dont il est responsable) dont le domaine associé est l'ensemble des couleurs, de cardinalité

|C|

. Pour chaque sommet

niN

, on crée dans le DCOP une variable

viV

avec pour domaine domaine

Di=C

. Pour chaque paire de sommets adjacents

ni,njE

, on ajoute une contrainte de coût 1 si les deux variables associées ont la même couleur:

(cC:f(vi,c,vj,c)1).

L'objectif est ici de minimiser

η(f)

.

Problème distribué des sacs à dos multiples

Le problème du sac à dos multiple est une variante du problème du sac à dos où: étant donné un ensemble d'objets de volume variable et un ensemble de sacs à dos de capacité variable, on cherche à attribuer à chaque objet à un sac à dos de manière à minimiser le débordement des sacs. Soit I l'ensemble des objets, K l'ensemble des sacs à dos, s:I une fonction qui associe les éléments à leur volume, et c:K une fonction associant les sacs à dos à leurs capacités.

Pour formaliser ce problème sous la forme d'un DCOP, on crée pour chaque

iI

une variable

viV

dont le domaine est

Di=K

. Puis pour tous les contextes possibles

t

 :

f(t)kK{0r(t,k)c(k),r(t,k)c(k)otherwise,

r(t,k)

est une fonction telle que

r(t,k)=vit1(k)s(i).

Algorithmes

Les algorithmes DCOP peuvent être classés en fonction de la stratégie de recherche (algorithme de recherche best-first ou parcours en profondeur avec séparation et évaluation), de la synchronisation du protocole (synchrone ou asynchrone), de la communication entre agents (pair à pair avec ses voisins dans le graphe de contraintes ou diffusion à tous les autres) et de la topologie de communication principale (chaîne ou arborescence)[3]. ADOPT utilise par exemple un algorithme de recherche best-first asynchrone avec une communication pair à pair entre les agents voisins dans le graphe de contraintes, et une arborescence de contraintes comme topologie de communication principale.

Nom de l'algorithme Année Complexité en mémoire Nombre de messages Correction/Complétude Implémentations
SynchBB

Synchronous Branch-and-Bound[4]

1997 Linéaire Exponentiel Complet FRODO (GNU Affero GPL)

pyDCOP (BSD-3)

AFB

Asynchronous Forward Bounding[5]

2009 Linéaire Exponentiel Complet FRODO (GNU Affero GPL)
ConcFB

Concurrent Forward Bounding[6]

2012 Linéaire Exponentiel Complet Modèle:Référence nécessaire
Max-Sum[7] 2008 Exponentiel en le nombre moyen de voisins de l'agent Linéaire Incomplet, très rapide FRODO (GNU Affero GPL)

pyDCOP (BSD-3)

MGM

Maximum Gain Message[8]

2004 Linéaire en le nombre de voisins Linéaire Incomplet FRODO (GNU Affero GPL)

pyDCOP (BSD-3)

DSA

Distributed Stochastic Algorithm[9]

2005 Linéaire en le nombre de voisins Linéaire Incomplet FRODO

pyDCOP

D-Gibbs

Distributed Gibbs[10]

2013 Linéaire en le nombre de voisins Linéaire Incomplet mais garantit une erreur d'approximation bornée Modèle:Référence nécessaire
NCBB

No-Commitment Branch and Bound[11]
2006 Polynomial (ou any-space)[12] Exponentiel Complet Implémentation de référence: indisponible publiquement

DCOPolis (GNU LGPL)

DPOP

Distributed Pseudotree Optimization Procedure[13]
2005 Exponentiel Linéaire Complet Implémentation de référence: FRODO (GNU Affero GPL)

pyDCOP (BSD-3)
DCOPolis (GNU LGPL)

OptAPO

Asynchronous Partial Overlay[14]
2004 Polynomial Exponentiel L'algorithme initial a été démontré incomplet[15], mais une autre version complète de l'algorithme existe [16] Implémentation de référence: Modèle:Lien webArtificial Intelligence Center. SRI International. Archived from the original on 2007-07-15.

DCOPolis (GNU LGPL); en cours de développement

Adopt

Asynchronous Backtracking[17]
2003 Polynomial (ou any-space)[18] Exponentiel Complet Implémentation de référence: Adopt

DCOPolis (GNU LGPL) FRODO (GNU Affero GPL)

DBA

Distributed Breakout Algorithm
1995 Modèle:Référence nécessaire Modèle:Référence nécessaire Note: incomplet mais rapide FRODO (GNU Affero GPL)
AWCModèle:Référence nécessaire

Asynchronous Weak-Commitment
1994 Modèle:Référence nécessaire Modèle:Référence nécessaire Note: reordonnancement, rapide, complet (seulement avec un espace exponentiel) Modèle:Référence nécessaire
ABTModèle:Référence nécessaire

Asynchronous Backtracking
1992 Modèle:Référence nécessaire Modèle:Référence nécessaire Note: statique ordonnancement, complet Modèle:Référence nécessaire
CFL

Communication-Free Learning[19]
2013 Lineaire None Note: aucun message n'est envoyé; l'lagorithme repose sur la connaissance de la satisfactoin de contraintes locales Incomplet

Des versions hybrides de ces algorithmes DCOP existent également. BnB-Adopt[20] par exemple, modifie la stratégie de recherche d'Adopt passant d'un algorithme de recherche best-search à un algorithme de séparation et évaluation.

Logiciels de simulation

Les logiciels de simulation DCOP permettent de formaliser un problème dans un format prédéterminé puis de choisir l'algorithme qui y sera appliqué dans une librairie rassemblant un certain nombre d'algorithmes. Deux plates-formes sont principalement utilisées: une bibliothèque écrite en Java, FRODO 2[21], sous licence GNU Affero General Public License, propose une interface pour Java, avec un module permettant de faire appel à la bibliothèque depuis python. Elle propose une bibliothèque de 16 algorithmes, notamment ADOPT, DPOP et des variantes, SynchBB, DSA, Max-Sum et MGM. La seconde plate-forme est pyDCOP[22], une bibliothèque écrite en python pour python par Orange (entreprise) sous licence Open Source BSD-3. pyDCOP inclut 13 algorithmes, notamment Max-Sum et des variantes, DSA et des variantes, DPOP, MGM et SynchBB. pyDCOP propose aussi une librairie permettant de déployre les algorithmes de manière décentralisée sur de l'IoT.

Voir aussi

Livres et revues de littérature

Notes et références

Modèle:Traduction/Référence

  1. "𝔓(𝔙)" représente l'Ensemble des parties de V
  2. "×" et "" représente le produit cartésien.
  3. Modèle:Article
  4. Modèle:Article
  5. Modèle:Article
  6. Modèle:Article
  7. Modèle:Article
  8. Modèle:Article
  9. Modèle:Article
  10. Modèle:Article
  11. Modèle:Article
  12. Modèle:Article
  13. Modèle:Article
  14. Modèle:Article
  15. Modèle:Article
  16. Modèle:Article
  17. La version initiale d'Adopt n''utilisait pas d'heuristique voir Modi, Pragnesh Jay; Shen, Wei-Min; Tambe, Milind; Yokoo, Makoto (2003), "An asynchronous complete method for distributed constraint optimization", Proceedings of the second international joint conference on autonomous agents and multiagent systems, ACM Press, pp. 161–168. Une seconde version voir Ali, Syed; Koenig, Sven; Tambe, Milind (2005), "Preprocessing Techniques for Accelerating the DCOP Algorithm ADOPT" (PDF), Proceedings of the fourth international joint conference on autonomous agents and multiagent systems, ACM Press, pp. 1041–8, doi:10.1145/1082473.1082631, Modèle:ISBN, S2CID 10882572 a ensuite été développée; dans cette version, l'algorithme utilise une heuristique basée sur des estimations des coûts des solutions explorées. C'est généralement cette implémentation qui fait foi lorsqu'il est question d'Adopt.
  18. Modèle:Article
  19. Modèle:Article
  20. Modèle:Article
  21. Modèle:Article
  22. Modèle:Article

Modèle:Portail