说明

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

老规矩，先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份）来确保数据的稳定性，同时，策略自身也要对数据本身进行推断，避免“正确的错误”。