我們如何幫量化基金挑選行情數據源：延遲、完整性與長期穩定性實戰談

場景：一條延遲曲線，毀掉一整週的回測信心

先說一個印象深刻的案例。某家管理規模不小的私募，用某個海外行情 API 跑了一套日內統計套利策略，回測年化報酬率非常漂亮。但切到模擬盤後，績效直接腰斬。我們被找去當「數據偵探」，比對之後才發現問題不在策略，而在行情時間軸。那個數據源在開盤前 5 分鐘，實際延遲（本地接收時間減去交易所時間戳）會從平常的 40 毫秒飆升到 1.8 秒，而且還是規律性發生。這段時間內產生的信號全部基於過期價格，當然不會賺錢。

這就是為什麼我們把「需求」定義為：不是要一個能回傳價格的端點，而是一條可被審計、可被監控、可被信任的數據鏈路。

數據痛點：看起來很快，不代表真的快

市面上的 API 大多強調「接口響應時間 20ms」「支持數百家交易所」，但這些指標和真實交易環境的關聯度其實不高。我們在評測過程中反覆踩到的第一個大坑，就是把網路延遲當成資訊延遲。伺服器回應快，可能只是它瞬間給了你一個緩衝區裡積壓的舊報價，真正的延遲應該這樣算：

實際延遲 = 本地接收時刻 − 行情交易所時間戳

我們遇過最誇張的情況是，API 回應時間穩定在 30ms，但這個差值卻長達 900ms，而且一到美股開盤就出現大幅抖動。這種延遲漂移對低延遲策略是致命的。

第二個同樣麻煩的痛點是無聲的數據丟失。tick 不會報錯，只會默默地沒出現。你如果只跑 5 分鐘測試，根本不會發現某個數據源每天固定在大約 02:30 UTC 附近漏掉幾百筆成交。我們後來養成一個習慣：每次測試新數據源，一定會同時拉一條我們已經驗證過穩定性極高的參考通道做平行比對。在一次評測中，我們就是透過 AllTick API 的即時行情串流作為時間基準，才成功抓出競爭對手的數據在歐美重疊交易時段有將近 2% 的 tick 無聲消失。

評估框架：四個我們必看的品質維度

為了讓選型過程不再依賴主觀「體感」，我們在團隊內部定了一套四維度的評分表，現在每一次接觸新數據源，第一件事就是把這張表攤開：

評估面向我們聚焦的檢查重點時間戳是否直接來自交易所撮合引擎？精度是毫秒還是微秒？有無被伺服器重新蓋戳？數據連續性有無未說明的缺失、重複或異常價格跳動？斷線重連後是否能補齊缺口？更新速度實際端到端延遲的分佈情形，特別關注 P95、P99 以及高成交量區間的衰減幅度欄位穩定性API 結構是否長期一致？過去有無無預警變更欄位名稱或型態？

這四個問題只要有一個回答得含糊，我們就會提高警覺。畢竟對量化基金來說，數據源合約承諾的不是功能，是確定性。

實際測試：不是跑五分鐘，是跑一整週

我們絕對不會用短短幾分鐘的接收狀況來下判斷。標準的測試流程是：使用 WebSocket 長連線訂閱即時 tick，連續記錄至少 5 個交易日，而且一定包含重大經濟數據公佈（非農、利率決議）、開盤前後 30 分鐘以及收盤前 15 分鐘。下面這段程式碼就是我們每次啟動評測時會跑的基礎延遲監聽腳本，它只做一件事——忠實記錄每一筆行情從交易所產生到抵達本地所經過的時間。

# 匯入所需模組
import websocket
import json
import time

def on_message(ws, message):
    data = json.loads(message)

    # 擷取逐筆成交的關鍵欄位
    symbol = data.get("symbol")
    price = data.get("price")
    volume = data.get("volume")
    timestamp = data.get("timestamp")

    # 取得本地接收時間（毫秒）
    receive_time = int(time.time() * 1000)

    # 輸出股票代碼、成交價、成交量與實際延遲
    print(
        symbol,
        price,
        volume,
        "延遲:",
        receive_time - timestamp
    )

def on_open(ws):
    # 構建即時成交訂閱請求
    request = {
        "action": "subscribe",
        "symbol": "AAPL",
        "type": "trade"
    }

    ws.send(json.dumps(request))

ws = websocket.WebSocketApp(
    "wss://api.alltick.co/stock/websocket",
    on_open=on_open,
    on_message=on_message
)

# 讓 WebSocket 持續保持連線，接收即時行情
ws.run_forever()

收集到的資料會即時寫入時序資料庫，接著我們會畫出每小時的延遲百分位圖，並統計每分鐘應收與實收 tick 數量的比值。如果某個數據源總是在 21:30 後的 5 分鐘內出現 P99 延遲暴衝，或是成交量計數與交易所公佈數字有系統性偏差，那它就會被我們標記為「不適合自動交易環境」。

行業應用：把測試邏輯直接變成生產環境的品質閘門

對我們來說，數據源的評估不是一次性的專案，而是一個持續運轉的機制。基金客戶的生產環境中，我們會把同樣的監控邏輯部署為一道「品質閘門」——同時接收主數據源和至少一路參考數據源，即時比對兩者的延遲差與 tick 數量差。一旦偏差超過設定的安全門檻，系統就會自動發出告警，必要時切換到備援線路。這種設計聽起來成本不低，但跟一筆因為數據延遲而錯價的委託比起來，這些監控資源的投入性價比其實極高。

容易在開發後期才炸開的隱藏問題

除了延遲與丟失，我們在長期維運中還反覆碰到以下幾種「安靜的炸彈」：

• 時區與夏令時間陷阱：不同市場混用當地時間、UTC、經紀商時間，又缺乏明確的時區標記，合併多市場行情時極易產生時間軸錯位。

• 自建 K 線與廠商 K 線不一致：用 tick 自行聚合的分鐘線，OHLC 經常和廠商提供的分鐘線對不上，主因是時間窗口邊界定義不同。

• 複權因子不同步：歷史價格已做除權息調整，即時行情卻是未調整的原始價格，導致回測信號與實盤信號在事件發生前後出現幽靈偏離。

• 停牌期間的殭屍價格：部分數據源會在股票暫停交易時持續推送最後一筆成交價，讓流動性過濾器誤判該標的仍在可交易狀態。

這些細節在純展示系統裡幾乎無感，但放在量化基金的策略運算裡，每一項都會直接侵蝕 Alpha。我們的解方很明確：在數據源接入層之上，一定再加一層校驗服務，把所有不確定性攔在策略引擎之外。

我們的最終判斷：穩定，才是最划算的選擇

走過這麼多專案之後，我們現在評估行情數據源的視角已經完全不一樣了。與其關注它宣稱支援多少交易所、有多少欄位，不如回頭問一個更根本的問題：這條數據流在市場最暴力的時刻，是否依然能安靜、準確地把你需要的每一筆 tick 送到手上？ 對我們來說，這就是性價比的終極定義。好的數據源不是功能清單最長的那一個，而是能在凌晨、開盤、重大新聞發布等每一個極端時刻，依然穩定輸出真實行情的那一個。把測試時間拉長，讓數據自己說話，往往比任何規格書都更有參考價值。