訓練與多區段 API 詳細¶

這一頁補兩條主流程：

參數訓練區間
多區段回測 multi_params

它們都屬於研究工具層，但與一般回測 / 最佳化的定位不同。

一、參數訓練區間 API¶

訓練在這個專案裡，不是機器學習訓練，而是：

把某段時間圈出來
配上一組參數
保存顏色與備註
給前端圖表與人工研究使用

1. 圖表資料¶

`GET /api/training/chart_data`¶

Query:

ticker
start_time
end_time
timeframe_minutes

用途：

取前端畫圖需要的 OHLCV
若 timeframe_minutes > 1，後端會先做 resample

回傳格式的核心是：

data_feed.data[]
每筆包含 datetime/open/high/low/close/volume

2. 建立訓練區間¶

`POST /api/training/param_range`¶

Body 範例：

{
  "ticker": "TXFR1",
  "timeframe_minutes": 5,
  "start_time": "2025-01-01 09:00:00",
  "end_time": "2025-01-01 12:00:00",
  "params": {
    "strategy_name": "BollingerATRStrategyV4",
    "init_window": 25,
    "std": 2.0
  },
  "color": "rgba(255, 99, 132, 0.15)",
  "notes": "測試區間"
}

注意：

strategy_name 不在外層欄位，而是常被放進 params 裡當作參數快照的一部分
這跟一般回測系統中明確的 strategy_name 欄位是不同設計

3. 查詢區間¶

`GET /api/training/param_ranges`¶

用途：

依商品、時間週期、時間範圍查詢
支援 page / page_size

`GET /api/training/param_range/{range_id}`¶

用途：

取單一區間詳細資料

4. 更新與刪除¶

`PUT /api/training/param_range/{range_id}`¶

可更新：

params
color
notes
start_time
end_time

`DELETE /api/training/param_range/{range_id}`¶

用途：

刪除單一區間

5. 批量查詢¶

`POST /api/training/param_ranges/batch`¶

用途：

前端頁面一次取某時間範圍內所有區間

這支 API 很像為圖表頁載入而設計，不是通用查詢 API。

二、多區段回測 `multi_params`¶

這是專案裡很重要、但也最需要小心的一塊。

它是什麼¶

你可以把它理解成：

先在 DB 中存很多段時間區間
每段區間都配一組參數
最後一次把所有區段都跑完

1. Segment 建立¶

`POST /multi_params/segments`¶

Body：

{
  "ticker": "TXFR1",
  "start_date": "2025-01-01",
  "end_date": "2025-03-31",
  "params": {
    "std": 2.0,
    "min_window": 20
  }
}

關鍵設計¶

這個模型目前只有：

ticker
start_date
end_date
params

沒有 strategy_name。

這是它和新主流程最大的落差。

2. Segment 查詢與修改¶

`GET /multi_params/segments`¶

取所有區段。

`GET /multi_params/segments/{segment_id}`¶

取單段。

`PUT /multi_params/segments/{segment_id}`¶

更新：

ticker
start_date
end_date
params

`DELETE /multi_params/segments/{segment_id}`¶

刪除後會清掉多區段回測 cache。

3. 執行多區段回測¶

`GET /multi_params/result`¶

用途：

取所有 segment
計算 hash
若 cache 命中直接回傳
否則呼叫 run_multi_period_backtest(segments, return_json=True)

三、`multi_period_backtest.py` 的真實行為¶

這個檔案是多區段回測的實際執行器。

流程¶

先看 segments 中有沒有 TXFR1 / TXFR2
若有，先一次性預載整段 TXF 資料
每個 segment 逐一執行
如果是 TXF，優先用 backtest_txf_with_data(...)
否則走 simple_backtest(...)

四、為什麼它是特殊路徑¶

因為它目前不是完全沿用 app.py 的新主流程。

它的問題點¶

1. 沒有 `strategy_name`¶

不能明確指定：

這個 segment 要跑哪個策略

2. 走舊回測腳本¶

它會進到：

simple_backtest.py
backtest_txf_with_data(...)

而這些舊腳本中還有：

硬編碼策略類別
舊參數名

例如：

backtest_txf_with_data() 直接使用 BollingerATRStrategyV2

這代表：

你在一般回測切到 V4
不代表 multi_params 也會跟著切到 V4

五、如果前端要接這條線，該怎麼理解¶

請把 multi_params 當成：

舊系統保留下來的多區段批次回測工具

而不是：

完全與新策略系統一致的最新功能

前端要避免的誤解¶

誤解 A¶

「我前端選了 strategy_name，multi_params 應該也會跟著跑」

目前不對。

誤解 B¶

「segment 的 params 已等同於完整任務定義」

也不對。
segment 目前沒有策略維度、沒有獨立任務模型。

六、未來重構建議¶

若要把 multi_params 納入正式主流程，建議至少補：

BacktestSegment 增加 strategy_name
BacktestSegmentCreate / Update 增加 strategy_name
run_multi_period_backtest() 改走新主流程
淘汰 simple_backtest.py 內的硬編碼策略

七、實務結論¶

參數訓練¶

定位清楚：

人工研究 / 圖表標記工具

多區段回測¶

功能可用，但架構上屬於：

還沒完全升級到新策略系統的一塊

如果你在寫文件、做前端或準備重構，應該把它明確標記成：

legacy-compatible path

訓練與多區段 API 詳細¶

一、參數訓練區間 API¶

1. 圖表資料¶

GET /api/training/chart_data¶

2. 建立訓練區間¶

POST /api/training/param_range¶