標準化作業模型 · Standardised Operating Model
建模競賽參賽方案 · Modeling Contest Entry

燃氣電廠決策系統
標準化資料處理與決策作業模型 Gas Power Plant Decision System — Standardised Data & Decision Operating Model

這張圖表達的不是專案開發 phase，而是系統每天 / 每次運行時都會重複執行的標準作業模型。數字只代表資料流順序，不代表開發階段；核心是把原始資料轉成標準特徵、把預測轉成標準分布接口，再把結果送進標準決策接口。 This diagram is not a development phase plan. It is the standard operating model the system repeats every day / every run. The numbers indicate data-flow order, not development stages. The core idea: convert raw data into standard features, turn forecasts into a standard distribution interface, then push the results into a standard decision interface.

標準資料入口 Standard Data Intake 兩條資料支線先做標準化處理，再轉成一致格式的特徵與事件向量。 Two data tributaries are standardised first, then converted into uniformly formatted features and event vectors.
標準預測接口 Standard Forecasting Interface 預測層輸出的應是分布、場景與機率，而不是單一數字。 The forecasting layer should emit distributions, scenarios, and probabilities — not a single number.
標準決策接口 Standard Decision Interface 決策層接收統一格式的預測封包，再做顯式求解與人工覆核。 The decision layer receives forecast packets in a uniform format, then performs explicit optimisation and human review.
標準回寫接口 Standard Feedback Interface 執行結果、偏差、盈虧與異常都要回寫，形成穩定營運閉環。 Execution results, deviations, P&L, and anomalies are all written back, closing a stable operational loop.

標準化處理流程 Standardised Processing Flow

下面描述的是固定 operating model：原始資料如何被標準化、預測如何被封裝成標準輸出、決策如何在統一約束下被求解與覆核。 What follows is a fixed operating model: how raw data is standardised, how forecasts are wrapped into a standard output, and how decisions are solved and reviewed under unified constraints.

1.1 事件資料標準化 · Event Data Standardisation

新聞資料 → 事件特徵 → 向量封裝 News → Event Features → Vector Packaging

政策公告、市場新聞、天氣警報、供應中斷與物流事件先轉成可用的事件特徵，而不是直接拿原文做交易決策。 Policy bulletins, market news, weather alerts, supply outages, and logistics events are first converted into usable event features — raw text is never fed directly into trading decisions.

文字清理 Text Cleaning 去重、去噪、時間標註、來源可信度評分。 Deduplicate, denoise, timestamp, and score source credibility.
事件抽取 Event Extraction 抽出政策衝擊、供應風險、價格上行壓力、波動狀態。 Extract policy shocks, supply risks, upward price pressure, and volatility regime.
向量與分數 Vectors & Scores 輸出文字向量、主題標籤、衝擊分數與事件發生機率。 Emit text vectors, topic tags, shock scores, and event-occurrence probabilities.
1.2 時序資料標準化 · Time-Series Standardisation

歷史 / 即時資料 → 清洗整理 → 特徵封裝 Historical / Real-Time Data → Cleansing → Feature Packaging

市場、天氣、機組、庫存與合約資料必須先標準化處理，否則預測網路會被錯誤時間對齊、缺值與單位不一致污染。 Market, weather, unit, inventory, and contract data must be standardised first — otherwise forecast networks get polluted by misaligned timestamps, missing values, and inconsistent units.

資料清洗 Data Cleansing 缺值補齊、異常值處理、重複紀錄刪除、單位標準化。 Impute missing values, treat outliers, drop duplicates, normalise units.
時間對齊 Temporal Alignment 按小時 / 日頻率對齊，確保每個時點只用當時可見資訊。 Align to hourly / daily frequency, guaranteeing each point uses only information visible at that moment.
特徵建構 Feature Engineering 滯後項、滾動統計、季節性、設備狀態、庫存與合約暴露。 Lags, rolling statistics, seasonality, asset state, inventory, and contract exposure.
↓
標準特徵匯流層 Standard Feature Confluence Layer 數值特徵 + 事件向量 + 當前機組狀態 + 當前庫存 + 即時市場訊號，以統一時間戳與欄位契約封裝 Numeric features + event vectors + current unit state + current inventory + live market signals, wrapped under a unified timestamp and column contract.
↓
2. 標準預測處理 · Standard Forecasting Stage

把標準特徵輸入預測神經網路 / 模型群 Feed Standard Features into the Forecast Network / Model Ensemble

這裡不建議只有一個單一神經網路。較實務的做法是：事件特徵與數值特徵先匯流，再由多個預測模型分別負責不同目標因子，最後統一封裝成可供決策使用的標準分布輸出。 A single monolithic network is not recommended. The pragmatic pattern: merge event and numeric features first, let multiple forecast models each own a target factor, then wrap everything in a standard distribution payload the decision layer can consume.

  • 輸入：事件向量、歷史特徵矩陣、即時市場狀態、設備狀態、庫存與合約狀態。 Inputs: event vectors, historical feature matrix, real-time market state, unit state, inventory, and contract state.
  • 目標：電價、購氣成本、售氣淨回值、淨負荷缺口、機組可用率、供應中斷機率。 Targets: power price, gas procurement cost, gas resale netback, net-load gap, unit availability, and supply-disruption probability.
  • 形式：不只要預測均值，還要輸出波動、分位數、尖峰機率與離散場景。 Form: not just point predictions — also volatility, quantiles, peak probabilities, and discrete scenarios.
↓
2.5 標準分布輸出 · Standard Distribution Output

預測層之後，必須得到標準化的機率分布輸出封包 After Forecasting, Emit a Standardised Probability Distribution Packet

如果只有單一點預測，決策層只能做平均情境下的建議，無法處理尾部風險。這一層的重點不只是「有分布」，而是「每個關鍵因子都用統一格式交付給決策層」。 With only point forecasts, the decision layer can recommend only for the average case — tail risk is invisible. The point of this layer is not merely “having a distribution” but “handing every key factor to the decision layer in a uniform format”.

電力價格分布 Power Price Distribution 輸出期望值、方差、分位數、尖峰機率。 Mean, variance, quantiles, peak probability.
購氣成本分布 Gas Procurement Cost Distribution 輸出到廠成本區間、供應緊張時的右尾風險。 Delivered-cost range and right-tail risk during tight supply.
售氣價值分布 Gas Resale Value Distribution 輸出對外售氣淨回值與轉售機會概率。 Outbound resale netback and probability of resale opportunities.
淨負荷缺口分布 Net-Load Gap Distribution 輸出新能源波動後的調峰需求分布。 Peak-shaving demand after renewable variability.
機組可用率分布 Unit Availability Distribution 輸出降額機率、故障機率與可用容量區間。 Derating probability, failure probability, and usable-capacity range.
供應中斷分布 Supply Disruption Distribution 輸出延遲、減供與中斷場景的發生機率。 Probabilities of delay, curtailment, and outage scenarios.
↓
3. 標準決策接口 · Standard Decision Interface

把標準分布輸出送入顯式決策，再進入互動式決策介面 Feed the Standard Distribution into Explicit Optimisation, Then into the Interactive Decision UI

這裡最好分兩層：先由顯式決策引擎對統一格式的預測封包做可行且可審計的求解，再交給操作員 / 交易員做覆核、比較與必要覆寫。 Use two layers: an explicit decision engine first solves the uniform forecast packet in a feasible and auditable way, then operators / traders review, compare, and override where necessary.

顯式決策引擎 Explicit Decision Engine 用情境式最適化或規則加求解器，輸出啟停、出力、買氣、賣氣、存氣與不發電轉交易建議。 Scenario-based optimisation or rules + solver, emitting unit commitment, dispatch, gas buy/sell/store, and resale-instead-of-generate recommendations.
互動式決策介面 Interactive Decision UI 顯示基準情境、悲觀情境、敏感因子與推薦原因，允許人工加上臨時限制。 Show baseline / pessimistic scenarios, sensitivity drivers, and reasons; allow operators to add temporary constraints.
執行前檢查 Pre-Execution Checks 再次檢查物理可行性、合約衝突、政策違規與風險超限。 Re-verify physical feasibility, contract conflicts, regulatory breaches, and risk-limit overruns.
落地輸出 Operational Output 形成可執行排程與交易建議單，並留下審計記錄。 Produce executable schedules and trade tickets, with an audit trail.
標準約束接口 · Standard Constraint Interface

這些條件應直接進入決策求解，而不是事後補檢 These Constraints Belong Inside the Solver, Not as a Post-Hoc Check

物理約束 Physical Constraints 最小開停時間、升降載速率、最小技術出力、最大容量。 Min up/down time, ramp rate, minimum technical output, maximum capacity.
燃料約束 Fuel Constraints 供氣上限、庫容、最小安全庫存、注入與提取速率。 Supply caps, storage capacity, minimum safety stock, injection and withdrawal rates.
合約與規則 Contract & Regulation 長協履約、罰則、地方市場規則、環保與碳排要求。 Long-term contract performance, penalties, local market rules, environmental and carbon requirements.
風險邊界 Risk Bounds 最大可接受損失、尾部風險上限、極端情境下最低收益。 Max acceptable loss, tail-risk cap, minimum return under extreme scenarios.
↓
4. 標準作業輸出 · Standard Operational Output

最後輸出的不是模型分數，而是標準化可執行動作 The Final Output is Not Model Scores — It is Standardised Executable Actions

機組啟停 Unit Commitment 哪些機組何時開、何時停。 Which units start, which units stop, and when.
發電出力 Generation Dispatch 每個時段的出力與備轉配置。 Output and reserve allocation per time slot.
購氣決策 Gas Procurement 買多少、何時買、走哪一種供應路徑。 How much to buy, when to buy, which supply path to use.
售氣與存氣 Resale & Storage 何時外售、何時保留庫存、何時提氣。 When to resell, when to hold inventory, when to withdraw.
不發電轉交易 Skip Generation, Trade Instead 若售氣價值高於發電價值，直接做氣體變現。 If resale value exceeds generation value, monetise the gas directly.
↓
標準回寫與監控接口 Standard Feedback & Monitoring Interface 實際電價、實際氣價、實際機組狀態、實際盈虧、決策偏差與人工覆寫原因 → 回寫資料層，供監控、再訓練與治理使用 Actual power price, gas price, unit state, P&L, decision deviation, and human-override reasons → written back to the data layer for monitoring, retraining, and governance.

這個工作模型還缺的標準定義 Standards Still Missing from This Operating Model

如果要把這張圖變成真正可運行的 operating model，下面幾個接口與規格最好明確寫死，而不是留在口頭討論。 To turn this diagram into a truly runnable operating model, the following interfaces and specs should be fixed in writing — not left to verbal agreements.

一、標準時間粒度 1. Standard Time Granularity 要先定義主頻率是每小時、每四小時還是每日決策，並規定所有資料如何映射到該時間格點。 Decide whether the master cadence is hourly, four-hourly, or daily, and specify how every data source maps onto that grid.
二、標準欄位契約 2. Standard Column Contract 每個資料表是否有固定主鍵、時間戳、單位、地點、版本號與資料來源標記，這是標準化作業模型的核心。 Whether every table has a fixed primary key, timestamp, unit, location, version, and source tag — this is the heart of a standardised operating model.
三、哪些因子一定要有分布 3. Which Factors Must Be Distributional 至少建議包括電價、購氣成本、售氣價值、淨負荷缺口、機組可用率與供應中斷風險。 At minimum: power price, procurement cost, resale value, net-load gap, unit availability, and supply-disruption risk.
四、分布輸出格式 4. Distribution Output Format 要定義是用均值加方差、分位數、場景樹，還是三者並存，否則決策層接口不穩定。 Define whether outputs use mean+variance, quantiles, scenario trees, or all three — otherwise the decision-layer interface stays unstable.
五、決策層是規則還是求解器 5. Rules Engine or Solver? 如果只是互動式介面而沒有顯式求解器，系統很難處理多重約束與風險權衡。 An interactive UI without an explicit solver cannot handle multiple constraints and risk trade-offs cleanly.
六、硬約束、軟約束與人工權限 6. Hard / Soft Constraints & Override Rights 要明確定義哪些約束不可被人工跳過，哪些可以透過覆核後臨時放寬，以及所有人工覆寫如何被回寫留痕。 Define which constraints can never be bypassed, which can be relaxed after review, and how every human override is logged.

討論焦點：現在最值得先定義的是資料欄位契約、分布輸出契約，以及決策層到底是不是明確的情境式最適化引擎。 Discussion priority: define the column contract, the distribution-output contract, and whether the decision layer is truly an explicit scenario-based optimisation engine.