【最后203篇系列】021 Q201再计划

忙了一周，终于到周末有时间再细细想这个问题了。这周还是不经意的弥补了kv硬盘存储库这个小空白的，这样也有助于构建更好的Q201。

计划是到6.1再发版，之所以留那么长时间，一方面是因为平时的确忙，另一方面则是可以有更长的时间轴去细细思考，慢就是快。现在越来越觉得，不是极限的加速某一件事情，而是保持一个合理的节奏，最后反而有出乎意料的好处。

前阵子，在衍生策略这块已经思考比较多了，挺有意思。

首先，还是在基准策略有效的前提下，去讨论衍生策略才有意义。在找基准策略的过程也是挺戏剧的，只能说，对的东西往往都出奇的简单。基准策略的盈亏比已经显著超过了2，这是一个很有意义的数字，而且这是在一个相对比较大的统计数字下得到的，很可靠。但是，基准策略的问题是不太稳定，而且有滞后性。基准策略是没法达到一个专业产品的要求的：可能出现较大幅度回撤(可能会到10%），并且有可能几个月连续亏损。

所以衍生策略是必须的，第一目的是为了将尖峰盈利能力转为较为平缓的盈利能力；第二目的是在稳定的基础上细化，优化稳定系统的盈利能力。

很自然的，可以把这样的框架类比为战略经营类游戏。国王、骑士、盗贼、刺客、轻骑兵、哨兵… , 我按照各种策略行为的特性抽象成一个游戏框架，并制定他们行动的规则以及游戏的奖励与惩罚。我觉得非常有趣，能够帮助我们有效的细化、区分各种不同的操作，从而避免过于直接的心理碰撞。（搞量化的最难过的是自己那关）

当然，如果仅仅是自己yy一套这样的游戏框架还不能起大作用。所以下一步我会想用强化学习的方法来抽象，然后构造一个虚拟的游戏环境，同时确保环境的时间、数据与真实世界同步。未来的变化，是交给算法去做的，我只是定了一个基础框架而已。

在这个过程中，我相信随着时间推进，我可以完善越来越多的细节，所以这部分就暂时不去做专门思考。

想法还是要落到实地，要工程化。

我想我并不是特别擅长搞理论，没多大兴趣；我还是更在意如何实现特定的效果，也就是工程化。

既然终点（量化目标）是已经明确的，那么起点在哪里呢？

我觉得可以是一个code。所以从这点开始谈工程化。

就是突然有一天，业务觉得某个code可能很不错，希望能上线使用。那么这意味着：

• 1 开始拉取这个code的daily数据和minute数据
• 2 对这个code的数据进行ETL
• 3 对ETL的数据进行特征计算
• 4 将特征按某种方法转为信号
• 5 至少选择一种策略(默认是基准策略)
• 6 至少进行一次回测(默认全周期回测)
• 7 对回测结果进行评估，如果通过就可以上线；不然就要觉得是在哪个层级开始剔除这个code。
• 8 如果上线，则要确保实时计算，通信的顺利
• 9 上线运行了，还要周期性回顾各种指标

必须要有机制，才能确保至少能实现以上（基础）的自动上线过程。实际上，一个code的探索，应该有非常庞大的计算量，例如在任何时间开始回测，采取多种策略的pk。

怎么能既简单，又清晰的控制庞大的code系统？

• 1 从数据上
• 2 从运行机制上

数据上，最核心的改变是采用时间序列方式。最终特征、信号都会将按照时间序列完全统一起来，这样无论横向的尝试有多少，最终都将可以汇聚到一起。说起来，我周末的记得开始处理一部分新闻数据了，至少先提取处罚类的数据，这两天发现还是挺有预测性的。

从运行机制上，可能会更复杂一些。简单来说，是一横一纵。

假设一个code的处理开始触发了，那么代表深度的“纵”部分就如上面所示，可以想象成每个步骤都有一个消息队列。每个消息队列只是为了高效处理一个流程上的问题。而“横”的部分则是以code为抓手，顺着队列的变化去追踪每次变化。可以想象成mongo中若干个流程字段。

纵的部分是为了能够无差别处理大量的逻辑计算，横的部分是为了确保这些纵都是有意义的。

还有一个思路是图的思路,万物皆可图。

图的话，暂时定位为各逻辑流程的组织和构建吧。

然后，很多元信息可以汇聚到一个点。例如，还是这个code。我还是希望有一个点状数据打开，里面的元信息足够指引我去到任何相关的部分。所以昨天做的Rock挺有用的。虽然以前有redis，但是概念总是在内存中；也有mongo，但是mongo的功能是在太多的，也不太适合容纳点的概念。Rock就挺好的。

嗯，最后又想搞台服务器了。霄龙是在不适合放家里，还是锐龙好一些。然后盘算了一下，哈哈哈，成本不低呀

到年底看看，如果超额利润能满足就搞一台 😄