QuantStart门户的编辑撰写了有关您在开始开发自己的系统以测试交易策略时应了解的知识的
材料 。 我们检查了博客前面文章中提出的一些问题，因此这次我们对这些问题进行了适当的复述，内容涉及开发人员面临的问题，不同类型的回测之间的区别是什么，以及它们的优缺点。
什么是回测器
回溯测试是将交易策略规则应用于一系列有关金融工具价格的历史数据。 该方法的本质是，如果我们开发一种机制来确定进入和退出头寸（买入/卖出）的时间（例如，某个投资组合中的股票），并将所得规则应用于历史数据，则可以“了解过去的交易策略的生产率” ”。
曾经有人说“所有模型都是错误的，但有些模型是有用的”。 这个短语非常适合回测。 用于财务策略历史测试的系统有助于确定是否值得将现有规则集应用于实际交易。 如果我们知道某项策略在过去的表现，那么它将有助于滤除不良策略，而无需造成实际财务损失。
问题在于回测结果与交易所的真实交易结果无关。 这只是现实的模型。 通常包含许多假设的模型。
回溯测试器有两种主要类型-循环测试和事件驱动测试。
在开发这样的系统时，始终需要在准确性和实现复杂性之间进行折衷。 这两种类型的回测器代表了针对这种折衷方案的所有选择。
回测挑战
对历史数据进行测试会遇到很多困难。 所有这些都与整个过程只是对现实的模拟这一事实有关。 这里只是其中一些：
- 样本内测试 -使用相同的数据训练交易模型并进行进一步测试时会出现问题。 在这种情况下，显示的生产率将大大降低-因为在以前已知的数据系统上可以实现结果。 实际上，数据通常会与训练有很大不同。 实际上，这是再培训的一种形式。
- 幸存者的错误 -当某些股票和金融工具出现或被排除在外时，股票指数（例如S＆P500）的特征是上市和退市。 如果在回测期间未考虑这些变化，则不考虑因资本不足而被排除在指数之外的公司的股票的策略将被认为是成功的。 为避免此类问题，长时间运行回溯测试时，您需要使用不受幸存者错误影响的数据。
- 预测错误（前瞻性偏差） -将来的数据也可能影响回测结果。 例如，考虑以一定时间间隔计算线性回归指数的情况。 如果随后在同一样本中使用此指标，则表明将来的数据会渗透到该样本中，这意味着该策略的最终生产率将大大降低。 面向事件的回测器有助于解决此问题。
- 市场状况的变化 -金融市场参数不是固定的。 这意味着导致股价波动的过程不依赖于随时间恒定的参数。 这个事实使参数化模型的泛化变得复杂（许多交易策略是此类策略的特例），这导致以下事实：该策略在历史数据上的有效性比在真实交易中要好得多。
- 交易成本 -许多周期性的回测员甚至不考虑有关交易成本的最基本信息，例如各种费用。 通常，科学论文的作者犯罪，他们不愿屈从于这些琐事。 寻找在无成本的理想条件下非常有利可图的策略非常容易。 问题是，在真实条件下进行交易时，此类策略可能根本无法盈利。 考虑点差，市场情况，各种费用，滑点（在资产波动较大的交易中，交易的实际价格可能与提出申请时的预期价格略有不同-在有利的方向和负面的情况下）都非常重要。
还有其他一些不常讨论的问题，但是对于创建一个高质量的回测器来说却极为重要。 其中包括：
- OHLC数据是有关开盘价，交易期间金融工具的最高价格，其最低价格和交易时段的收盘价的信息（开盘价-高低-收盘价图表，OHLC）。 通常是从Yahoo Finance等来源导入的。 在这种情况下，可能是不同数据馈送的组合。 这意味着很难获得实时交易系统的极高价值（包括高价和低价）。 在交易模型中也需要考虑这一点。
- 容量限制 -回测正试图使用无限量的资金。 实际上，可用于交易的资金数量总是有限的（用于保证金交易的借入资金的数量也是如此）。 同样重要的是不要忘记平均每日交易量限制（Average Daily Volume，ADV），尤其是对于低流动性股票，当交易系统将导致价格真正变动的风险很高时。 这种市场效应也应予以考虑。
- 基准选择 -必须回答以下问题：是否正确选择了基准，以与测试策略进行比较。 例如，如果您交易的商品期货对S＆P500指数是中性的，是否值得将该指数用作基准？ 一篮子其他大宗商品基金可能是一个更合适的选择。
- 稳健性 -如果您在回测期间更改策略的开始时间，这会对结果有多大影响？ 对于长期策略，工作的开始时间不会严重影响生产率-回溯测试是在星期一还是星期四开始都没有关系。 如果它对初始条件过于敏感，则意味着无法在实际交易开始时预测其可能的生产率。
- 再培训和差异 -我们已经在上面讨论过再培训问题，但这是所有受监督的机器学习方法中固有的更广泛的问题。 这个问题只能通过仔细使用交叉验证技术来解决。 即使在这种情况下，在使策略适应测试数据集中的噪声时也应格外小心。
- 心理承受力-创建自动交易系统时，通常会忽略心理学，因为应通过算法将其影响降至最低。 但是，即使不是通过双手而是借助机器人进行交易，人们仍然是人类。 结果，这可能会影响结果。 例如，如果在回测期间提取50％的存款似乎是可以接受的风险，那么实际上损失资产价值的一半证明是更加痛苦的经历。 在这种情况下，抵抗计划外的行动并不容易。
这就是关于历史测试的问题，现在我们转向对此类测试的系统本身的描述。
两种类型的背部测试仪
首先，考虑循环系统。 这是最简单的回测器类型，经常在各种金融博客文章中描述。
循环回测
它们的工作方式是这样-系统仅在每个交易日（或OHLC条）中进行迭代，进行与所需资产价格相关的计算（例如，计算移动平均收盘价），然后执行相应的操作（输入多头或空头头寸）。 进一步的迭代将继续。 在此过程中，会存储有关性能的信息，以便构建图形（股权曲线）。
这是这种算法的伪代码：
for each trading bar: do_something_with_prices(); buy_sell_or_hold_something(); next_bar();PythonCopy
如您所见，该系统非常简单，这使得此类反向测试人员成为获取有关交易系统前景的初步估计的绝佳选择。
优点
循环回测器非常容易使用几乎所有编程语言来实现，并且可以快速完成。 当您要测试许多不同参数的效果时，这很有用。
缺点
主要缺点是结果不切实际。 通常，在循环回测器中，甚至没有用于会计交易成本的基本功能，因此必须单独实施。 通常也仅使用MARKET订单。
另外，为测试和生产系统重用代码的可能性很小，因此您必须再次编写。 这增加了软件错误的可能性。
环回测试仪容易出现预测错误。 它们应专门用作过滤工具，以拒绝明显不成功的策略。 同时，重要的是要对已经显示出良好结果的策略保持高度怀疑。 重要的是要记住，在现实生活中，策略执行得比回测期间要好。
面向事件的系统
这种类型的系统在频谱的另一侧。 他们更接近现实。 通常，它们在巨大的while循环中工作，在此期间，不断在特殊的“事件队列”中搜索“事件”，包括：
- 滴答 -新市场数据的出现；
- 信号事件 -交易信号的出现；
- 订单事件 -完成交易的订单已准备好发送到经纪人系统；
- 交易事件 -从经纪人处收到的有关应用程序执行的信息。
当识别到某个事件时，该事件将被传输到交易系统基础结构中的相应模块以进行进一步处理，并可能生成新事件，这些新事件再次落入队列。
这样的回测器的伪代码如下：
while event_queue_isnt_empty(): event = get_latest_event_from_queue(); if event.type == "tick": strategy.calculate_trading_signals(event); else if event.type == "signal": portfolio.handle_signal(event); else if event.type == "order": portfolio.handle_order(event); else if event.type == "fill": portfolio.handle_fill(event) sleep(600);
如您所见，该系统非常依赖项目组合处理模块-这是面向事件的系统的真正核心。
优点
这种类型的回测器具有许多优点：
- 减少预测错误的可能性 -由于结构假定消息是分阶段传输的，因此在面向事件的系统中，至少在交易级别，不太可能发生预测错误。 但是，由于模型本身可能包含错误，因此仍保留了它们发生的可能性。
- 重用代码的能力 -要在实际交易中使用该策略，您只需要替换数据处理模块和订单执行引擎即可。 策略的描述，风险管理和职位管理的模块，评估系统生产率的代码-所有这些都可以使用而无需更改。 这样可以减少出现新错误的可能性。
- 投资组合级别 -事件驱动的策略使在投资组合级别更容易思考。 最终，这使更改策略和开发对冲方法变得更加容易。
- “正确”的风险管理 -在这样的系统中，更容易“调整”风险管理。 交易者可以轻松使用像Kelly准则这样的技术，并且还可以包括各种警报，设置限制（例如，波动性）。
- 远程部署和监视 -编写代码的模块化原理简化了其在云中或根据交换并置方案的部署。
缺点
面向事件的系统的优点是可以理解的，但是存在某些缺点。 其中包括：
- 复杂的代码 -要开发一个完全被测试覆盖的系统，将需要花费数周甚至数月的全职模式。
- 面向对象 -系统的模块化设计需要一种面向对象的编程方法。 因此，我们需要一种支持这些原则的语言。 单元测试不会再容易了。
- 高入门门槛 -编程新手将无法创建这样的系统。 需要大量的工程经验，这将使得处理代码，实现日志记录，进行单元测试，实现版本控制和持续集成实践成为可能。
- 低速 -与矢量化循环方法相比，一种方法，在该方法中系统内的消息在其不同级别内顺序传输，从而降低了应用程序的执行速度。 计算参数的各种组合可能很耗时。