Zum Inhalt springen
Alle Bibliotheksdokumente

Backtest-Kosten bei wirkungslosen Konfigurationsfeldern richtig einordnen

Code Machine Learning for Trading

Zusammenfassung

Diese Konfigurationsnotiz unterscheidet Einstellungen, die in einer Backtest-Identität erscheinen, von Einstellungen, die tatsächlich simulierte Handelskosten beeinflussen. Im beschriebenen Fallbeispiel verwenden alle registrierten Läufe einen vektorisierten Pfad mit Rendite bis zum Verfall. Die konfigurierten Felder für Ausführungspreis, Provisionssatz und Slippage-Satz werden an diesen Pfad nicht übergeben. Quotierungsseitige Ausführungen gehören zu einem ereignisgesteuerten Broker, den die vektorisierten Läufe nicht erstellen. Die Einstellungen bleiben in der Konfiguration, da ihre Entfernung die gehashte Identität bestehender Läufe verändern würde.

Die tatsächlichen Kosten werden separat aus einer Setup-Datei ausgelesen: Spreads beim Ein- und Ausstieg in Optionen, geschätzte Hedge-Spreads bei jedem Rebalancing sowie Provisionen pro Kontrakt oder Aktie. Laut Notiz ist das erfasste Feld für die gesamte Slippage in der angegebenen Population null, obwohl Kosten berechnet werden, weil dieser Pfad keine Kostensummen erfasst. Die praktische Lehre für Audits: Ein Konfigurationswert oder eine fehlende Kostenkennzahl allein belegt nicht, welche Kosten ein Backtest verursacht hat. Die Ergebnisse gelten für die angegebene Implementierung und sollten erneut geprüft werden, wenn sich Runner oder Kostenverarbeitung ändern.

Kernaussagen

  • Konfigurationsfelder können die gehashte Identität eines Laufs beeinflussen, auch wenn der Ausführungspfad sie nicht verwendet.
  • Der hier beschriebene vektorisierte Pfad mit Rendite bis zum Verfall verwendet die konfigurierten provisions- und slippagebasierten Sätze nicht.
  • Die tatsächlich simulierten Kosten stammen aus separaten Kostenkomponenten für Optionen, Hedges und Liquidationen.
  • Ein Nullwert für die aggregierte Slippage beweist nicht, dass keine Kosten berechnet wurden.
  • Die Interpretation der Kosten hängt davon ab, den konkreten Runner und seinen Datenfluss nachzuvollziehen.

Schlagwörter

Volltext
# base.yaml


```yaml
# Three fields below are inert on the path this case study runs: `execution.execution_price`,
# `commission.rate` and `slippage.rate`. Every registered backtest here is `ret_to_expiry`,
# which `case_studies/utils/backtest_runner.py` routes to `_run_htm_daily_mtm`, and that call
# is not passed `cost_spec` - the only thing that carries these rates into a run. The
# `quote_side` fill is read by the event-driven broker, which a `rebalance.mode: vectorized`
# case study never constructs. They still reach the registered `backtest_config` and so the
# hashed identity, which is why they stay: removing them would re-key 879 backtests to delete
# values nothing reads.
#
# The costs this case study actually pays come from `_htm_backtest.py`, which reads
# `config/setup.yaml::costs.components` directly - per-leg entry spread from the real option
# quotes, `hedge_spread.estimate_bps_of_notional` on every hedge rebalance,
# `commission.option_per_contract` and `commission.equity_per_share`, plus an exit spread on
# liquidation. Verified 2026-09-12; `total_slippage` is NULL on all 879 rows because the
# vectorized path records no cost totals, not because nothing was charged.
account:
  allow_short_selling: true
execution:
  execution_price: quote_side
  mark_price: price
  execution_mode: next_bar
commission:
  model: percentage
  rate: 0.0005
slippage:
  model: percentage
  rate: 0.0002
calendar:
  calendar: NYSE
  timezone: UTC
  data_frequency: daily
feed:
  timestamp_col: timestamp
  entity_col: symbol
  price_col: instr_mid
  close_col: close
  bid_col: instr_bid
  ask_col: instr_ask
  mid_col: instr_mid
metadata:
  case_study: sp500_options

```

Vollständig mit Quellenangabe unter der Lizenz der Quelle angezeigt. Lizenz: MIT

Diese Zusammenfassung wurde vom Research-Agenten von Stratmill anhand des Originals verfasst; sie ist keine Kopie der Quelle.