資料中心人工智慧工程

資料中心建議需要撤回規則

Ashutosh Singhal 2026年8月8日6 min

資料中心設定有兩項可能產生衝突的任務：在短暫的電壓擾動期間保持設施與電網連接，以及在故障需要回應時切換到備用電源。解決第一個問題的建議尚未獲得第二個問題的許可。我的設計標準是將這兩個條件明確化，包括能夠撤回看似成功答案的證據。

我們的Veriprajna模擬在合成設施中落實了這一標準。其設備清單、電壓事件和結果均為測試固件，而非客戶實際安裝或測得的事件。模型輔助運行透過本地網橋使用先前快取的答覆，而非全新推論。在這個有限的範例中，新增的提議故障將最終答案從初步通過的設定變為無建議。

這種逆轉至關重要，因為即便工作流程已經擁有合理的設定和流暢的解釋，也必須保留失敗的驗收測試。

切換備用電源的兩個原因

該模擬對一組UPS（不斷電系統）設備進行了建模。一條切換路徑在滑動時間窗口內對符合條件的電壓擾動進行計數。一旦累積足夠的次數，設備就會切換到備用電源。另一條路徑則對足夠深且持續的電壓驟降做出獨立回應。更改計數設定不會影響這第二條路徑。

無需設備圖表即可理解這種工程上的權衡。敏感的計數器可能會在設施本應平穩度過的一系列擾動期間發生切換。更具寬容度的計數器可以保持建模負載處於連接狀態，但仍需對用於測試保護的故障案例做出回應。在此演示中，驗收要求在有限事件庫中同時滿足這兩種行為。

這些結果同樣需要嚴謹的命名。將資料中心切換到備用電源會將其負載從公用電網中切除；但這本身並不能證明伺服器斷電。相反，保持建模的電網負載並不能說明實際電池是否具有充足的能量。設定建議不能從另一項指標中借用任何結論。

初步搜尋使用聚合計數，在90秒窗口內找到了允許五次事件的候選方案。它通過了基礎庫。這為工作流程提供了繼續測試該候選方案的理由，而不是停止質疑它的理由。

快取的模型挑戰者添加了一個標記為變壓器繞組漸進絕緣故障的合成事件。有用的證據是其在模擬器內部的行為，而不是其名稱所暗示的權威性。

它包含四次計數的電壓驟降，間隔均超過90秒。對於初步的五次計數候選方案，在累積足夠次數之前，早期的驟降就已經滑出了時間窗口。每次驟降也始終高於建模的0.60 per-unit深度驟降閾值（per unit表示標稱電壓的分數）。對於該候選方案，兩條切換路徑都未能擷取所提議的事件。

隨後，工作流程使用四個基本故障加上新增的提議，針對事件閾值、時間窗口和計數模式的所有32種配置組合重複搜尋。沒有候選方案能夠同時滿足良性事件和故障事件條件。最終結果是棄權，未選擇任何配置。這是對初步建議的撤回，而不是每個候選方案在每個個別測試中都失敗的測量結果。

這裡展現了一個重要的設計抉擇：模型可以提供新的案例，但確定性檢查決定候選方案是否仍然可接受。在這些檢查失敗後，對所提議設定的令人信服的解釋無法恢復該建議。演示說明提供了該範例的影片和更多背景資訊。

擴大計數窗口聽起來像是應對間隔較遠擾動的自然反應。降低閾值聽起來是另一種選擇。兩者都會改變引起切換的事件，因此兩者也都可能破壞平穩度過良性擾動的目標。修復方案必須根據這兩個目標進行評估，而不能僅憑其是否擷取新添加的事件來評判。

演示的搜尋已經檢查了其有限的選單並返回無結果。擴大該選單將是一項新的實驗。它可以確定另一個候選方案，但成功仍然取決於相同的驗收條件以及模型所代表的內容。選單耗盡是有關這些被搜尋選項的證據，而不是證明每種可能的設備設定都不合適。

我更傾向於保留可見的未解決結果，而不是選擇最不令人失望的失敗並將其作為配置呈現。這種偏好是有代價的：團隊無法從這次運行中獲得新設定。團隊必須決定哪些證據或建模變化可以證明再次搜尋的合理性。這種拒絕透過將缺失的工作明確化而贏得了其存在的價值。

在實際工程過程中，暫緩提議的更改也必須與運行現有設備區分開來。該模擬不發出任何設備指令。其棄權並不證明設施應該斷開連接、其當前設定是安全的或必須更換硬體。

困難的測試可以暴露驗收程序中的漏洞，同時仍然是對物理設備的粗略描述。「繞組絕緣故障」這一名稱並不構成變壓器診斷。這個例子展示了一個模擬事件逃脫了兩條建模切換路徑；它並沒有將該事件驗證為真正的電氣故障。

這就留下了兩個獨立的決定。在目前的測試假設下，工作流程沒有可接受的建議。對於實際設施，工程師還需要評估這些假設是否代表了重要的設備和擾動。因為挑戰阻礙了答案而將其移除，會掩蓋第一個決定。將挑戰視為物理證據，則會跳過第二個決定。

因此，有益的下一步是闡明什麼能夠消除不確定性。如果提議的事件在物理上具有相關性，則在繼續推進建議之前，模型或可用設定可能需要修改。如果不相關，將其排除需要一個與建模範圍相關的工程理由。無論哪種途徑，都應保留失敗的測試及其處理結論，以便理解以後的通過結果。

實測設備行為、電池能量和切換時序仍不屬於本次演示的範圍。真正的設定更改需要經過驗證的設備設定、實測擾動數據、合適的經過驗證的電氣模型以及獨立的工程審查。更流暢的模型輸出無法提供這些缺失的輸入。

以下是我對為什麼在支持性測試失敗時希望撤回建議的簡要解釋。

對於人工智慧輔助的工程工作流程，我希望驗收記錄能夠標明當前候選方案、其滿足的測試、能夠將其排除的測試以及撤回後留下的不確定性。通過的答案僅在其陳述的理由繼續成立時才有用。當這些理由不再成立時，工作流程應保留異議並在任何人將其視為更改設備的許可之前撤回建議。