Optimisation sous contraintes distribuée
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 , où:
- est un ensemble d' agents ;
- est un ensemble de variables, ;
- est un ensemble des domaines, , où chaque est un ensemble fini contenant les valeurs qui peuvent être affectées à la variable vi associée au domaine Di;
- est une fonction [1]Modèle:,[2]
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 qui associe les variables à l'agent qui leur est associé. implique que l'agent a la responsabilité d'attribuer sa valeur à la variable . 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 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:
.
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é) .
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:
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
lorsque l'agent
n'a pas encore attribué de valeur à la variable
. Compte tenu de cette représentation, le "domaine" (c'est-à-dire l'ensemble des valeurs d'entrée) de la fonction
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
) comme entrée de la fonction
.
Exemples de problèmes
Coloration de graphique distribuée
Le problème de coloration de graphe est le suivant: étant donné un graphe et un ensemble de couleurs , on cherche à attribuer à chaque sommet du graphe , une couleur, 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é
. Pour chaque sommet
, on crée dans le DCOP une variable
avec pour domaine domaine
. Pour chaque paire de sommets adjacents
, on ajoute une contrainte de coût 1 si les deux variables associées ont la même couleur:
L'objectif est ici de minimiser
.
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 l'ensemble des objets, l'ensemble des sacs à dos, une fonction qui associe les éléments à leur volume, et 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
une variable
dont le domaine est
. Puis pour tous les contextes possibles
:
où
est une fonction telle que
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 |
| 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 |
| DPOP Distributed Pseudotree Optimization Procedure[13] |
2005 | Exponentiel | Linéaire | Complet | Implémentation de référence: FRODO (GNU Affero GPL) |
| 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. |
| Adopt Asynchronous Backtracking[17] |
2003 | Polynomial (ou any-space)[18] | Exponentiel | Complet | Implémentation de référence: Adopt |
| 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
- Modèle:Article
- Modèle:Article
- Modèle:Ouvrage
- Modèle:Ouvrage.
- Modèle:Ouvrage
- Modèle:Article
- Gauthier Picard, Optimisation sous contraintes distribuée – une introduction. Tutoriel donné aux Journées Francophones sur les Systèmes Multi-Agents, 2018 Modèle:Présentation en ligne
Notes et références
- ↑ "" représente l'Ensemble des parties de
- ↑ "" et "" représente le produit cartésien.
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ 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.
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article
- ↑ Modèle:Article