時間定錨縮放

多時間點資料是指在同一業務流程或實體生命週期中，記錄了多個具有明確時序關係的關鍵時間節點。與時間序列資料不同，多時間點資料並非等間隔觀測值，而是代表業務流程中的重要里程碑。這類資料的核心特徵在於時間點之間存在明確的業務邏輯與依賴關係，每個時間點代表業務流程中的關鍵事件，時間點的存在與否本身就具有商業意涵，而時間點之間的間隔則反映了業務規律和個體差異。典型的應用場景包括企業資料（成立日期 → 首次融資申請 → 核准日期 → 最近追蹤日期）、客戶旅程（註冊日期 → 首次購買 → 會員升級 → 最後活動日期）、以及醫療紀錄（首次就診 → 診斷確定 → 治療開始 → 追蹤檢查）。

多時間點資料的挑戰與解決方案

在合成資料領域，多時間點資料需要特別處理的原因相當複雜。首先是邏輯約束的問題，不同時間點之間有明確的業務邏輯約束，例如申請貸款時間不可能早於企業創立時間，財務追蹤時間必定晚於貸款核准時間。其次，目前市面上開源的合成器在處理多時間點時存在明顯不足，它們將各時間點視為獨立的時間分配來學習，雖然可能從資料中捕捉到潛在關係，但容易產生違反業務邏輯的結果。如果不明確指定這些關係，會出現荒謬情況如申請日期早於成立日期。此外，時間點的存在與否及其間隔都隱含重要的商業邏輯，時間差異反映產業特性和景氣週期等因素，缺失的時間點可能代表特定業務狀態（如申請未核准），時間間隔也可能暗示風險等級或政策變化。

時間定錨（Time Anchoring）是本團隊基於實務經驗提出的最佳實踐方法，用以解決上述挑戰。其核心概念是選擇最重要且絕不會有空值的時間欄位作為「錨點」，然後將其他時間點依照適當的時間精度轉化為相對於錨點的時間差（duration），將這些時間差作為數值欄位供合成器學習，合成完成後再還原為絕對日期或時間。這種方法帶來多重優勢：將絕對時間轉為相對時間差能簡化合成器的學習難度，合成器對整數型態（時間差）的分佈把握度通常高於日期型態，對「數值大於零」等簡單約束的學習效果更好，並能更有效確保多個時間點之間的邏輯連貫性。

判斷是否需要時間定錨

當資料存在多個時間點且符合以下特徵時，應考慮使用時間定錨。若時序邏輯明確，時間點之間有明確的先後順序關係，這是最重要的判斷依據。若時間點與業務流程相關，代表同一實體的不同生命週期階段，時間定錨能有效捕捉這些關係。當存在時間約束，某些時間點必須晚於其他時間點時，時間定錨能確保合成資料滿足這些約束。若時間差有意義，時間點之間的間隔反映重要的業務規律，時間定錨能保留這些業務洞察。

典型需要時間定錨的資料類型包括企業融資（成立→申請→核准→追蹤）、客戶旅程（註冊→首購→升級→流失）、醫療紀錄（就診→診斷→治療→追蹤）、訂單資料（下單→付款→出貨→收貨）等。這些場景中，時間點之間都存在明確的業務邏輯和依賴關係。

理想的錨點應具備以下特徵：絕不缺失，時間點對所有記錄都存在；最早發生，通常是業務流程的起點；業務穩定，不受後續業務變化影響；語意明確，有清晰的業務定義。常見的錨點包括企業資料的成立日期、客戶資料的註冊日期、專案資料的立案日期、以及病歷資料的首次就診日期，這些時間點都代表了各自業務流程的起點。

某些情況下不適合使用時間定錨。單一時間戳記（如單一欄位的交易時間）或等間隔時序資料（如每月銷售額）則不需要時間定錨。時間序列資料（等間隔的連續觀測值）應使用時序預測模型如 TimeGAN 或 DoppelGANger。時間點之間沒有邏輯關聯時，應將各時間點視為獨立欄位處理。若沒有永遠存在的起始時間點，可考慮使用業務規則產生虛擬錨點。當時間關係會根據其他條件變化時，建議分群處理或加入條件約束。

實際應用範例

以下範例展示如何在政策性金融機構的企業融資資料中使用時間定錨：

Preprocessor:
  time_anchoring:
    method: 'default'
    config:
      scaler:
        established_date:
          # 以公司成立日為錨點，計算與其他時間點的天數差異
          method: 'scaler_timeanchor'
          reference:
            - 'first_apply_date'
            - 'first_approval_date'
            - 'latest_apply_date'
            - 'latest_approval_date'
            - 'last_tracking_date'
          unit: 'D'  # D 代表以天為單位

此設定以企業成立日期（established_date）作為錨點，計算其他五個時間點與錨點之間的天數差異。原始資料中，公司 C000001 的 established_date 為 2019-11-03，first_apply_date 為 2022-01-21，經轉換後 first_apply_date 變成 810（天數差），其他時間點也依此轉換。時間點的缺失（如某些企業的首次核准日期為空值）會被保留為 NaN，合成器會學習其分布模式。

根據業務需求可選擇不同時間單位。秒（s）適用於即時系統和交易記錄如金融交易時間戳記，分鐘（m）適用於排程系統和短期流程如客服通話記錄，小時（h）適用於當日業務和輪班制度如醫院病床使用，天（D）適用於跨日週月流程如企業融資和專案管理，週（W）則適用於長期追蹤如定期健檢和季報。選擇原則應基於業務特性和資料精度，建議選擇能充分反映業務精度的最大單位，避免過度精細（如用秒記錄年度事件）或過度粗略（如用週記錄即時交易）。

注意事項與常見問題

為什麼不直接讓合成器學習絕對時間？

直接使用絕對時間（如完整的日期時間戳記）會遇到多重困難。絕對時間的數值範圍很大（如 Unix 時間戳記），時間點之間的關係不明顯，合成器難以捕捉時間約束。這容易產生無效值，可能生成未來的日期或違反時間順序（如申請日期晚於核准日期），難以確保業務邏輯一致性。

時間定錨的優勢在於時間差的數值範圍較小且有界，時間關係更明確（如「核准日期必須晚於申請日期」變成「時間差必須為正」），合成器更容易學習和保持這些約束。

時間差出現負值怎麼辦？

負值時間差通常表示資料有問題，需要檢查可能原因包括資料錄入錯誤、系統時區不一致、業務邏輯變更（如補登歷史資料）或特殊業務情境（如申請日期被追溯修改）。

建議優先在資料前處理階段解決，之後再輸入 PETsARD 前處理，確保輸入資料的業務邏輯正確性。若無法完全避免，可在合成器中使用約束條件確保時間差為正，或在合成後驗證並修正違反約束的記錄。

如果沒有明確的錨點怎麼辦？

當資料中沒有永遠存在的起始時間點時，可考慮創建虛擬錨點，在資料前處理階段取所有時間欄位的最小值作為錨點。

另一種方法是使用最常見的時間點，選擇缺失率最低的時間點作為錨點，接受少數記錄無法計算時間差。

也可以根據業務類型分群，每群使用不同的錨點。若時間點高度獨立，可以不使用時間定錨，直接使用原始時間欄位並配合約束條件。

時間定錨對合成品質有什麼影響？

根據本團隊的實務經驗，時間定錨帶來顯著的正面影響。在減少無效樣本方面，大幅降低違反時間邏輯的合成記錄。在提升相關性方面，更好地保留時間點之間的關聯模式。在穩定性增強方面，減少極端或異常的時間值。

可能的權衡包括需要額外的前處理步驟、錨點選擇需要領域知識、對於複雜時間關係可能需要多次調整。但整體而言，對於包含多時間點的資料，使用時間定錨幾乎總是能帶來品質提升，是強烈建議的最佳實踐。