---
title: 多時間點資料 - 時間定錨
type: docs
weight: 42
prev: docs/best-practices/multi-table
next: docs/best-practices/high-cardinality
---

## 個案背景

某政策性金融機構擁有豐富的企業融資相關數據，包含企業基本資訊、融資申請、財務變化等多面向歷史紀錄。機構希望透過合成資料技術來推動與金融科技業者的創新合作，讓第三方能在確保資料隱私的前提下，利用這些資料開發風險預測模型，協助機構提升風險管理效能。

### 資料特性與挑戰

- **複雜的表格結構**：原始資料分散在多個業務系統的資料表中，涉及企業基本資料、申請紀錄、財務追蹤等不同面向
  - 處理方法見 [多表格資料 - 反正規化](docs/best-practices/multi-table)
- **時序性資料**：包含多個關鍵時間點（如申請日期、核准日期、追蹤時間等），且這些時間點之間具有邏輯順序關係

## 多時間點資料的合成挑戰

多時間點資料是指在同一業務流程或實體生命週期中，記錄了多個具有明確時序關係的關鍵時間節點。與時間序列資料不同，多時間點資料並非等間隔觀測值，而是代表業務流程中的重要里程碑，如企業從成立、融資申請到核准等各時間點。這類資料的核心特徵是時間點之間存在明確的業務邏輯與依賴關係。

在合成資料領域，多時間點資料需要特別處理，原因在於不同時間點之間有明確的業務邏輯約束。例如，企業的申請貸款時間不可能早於其創立時間，財務追蹤時間必定晚於貸款核准時間。然而，目前市面上開源可用的合成器在處理這類資料時存在明顯不足。當放入多個時間點時，這些合成器通常將各時間點視為獨立的時間分配來學習，雖然仍有機會從資料中捕捉到潛在的業務邏輯關係，但若不明確指定這些關係，很容易產生違反業務邏輯的合成資料，如出現申請日期早於成立日期等荒謬情況。

### 模擬資料示範

本模擬資料即是由 [多表格資料 - 反正規化](docs/best-practices/multi-table) 整併而來的寬表，此處僅擷取日期相關欄位：

| company_id | established_date | first_apply_apply_date | first_apply_approval_date | latest_apply_apply_date | latest_apply_approval_date | latest_track_last_tracking_date |
|------------|------------------|------------------------|---------------------------|--------------------------|----------------------------|--------------------------------|
| C000001    | 2019-11-03       | 2022-01-21             | 2022-03-19                | 2025-01-05               | 2025-01-30                 | 2027-07-19                     |
| C000002    | 2017-01-02       | 2020-12-12             |                          | 2022-12-02               | 2023-01-05                 | 2024-09-26                     |
| C000003    | 2012-05-29       | 2016-05-08             | 2016-06-29                | 2018-04-28               |                           | 2018-12-16                     |
| C000004    | 2010-09-24       |                        |                          |                          |                           |                                |
| C000005    | 2010-07-24       | 2014-07-03             | 2014-08-11                | 2014-01-04               |                           | 2020-06-26                     |

表格中顯示了六個日期欄位：

- established_date（成立日期）
- first_apply_apply_date（首次申請日期）
- first_apply_approval_date（首次審核通過日期）
- latest_apply_apply_date（最近申請日期）
- latest_apply_approval_date（最近審核通過日期）
- latest_track_tracking_date_last_tracking_date（最近追蹤日期）

日期欄位的存在與否及其時間點本身即暗示了重要商業邏輯，例如從以上幾筆觀察：

- 成立日期與首次申請日期的時間差，如 C000001 間隔了 810 天，這個時間差除了個體差異，也會受到產業、景氣週期影響
- 有申請日期卻沒有審核通過日期，如 C000002 的首次申請，代表了本次申請未獲批准（也可能是主動放棄），這也對應了 withdrawn 狀態
- 申請日期與追蹤日期的時間差，如 C000003 間隔了 232 天，體現了申請後的監管機制。在多表格資料中我們並沒有深入追蹤歷史紀錄，但訪談得知「申請通過後會執行定期或不定期的財務狀況追蹤」，其意味著不定期追蹤可能代表著高風險個案、或景氣政策波動等商業意涵，如果希望深入追蹤不定期事件，則可額外建立特徵標記。本範例先予以省略
- 完全缺乏申請與追蹤紀錄，如 C000004。經訪談得知部分承作案係通過政策性補助，而非主動申請流程獲得資金。這類案例不僅建議在流程前事先討論是否納入分析，也佐證了成立日期是唯一穩定的企業基礎時間指標

## 時間差異的模擬合成

基於實務經驗，CAPE 團隊建議的最佳實踐是採用我們稱之為「時間定錨」(Time Anchoring) 的方法：將最重要且絕不會有空值的時間欄位設為錨點，其他時間點則全部依照適當的時間精度，轉化為相對於錨點的時間差(duration)，合成完成後再加以還原為絕對日期／時間。

以模擬資料為例，前處理會將資料轉變為下表的內容，供合成器學習：

| company_id | established_date | first_apply_apply_date | first_apply_approval_date | latest_apply_apply_date | latest_apply_approval_date | latest_track_last_tracking_date |
|------------|------------------|------------------------|---------------------------|--------------------------|----------------------------|--------------------------------|
| C000001    | 2019-11-03       | 810                    | 867                       | 1889                     | 1914                       | 2815                           |
| C000002    | 2017-01-02       | 1440                   |                           | 2160                     | 2194                       | 2824                           |
| C000003    | 2012-05-29       | 1440                   | 1492                      | 2160                     |                            | 2392                           |
| C000004    | 2010-09-24       |                        |                           |                          |                            |                                |
| C000005    | 2010-07-24       | 1440                   | 1479                      | 1260                     |                            | 3624                           |

在 PETsARD 中我們提供 `TimeAnchor` 前處理模組來達成。請點擊下方按鈕在 Colab 中執行範例：

[![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/nics-tw/petsard/blob/main/demo/best-practices/multi-timestamp.ipynb)

```yaml
Preprocessor:
  demo:
    method: 'default'
    config:
      scaler:
        'established_date':
          # 以公司成立日為錨點，計算與申請、核准、追蹤等重要時間點的天數差異
          # Using company establishment date as anchor to calculate day differences
          #  with application, approval and tracking dates
          method: 'scaler_timeanchor'
          reference:
            - 'apply_date'
            - 'approval_date'
            - 'tracking_date_last_tracking_date'
          unit: 'D' # D 代表以天為單位 D represents measurement in days
```

透過將公司成立日設為時間錨點，並參考後續的申請、核准和追蹤時間，我們能讓合成資料更好地模擬這些時間差異的分布特性，進而產生更符合實際業務邏輯的時序模式。

在進行此類時間定錨處理時，需特別注意：

1. 選擇適當的時間基準點：企業成立日期通常是最穩定且普遍存在的時間點
2. 處理缺失值與異常值：部分時間差可能呈現負值或極端值，需評估其合理性
3. 保持業務邏輯一致性：確保事件發生的先後順序（如申請必須早於審核）
4. 時間單位選擇：依據業務需求選擇合適的時間單位（天/秒）

這種方法具有多重優勢：

1. 減少合成器的學習運算量：將絕對時間轉為相對時間差能簡化學習難度
2. 提升類型相容性：相較於日期型態，合成器對於整數型態(時間差)的分佈把握度通常較高
3. 強化邏輯約束學習：合成器對於數值是否大於零等簡單約束的學習效果更好
4. 增強時間關係一致性：能更有效地確保多個時間點之間的邏輯連貫性

## 小結

時間定錨是處理多時間點資料合成的關鍵策略。透過將公司成立日設為時間錨點，並計算後續申請、核准和追蹤時間的相對差值，我們能讓合成資料更好地模擬這些時間差異的分布特性。雖然這種轉換主要是幫助合成器學習，但建議後續仍應搭配具體的業務約束條件進行檢查，以確保合成資料在時序邏輯上的完整性與合理性。