Note: Overlapping labels 重叠的标签, AI for Trading

问题 重叠标签(overlapping labels)问题是使用金融数据训练预测模型遇到的一个问题。如下图所示,假设我们要训练一个模型预测未来一周的收益,最简单的情况下我们会用某一天T的后一周连续收益作为训练的标签(label, i.e. 那个y)。这样每天的样本例子都有一个未来一周的label对应。但由于金融数据有自相关性,连续几天的label通常是相互关联的——这就和大多数机器学习模型的假设冲突,因为这些模型通常假设我们输入的每个样本间是独立同分布的(independent and identically distributed, IID)。 以随机森林(Random Forest)模型为例,如果按照上述样本进行训练,那么一个bag里面的样本很容易互相关联,out-bag的样本也亦如此,于是生成的各个决策树就比较相似,最终导致生成的森林的error rate上升——他们太相似了。 解决方案1:sum-sampling 子采样 如上图,若要训练的目标是未来一周的收益,可以子采样每周五的未来一周收益。这种方法的缺陷很明显,就是少了很多训练数据。设想一下如果预测目标是未来一月或是一年的收益,训练数据就被删的所剩无几了。 解决方案2:调整随机森林的bagging过程 减少每次bag的样本数量,这样一个bag里的样本相关性就会降低。 解决方案3:轮动数据 基于方案1,假设我们还是要未来一周收益,那么可以训练5个不同的模型,分别子采样周一、周二、…、周五的数据,最后合并这五个森林。

笔记 – Tree-based models with financial data, AI for Trading

Importance of Random Column Selection / 随机列选择的重要性 Sometimes one feature will dominate in finance. If you don’t apply some type of random feature selection, then your trees will not be that different (i.e., will be correlated) and that reduces the benefit of ensembling.有时,一项特征将在财务数据中占主导地位。 如果您不应用某种类型的随机特征选择,那么您的树将不会有太大的不同(即, 他们之间的相关性太高),从而降低了集成(ensembling)的好处。 What features are typically dominant? Classical, price-driven factors, like mean…

Cross Validation for Time Series 时间序列数据的交叉验证

Methods for choosing training, testing and validation sets for time-series data work a little differently than the methods described so far. The main reasons we cannot use the previously described methods exactly as described are,选择时间序列数据的训练,测试和验证集的方法与到目前为止描述的方法稍有不同。我们无法完全按照上述说明使用前述方法的主要原因是: We want our validation and testing procedure to mimic the way our model would work in production. In production, it’s…

期权高频交易系统 简单揭秘

温故而知新。 框架 上图是我眼中的最简交易系统,它分为几个部分: 网关(Gateway): 负责和交易所/经纪人(远端)打交道。一方面接收行情数据(报价更新,订单更新等),另一方面把交易指令传给远端. 定价引擎(Pricing Engine): 接入的行情数据需要转换成策略需要的报价。对于衍生品来说,它的输出应当至少包含衍生品的理论价格。定价引擎可能还有额外的输入,比如对于期权定价而言,,一般会使用类Black-Scholes模型定价,有了标的物(underlying)的市场数据之后,它还需要波动率(volatility)、利率等参数的输入以及一些合规、风控相关的参数。 策略(Strategy): 交易策略接收定价引擎的信息,同时他也接受策略目标instrument的实时行情。不同的策略给出不同的执行建议,然后把这些执行建议传给后续模块。 风控&执行复用(Compliance & Execution Mux): 一个交易系统(很)可能同时执行多个策略。不同策略发出的执行建议可能互相重合、冲突或者产生执行时的合规风险。这个模块负责处理所有的执行请求,把合格的请求发给Gateway执行。这边用Mux相对形象一些,暂时还没想到更好的词。 需要说明的是,上面这些仅仅是极其基础的组件。如果把交易系统作为一个模块看待,它其实会有许多附加组件,例如高频交易员往往会根据经验值调整一些参数,这些参数会反映在策略执行、风控、定价模块中,于此就会产生一些和人交互的UI组件。 优化: 软件、硬件、程序语言… 不同于一众互联网公司的系统,高频交易系统对于低延迟的渴求相当急切,对它来说高并发往往是可以忽略的。重要的是一个报价更新如何最快到达系统,一个订单(order)如何在最快的时间内到达交易所。目前能见到的国外交易公司,主要用C++编写交易系统,当然也有很厉害的公司用自己定制的JVM跑Java交易。对于延迟不是非常敏感的市场,也有使用Python作为开发语言的。当然这些仅限于软件层面,事实上很多交易公司已经用上了FPGA用来进一步加速执行速度,甚至使用FPGA来执行一些简单但是对延迟极其敏感的交易策略。以C++为例,代码编写上将会大量使用模板(template)替代虚函数。一般应用场景上虚函数调用的开销可能是不值一提的,但是如果算到了纳秒(或CPU tick)级别,虚函数的开销也会令人头疼。也许有人会问,那接口继承怎么不用虚函数弄呢?有兴趣的可以去看一下CRTP设计模式。 Gateway 网关系统的职责是负责对外联系,一般分为行情数据(Market Data)和订单执行(Order Execution)两个部分。交易所一般会提供机房租赁,衍生品交易公司会采用co-location策略把交易主机放在租的机房里,确保和交易所的Matching Engine距离最近。所谓Matching Engine就是交易所自己用来匹配订单(order)的中央机器(其实有很多个机器)。就行情数据而言,绝大多数交易所是用UDP组播的方式下发数据的。收到组播数据后,需要把订单报价更新的信息尽快处理并上发。就程序逻辑优化而言,第一是要尽最大可能减少内存拷贝(memory copy)。第二是要钻研(并且实验!)交易所给的数据格式,避免去读取不需要的字段。其次某些交易所的市场数据可能还是通过ASCII字符下放的,这边就要尽量优化string to int的延迟。 Market Data 对于某些交易Gateway实现,也会包含price book/order book的更新。行情数据可以细分为不同的频道(channel),一些会播放price book update, 另一些则是order book update. 后者往往包含更多的交易信息,这些交易信息与trade update合并关联之后,就能给pricing module提供实时更新。对于price book/ order book,写代码的小哥往往会对他们各自抽象各自的数据结构,这些数据结构需要保证book update的响应尽量快。在book得到更新后,上层系统(strategy, pricing module)对它的需求是不同的,有些需要full depth of book,有些可能只需要几个book level或是只要TOB(top of book),针对这些不同的需求,系统也会给出不同的优化。也有系统把book update的具体操作另外归类为几个特殊事件直接传给系统上层、以便做出最快响应。这些事件可能包括巨大的价格变动(此时很可能需要撤单)。另一部分个重要部分是重启、恢复机制。由于UDP传输的不稳定性(尽管已经是co-location了),交易所一般提供通信恢复的专门channel播放恢复数据。在网络中断或者系统故障后,需要通过数据恢复机制重建各种交易工具(instrument)的最新信息。…