[JAVA] Planifiez une «image d'utilisation» d'optimisation avec une IA qui comprend la raison du résultat

Auteur: Takashi Takahisa, Hitachi, Ltd.

introduction

Dans cet article, j'ai publié [Red Hat Decision Manager](https: // www.) Dans "Planifier l'optimisation par une IA qui comprend la raison du résultat". Nous présenterons un cas de modèle concret et une image d'utilisation des fonctionnalités d'optimisation de la planification à l'aide de redhat.com/en/technologies/jboss-middleware/decision-manager). Si vous n'avez pas lu l'article ci-dessus, nous vous recommandons de le lire d'abord.

Liste des messages:

1. Planifiez l'optimisation avec une IA qui comprend la raison du résultat
2. Planifiez une "image d'utilisation" d'optimisation avec une IA qui comprend la raison du résultat (cet article)

Cas modèle (plan d'inspection des équipements)

Dans ce cas modèle, nous optimiserons le plan d'inspection annuel des gros équipements.

Contexte

Pour les raisons suivantes, nous systématiserons le travail de planification des contrôles qui a été effectué manuellement. ・ À mesure que le nombre et les types d'équipements à inspecter augmentaient, il a fallu beaucoup de temps pour élaborer un plan. -Comme il s'agit d'un appareil volumineux, le coût d'inspection par unité est élevé, et en augmentant le nombre de jours de retour (intervalle d'inspection) dans la plage autorisée, on peut s'attendre à une réduction significative des coûts. (Dans le passé de la planification manuelle, il était difficile de considérer les restrictions à observer et l'efficacité ne pouvait pas être prise en compte.)

Aperçu du plan

Entrez la liste des appareils à inspecter pour l'année en cours et les données associées utilisées dans le calcul d'optimisation, puis calculez et sortez la date de début de l'inspection et la zone d'inspection (emplacement où l'inspection est effectuée) pour chaque appareil. Le nombre de jours d'inspection pour chaque type d'appareil doit être prédéterminé. Les inspections ne peuvent être effectuées que les jours de semaine. Il n'est pas possible d'inspecter plusieurs appareils en même temps dans une zone d'inspection.

Constitution

Dans ce cas modèle, il est implémenté avec la configuration suivante.

Contraintes / indicateurs d'évaluation (règles Excel)

Dans ce cas de modèle, les contraintes suivantes sont définies.

■ Restrictions absolues (restrictions que vous souhaitez absolument conserver) -Limitation du nombre d'inspections simultanées par jour: Seules x unités peuvent être inspectées par jour. -Nombre de jours limité: l'inspection doit être effectuée dans les x jours à compter de la dernière date de fin d'inspection. ■ Contraintes de prise en compte (contraintes que vous souhaitez conserver autant que possible) -Considération du nombre d'inspections simultanées pendant la haute saison: Pour les appareils d'une classification spécifique, nous souhaitons maintenir le nombre d'inspections à effectuer à moins de x pendant la haute saison. -Considération du système d'inspection pour le même appareil: Pour les appareils du même type, la date de début de l'inspection doit être de x jours ou plus. ■ Indice d'évaluation (indice pour calculer une meilleure combinaison) -Maximisation des jours de retour: Plus les jours de retour (intervalle d'inspection) sont longs, mieux c'est. (Pour réduire les coûts d'inspection et les temps d'arrêt) -Nivellement du travail pour chaque mois: niveler le nombre d'inspections pour chaque type d'appareil chaque mois.

** Règles Excel **

■ À propos de l'ajustement de priorité entre les règles La priorité est définie par niveau + coefficient de poids, et le résultat est évalué comme une valeur de score pour chaque niveau. Il est évalué dans l'ordre à partir de la valeur de score de niveau le plus élevé (difficile dans l'exemple ci-dessus), et si la valeur de score de haut niveau est la même, elle est évaluée par la valeur de score de niveau suivant, et la combinaison avec la meilleure valeur de score est la solution optimale. Je vais. Dans cet exemple, nous utilisons deux niveaux, Hard et Soft, afin d'optimiser le degré de respect des contraintes de prise en compte et de l'indice d'évaluation tout en respectant toujours les contraintes absolues.

Dans cet exemple, il existe deux niveaux, Hard et Soft, mais il peut y en avoir trois ou plus. Si vous souhaitez donner la priorité au respect des contraintes de prise en compte par rapport à l'amélioration des indicateurs d'évaluation, plutôt qu'à une évaluation complète du degré de conformité aux contraintes de prise en compte et à l'amélioration des indicateurs d'évaluation, définissez les contraintes de prise en compte sur le niveau Moyen. Cela peut être réalisé en faisant.

Le facteur de pondération est le facteur d'ajustement de priorité pour les règles de même niveau. Dans cet exemple, le coefficient de pondération est spécifié sous la forme d'un entier, mais vous pouvez spécifier une valeur de type BigDecimal. Par exemple, vous pouvez spécifier des valeurs telles que «12,345» et «0,02». Augmentez le facteur de pondération pour les règles de priorité élevée, mais considérez également la valeur de base du score pour chaque règle. Par exemple, la contrainte absolue n ° 1 est basée sur le nombre d'unités qui dépassent la limite du nombre d'inspection, la contrainte absolue n ° 2 est basée sur le nombre de jours qui dépasse la limite de jours, et la valeur de base est susceptible d'être plus grande dans n ° 2, donc le coefficient de n ° 1 est utilisé. Je le fais plus grand. Dans le cas des contraintes absolues, nous voulons toujours les protéger, donc nous n'avons pas à être très conscients du coefficient de pondération du niveau Hard, mais cette fois nous pouvons détecter les deux en moyenne lorsque des données d'entrée difficiles à protéger entrent. Ajusté en considération. Les facteurs de pondération de niveau souple doivent être soigneusement pris en compte et déterminés afin de faire un bon plan. Cependant, vous pouvez le modifier à tout moment, vous pouvez donc spécifier une valeur approximative dans un premier temps.

Des données d'entrée

L'équipement à planifier et les données de base sont reçus en tant que données d'entrée. En recevant le seuil de la règle de contrainte comme données d'entrée, il est facile de le modifier ultérieurement. Comme il serait trop long de lister toutes les données d'entrée, je vais les lister comme un extrait (il y a d'autres données de base auxquelles se référer).

** Données de l'appareil à inspecter **

** Données de définition **

** Données des jours d'inspection **

Application métier

Dans ce cas de modèle, nous avons implémenté la lecture des données d'entrée, le traitement d'évaluation de certaines conditions de contrainte référencées à partir des règles de contrainte, l'appel du calcul d'optimisation de Red Hat Decision Manager, la sortie du résultat du calcul d'optimisation, la sortie des données de score, etc. Je crée une application métier. Le calcul d'optimisation de l'IA le plus important et le plus difficile lui-même est effectué par Red Hat Decision Manager, de sorte que le nombre d'étapes pour les applications métier est de 1,2 K, ce qui est une implémentation simple.

Calcul d'optimisation (Red Hat Decision Manager)

Le calcul d'optimisation de Red Hat Decision Manager est effectué en exécutant à plusieurs reprises les processus suivants (1) à (3). ① Générez une combinaison de chaque appareil et de la date de début d'inspection et de la zone d'inspection (2) Calculez le score de la condition de contrainte / indice d'évaluation défini comme une règle Excel pour la combinaison générée. ③ Comparez la valeur de score de cette combinaison avec la valeur de score de la combinaison de solutions optimale passée et définissez la meilleure comme solution optimale.

Ici, l'algorithme de génération de combinaison de (1) et le temps de répétition (temps de calcul) de (1) à (3) sont définis dans le fichier de configuration de Red Hat Decision Manager. Le temps de calcul optimal et les paramètres d'algorithme dépendent de la quantité de données, du nombre de contraintes / indicateurs d'évaluation, etc., mais dans ce cas de modèle, les paramètres suivants sont utilisés. Algorithme de génération de solution initiale: First Fit Algorithme de recherche locale: Acceptation tardive Temps de calcul d'optimisation: 60 secondes

Contenu de la définition de cet algorithme d'optimisation

<termination>
	<secondsSpentLimit>60</secondsSpentLimit>
</termination>
<constructionHeuristic>
	<constructionHeuristicType>FIRST_FIT</constructionHeuristicType>
</constructionHeuristic>
<localSearch>
	<acceptor>
		<lateAcceptanceSize>80</lateAcceptanceSize>
	</acceptor>
	<forager>
		<acceptedCountLimit>1</acceptedCountLimit>
	</forager>
</localSearch>

■ À propos de l'algorithme d'optimisation Les algorithmes d'optimisation de Red Hat Decision Manager sont basés sur une combinaison d'algorithmes de génération de solution initiale et d'algorithmes de recherche locale. L'algorithme de génération de solution initiale génère la première combinaison, et l'algorithme de recherche locale génère la deuxième combinaison et les suivantes.

L'algorithme de génération de solution initiale utilise cette fois First Fit, qui est le plus simple à utiliser. Si vous souhaitez améliorer les performances, envisagez d'utiliser d'autres algorithmes tels que First Fit Decreasing, qui vous permet de hiérarchiser la combinaison des solutions initiales.

L'algorithme de recherche locale utilise cette fois l'acceptation tardive car il est hautement évolutif, il est facile de trouver la solution optimale et il est facile à régler. D'autres algorithmes bien connus tels que Tabu Search et Simulated Annealing sont également pris en charge, et nous les considérerons si nécessaire.

Pour une acceptation tardive, il vous suffit de fixer la valeur AcceptéeCompteLimit à 1 (4 dans certains cas) et de régler uniquement la taille LateAcceptance. De plus, pour lateAcceptanceSize, plus la valeur spécifiée est élevée, plus le nombre de combinaisons de cibles est élevé et plus la résolution du problème prend du temps, mais plus le score maximal est élevé. Par conséquent, la valeur est ajustée en fonction de l'échelle des données d'entrée (dans ce cas, le nombre d'appareils à inspecter, le nombre de dates candidates pour la date de début de l'inspection, le nombre de zones d'inspection) et l'heure de calcul. Même si les données d'entrée sont différentes à chaque fois, vous pouvez les utiliser pour définir dynamiquement la valeur spécifiée pour lateAcceptanceSize en fonction de l'échelle des données d'entrée.

La recherche Tabu doit être réglée en combinant deux paramètres, et la plage de valeurs spécifiées doit également être réglée dans une plage plus large que l'acceptation tardive.

Le recuit simulé est une valeur spécifiée du paramètre de réglage, et il est nécessaire de prendre en compte le score de la règle de contrainte en plus de l'échelle et du temps de calcul des données d'entrée, et lorsque la règle de contrainte est ajoutée ou que le coefficient de poids est modifié, le paramètre de réglage est également modifié. Il doit être revu.

La fonction d'optimisation de la planification de Red Hat Decision Manager est basée sur un OSS appelé OptaPlanner. Si vous souhaitez voir une liste d'algorithmes et de spécifications détaillées disponibles dans Red Hat Decision Manager, veuillez vous référer au Guide de l'utilisateur d'OptaPlanner.

■ À propos du temps de calcul et de la convergence des scores Plus le temps de calcul est long, meilleur est le résultat, mais avec le temps, le score convergera et ne s'améliorera guère. Décidez du temps que vous souhaitez, en tenant compte de votre score cible (degré d'optimisation) et des exigences de performance. En plus de la simple fin du calcul, il est possible de terminer le calcul lorsqu'un score spécifique est atteint, de terminer le calcul si le score ne s'améliore pas pendant une certaine période de temps et de terminer le calcul lorsque l'une des multiples conditions de fin est remplie.

** Exemple de time lapse et de convergence de score **

Données de résultat

-Les données de résultat d'optimisation sont les données auxquelles la date de début d'inspection et la zone d'inspection sont affectées à l'équipement à inspecter. -Pour les zones d'inspection, nous préparons autant de zones d'inspection que le nombre d'inspections simultanées par jour, et attribuons la zone d'inspection utilisée par chaque appareil. -Pour la date de fin d'inspection, la valeur calculée automatiquement à partir de la date de début d'inspection et du nombre de jours d'inspection est sortie. -Pour le nombre de jours de retour, la valeur calculée automatiquement à partir de la date de début d'inspection et de la date de fin d'inspection précédente est sortie.

** Données de résultat (extrait) **

** Données de résultat visualisées (extrait) **

Données d'information sur le score (raison des résultats)

Ce sont les données qui produisent le degré de conformité aux conditions de contrainte et l'évaluation par l'indice d'évaluation sous forme de score. Le score cette fois est une méthode de déduction pour toutes les règles, et plus il est proche de 0, meilleure est l'évaluation. Dans cette application métier, il est généré dans un fichier Excel.

** Feuille récapitulative **

** Règle + fiche d'unité de l'appareil (extrait) **

** Règle + feuille de date de début du plan (extrait) **

Image de l'utilisation des données d'information sur le score (raison des résultats)

Confirmation qu'il fonctionne comme prévu

La contrainte absolue et la contrainte de considération se trouvent dans la "feuille de synthèse" ci-dessus, le score est "0hard / 0soft", et vous pouvez voir qu'il n'y a pas de violation (protégé).

Pour l'indice d'évaluation n ° 1, "- (jours limite-jours de retour)" * "Coefficient de pondération de règle Excel 1" est utilisé comme valeur de score. En regardant la «Feuille de règles + unité de périphérique (extrait)» ci-dessus, les valeurs dans la colonne «Score» et les valeurs «Jours limités-jours de retour» sont «0hard / -109soft» et «109» dans chaque ligne. Vous pouvez voir qu'ils correspondent et fonctionnent correctement.

Pour l'indice d'évaluation n ° 2, la valeur du score est "- (nombre total d'appareils / 12 appareils au cours du mois en cours) ^ 2" * "Coefficient de poids de règle Excel 100" pour les appareils du même type d'appareil. La fraction de la division est arrondie à la deuxième décimale. En regardant la feuille de date de début de la règle + planification (extrait) ci-dessus, la valeur de la colonne "Score" correspond à la valeur calculée par la formule ci-dessus dans chaque ligne, et elle fonctionne correctement Je comprends. Exemple :-( 13/12 --1) ^ 2 * 100 = - (1.08333 ... --1) ^ 2 * 100 = - (1.1 --1) ^ 2 * 100 = - (0.1) ^ 2 * 100 = - 0,01 * 100 = -1 ⇒ Correspond à "0 difficile / -1,00 doux".

Détection des problèmes des données d'entrée et des conditions de contraintes

Selon le contenu des données d'entrée, les contraintes peuvent ne jamais être satisfaites et la planification peut ne pas être possible. Par exemple, les cas suivants. ・ Développer un plan d'inspection pour FY2019 (après le 1er avril 2019). ・ La date de fin de la dernière inspection est le 2016/3/1. -Le nombre maximum de jours pour la contrainte absolue n ° 2 est de 900 jours. Dans un tel cas, même si la date de début de l'inspection est prévue au plus tôt le 1er avril 2019, les restrictions absolues ne peuvent pas être respectées et le plan ne peut pas être fait. (Il est possible que l'année prévue, la date d'inspection précédente et le nombre maximum de jours aient été définis de manière incorrecte.) Les données relatives aux informations de score facilitent la détection de ces problèmes, car vous pouvez voir rapidement les données non conformes.

** Informations sur le score (feuille récapitulative) lorsque le nombre de jours limite est dépassé ** ** Informations de score en cas de non-respect de la limite du nombre de jours (règle + fiche d'unité d'appareil (extrait)) **

Comparaison avec les plans antérieurs

Vous pouvez comparer les scores du plan précédent et du nouveau plan pour voir si le plan est meilleur que le plan précédent. Vous pouvez générer les informations de score du plan précédent en spécifiant les données planifiées comme données d'entrée à l'aide de l'application métier et de la règle Excel créées pour le calcul d'optimisation normal telles quelles. Les données planifiées sont les données d'entrée (données de l'appareil cible du contrôle) plus les valeurs prévues pour la "date de début du contrôle" et la "zone de contrôle".

** Configuration de la sortie des informations de score des données planifiées **

** Données planifiées des plans précédents **

** Notez les données d'information des plans précédents ** ** Données d'information de score pour les nouveaux plans par Red Hat Decision Manager **

Dans cet exemple, toutes les contraintes sont satisfaites à la fois dans le plan précédent et dans le nouveau plan, mais le score de la métrique est meilleur dans le nouveau plan et vous pouvez voir que le plan est plus efficace.

De plus, si vous ajustez le poids du score Soft en fonction du coût, vous pouvez évaluer quantitativement la réduction des coûts obtenue grâce au score amélioré. Par exemple, si le nombre d'inspections est réduit en maximisant le nombre de jours de retour et que les coûts d'inspection supplémentaires tels que la rémunération des heures supplémentaires sont réduits par le nivellement du travail, le coût est réduit de 20 000 yens par score Soft. (Score du plan précédent - Nouveau score du plan) * (Coût de la réduction des coûts par score Soft) = (10426 - 6979) * 2 = 3447 * 2 = 6894 On peut estimer que "le coût a été réduit de 68,94 millions de yens par rapport au plan précédent".

En comparant ainsi les scores du plan passé et du nouveau plan, il est possible de juger quantitativement dans quelle mesure il est optimisé. De plus, dans le cas peu probable où le plan précédent obtiendrait un meilleur score, vous serez conscient qu'il existe des spécifications qui n'ont pas été prises en compte et qu'il y a des problèmes tels que le temps de calcul et le réglage de l'algorithme.

en conclusion

Dans cet article, nous avons présenté une image de l'utilisation de l'optimisation du plan à l'aide de l'IA, qui montre la raison des résultats. En utilisant les données d'informations de score qui sont la raison du résultat, il est possible de juger quantitativement combien d'optimisation a été effectuée et de l'améliorer afin qu'une meilleure optimisation puisse être obtenue. J'espère que vous envisagerez de l'utiliser.