[JAVA] Vérification des performances de l'optimisation du plan Red Hat Decision Manager
Auteur: Hitachi Solutions Co., Ltd. Akihiro Yanagimura Supervision: Hitachi, Ltd.
introduction
L'optimisation du plan consiste à formuler le meilleur plan (plan de combinaison) avec des ressources limitées, compte tenu des contraintes et de l'efficacité à observer.
Ici, à mesure que l'échelle du plan cible (par exemple, dans le cas d'un plan de rotation du personnel, le nombre de membres du personnel cible et le nombre de créneaux à allouer) augmente, le nombre de combinaisons augmente également et le temps jusqu'à ce qu'un bon plan puisse être élaboré augmente également. Augmentera. Par conséquent, lors de l'optimisation du plan, il est nécessaire de prendre en compte le contenu suivant.
―― Quelle est la taille de l'optimisation? ―― Combien de temps de calcul pouvez-vous consacrer? ―― De combien de spécifications de machine avez-vous besoin?
Dans cet article, nous présenterons la vérification des performances qui optimise le plan à l'aide de Red Hat Decision Manager pour le cas modèle de la planification des équipes quotidiennes du personnel. Nous espérons que cet article sera utile dans les points suivants.
--Confirmez que l'optimisation de la planification peut gérer des cas à grande échelle avec un temps de calcul réaliste. --Utiliser comme valeur de référence lors de l'estimation du temps de calcul et des spécifications de la machine
- Référence comme valeur de base des algorithmes d'optimisation et des paramètres à ajuster pendant la conception et le développement
Veuillez vous référer aux articles suivants pour un aperçu de l'optimisation de la planification à l'aide de Red Hat Decision Manager et une image de son utilisation. Planifiez l'optimisation avec une IA qui comprend la raison du résultat Planifier une "image d'utilisation" d'optimisation avec une IA qui comprend la raison du résultat
Cas modèle
Aperçu du plan
Développer un plan de travail quotidien pour le personnel qui a plusieurs tâches dans une zone de travail. Plus précisément, nous affecterons du personnel pour effectuer le travail pour chaque créneau horaire, en tenant compte des contraintes et de l'efficacité.
L'image de création des données de décalage (trame de décalage après affectation du personnel) est présentée ci-dessous.
Dans ce cas de modèle, on suppose qu'il existe les trois modèles suivants de personnel et de créneaux de quart.
| # | Effectifs | Nombre d'images de décalage |
|---|---|---|
| 1 | 1000 | 4212 |
| 2 | 500 | 2106 |
| 3 | 250 | 1053 |
Règle de contrainte
Dans ce cas de modèle, les règles de contrainte suivantes sont définies.
| # | règle de contrainte | Type de contrainte | Description du type de contrainte | level |
|---|---|---|---|---|
| 1 | Veillez à affecter du personnel à la trame d'équipe. | Contrainte absolue | Règles de contrainte à respecter. | Hard |
| 2 | N'affectez pas le même personnel à plusieurs créneaux horaires pendant les mêmes heures de travail. | |||
| 3 | Observer les heures de travail de chaque personne (départ anticipé, ne pas faire d'heures supplémentaires). | Contraintes de prise en compte | Règles de contrainte qui respectent autant que possible. Cependant, il existe des cas où il n'est pas observé en raison de l'équilibre avec d'autres règles de contraintes et indices d'évaluation. | Soft |
| 4 | Affecter du personnel possédant les compétences nécessaires au travail. | |||
| 5 | N'affectez pas de personnel de faible niveau à des changements de niveau de compétence élevé. | |||
| 6 | Le personnel faisant partie du même groupe de FCE (instructeur et nouvel arrivant) aura les mêmes heures de travail + le même lieu de travail. | |||
| 7 | Les personnes appartenant au même groupe d'exclusion du cadre de travail (comme celles qui ne correspondent pas) ne doivent pas être placées dans les mêmes heures de travail + le même lieu de travail. | |||
| 8 | Réduisez le nombre de mouvements dans la zone de travail. | Index d'évaluation | Règle de contrainte pour calculer de meilleures combinaisons. | |
| 9 | Égaliser les heures de travail du personnel. |
Taille du cas du modèle (taille de l'espace de recherche) et score cible
Le score est une valeur d'index qui évalue le calcul d'optimisation. Dans ce cas de modèle, 0 (0 difficile / 0 souple) est le meilleur score car toutes les règles de contrainte donnent une valeur de pénalité (valeur négative) au score. Cependant, étant donné les ressources limitées (nombre de personnel, nombre de créneaux horaires) et le temps disponible pour la planification, nous fixons le score cible quant à ce que nous devons optimiser.
Le score cible pour l'échelle (taille de l'espace de recherche) défini dans ce cas de modèle est le suivant.
| # | Echelle (taille de l'espace de recherche) | Score cible | |
|---|---|---|---|
| Nombre de personnes | Nombre d'images de décalage | ||
| 1 | 1000 | 4212 | 0hard/-69000soft |
| 2 | 500 | 2106 | 0hard/-34500soft |
| 3 | 250 | 1053 | 0hard/-17250soft |
L'idée du score cible est la suivante.
| Type de contrainte | Score cible | Formule de calcul du score cible |
|---|---|---|
| Contrainte absolue | 0 | ― |
| Contraintes de prise en compte | 0 | ― |
| Index d'évaluation |
Dans ce cas de modèle, réduisez au minimum avec les objectifs suivants.
|
|
| Total 0 hard / - (69 x nombre de personnes) soft | ||
Taille de l'espace de recherche
La taille de l'espace de recherche est le nombre de combinaisons possibles pour le plan, et plus la taille de l'espace de recherche est grande, plus le temps de calcul est long. La taille de l'espace de recherche dans ce cas modèle est la puissance du «nombre de personnel» par rapport au «nombre de cadres de décalage».
| # | Nombre de personnes | Nombre d'images de décalage | Taille de l'espace de recherche |
|---|---|---|---|
| 1 | 250 | 1053 | 2501053 ≧ 102525 |
| 2 | 500 | 2106 | 5002106 ≧ 105684 |
| 3 | 1000 | 4212 | 10004212 ≧ 1012636 |
La spécification de la taille de l'espace de recherche de Red Hat Decision Manager se trouve dans le Guide de l'utilisateur d'OptaPlanner Taille de l'espace de recherche. Veuillez vous y référer. Lorsque vous utilisez les résultats de vérification de cet article comme valeurs de référence, considérez attentivement la taille de cet espace de recherche.
Environnement de vérification
Dans cette vérification, la vérification a été effectuée à l'aide de l'environnement de vérification suivant.
** Environnement machine **
| Articles | valeur |
|---|---|
| nom du système d'exploitation | Microsoft Windows10 Pro |
| processeur | Processeur Intel® Core ™ i7-6700 à 3,40 GHz, 3408 Mhz, 4 cœurs, 8 processeurs logiques |
| Mémoire physique | 16GB |
| Nom du logiciel | version |
|---|---|
| Red Hat Decision Manager | 7.6.0 |
| OpenJDK | 1.8.0 |
** Informations de réglage **
| Articles | value |
|---|---|
| Taille initiale du tas Java | 4096 MB |
| Taille maximale du tas Java | 4096 MB |
| Nombre de threads utilisés | 6 |
Pour une spécification détaillée de la résolution incrémentielle multithread, consultez Résolution incrémentielle multithread dans le Guide de l'utilisateur d'OptaPlanner (https://docs.optaplanner.org/7.30.0.Final/optaplanner-docs/html_single/#multithreadedIncrementalSolving).
Méthode de vérification
Algorithme d'optimisation et paramètres de réglage
Red Hat Decision Manager prend en charge une variété d'algorithmes d'optimisation. Le temps de calcul nécessaire pour atteindre le score cible dépend de l'algorithme d'optimisation sélectionné et des valeurs spécifiées des paramètres de réglage de cet algorithme.
Dans cette vérification, la vérification est effectuée à l'aide des trois algorithmes optimisés couramment utilisés suivants.
- Tabu Search
- Late Acceptance
- Simulated Annealing
Si vous souhaitez connaître les spécifications détaillées de l'algorithme et d'autres alligorismes disponibles dans Red Hat Decision Manager, veuillez contacter le [Guide de l'utilisateur d'OptaPlanner](https://docs.optaplanner.org/7.30.0.Final/optaplanner-docs/html_single]. /)Prière de se référer à.
De plus, Red Hat Decision Manager a une fonction de référence en tant que fonction pour produire les résultats des calculs d'optimisation des algorithmes et des paramètres dans un rapport. En utilisant la fonction de référence et en comparant la configuration de chaque algorithme et paramètre, le réglage des paramètres peut être promu efficacement. Pour les spécifications détaillées de la fonction de benchmark, reportez-vous à Benchmarking and Tweaking in the OptaPlanner User Guide.
Condition de terminaison du calcul d'optimisation
Dans cette vérification, la condition de fin du calcul d'optimisation est définie pour se terminer lorsque l'une des deux conditions suivantes est satisfaite.
- Atteint l'heure spécifiée
- Meilleur score non mis à jour pendant 5 minutes
Vous pouvez également définir la condition de fin "atteindre le score cible", mais je voulais vérifier dans quelle mesure le score augmenterait, j'ai donc utilisé la condition de fin ci-dessus. Même dans un système réel, je pense qu'il arrive souvent que les conditions de résiliation ci-dessus soient fixées de manière à obtenir de meilleurs résultats dans un délai acceptable, plutôt que de mettre fin au calcul dès que le score cible est atteint.
Points d'évaluation
Les résultats suivants sont résumés dans cette vérification.
- Il est temps d'atteindre le score cible
- Meilleur score après 30 minutes
- Meilleur score après 60 minutes (250 personnes vérifiées jusqu'à 30 minutes, donc seulement 500 personnes et 1 000 personnes sont répertoriées)
Pour les calculs d'optimisation à petite échelle, tels que 250 personnes, atteindre le score cible le plus rapidement possible est considéré comme le point d'évaluation numéro un et est évalué (classé) par 1. Dans les calculs d'optimisation à grande échelle tels que 500 ou 1000 personnes, le temps nécessaire pour atteindre le score cible est également un point d'évaluation important, mais on considère que le point d'évaluation le plus important est de dériver la solution optimale dans un temps limité. , 2 pour évaluer (rang).
résultat de l'inspection
Puisqu'il y a tellement de modèles vérifiés, nous présenterons les meilleurs résultats de vérification. Le nombre entre parenthèses en bas de la colonne "Meilleur score après 30 minutes / 60 minutes" indique le temps (en secondes) auquel la condition finale "Le meilleur score n'a pas été mis à jour pendant 5 minutes" est satisfaite et le calcul d'optimisation est terminé. Je vais. La partie en gras dans la colonne "Temps nécessaire pour atteindre le score cible [secondes]" indique le temps nécessaire pour atteindre le score cible le plus rapidement dans chaque modèle de vérification.
1000 personnes (score cible: 0hard / -69000soft)
Tabu Search
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| entityTabuSize | acceptedCountLimit | ||||
| 1 | 9 | 4000 | 602 | 0hard/-55780soft | 0hard / -53928soft (3559 [secondes]) |
| 2 | 9 | 2000 | 687 | 0hard/-57125soft | 0hard / -56419soft (2545 [secondes]) |
| 3 | 5 | 4000 | 668 | 0hard/-57476soft | 0hard/-55623soft |
| 4 | 7 | 2000 | 1154 | 0hard/-57586soft | 0hard / -57208soft (2317 [secondes]) |
Late Acceptance
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| lateAcceptanceSize | acceptedCountLimit | ||||
| 1 | 3 | 1 | 731 | 0hard/-51909soft | 0hard/-50175soft |
| 2 | 1 | 1 | 306 | 0hard/-53840soft | 0hard/-52862soft |
| 3 | 5 | 1 | 1239 | 0hard/-54752soft | 0hard/-51532soft |
| 4 | 1 | 4 | 1270 | 0hard/-55282soft | 0hard/-53976soft |
Simulated Annealing
| Rang | paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| simulatedAnnealing StartingTemperature |
acceptedCountLimit | ||||
| 1 | 0hard/10soft | 4 | 348 | 0hard/-53457soft | 0hard/-52426soft |
| 2 | 0hard/5soft | 4 | 1113 | 0hard/-55198soft | 0hard/-53803soft |
| 3 | 0hard/50soft | 4 | 477 | 0hard/-55700soft | 0hard/-52170soft |
| 4 | 0hard/100soft | 4 | 1210 | 0hard/-58192soft | 0hard/-51499soft |
Avec des données de 1000 personnes, le score cible a été atteint en 306 secondes au plus vite. De plus, le meilleur score a été mis à jour en effectuant un calcul d'optimisation même après avoir atteint le score cible.
Vous trouverez ci-dessous la transition de score Soft n ° 1 pour chaque algorithme du tableau ci-dessus.
Le point de départ de chaque algorithme est le point où le score Hard devient 0 difficile.
Le recuit simulé a convergé vers 0 dur plus rapidement, comme indiqué dans ①.
Ci-dessous, une vue agrandie de ②.
L'algorithme le plus rapide pour atteindre le score cible était le recuit simulé.
Jusqu'à environ 1000 secondes, le recuit simulé a le meilleur score, mais après cela, l'acceptation tardive a le meilleur score.
Concernant l'augmentation du score de 3000 secondes en (1) à la fin du calcul d'optimisation, chaque algorithme en compte environ plusieurs centaines, et on suppose qu'aucune amélioration significative du score n'est attendue même si le calcul d'optimisation n'est plus effectué.
500 personnes (score cible: 0hard / -34500soft)
Tabu Search
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| entityTabuSize | acceptedCountLimit | ||||
| 1 | 7 | 2000 | 436 | 0hard/-27506soft | 0hard / -27506soft (2027 [secondes]) |
| 2 | 5 | 4000 | 263 | 0hard/-28082soft | 0hard / -27701soft (2584 [secondes]) |
| 3 | 7 | 4000 | 464 | 0hard/-28222soft | 0hard / -27649soft (3237 [secondes]) |
| 4 | 9 | 2000 | 170 | 0hard / -28585soft (1129 [secondes]) | ― |
Late Acceptance
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| lateAcceptanceSize | acceptedCountLimit | ||||
| 1 | 5 | 1 | 188 | 0hard/-24991soft | 0hard/-24621soft |
| 2 | 3 | 1 | 153 | 0hard/-25755soft | 0hard / -25625soft (2712 [secondes]) |
| 3 | 100 | 4 | 517 | 0hard/-25983soft | 0hard/-25213soft |
| 4 | 50 | 4 | 284 | 0hard/-26562soft | 0hard/-26196soft |
Simulated Annealing
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| simulatedAnnealing StartingTemperature |
acceptedCountLimit | ||||
| 1 | 0hard/5soft | 4 | 244 | 0hard/-26071soft | 0hard/-25384soft |
| 2 | 0hard/10soft | 4 | 685 | 0hard/-26438soft | 0hard/-25791soft |
| 3 | 0hard/5soft | 1 | 468 | 0hard/-27423soft | 0hard/-26365soft |
| 4 | 0hard/50soft | 4 | 151 | 0hard/-27932soft | 0hard/-26146soft |
Vous trouverez ci-dessous la transition de score Soft n ° 1 pour chaque algorithme du tableau ci-dessus.
Le point de départ de chaque algorithme est le point où le score Hard devient 0 difficile.
Le recuit simulé a convergé vers 0 dur plus rapidement, comme indiqué dans ①.
Ci-dessous, une vue agrandie de ②.
L'algorithme le plus rapide pour atteindre le score cible était l'acceptation tardive.
De 250 secondes à 700 secondes, le recuit simulé a le meilleur score, mais après cela, l'acceptation tardive a le meilleur score.
Concernant l'augmentation du score de 1800 secondes en (1) à la fin du calcul d'optimisation, chaque algorithme en compte environ plusieurs centaines, et on suppose qu'aucune amélioration significative du score n'est attendue même si le calcul d'optimisation n'est plus effectué. En ce qui concerne Tabu Search, le calcul d'optimisation a été réalisé sans aucune amélioration du score en environ 2000 secondes.
250 personnes (score cible: 0hard / -17250soft)
Tabu Search
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| entityTabuSize | acceptedCountLimit | ||||
| 1 | 11 | 2000 | 167 | 0hard / -15400soft (1378 [secondes]) | ー |
| 2 | 9 | 2000 | 224 | 0hard / -15265soft (1722 [secondes]) | ー |
| 3 | 5 | 1000 | 244 | 0hard / -16190soft (686 [secondes]) | ー |
| 4 | 7 | 4000 | 262 | 0hard/-15850soft | ― |
Late Acceptance
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| lateAcceptanceSize | acceptedCountLimit | ||||
| 1 | 5 | 1 | 98 | 0hard / -14755soft (1775 [secondes]) | ー |
| 2 | 20 | 1 | 182 | 0hard/-14681soft | ー |
| 3 | 10 | 1 | 216 | 0hard / -14534soft (1739 [secondes]) | ー |
| 4 | 10 | 4 | 248 | 0hard / -15118soft (1499 [secondes]) | ー |
| Rang | Paramètres | Temps nécessaire pour atteindre le score cible [secondes] | Meilleur score après 30 minutes | Meilleur score après 60 minutes | |
|---|---|---|---|---|---|
| simulatedAnnealing StartingTemperature |
acceptedCountLimit | ||||
| 1 | 0hard/5soft | 4 | 193 | 0hard / -15151soft (1159 [secondes]) | ー |
| 2 | 0hard/100soft | 4 | 325 | 0hard/-14977soft | ー |
| 3 | 0hard/50soft | 1 | 1215 | 0hard/-14584soft | ー |
| 4 | 0hard/500soft | 4 | 1355 | 0hard/-15122soft | ー |
Avec des données de 250 personnes, le score cible a été atteint en 98 secondes au plus vite. De plus, le meilleur score a été mis à jour en effectuant un calcul d'optimisation même après avoir atteint le score cible.
Vous trouverez ci-dessous la transition de score Soft n ° 1 pour chaque algorithme du tableau ci-dessus.
Le point de départ de chaque algorithme est le point où le score Hard devient 0 difficile.
Le recuit simulé a convergé vers 0 dur plus rapidement, comme indiqué dans ①.
Ci-dessous, une vue agrandie de ②.
L'algorithme le plus rapide pour atteindre le score cible était l'acceptation tardive.
L'acceptation tardive a donné le meilleur score du début à la fin.
Concernant l'augmentation du score de 300 secondes en (1) à la fin du calcul d'optimisation, chaque algorithme en compte environ plusieurs centaines, et on suppose qu'aucune amélioration significative du score n'est attendue même si le calcul d'optimisation n'est plus effectué.
Considération
Lors de cette vérification, nous avons pu confirmer que Red Hat Decision Manager peut réaliser une optimisation de la planification à une échelle de 1 000 personnes dans un laps de temps réaliste. Ici, nous allons considérer ce que nous pouvons voir à partir de la vérification.
Temps de calcul et caractéristiques du score de chaque algorithme
Dans le cas du modèle, l'échelle (taille de l'espace de recherche) et les valeurs de poids de la règle de contrainte de cette vérification, la caractéristique (tendance) du score du temps de calcul de chaque algorithme n'a pas été trouvée.
Facilité de réglage de chaque algorithme
| # | Algorithme d'optimisation | Caractéristiques vues de la vérification | Prise en compte des résultats de vérification |
|---|---|---|---|
| 1 | Tabu Search | La plage de valeurs des paramètres de réglage est large. | Si vous vérifiez et ajustez de nombreux paramètres, il est fort possible que vous obteniez le score le plus élevé. Cependant, comme les données d'entrée ne sont pas les mêmes à chaque fois, on suppose que l'ajustement général est difficile. |
| 2 | Late Acceptance | La plage de valeurs des paramètres de réglage est relativement étroite. Il est facile de voir la tendance à l'amélioration / la détérioration du score due au changement du paramètre | , et on suppose que c'est le plus facile à ajuster parmi les trois algorithmes utilisés dans cette vérification. |
| 3 | Simulated Annealing | Dans le résultat de la vérification de cette vérification, la plage de valeurs des paramètres de réglage est relativement étroite. Cependant, puisque le paramètre de réglage "simulatedAnnealingStartingTemperature" spécifie la "valeur initiale de la valeur de score qui permet l'acceptation", il dépend de la valeur de poids de la règle de contrainte. Il est nécessaire de prendre en compte non seulement l'échelle | (la taille de l'espace de recherche) mais également la valeur de poids de la règle de contrainte, et on suppose qu'elle est plus difficile à ajuster que l'acceptation tardive. |
Comment ajuster les paramètres de réglage
| # | Optimisation Algorithme | Paramètres de réglage | Plage spécifiée |
|---|---|---|---|
| 1 | Tabu Search | entityTabuSize | 5～12 |
| 2 | acceptedCountLimit | 1000～4000 | |
| 3 | Late Acceptance | lateAcceptanceSize | 1～600 |
| 4 | acceptedCountLimit | 1 ou 4 | |
| 5 | Simulated Annealing | simulatedAnnealingStartingTemperature | (Dépend de la valeur de poids de la règle de contrainte.) |
| 6 | acceptedCountLimit | 1 ou 4 |
Si la valeur spécifiée est grande, le nombre de combinaisons à évaluer sera important et le temps de résolution du problème sera long, mais le score maximum sera élevé.
Si la valeur spécifiée est petite, le nombre de combinaisons à évaluer sera petit et le temps pour résoudre le problème sera court, mais le score maximum sera faible. **#1 :** La tendance n'est pas claire, mais si 7 et 9 sont relativement bons et que l'échelle (la taille de l'espace de recherche) est petite, nous supposons que vous devez augmenter la valeur. **#2,#4,#6 :** Il est recommandé de mesurer réellement car la tendance est inconnue.
J'ai vérifié la plage spécifiée de entityTabuSize de Tabu Size dans la plage de 5 à 11, mais le site suivant a déclaré que "une valeur de 5 à 12 est bonne". https://ja.wikipedia.org/wiki/%E3%82%BF%E3%83%96%E3%83%BC%E3%82%B5%E3%83%BC%E3%83%81
Pour tous les algorithmes, la modification des paramètres de réglage peut faire une grande différence dans les résultats, mais nous avons constaté que les ajustements donnaient de bons résultats. J'ai présenté comment ajuster les paramètres de réglage de chaque algorithme, mais j'ai senti que l'acceptation tardive est plus facile à ajuster que d'autres algorithmes. Par conséquent, si vous ne disposez pas de suffisamment de temps pour mesurer réellement, c'est une bonne idée de s'ajuster à partir de l'acceptation tardive.
Paramètres pouvant être utilisés comme valeurs de base pour chaque échelle (taille de l'espace de recherche)
Dans cette vérification, environ 60 modèles ont été vérifiés sur chaque échelle. Lors de l'exécution de calculs d'optimisation avec des cas de modèle similaires, l'échelle (taille de l'espace de recherche) et les valeurs de pondération des règles de contrainte, il est efficace d'ajuster les paramètres à partir de la gamme de combinaisons d'algorithmes d'optimisation et de paramètres ci-dessous. Je suppose que vous pouvez régler.
| Échelle (taille de l'espace de recherche) | Algorithme d'optimisation | Paramètres | |
|---|---|---|---|
| Nombre d'employés | Shift Nombre d'images | ||
| 1000 | 4212 | Tabu Search | entityTabuSize : 7～9 acceptedCountLimit : 1000～4000 |
| Late Acceptance | lateAcceptanceSize : 1～10 acceptedCountLimit : 1 |
||
| Simulated Annealing | simulatedAnnealingStartingTemperature : 0hard/5soft～0hard/100soft acceptedCountLimit : 4 |
||
| 500 | 2106 | Tabu Search | entityTabuSize : 5～9 acceptedCountLimit : 1000～4000 |
| Late Acceptance | lateAcceptanceSize : 3～10 acceptedCountLimit : 1 |
||
| lateAcceptanceSize : 30～100 acceptedCountLimit : 4 |
|||
| Simulated Annealing | simulatedAnnealingStartingTemperature : 0hard/5soft～0hard/100soft acceptedCountLimit : 4 |
||
| 250 | 1053 | Tabu Search | entityTabuSize : 11 acceptedCountLimit : 1000～4000 |
| Late Acceptance | lateAcceptanceSize : 5～20 acceptedCountLimit : 1 |
||
| Simulated Annealing | simulatedAnnealingStartingTemperature : 0hard/5soft acceptedCountLimit : 4 |
||
en conclusion
Dans cet article, nous avons présenté les résultats de la vérification des performances pour l'optimisation planifiée de 250, 500 et 1000 personnes. Je pense que Red Hat Decision Manager sera plus facile à utiliser en se référant à la méthode d'ajustement des paramètres de réglage introduite et aux paramètres qui peuvent être utilisés comme valeurs de base, alors essayez-le.