Python 算法交易实验65 算法交易二三事

说明

对算法交易的一些内容做一些回顾和反思吧。

老规矩,先chat一下

道理说的都对,如果要补充就推荐再看一本书量化交易:如何建立自己的算法交易事业,我觉得这样就比较完整了。

简单来说,把量化当成事业,而不是一种投机,那么就要从模式、规范和工程的角度来思考:

  • 1 量化作为事业,应该是怎样的?(为什么个人,也包括我自己以前的交易不能称为事业)
  • 2 运营模式,特别是风险管控模式是怎样的?(真正的事业,即使是遇到大股灾,或者金融危机也不会崩溃的)
  • 3 数据、IT与智能系统以及策略。构成量化事业的最核心环节。

内容

算法交易相关的依赖知识,技能在这里不多说细节了,但整体上看,要求并不低,而是非常高。一种方式是一个人可以全部carry,包括业务理解、算法设计、架构设计、部署运维、项目计划(筹措)、风控等;这种方式的好处没有沟通成本,整个链条一定是高度一致的,限制就在于需要海量的时间和精力投入。另一种方式是可以有小团队协作,把以上几块分开,这样的成本非常之高,而且很难保证信息安全,毕竟量化的结果和利益往往只有一线之隔。反正,都挺不容易的,但坚持到底就会胜利。

本篇主要从更泛一点的角度来回顾这件事。

1 分阶段

想一次性的做好这件事几乎是不可能的。

粗略的,我将整个过程分为三个阶段。第一阶段属于试产,第二阶段属于量产,第三阶段暂不提。

试产的标准是整个过程是服务化,半自动化的,并可以稳定取得收益。量产的标准则是算法和交易过程更加稳健、更加深入以及自动化交易。

1.1 试产阶段

由于整个可执行项目有很多组件,我觉得第一个目标是"连通性测试",也就是说从数据、特征、算法、策略、服务、交互等各方面都要全部正常工作,这里面需要调试、校验的地方非常多,所以能够整个跑通,从想法变成服务,并能成功运行就很不容易了。

这里稍微区分一下,我的上线标准和普通的软件版本发布是不同的。我认为,一次上线必须从最初的想法,到系统工作机制,以及系统的各项功能必须是自洽的,符合预期的。而一般的软件发布只要功能正常就ok了,这种方式其实有很大的问题。实体需要盈利,所以产生了业务,业务是为了盈利服务的。为了实现业务盈利,就会有很多计划、想法,有相当一部分又需要通过系统去实现、落地。但是在大型组织,大量分工的情况下,其实信息是无法维持一致性的。结论是:成功的软件上线,对实体来说未必是成功的

量化比较有意思的是,只要试产成功了,其实业务也就成立了。 所以作为一个阶段是合理的,甚至试产阶段的产物会被长期保留、运行和维护,因为它们具有价值。

1.2 量产阶段

量产阶段是真正比较专业的实现。我觉得会有一些比较有标志性的特征:

  • 1 购买付费的数据源(可能还不止一个) ⇒ 从外部的角度来说数据更加稳定、可靠,而系统本身也具备了主数据管理的功能
  • 2 接口交易。 ⇒ 试产阶段还是需要手工进行买卖的,只是不需要人进行盯盘和判断。但是人的操作时延较大、精细度较低、复杂度也较低。这个阶段,系统具有规则引擎进行交易执行。
  • 3 高阶算法。 ⇒ 从特征到模型,压倒性的优势。
  • 4 自适应、自优化。 ⇒ 从参数调优、模型组合、探索性调整(多臂老虎机)等,量产的系统会分担相当一部分繁重的前进工作。

量产阶段的目标是建立一个具有门槛的,可以大规模运行的系统。

第一的关键点是具有非常强的竞争力,或者说非常大的差异性。从技术上,这点其实是很明显,也容易分辨的。例如,将LLM迁移到量化系统中,就是一种升级。当然,LLM在量化系统中只是外围的部分,真正的核心功能技术门槛更高,目的性更强。

第二的关键点是智能系统。或者说,整个提供具有局部优化、以及长期演进(强化学习)的特点。系统的产出结果将由若干个超参数决定,系统在内部会自动进行演变,以达到目标。

所以说量产阶段的产物,已经足够成为一个顶级的产品。

这里有个小疑问,量化大约已经存在了几十年,即使在中国也超过了10年,为什么没有出现特别有名的量化公司?

首先我并不是量化行业里的人,所以信息是很有限的,我只是从逻辑上来推断目前的结果:

  • 1 计算机硬件以及人工智能算法是在最近10年内高速发展的。从技术的特点来看,我认为2010年之前,几乎不可能存在我上面提到的量产阶段产品,至少智能化程度是很低的。
  • 2 美国的文艺复兴应该是最早把这件事做成的,但是他们没有透露太多信息,我猜测他们是基于语音、概率图这方面的方法去做的,年化30%其实不是一个特别高的值,从结果上来看,应该并没有达到想象中的高度。当然,控制这个值如果是他们策略的一部分的话就不好说了。
  • 3 国内比较出名的是幻方。我大致看了一些他们的产品介绍和收益结果,整个方向上不是我想象的那种类型,靠"蛮力"部分比较大。但某种程度上,幻方的大方向其实是对的,也非常重视技术,而不是行业分析。从他们的发展历程来看,甚至还有些励志:**幻方证明了,搞量化这件事,实际上是可以不太需要历史包袱的。**我的想法甚至和幻方的方向是一致的(依赖模型、算法),只不过在落地、工程方面的理念(具体的模型技术栈、架构技术栈)差异非常大。一篇文章

它们遇到的一些问题如下,这算是我推断有问题的点,一个稳定的量化不应该出现这种情况。当然,幻方作为一家公司,必须保证对资金的利用和回报,有时候即使避而不战是上策,但是也不得不下场,所以这是作为公司运行的一个弊端。注意,2019,2020幻方就有了比较夸张的算力,而回撤是2021年出现的,所以这不是算力不足的锅。 甚至我认为,其实量化对于算力的需求没有那么大,很多算力的投资回报降的是很快的。

2 功能

从一个最简单实例来看功能。

一个很有趣的经验是,通常在开始之前总会有各种美妙幻想,认为自己是英雄。上了战场以后通常就是一片混乱,最后连滚带爬的像个狗熊。

因为都是自己的经验,所以评级自己的时候也觉得还能接受;慢慢的我觉得这可能是一种常态、本能:我总是希望用最优雅的方式解决问题,然后问题总是在深入了解之后发现了更多的问题,然后又触发了我更多的想法。这种连锁反应通常会让我的很多工作进度被耽搁,所以为了准时完成任务就各种加班和补救。所以开始前的设计,任务中的重规划,以及交付结果,总是开始英雄,最后狗熊。

不过当任务总归能按要求交付,这种折腾也有好处。我逐渐习惯,并定制了一套完全自主的规范和工具。我相信这些规范和工具的最终结果是非常强大的,不过在规范和工具的形成过程中,又需要反复迭代,所以也是挺不容易的。就像华为说的:一边飞行,一边换发动机。

比较让我开心的是,这半年来有不少工具已经开始产生正向回报了:为了维护和进化这些工具所花的时间,已经明显短于不使用这些工具的时间。例如,开发及生产。对于建模来说,开发过程是非常灵活多变的,是一个探索过程;而当一个探索过程符合要求的时候,其实已经忘记来路了。所以如果花时间去追溯和验证,最终应该是可以复现的,但那样花的时间和精力真的无法想象。而现在,在一定的前提下,使用自己的工具可以做到用极少的时间(1~2小时)就可以精确复现建模时的所有操作。

客观的结果是:在研究和生产之间搭了一座桥,开发即生产。

回到正题,下面较为概括的列一下一个实例的完整过程。

2.1 数据

无论是研究还是生产,都需要数据。特别是考虑到要生产,数据必须是实时,或至少为准实时的。这个实例只用到了非常常规和少量的数据维度,就这样也发现了问题:

  • A数据源相对好,但是不能提供实时的获取
  • B接口可以有实时的数据,但是周期不能覆盖那么长

所以在使用的时候是采取A+B的方案。然后我发现这两个数据源,一个交易数用的是手,一个用的是股,而且B有时候是股,有时候又是手。幸好交易额是一致的,都是用元,所以这个错误通过交易量/收盘价可以纠偏过来。

虽然未来是可以都走付费数据,但其实从机制上看,这种问题还是具有普遍性的:系统如何能确保数据的即时、全面及有效性?

这个问题涉及的主题是:数据治理 ~ 主数据管理(数据融合)的问题

另外,未来会有大量的数据维度并不是那几个结构化的字段,例如可能需要对某些数据进行实时的探索性查询和分析,像热度这样的非标维度等。

**数据有效性会影响后续的可用策略,也就是说,当策略在执行时,必须要先判断依赖的数据是否正常。**一种是从入口处返现问题,一种是基于依赖关系发现问题。前者是数据治理问题,后者是图管理的问题。所以,在获取数据的时候,尽量采取冗余的方式(至少3份)来确保数据的稳定性,同时,策略自身也要对数据本身进行推断,避免"正确的错误"。

2.2 策略

在之前提到的那本书中,建立是基于经典的策略进行变体,从而创建新的策略。我本来也想这么干,试了一下发现效果不好。后来用了自己最熟悉的方法来做,也就是决策。

如何用算法,作出更合理的决策。只要能够证明机器的决策优于人的决策就可以了,其他都可以不看。另外还有一些理论,简单来说就是捡好的吃。

2.3 数据处理 & 模型

有了数据,又有了策略,那么接下来就是数据处理和建模的事了。

数据处理一方面是对脏数据进行清洗,另外就是将数据表达为特征,便于模型处理。这个过程是非常复杂的,按传统的方法手工的操作很多;未来用神经网络处理,那么这个复杂过程会转移到模型本身的架构上。

这次我还是按照最熟悉的传统办法来做,同时我构造了工具,来实现了开发到生产的快速连接。

完全的手工或者完全的自动化应该都是不可取的,所以未来还是两种方式都用,但是有不同的分工。例如神经网络用来进行深度感知,形成某一个x,而手工处理则将若干个x变为新的x'。这种方式,就实现了既灵活,强大,又可靠的系统。

模型方面,的确是要稍微强一点的才能达到预期效果。

2.4 离线回测

回测是必须的,而且要在足够长的周期上测试,来确保模型的确是经得住考验的。回测由:

  • 1 信号对象: 将模型分转为交易信号。
  • 2 订单对象: 根据策略规则进行交易,例如止盈止损
  • 3 资产对象:记录了策略资产在现金、持仓上的变化,并计算回撤等关键指标
  • 4 策略对象:制定业务上的策略规则,并驱动信号、订单和资产对象按时隙执行,返回结果。

回测有几个主题:

  • 1 生存型。在策略执行触及到资产损失的时候,会被终止,理论上这需要人停下来觉得,是否继续启动策略。好的策略可以在整个周期都正常运行,不会被kill。
  • 2 稳定性。按月、按年来看,策略是否是安全的。
  • 3 盈利性。盈利的总量,或者是资金的年化收益率等,这是直观的,也是所有人都看得懂的。
  • 4 盈亏比。这个能看出策略的有效性,而且说实话,刚开始的时候应该挑盈亏比高的,容易接受。
  • 5 资金占用比。这个也很重要,一方面是策略本身的制约,另一方面也会与盈利性相关。

2.5 服务与部署

服务方面,ADBS还是挺好的,对于每时隙必定执行的,一一对应的数据处理应对非常完美。所以,一个策略只需要两个ADBS就好了。

一个ADBS负责获取原始数据,另一个ADBS则从原始数据变换为模型结果。

另外一个则是APS方式。实现实时处理与通知。

目前可能还比较欠缺是的一个前端页面,记录实际的手工交易(不过问题也不大,证券软件也可以追溯)

2.6 发布与无限回测

发布的过程就是转为服务态,与本地执行的不同点在于执行的速度和间隔会更慢,但是是无限执行的。处理实时数据并给出结果,这个是与生产挂钩,与业务挂钩的过程。

这个时候更倾向于数据库进行交互,而不是本地文件;无限循环的间隔是若干秒,而不是直接遍历for,所以这点是差异很大的。所以在设计的时候必须要考虑这套。数据库才是大规模和持久化运行的保证。

即使进入生产态,回测也不应该停,而是应该随着数据继续刷新。一方面可以用于验证上线的准确性,另一方面新的信号就可以直接从回测出。所以回测,也要考虑到生产态的使用,在设计时尽量兼容。

3 重复

总体上,这个实例还是不错的,该实现的功能都实现了。本来我打算进行策略的变体测试,但现在觉得进行横向的拓展更有意义。

人工智能,总是要先人工再智能。

这个实例的流程做完了挺简单,做的时候都还挺迷糊的,有不少点我是希望做的更优雅一些的,但是发现真的没办法:在取得目标胜利和完美之间,我只能选前者。

但这事总归要继续演进的,所以,在同样的内容上进行简单的重复, 3次。

所以接下来会完全按照这个实例的做法,在3个新的标的上进行重复,每次的最终形态都是一样的,但是中间的过程会进行优化。最终要达到针对任何新标的,都有一个流水线可以直接处理、开发、测试和上线。

整体上,希望到10月的时候,这个重复完成,这样就初步形成了一个简单体系。

4 再看以后

一阶段完成后,应该会有足够积极的反馈,整体上要到年底,会有一个足够可靠的估计。然后就直接向二阶段进发:

  • 1 数据源。调研,并预计在2024年开始使用付费数据源。
  • 2 新维度。目前一阶段用的维度很少,有些明显相关的可以纳入。
  • 3 新特征。在一阶段其实就有一些有用,但因为时间原因没有纳入的特征。
  • 4 新模型-决策:其实有一些更好的模型,但是这次没用,之后会基于本次结果作为bench mark,引入新的决策模型
  • 5 新模型-特征:过于有一些概率图的提取方法,现在其实可以用大语言模型方法,构造新的特征。这些应该都是非常具有挑战性的内容。
  • 6 基础优化方法:基于遗传算法的整体优化。
  • 7 探索性优化方法:例如多臂老虎机。
  • 8 接口交易调研。估计在2024年以后开始使用接口交易
  • 9 规则引擎,是时候再进行Review和设计了,估计在2024年开始重设计和开发(我最早做的一个尝试是在2018、2019年左右)

在2024年底形成一个类似这样的结构:

相关推荐
齐 飞25 分钟前
MongoDB笔记01-概念与安装
前端·数据库·笔记·后端·mongodb
云空26 分钟前
《Python 与 SQLite:强大的数据库组合》
数据库·python·sqlite
暮毅30 分钟前
10.Node.js连接MongoDb
数据库·mongodb·node.js
wowocpp33 分钟前
ubuntu 22.04 server 格式化 磁盘 为 ext4 并 自动挂载 LTS
服务器·数据库·ubuntu
成富1 小时前
文本转SQL(Text-to-SQL),场景介绍与 Spring AI 实现
数据库·人工智能·sql·spring·oracle
songqq271 小时前
SQL题:使用hive查询各类型专利top 10申请人,以及对应的专利申请数
数据库·sql
计算机学长felix1 小时前
基于SpringBoot的“校园交友网站”的设计与实现(源码+数据库+文档+PPT)
数据库·spring boot·毕业设计·交友
小码的头发丝、2 小时前
Django中ListView 和 DetailView类的区别
数据库·python·django
Karoku0662 小时前
【企业级分布式系统】Zabbix监控系统与部署安装
运维·服务器·数据库·redis·mysql·zabbix
周全全3 小时前
MySQL报错解决:The user specified as a definer (‘root‘@‘%‘) does not exist
android·数据库·mysql