Une recommandation de centre de données exige une règle de retrait
Un paramètre de centre de données a deux missions qui peuvent tirer dans des directions opposées : maintenir l'installation connectée lors de brèves perturbations de tension et basculer sur l'alimentation de secours lorsqu'un défaut exige cette réponse. Une recommandation qui résout le premier problème n'a pas encore mérité l'autorisation pour le second. Ma norme de conception consiste à expliciter les deux conditions, y compris les preuves qui peuvent retirer une réponse apparemment réussie.
Notre simulation Veriprajna applique cette norme dans une installation synthétique. Son inventaire d'équipements, ses événements de tension et ses résultats sont des fixtures, et non une installation client ou un incident mesuré. L'exécution assistée par modèle utilise des réponses préalablement mises en cache via un pont local plutôt qu'une inférence fraîche. Au sein de cet exemple limité, un défaut proposé supplémentaire transforme la réponse finale d'un paramètre préliminairement validé en aucune recommandation.
Ce revirement compte, car le flux de travail doit préserver un test de recette échoué même lorsqu'il dispose déjà d'un paramètre plausible et d'une explication fluide en sa faveur.
Deux raisons de basculer
La simulation modélise un parc d'unités UPS (alimentations sans interruption). Une voie de basculement compte les perturbations de tension admissibles à l'intérieur d'une fenêtre temporelle glissante. Dès qu'un nombre suffisant d'événements s'accumule, une unité bascule sur le secours. Une autre voie réagit de manière indépendante à un creux de tension suffisamment profond et prolongé. La modification du réglage de comptage laisse cette seconde voie intacte.
La tension technique est compréhensible sans schéma d'équipement. Un compteur sensible peut basculer lors d'une succession de perturbations que l'installation est censée traverser. Un compteur plus tolérant peut maintenir la charge modélisée connectée, mais il doit toujours répondre aux cas de défaut utilisés pour tester la protection. Dans cette démonstration, la recette exige les deux comportements sur une bibliothèque finie d'événements.
Ces résultats nécessitent également une dénomination rigoureuse. Basculer un centre de données sur le secours retire sa charge du réseau électrique ; cela n'établit pas en soi que les serveurs ont perdu l'alimentation. Inversement, conserver la charge modélisée sur le réseau ne dit rien sur le fait qu'une vraie batterie dispose d'une énergie suffisante. Une recommandation de paramètre ne peut emprunter aucune conclusion à l'autre métrique.
La recherche initiale trouve un candidat avec cinq événements dans une fenêtre de 90 secondes en utilisant un comptage global. Il réussit la bibliothèque de base. Cela donne au flux de travail une raison de continuer à tester le candidat, et non une raison de cesser de le remettre en question.
Un défaut proposé tombe entre les voies
Le challenger de modèle en cache ajoute un événement synthétique étiqueté comme un défaut d'isolation progressif de l'enroulement du transformateur. La preuve utile est son comportement dans le simulateur, plutôt que l'autorité suggérée par son nom.
Il contient quatre creux comptabilisés espacés de plus de 90 secondes. Pour le candidat préliminaire à cinq événements, les creux antérieurs sortent de la fenêtre avant qu'un nombre suffisant ne puisse s'accumuler. Chaque creux reste également au-dessus du seuil de creux profond modélisé de 0.60 par-unit, où « par-unit » désigne une fraction de la tension nominale. Aucune des deux voies de basculement ne capture l'événement proposé pour ce candidat.
Le flux de travail répète ensuite la recherche sur l'ensemble des 32 combinaisons configurées de seuil d'événements, de fenêtre et de mode de comptage, en utilisant les quatre défauts de base ainsi que la proposition ajoutée. Aucun candidat ne satisfait à la fois aux conditions d'événements bénins et d'événements de défaut. Le résultat final est une abstention, sans aucune configuration sélectionnée. Il s'agit d'un retrait de la recommandation préliminaire, et non d'une mesure indiquant que chaque candidat a échoué à chaque test individuel.
Un choix de conception majeur est visible ici : le modèle peut apporter un nouveau cas, mais des vérifications déterministes décident si un candidat reste acceptable. Un exposé convaincant du paramètre proposé ne peut pas rétablir la recommandation après l'échec de ces vérifications. L'explication de la démo fournit la vidéo et un contexte supplémentaire pour cet exemple.
Pourquoi ne pas continuer à ajuster jusqu'à ce que quelque chose passe ?
Élargir une fenêtre de comptage semble être une réponse naturelle à des perturbations très espacées. Abaisser un seuil en paraît une autre. L'une ou l'autre modifie les événements qui déclenchent un basculement, de sorte que l'une ou l'autre peut également compromettre l'objectif de traverser des perturbations bénignes. Une correction doit être évaluée par rapport aux deux objectifs, plutôt que jugée uniquement sur sa capacité à capturer l'événement nouvellement ajouté.
La recherche démontrée vérifie déjà son menu fini et ne renvoie aucune réponse. Élargir ce menu constituerait une nouvelle expérience. Elle pourrait identifier un autre candidat, mais le succès dépendrait toujours des mêmes conditions de recette et de ce que le modèle représente. Un menu épuisé constitue une preuve concernant ces choix examinés, et non la preuve que chaque réglage d'équipement envisageable est inadapté.
Je préfère un résultat non résolu visible plutôt que de sélectionner l'échec le moins décevant et de le présenter comme une configuration. Cette préférence a un coût : une équipe ne reçoit aucun nouveau paramètre de cette exécution. Elle doit décider quelles preuves ou quelle modification de modélisation justifieraient une autre recherche. Le refus gagne sa légitimité en rendant ce travail manquant explicite.
Dans un processus d'ingénierie réel, suspendre une proposition de modification doit également être distingué de l'exploitation des équipements existants. Cette simulation n'émet aucune commande d'équipement. Son abstention n'établit pas qu'une installation doit se déconnecter, que ses réglages actuels sont sûrs ou que du matériel doit être remplacé.
Un contre-exemple nécessite aussi un examen minutieux
Un test difficile peut révéler une lacune dans une procédure de recette tout en restant une mauvaise description des équipements physiques. Le nom « défaut d'isolation d'enroulement » n'établit pas un diagnostic de transformateur. Cet exemple montre un événement simulé échappant à deux voies de basculement modélisées ; il ne valide pas cet événement comme un véritable défaut électrique.
Cela laisse deux décisions distinctes. Selon les hypothèses de test actuelles, le flux de travail ne dispose d'aucune recommandation acceptable. Pour une installation réelle, les ingénieurs devraient également évaluer si ces hypothèses représentent les équipements et les perturbations pertinents. Supprimer l'épreuve parce qu'elle bloque une réponse dissimulerait la première décision. Traiter l'épreuve comme une preuve physique éluderait la seconde.
Une étape ultérieure utile consiste donc à définir ce qui permettrait de lever l'incertitude. Si l'événement proposé est physiquement pertinent, le modèle ou les paramètres disponibles peuvent nécessiter une révision avant qu'une recommandation ne puisse aboutir. S'il n'est pas pertinent, son exclusion nécessite une raison technique liée au périmètre modélisé. L'une ou l'autre voie doit préserver le test échoué et sa qualification afin qu'un résultat ultérieur validé puisse être compris.
Le comportement mesuré des équipements, l'énergie de la batterie et les temps de basculement restent en dehors de cette démonstration. Un véritable changement de paramètre nécessiterait des réglages d'équipement vérifiés, des données de perturbation mesurées, un modèle électrique validé approprié et un examen d'ingénierie indépendant. Une sortie de modèle plus fluide ne peut pas fournir ces données manquantes.
Voici ma brève explication des raisons pour lesquelles je souhaite que la recommandation soit retirée lorsque ses tests justificatifs échouent.
Pour un flux de travail d'ingénierie assisté par l'IA, je souhaite que le registre de recette identifie le candidat actuel, les tests qu'il satisfait, le test capable de le disqualifier et l'incertitude subsistant après le retrait. Une réponse positive n'est utile que tant que ses raisons déclarées continuent de s'appliquer. Lorsqu'elles ne le font plus, le flux de travail doit préserver l'objection et retirer la recommandation avant que quiconque ne la traite comme une autorisation de modifier l'équipement.
