量化交易：回测框架

可视化演示

展示事件驱动与向量化回测差异、前视偏差控制与滑点模拟过程，可切换三种模式观察回测结果如何更真实可靠。

回测的价值

开一家新餐厅，厨师长会直接把整本菜谱挂出去营业吗？当然不会。他一定会在后厨反复试做：按菜谱下料、调火候、请朋友试吃、记录反馈、调整配方，直到确认这道菜“拿得出手”才敢写进正式菜单。量化交易里的回测框架，就是量化团队的这间“试菜厨房”——在投入真金白银之前，用历史行情作为“往日菜价记录”，把一套交易逻辑完整地彩排一遍。

量化策略本质上是一条“自动化买卖菜谱”：什么价位买入（开仓）、什么价位卖出（平仓）、每次买多少（仓位管理）。回测（Backtesting）要做的事情，就是把这个菜谱放到过去若干年的行情数据上，模拟每一笔交易，最后算出这套策略如果真实运行过会赚多少钱、波动多大。它回答的问题很简单：这道菜，到底值不值得上正式菜单？

回测框架最基础的评价指标是收益率。假设期初投入资金为 $V_{start}$，回测结束时账户资产为 $V_{end}$，则简单收益率可以用下面的公式计算：

当然，收益率只是第一道“口味评分”。真正专业的试菜还要看波动、回撤、夏普比率等指标，就像评价一道菜不能只看卖相，还要看它是否稳定、是否经得起客人反复点。接下来，我们走进两间风格不同的“试菜厨房”——事件驱动与向量化回测。

事件驱动回测

私房菜馆的做派是客人点什么，厨师就一道一道现场做：下单、切菜、起锅、上桌，每一步都在真实的后厨发生。事件驱动回测就是这种“私房菜做派”——它不会把整段历史行情一次性算完，而是把行情报价、信号触发、订单成交都看作一个个“事件”，像接待客人一样按时间顺序逐个处理。

事件驱动回测（Event-driven Backtesting）维护一个事件队列和一口“计时钟”。每来一个新事件，系统就检查当前持仓是否需要调整：如果均线金叉信号触发，就模拟按当前价格买入；如果信号消失，就模拟卖出。每一步都会记录成交价、手续费和当时的资金变化。这种写法像后厨的流水线账本，每一笔都清清楚楚。

这个框架最核心的环节是“撮合决策”——根据当前信号决定持仓状态。设 $Position_t$ 表示 t 时刻的持仓，$Signal_t$ 表示策略发出的信号，则：

事件驱动的优势在于真实——它能精细处理涨跌停无法成交、停牌、成交滑落等现实细节，像私房菜一样“每一步都有讲究”；缺点是慢，每一笔都要走完整流程。如果只是想知道“这道菜大概好不好吃”，有没有更快的办法？下一节的“中央厨房”给出了答案。

向量化回测

大型连锁餐厅的中央厨房，会把几百份同款菜一次性批量备好，而不是等客人来了才开火。向量化回测（Vectorized Backtesting）沿用了这个思路：把多年的历史行情看作整批“食材”，用矩阵和向量运算一次性算出每一天“如果按当前仓位持有会赚多少”。

向量化回测的关键是构造收益率序列。给定每日收盘价序列 $P_t$，相邻两天的收益率：

有了收益率向量，再配合策略给出的持仓向量做逐元素相乘、累加，就能快速得到整体资金曲线。矩阵库（如 NumPy）能在极短时间内完成几十万行的计算。这让向量化回测特别适合初期海选：快速过滤掉明显不靠谱的菜谱，再把少数候选交给事件驱动精测。不过“快速”有代价——向量化难以模拟涨跌停不成交、停牌等真实约束，精度上更像“理论口味”。聪明的团队会把两者搭配成完整的研发流水线：用中央厨房的粗筛速度，保私房菜的最终精度。

前视偏差控制

试菜时如果厨师长先翻开明天的菜价单，再决定今天买什么菜，朋友们的“好吃”评价就毫无意义——作弊得来的成绩单不能预测真实营业。回测中的前视偏差（Look-ahead Bias），就是一切“偷看未来”的行为。

最常见的前视偏差有两类。第一类是“未来函数”：策略代码本应只用 t 时刻及之前的数据来做 t 时刻的决策，却误用了 t+1 时刻甚至更晚的数据（比如用了未来财报数据、用全样本统计量做归一化）。第二类是“幸存者偏差”：研究者用今天还活着的股票列表回测过去十年，早已退市、暴跌的股票被悄悄剔除，等于只统计活下来的名菜，收益自然虚高。

控制前视偏差要守住一条“信息边界”：t 时刻的决策只能依赖当时信息集 $I_t$，任何未来信息都不得进入。

守住这条红线，回测结果才有“预测未来”的资格。但即便不偷看未来，还有一件每天都会发生的麻烦事——真到了菜市场，你根本买不到价目表上那个完美价格。

滑点与成本模拟

厨师长拿着昨天的价目表去买菜，到了市场发现今天的价格已经变了；如果一次要买几百斤，摊主甚至还会顺势涨价。这种“实际成交价偏离信号价”的现象，在量化交易里叫滑点（Slippage）。

滑点的来源主要包括：市场短时波动、订单量过大对价格产生的冲击、以及下单与成交之间的时间差。回测如果完全忽略滑点，资金曲线就像一个“从不被涨价、从不付运费”的完美买菜计划，长期来看必然高估收益。把成本计入账本，才是对试菜诚实的做法。

工程上，最常见的做法是在信号价格上叠加一个惩罚项。假设策略看到信号价 $P_{signal}$ 后下单，模拟的实际成交价为：

把滑点、手续费一起计入回测账本后，报告才具备参考价值。很多人走到这一步就以为万事大吉——但别忘了，还有一道更隐蔽的坎：菜谱可能在试菜时完美，一开张就翻车。

过拟合检测

为了讨好试菜评委，厨师长反复微调调料的克数，直到评委们连连点头。可正式开张后，新来的客人尝了一口就皱眉：“这菜太咸了。”菜谱“过拟合”了——它背熟了评委的口味，却没有学会大众的味蕾。

回测过拟合（Overfitting）指策略在历史数据（样本内）上表现极佳，但换到没见过的数据（样本外）就大幅衰减。原因是调参过程中，参数被反复打磨到贴合历史噪声，而不是抓住真实规律。检测过拟合最基础的方法是样本外测试：把历史数据切分成训练段与验证段，前者用于调参，后者用于检验。

样本外收益的计算如下，其中 $N_{OOS}$ 为样本外交易日数量：

如果样本内收益很高而样本外明显缩水，几乎可以判定过拟合。更稳健的做法还有滚动交叉验证（多换几批客人盲测）和参数敏感性分析（微调配方参数，看表现是否忽上忽下）。通过考验的菜谱终于可以批量复制了，但新的瓶颈随之而来——出菜太慢。

性能优化

餐厅火了，后厨开始排长龙：备料占地方、灶台不够用、工序有等待。回测框架的性能优化，就是让同一套菜谱在最短时间内完成试做，为反复调参争取更多迭代次数。

一次回测的耗时可以分解为三个部分：数据准备耗时 $T_{data}$、信号计算耗时 $T_{signal}$、撮合记账耗时 $T_{exec}$。总耗时是三者之和：

常用优化手段包括：把行情数据缓存到内存或 Parquet 文件中，避免重复加载；用 NumPy/Numba 对信号计算做向量化加速；把事件驱动中的撮合热点用 Cython 重写。优化的第一步永远是剖析（Profiling）——先量化出三块耗时各占多少，再对症下药，而不是盲目优化所有代码。厨房效率提升后，就能同时试做更多菜谱了，这就引出了最后一道工序：让多个厨师在多口灶台上并行开工。

并行与工程落地

成熟的餐厅研发部不会一道一道菜慢慢试，而是让多位厨师同时试做不同候选菜谱，一次性比较哪个最有潜力。量化团队的做法类似：把几百组策略参数拆成独立任务，分发到多台机器上并行回测。

并行验证的收益可以用加速比衡量。若单机串行完成所有任务需要 $T_{serial}$，n 个 worker 并行后实际耗时为 $T_{parallel}$，则：

工程落地时通常采用“任务队列”架构：调度中心把参数组合、数据路径打包成任务投入队列，空闲的 worker 领取任务、执行回测、上报结果。这个架构天然支持水平扩展，也方便做企业级 ROI 核算——把回测所需的机器成本、人力成本，与策略上线后的预期收益放在一起评估，决定一道菜是否值得上正式菜单。从私房菜的一口灶台，到中央厨房的批量出菜，再到多灶台并行研发——回测框架这套“试菜体系”，是量化团队在真金白银面前的第一道质检工序。它让我们用历史数据反复彩排，把失误留在模拟厨房里，只把最好吃的菜谱端上正式餐桌。

AI 应用场景

Python 演示

import numpy as np  class SlippageBacktest:    def __init__(self, prices, fast=5, slow=20, slippage=0.002):        self.prices = np.asarray(prices, dtype=float)        self.fast = fast        self.slow = slow        self.slippage = slippage        self.signals = self._make_signals()        self.returns = np.zeros(len(self.prices) - 1)        self.equity = np.ones(len(self.prices))     def _make_signals(self):        fast_ma = np.convolve(            self.prices, np.ones(self.fast) / self.fast, mode="same"        )        slow_ma = np.convolve(            self.prices, np.ones(self.slow) / self.slow, mode="same"        )        pos = np.where(fast_ma > slow_ma, 1.0, 0.0)        return np.concatenate(([0.0], np.diff(pos)))     def run(self):        position = 0.0        for t in range(1, len(self.prices)):            position += self.signals[t]            daily_ret = self.prices[t] / self.prices[t - 1] - 1.0            trade_cost = abs(self.signals[t]) * self.slippage            self.returns[t - 1] = position * daily_ret - trade_cost            self.equity[t] = self.equity[t - 1] * (1.0 + self.returns[t - 1])        return self.equity     def split_test(self, ratio=0.7):        cut = int(ratio * len(self.returns))        train_ret = self.returns[:cut]        test_ret = self.returns[cut:]        train_final = np.cumprod(1.0 + train_ret)[-1]        test_final = np.cumprod(1.0 + test_ret)[-1]        return train_final, test_final  def main():    rng = np.random.default_rng(42)    steps = 500    trend = np.linspace(0, 0.5, steps)    noise = np.cumsum(rng.normal(0, 0.01, steps))    prices = 100.0 * np.exp(trend + noise)     bt = SlippageBacktest(prices, fast=5, slow=20, slippage=0.002)    equity = bt.run()    train_end, test_end = bt.split_test(0.7)    print("样本内终值: {:.4f}".format(train_end))    print("样本外终值: {:.4f}".format(test_end))    print("全样本总收益: {:.2f}%".format((equity[-1] - 1.0) * 100))  if __name__ == "__main__":    main()

1. fast_ma = np.convolve(self.prices, np.ones(self.fast) / self.fast, mode="same")用滑动平均计算“快速均线”，相当于后厨快速判断食材短期走势的参考线。
2. pos = np.where(fast_ma > slow_ma, 1.0, 0.0)快速均线高于慢速均线时持有多头仓位，否则空仓，形成最朴素的趋势交易信号。
3. return np.concatenate(([0.0], np.diff(pos)))把仓位序列转换为“仓位变化”信号，只在切换时产生交易动作，降低无效换手。
4. position += self.signals[t]事件驱动式地逐日累加信号，模拟真实账户中仓位的开平过程。
5. trade_cost = abs(self.signals[t]) * self.slippage每次买卖都按滑点比例扣成本，让账本不再“理想化”。
6. self.equity[t] = self.equity[t - 1] * (1.0 + self.returns[t - 1])用复利方式滚动更新资金曲线，模拟真实账户净值。
7. train_final = np.cumprod(1.0 + train_ret)[-1]计算样本内外的累计增长倍数，是判断过拟合的第一道指标。

常见误区

面试题