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年底形成一个类似这样的结构：