高頻資料回測：Tick 與 1 分鐘 K 棒有哪些不同

目錄

1. 高頻資料回測會改變什麼？
2. 高頻回測需要多少資料？
3. 為什麼時間戳記的準確度在日內資料上更重要？
4. 高頻回測的滑價該怎麼設定？
5. ES 上 Tick 與 1 分鐘的回測結果差多少？
6. 硬體如何影響高頻回測？
7. 常見問題
8. 參考文獻

高頻資料回測會改變什麼？

高頻資料回測會同時改變三件事：交易筆數成倍增加，每筆交易捕捉的價差縮小，於是手續費、滑價與時間戳記錯誤成為左右結果的主因。日 K 棒上由規則決定成敗；1 分鐘或 Tick 資料上，決定成敗的是成本與資料假設。

高頻資料是指一個交易日內記錄多次的價格資料。Tick 資料記錄每一筆成交的價格、數量與時間。1 分鐘 K 棒則彙整一分鐘的成交：開盤價、最高價、最低價與收盤價，再加上成交量。兩者都比多數交易人入門時學的日 K 棒細得多。本文談的是用細部資料測試散戶速度的規則，不談採用主機託管（co-location）的交易公司；兩者的對照見高頻交易與散戶演算法交易。

把每筆交易想成一趟走收費公路的行程。過路費是手續費加滑價，不論行程長短都一樣。日 K 棒的一筆交易走得遠，過路費只占行程的一小部分。1 分鐘的一筆交易走得近，卻付同樣的過路費，過路費可能吃掉大半獲利。Tick 層級的交易走得更短。規則沒有任何改變，改變的是成本與所捕捉價差的比例。

這就是為什麼一條在 1 分鐘 K 棒上、不計成本時看似極佳的規則，加上成本後常顯得普通，而同一條規則在日 K 棒上幾乎不變。本文後續只圍繞一個主張：日內資料上，成本與資料假設對結果的影響大於進場規則，所以先檢查它們，再評斷規則。

高頻回測需要多少資料？

所需資料量取決於已完成的交易筆數，而非日曆年數；1 分鐘策略累積數百筆樣本外交易，只需數月而非數年。樣本外交易是指在規則從未見過的資料上產生的交易，這些資料沒有參與挑選設定的過程。許多系統化交易人把數百筆視為每筆數字開始有意義的下限，少於約 30 筆只能當作線索。一條在 1 分鐘 K 棒上每天交易兩次的規則，不到一年就能累積數百筆。每月交易一次的日 K 棒波段規則，要累積同樣的筆數則需要許多年。

交易筆數累積得更快，代價是檔案大小。近 24 小時的期貨交易時段，每個交易日約有一千四百根一分鐘 K 棒（交易 23 小時乘以 60 分鐘），日 K 棒則只有一根。以約 250 個交易日計，一年約有三十五萬根一分鐘 K 棒，是日 K 棒檔案的一千倍以上。Tick 檔案更大：每筆成交就是一列，流動性高的指數期貨，一年的資料就有好幾百萬列，實際列數取決於成交了多少筆。載入、儲存與檢查這樣的檔案，是日 K 棒交易人從未碰過的工作。

項目	日 K 棒	1 分鐘 K 棒	Tick 資料
每個交易日的 K 棒數（近 24 小時交易時段）	1	約一千四百	數千至數萬，取決於成交量
每年 K 棒數	約 250	數十萬	數百萬
累積數百筆樣本外交易所需時間	數年；每月交易一次的規則常需十年	每天交易的規則約需數月	數週至數月
工作量增加的檢查	假日、轉倉	缺口、交易時段邊界、K 棒時間戳記	缺口、錯誤成交價、交易時段邊界、成交先後順序

三項資料品質檢查，隨列數增加而加重。缺口：缺了一小時的 1 分鐘 K 棒，在縮小到數年的圖上看不出來，規則卻會把它讀成突然跳動。錯誤成交價：單筆遠離市場的錯誤成交，會在 Tick 資料上觸發停損，也會在 K 棒資料上留下假的高點或低點。交易時段邊界：每日的維護休市與合約月份之間的轉倉，都落在日內序列之中。轉倉的說明見期貨回測的合約規格與轉倉；在日內資料上，轉倉的價差大小不變，但落在相隔一分鐘的兩根 K 棒之間，看起來像一次價格變動，除非調整價格序列，否則規則會去交易它。

為什麼時間戳記的準確度在日內資料上更重要？

時間戳記的準確度在日內資料上更重要，因為同一個誤差，會讓成交位置偏掉數十根 K 棒，而不是一天；以開盤時間標記的 K 棒，還可能讓規則讀到尚未出現的價格。時間戳記是資料檔中寫在每根 K 棒或每筆 Tick 上的時間。日 K 棒幾乎沒什麼可錯：日期就是日期。1 分鐘 K 棒則有兩種慣例，而檔案少有註明用的是哪一種。

開盤標記的 K 棒帶有 K 棒開始的時間：標為 09:30 的 K 棒涵蓋 09:30:00 到 09:30:59。收盤標記的 K 棒帶有 K 棒結束的時間：同一分鐘標為 09:31。如果回測軟體假設是收盤標記，檔案卻是開盤標記，每根 K 棒都會被提早一分鐘讀取。規則決定「在 09:30 這根 K 棒收盤時」進場，拿到的卻是 09:31 才收盤的那根，也就是做決定的當下尚未成交的價格。這是前視偏差；在日內資料回測中，這是規則得到一個實際上無法交易的結果最常見的原因。第二種錯誤是時區錯位。以芝加哥時間存的檔案被當成台北時間載入，或夏令時間的調整只套用到檔案的一半，會讓每個交易時段的開盤與收盤整整錯開數個小時，於是「日盤開盤」規則在每個受影響的日子都在錯的 K 棒上觸發。

四項檢查，在執行任何規則之前就能釐清這個問題：

1. 打開檔案的第一天。把第一根 K 棒的標記，與交易所公布的該日交易時段開盤時間對照。標記是開盤時間，代表檔案為開盤標記；晚一根 K 棒，則為收盤標記。再把回測軟體設成相符。
2. 檢查春季與秋季各一個夏令時間日期。交易時段開盤的標記，只應隨交易所時間表移動，絕不會多出一小時。
3. 把每個訊號再延後一根 K 棒，重新執行。如果結果崩塌，代表原本的回測讀到的是過早的價格。
4. 每個測試年度，都讓交易時段範本符合當年的交易所時間。交易所多年來調整過時間，整個檔案只用一套範本，頭尾兩端都可能不對。

高頻回測的滑價該怎麼設定？

以跳動點為單位，每邊設定滑價：有自己的成交紀錄就用實際數字；沒有的話，以市價單或停損單交易的流動性高的期貨，至少每邊設定一個跳動點；再用兩倍的數字重跑一次。滑價是測試假設的價格與真實委託會拿到的成交之間的距離。每邊是指進場收一次、出場再收一次，所以每邊一個跳動點，一買一賣就是兩個跳動點。在日內 K 棒上，這一買一賣占平均每筆損益的比例相當高，第二次回測可以看出規則在成交稍差時能否撐住。

1. 有成交紀錄就從紀錄開始。比較實單的成交價與訊號 K 棒顯示的價格，取平均差距，以跳動點計。
2. 沒有紀錄，流動性高的指數期貨用每邊一個跳動點，流動性低的合約、交易時段開盤後的最初幾分鐘，以及預定的新聞時間，則要更多。
3. 把一買一賣的手續費與交易所費用加進去，單位與結果一致。回測裡的交易成本列出了這個數字該包含什麼。
4. 把滑價加倍，再跑一次。在看報表其他任何內容之前，先寫下兩次回測的平均每筆淨損益。
5. 用事先寫好的規則決定，例如：平均每筆毛損益必須是一買一賣成本的數倍，且滑價加倍的那次仍須高於零。

日 K 棒這一端的對照，是高頻測試所缺少的；AlphaPrime（Valynox）的一次真實回測，可以看到實際樣貌。下面這次回測測試 NQ 日 K 棒，期間 2019-01-02 至 2025-06-30，多空皆做，一口，每筆交易手續費 $20、滑價 $10。它的規則只是替代品，不是本文主題：只用隨機指標（KD）規則作為唯一的進場與出場，沒有停損、停利或濾網。搜尋試了 1,024 個候選策略，挑出這個保留，依據是報酬相對於回撤；事後挑出保留的候選策略，會讓它的數字看起來更好。

這次回測只看一件事：$30 的一買一賣成本，對照 $796.45 的平均每筆損益，遠低於所捕捉價差的二十分之一。NQ 一個跳動點是 0.25 個指數點，價值 $5.00（CME Group 合約規格），所以設定中的 $10 滑價就是每邊一個跳動點。同樣的 $30，若放在平均每筆損益只有數十美元的 1 分鐘規則上，會成為結果中最大的一項。這次回測也顯示了交易筆數規則的另一面：六年半只有 62 筆交易，遠低於信任每筆數字所需的數百筆，所以 $796.45 無法說明這條規則會賺多少，也不是讀者可以期待的數字。交易所會不定時調整跳動點大小與費用，請到交易所的合約頁面確認現行數值；免費的期貨合約與損益計算機可查主要合約的每跳動點價值與每點價值。在 AlphaPrime 中，你在回測設定中輸入的滑價與手續費，會在搜尋過程中對每個候選策略計入，並採下一根 K 棒成交，所以滑價加倍的那次回測只是改一個數字，不是另開一個專案。

ES 上 Tick 與 1 分鐘的回測結果差多少？

同一條規則分別用 ES 的 Tick 資料與 1 分鐘 K 棒回測，交易筆數與成交價不同，因為 1 分鐘 K 棒隱藏了棒內價格的先後順序，而且規則越快，差距越大。ES 是 E-mini S&P 500 期貨。它的 1 分鐘 K 棒記錄了最高價與最低價，卻不記錄哪個先出現。停損與停利都落在同一根 K 棒的區間內時，K 棒資料只能假設順序；Tick 資料則直接顯示。

多數回測軟體以固定假設解決這個平手：停損先（保守）、停利先（樂觀），或是離這根 K 棒開盤價較近的價位先。每一種假設，都會讓許多交易由賺轉賠或由賠轉賺。Tick 資料免去假設，因為成交序列顯示哪個價位先成交。成交價也不同。在 K 棒上，停損單以觸發價或下一根 K 棒的開盤價成交；在 Tick 上，則以觸及或穿越觸發價之後的第一筆成交價成交，常常差一個跳動點以上。因此在 Tick 資料上有效的規則，經過的是真實事件順序的測試；同一條規則在 K 棒上，經過的是對事件順序的假設的測試。Tick 圖與時間 K 棒的差異可以看到 K 棒壓縮掉了什麼。

差距隨規則變快而擴大，原因單純。停損與停利相距 40 個跳動點的規則，少有兩者同時落在一根 1 分鐘 K 棒內的情形，所以少有交易由假設決定。停損 4、停利 6 個跳動點的規則，幾乎每根 K 棒內都同時有兩者，所以幾乎每筆交易都由假設決定。一條實用的經驗法則：如果市場一般 1 分鐘的區間大於停損與停利之間的距離，就用 Tick 資料測試，或採保守假設，並把 K 棒的結果當成下限。不論選哪一種，樣本內與樣本外都要保持相同，讓切分的兩邊以同一種成交假設評分。

硬體如何影響高頻回測？

Classic 版以 CPU 運算，Reserve 版可用 NVIDIA GPU 加速策略生成與回測。兩版流程相同：檢查時間戳記與交易時段，設定手續費、滑價與下一根 K 棒成交，對各候選策略執行策略搜尋，讓留下的策略通過策略檢驗，再到策略資料庫與報表檢視結果。檔案有數十萬根 K 棒時，其中一步等得比較久；其餘四步所需的人工時間不變。

搜尋這一步的等待時間，隨每個候選策略的 K 棒數乘以候選策略數而增加。唯一的實測參考點是公布的基準測試：AlphaPrime 在單張 RTX 3090 上約 18 小時、約 12 億次策略評估（實測 18 小時 23 分鐘、1,268,200,000 次），2026-10-05 量測，資料為 TY 37 分鐘 K 棒，2015-01-01 至 2026-09-25，每個候選策略 114,371 根 K 棒，每次評估皆計入手續費與滑價；條件列於基準測試頁面。實際速度取決於顯示卡、資料長度與研究設定；1 分鐘或 Tick 檔案每個候選策略的 K 棒多得多，每個候選策略花的時間會比該次回測更長。Classic 與 Reserve 兩版的速度比較，請見 GPU 與 CPU 回測一文。Classic 版以 CPU 運算，Reserve 版可用 NVIDIA GPU 加速策略生成與回測；不論哪一版，改變的是第三步要等多久，不是測試檢查什麼。

手上已有規則時，下一步可以這樣做：打開它的 1 分鐘檔案第一天，釐清 K 棒是開盤標記還是收盤標記；再把規則跑兩次，每邊滑價分別為一個與兩個跳動點；在看報表中其他任何數字之前，先寫下兩次回測的平均每筆淨損益。

常見問題

高頻回測需要多少資料？

看已完成的交易筆數，不看年數。在相信每筆數字之前，至少要有數百筆樣本外交易，少於約 30 筆只算線索。每天交易的 1 分鐘規則，數月就能達到這個筆數；但近 24 小時期貨交易時段的一年 1 分鐘 K 棒，就有數十萬根，儲存、載入與資料品質檢查都成為工作的一部分。

Tick 與 1 分鐘的回測結果差多少？

規則的停損與停利可能同時落在一根 K 棒內時，差距最大。1 分鐘 K 棒不記錄最高價或最低價哪個先出現，回測軟體只能假設順序，Tick 資料則直接顯示。規則越快，由這個假設決定的交易越多，兩邊的交易筆數與平均每筆損益差得越遠。停損較寬的慢速規則，兩種結果通常接近。

高頻回測的滑價該怎麼設定？

以跳動點為單位，每邊設定。有自己的成交紀錄就用紀錄；否則流動性高的期貨用市價單或停損單，從每邊一個跳動點起算，流動性低的合約與開盤後最初幾分鐘則更多。然後把數字加倍，再測一次。如果在兩個跳動點時平均每筆淨損益轉負，代表這條規則依賴低成本的成交。

1 分鐘資料足以當作高頻交易（HFT）的回測資料嗎？

對持倉許多分鐘或數小時的散戶速度規則，檢查過時間戳記與交易時段邊界後，1 分鐘 K 棒通常已經足夠。對在數個跳動點內進出的規則，1 分鐘 K 棒隱藏了每根 K 棒內的價格順序，以及停損單的真實成交價。這類規則需要 Tick 資料，或採保守假設並把結果當成下限。

硬體如何影響高頻回測？

Classic 版以 CPU 運算，Reserve 版可用 NVIDIA GPU 加速策略生成與回測。K 棒數與候選策略數都大時，兩版的差別在搜尋這一步的等待時間。時間戳記、滑價與結果的檢查，所需的人工時間相同。

參考文獻

• Bailey, D. H., Borwein, J., López de Prado, M., & Zhu, Q. J. (2014). Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance. Notices of the American Mathematical Society, 61(5), 458–471.
• Harvey, C. R., & Liu, Y. (2015). Backtesting. The Journal of Portfolio Management, 42(1), 13–28.
• CME Group. E-mini Nasdaq-100 Futures Contract Specs. https://www.cmegroup.com/markets/equities/nasdaq/e-mini-nasdaq-100.contractSpecs.html