基于流程图的量化交易模型

Author Avatar
zccz14 10月 21, 2017
  • 在其它设备中阅读本文章

量化交易模型 (Quantitative Trading Model) 的开发是非常注重性能 (Performance) 的,而传统性能的测试通常只在于少数几个指标:净值 (Net Value)、回撤 (Drawdown) 、盈亏比、获胜概率等等,这些东西都是可以基于成交记录统计得出的数据,因而传统的性能测试实际上是一种黑盒测试。

黑盒测试不关心模型的内部构造,因而对于改良模型的帮助微乎其微。

量化交易模型的改进通常基于人工检查成交记录,然而人在看成交记录时通常会着眼于大的亏损以及明显不合理的交易,会产生幸存者偏差 (Survivorship Bias) ,严重影响了精度以及提高了成本。

真实的交易员的交易思路是比较抽象的,十分依赖经验,而经验则是通过历史的行情总结出来的。但人脑并非一个精确的统计机器,很多时候也就会被误导。而固化交易逻辑,严格执行正是量化交易的特点。

设计模型时通常都会基于流程图 (Flow Chart) ,因为它比较高级 —— 贴近人的逻辑;灵活 —— 上下文引用比较随意;可见 —— 图形化的逻辑更可读,检查起来也比代码方便得多。

设计完流程图以后需要程序员来理解和实现,变成可以执行的代码,然后统计才变得有可行性。运行之前,模型设计者对流程的执行情况也只局限于个别的情况,并不知晓其他类似的情况是否理想。设计 (Design) 与验证 (Validate) 之间这个间隙 (Gap) 要如何缩小甚至消除呢?

  • 创造一门新的领域专用语言 (DSL),开发编译器来处理它

    可能会使得已有的大多数函数库没法使用,使用的复杂度太高,不过类似 GraphQL 的配合 resolver 的思路也很不错,以后可以试试。

  • 在编程语言与底层代码之间新增一层虚拟机层,更换底层 API 实现

    利用编译器的 API 将代码解释执行并监控每行代码的 Hit 数。优点是无须更换代码就可以进行;缺点是跟代码行一一对应但无法很好地与流程图对应,这会造成统计结果的后续整理变得复杂。

  • 创建流程图框架,完全重写原有的程序

    建立一个类库,完全按照流程图的结构编写代码。

我的选择是创建模型框架 (Framework) 来吸收那些机械的复杂度,具有以下功能:

  • 运行热度统计 (运行路径跟踪)
  • 运行日志输出 (运行路径跟踪)
  • 可预测状态 (降低副作用,保持计算纯度)
  • 流程可视化
  • 增量修改与历史版本对比 (面向流程图对象编程)

在流程图中有几个常用的元素:过程 (矩形)、选择 (菱形)、路径 (线)。

这些元素的组合结构对应了结构化编程中的条件结构、顺序结构与循环结构。而结构化编程的一个原则是不使用 goto 语句,而在流程图中到处都是 goto 。基于流程图的编程,最重要的是直观。我不主张禁用 goto,但我认为使用 goto 一定要作用于局部,否则就一定需要将流程切割成更小的可复用组件。

过程调用/返回/循环 本质上跟 goto 并没有什么区别,无非是 可读性/可维护性 更强。但 可读性/可维护性 归根结底要看实现的方式是否贴近人思考事物的方式。远距离 goto,应该先问是不是真的这段的逻辑完全一致。

基于流程图还有一个好处,那就是距离底层计算模型 —— 图灵机非常近,顺序、跳转,simple and low-level。而它的图形表示又足够直观 —— 非计算机背景的人都能看懂。

而流程图的弊病在于难以描述大而复杂的逻辑,过于复杂的流程也会让人懵逼。因此流程图的切分也是一门艺术,但大体上与面向过程/面向对象的经典中的指导无异。

具体的模块设计留到下次,专门的项目 QuantFC (Quant Flow Chart) 已经开始准备,地址在 GitHub: zccz14/QuantFC