期货量化策略：神经网络变得轻松模型拖延症、原因和解决方案

赫兹期货量化软件

于 2023-12-13 15:44:26 发布

阅读量2.2k

点赞数 22

文章标签：神经网络人工智能深度学习

本文链接：https://blog.csdn.net/herzqt/article/details/134974083

版权

本文探讨了强化学习模型拖延症的成因，如训练资源受限、任务复杂性、目标设定不清等，并提出了通过改进数据集、优化算法、设置明确奖励和定期评估来解决这些问题。实例分析了交易环境下模型拖延的现象，并介绍了实施解决步骤，如分析原因、调整调度器和优化模型架构以提升适应性。

摘要由CSDN通过智能技术生成

概述

在强化学习领域，当学习过程变慢或卡顿时，神经网络模型经常面临拖延症的问题。模型拖延症会对达成既定目标产生严重后果，且需要采取相应的措施。在本文中，赫兹量化国联期货极速版将探查模型拖延症的主要原因，并提出解决这些问题的方法。

添加图片注释，不超过 140 字（可选）

1. 拖延症问题

模型拖延症的主要原因之一是训练环境不足。模型也许会遇到访问训练数据受限，或资源不足的情况。解决这个问题涉及创建或更新数据集，增加训练样本的多样性，并应用额外的训练资源，例如算力、或预训练模型进行转移训练。

模型拖延症的另一个原因也许出于它欲解决任务的复杂性，或者用到需大量计算资源的训练算法。在这种情况下，解决方案也许是简化问题或算法，优化计算过程，并采用更高效的算法、或分布式学习。

如果一个模型缺乏达成目标的动力，它也许就会拖延。为模型设定明确且相关的目标，设计一个奖励函数，来激励达成这些目标，且运用强化技术（如奖励和惩罚），如此可有助于解决这个问题。

如果模型没有收到反馈，或没有根据新数据进行更新，它的进展也许就会拖延。解决方案是基于新数据和反馈建立定期模型更新周期，并开发控制和监测学习进度的机制。

重要的是，定期评估模型的进度和学习成果。这将帮助您查看取得的进展，并确定可能的问题或瓶颈。定期评估能及时调整训练过程，以避免拖延。

为模型提供多样化任务，以及刺激环境，有助于避免拖延症。任务的多样化将有助于保持模型的兴趣和动力，而刺激环境，譬如竞争或游戏元素，可以鼓励模型积极参与并进步。

由于缺乏更新和改进，也许就会发生模型拖延症。重要的是，定期分析结果，并基于反馈和新思路迭代改进模型。模型的逐步发展，和直观的进展，可以帮助应对拖延症。

为模型提供正面和支持性的学习环境是训练强化模型的一个重要方面。研究表明，正面的样本可以带来更有效和更有针对性的模型学习。这是因为该模型正在搜素最优选择，对不正确动作的惩罚会导致选择错误操作的概率降低。与此同时，正面奖励清晰地表明模型选择正确，并显著增加了重复此类动作的可能性。

当一个模型针对某个动作获得正面奖励时，它会更加关注它，并在未来倾向于重复该动作。这种激励机制有助于模型搜索和判定达成其目标的最成功策略。

最后，为了有效解决拖延症问题，有必要分析其背后的原因。辨别拖延症的具体原因，令您能够采取有针对性的措施来消除它们。这也许包括审核训练过程、识别瓶颈、资源问题、或次优模型设置。

考虑并适应不断变化的条件有助于避免拖延症。基于新数据和学习任务的变化，定期更新模型，也会有助于保持相关性和有效性。此外，要考虑新到若干因素，譬如新的需求或约束，模型应能够适应这些，并避免停滞。

设定小目标和里程碑，可以帮助将较大的任务分解为更易于管理和达成的片段。这将有助于查看模型学习过程的进度，并保持活力。

为了成功克服强化学习模型中的拖延症，您需要运用各种方式和策略。这种综合性方式将帮助模型有效地克服拖延症，并在训练中取得最佳效果。通过结合各种技术，例如改善学习环境、设定明确的目标、定期评估进度和利用激励，该模型将能够克服拖延症，并朝着达成其学习目标前进。

2. 实施解决步骤

在理论研究之后，现在我们就转向这些思路应用的实施。

在上一篇文章中，我提到需要进一步的训练，从而尽量减少亏损交易。然而，而当我们继续训练时，我们遇到了一个状况，即 EA 在整个训练期间没有进行任何业务。

这种现象被称为“模式拖延症”，是一个需要我们关注和解决的严重问题。

添加图片注释，不超过 140 字（可选）

2.1. 分析原因

为了克服强化学习中的模型拖延症，首先要分析现状，并辨别这种现象的成因。该分析将帮助我们了解为什么该模型没有进行交易，以及可以进行哪些调整来提高其性能。

使用 “Test.mq5” EA 测试训练模型，该 EA 以贪婪方式选择代理者和动作。重点注意的是，相同参数和测试周期的 EA，后续每次启动都会导致高精度地复现前一次验算。这令我们能够在每次启动时添加控制点，并分析 EA 操作。

在每次启动时添加控制点，并分析 EA 的工作，为我们提供了更高的可靠性，以及对于训练强化模型结果的信心。我们能够更好地了解模型如何基于真实数据应用其知识和预测，并做出相应的结论及调整，从而提高其性能。

为了评估调度器的工作，我们引入了 ModelsCount 向量，它包含每个代理者被选中的次数。为此，在全局变量模块里声明 ModelsCount 向量：

vector<float> ModelsCount;

然后，在 OnInit 函数中，初始化该向量的大小为零，与对应于用到的代理者数量：

//+------------------------------------------------------------------+ //| Expert initialization function | //+------------------------------------------------------------------+ int OnInit() { //--- ........ ........ //--- ModelsCount = vector<float>::Zeros(Models); //--- return(INIT_SUCCEEDED); }

在 OnTick 函数中，调度器的每次前向验算之后，增加 ModelsCount 向量中相应代理者的计数器：

最后，在逆初始化 EA 时，在日志中显示计算结果：

//+------------------------------------------------------------------+ //| Expert deinitialization function | //+------------------------------------------------------------------+ void OnDeinit(const int reason) { //--- Print(ModelsCount); delete Result; }

因此，赫兹量化国联期货极速版加入的功能计算每个代理者的选择数量，并在 EA 逆初始化时在日志中显示计数结果。这令我们能够评估调度器的性能，并获取有关在 EA 执行期间每个代理者被选择频率的信息。

添加第一个控制点后，我们在策略测试器中启动该 EA，参数或测试周期都无变化。获得的结果确认了我们的担忧。我们可以看到，调度器在整个测试过程中只用到一个代理者。

添加图片注释，不超过 140 字（可选）

这一观察结果表明，调度器也许偏向于特定代理者，而忽略了探索其他可用代理者。这种偏向也许会阻碍我们的强化学习模型性能，并限制了其发现更有效策略的能力。

为了解决这个问题，赫兹量化国联期货极速版需要探究调度器只选择用一个代理者的原因。

继续分析此行为的原因，我们加入两个额外的控制点。现在，我们重点关注模型输出分布当中的变化动态，具体取决于环境状态的变化。为此，我们引入了两个额外的向量：prev_scheduler 和 prev_actor。在这些向量中，我们将分别存储调度器和代理者的上一次前向验算结果。

vector<float> prev_scheduler; vector<float> prev_actor;

这令我们能够将当前分布与以前的分布进行比较，并评估它们的变化。如果我们发现分布随时间或响应环境的变化而发生显著改变，这也许表明模型可能对变化过于敏感、或策略不太稳定。

将这些向量添加到我们的模型中，令我们能够获得有关不断变化的策略和分配的更详细动态信息，这反过来又有助于我们了解偏向特定代理者的原因，并采取措施解决这个问题。

与前一种情况一样，我们在 OnInit 方法中初始化向量，以便为数据控制做好准备。

实际的数据控制是在 OnTick 方法中完成的。

//+------------------------------------------------------------------+ //| Expert tick function | //+------------------------------------------------------------------+ void OnTick() { //--- if(!IsNewBar()) return; //--- ........ ........ //--- State1.AssignArray(sState.state); if(!Actor.feedForward(GetPointer(State1), 12, false)) return; Actor.getResults(Result); State1.AddArray(Result); if(!Schedule.feedForward(GetPointer(State1), 12, false)) return; vector<float> temp; Schedule.getResults(Result); Result.GetData(temp); float delta = MathAbs(prev_scheduler - temp).Sum(); int model = GetAction(Result, 0, 1); prev_scheduler = temp; Actor.getResults(Result); Result.GetData(temp); delta = MathAbs(prev_actor - temp).Sum(); prev_actor = temp; ModelsCount[model]++; //--- ........ ........ //--- }

在本例中，赫兹量化国联期货极速版要评估环境状态的变化如何影响模型的结果。该实验的结果就是，我们期望看到在模型输出中，测试样本中的每根蜡烛都有唯一的概率分布。换言之，我们希望取决于市场条件的变化来观察模型策略的变化。

我们不会记录分析结果，因为它含有大量数据。取而代之，我们将用调试模式来观察数值的变化。为了减少所比较数值的体量，我们只检查向量的总偏差。

不幸的是，我们在测试过程中没有发现任何偏差。这意味着在所有环境状态下，模型输出的概率分布几乎保持不变。

这一观察结果表明，该模型不适应不断变化的环境，也没有参考市场条件的差异。模型的这种行为有多种可能的原因，并有对应解决它们的各种方式：

训练数据集的局限性：如果训练数据集没有包含足够多样的状况，模型也许无法学会充分响应新条件。解决方案也许是扩展和多样化训练数据集，包括更广泛的场景，和不断变化的市场条件。
模型训练不足：模型可能没有接受足够的训练，或经历足够的训练世代，来适应不同的环境条件。在这种情况下，增加训练时间、或使用额外方法，例如优调，能帮助模型更好地适应。
模型复杂度不足：模型复杂度也许不足以捕获环境状态的细微差异。在这种情况下，增加模型的规模和复杂度，例如添加更多层、或增加神经元的数量，能帮助它更好地捕获和处理数据中的差异。
模型架构选择错误：目前的模型架构可能不适合解决环境不断变化的问题。在这种情况下，修订模型的架构可以提高其适应环境变化的能力。
不正确的奖励函数：模型的奖励函数也许信息量不够，或者也许无法达到所需的目标。在这种情况下，重新考虑奖励函数，并将更多相关因素纳入其中，这样就能帮助模型在不断变化的环境中做出更明智的决策。

所有这些方式都需要对模型进行额外的实验、测试和调整，从而更好地适应不断变化的环境，并提高其性能。

我们将分析每一层的架构，以便从模型中准确找出系统状态变化相关信息丢失的位置。在调试模式下，我们将检查模型每一层输出的变化。

我们将从完全连接的 CNeuronBaseOCL 层开始。在这一层中，赫兹量化国联期货极速版将检查是否保留了系统状态变化相关信息。接下来，我们将检查 CNeuronBatchNormOCL 批处理数据常规化层，确保它不会扭曲状态变化数据。然后，我们将分析 CNeuronConvOCL 卷积层，看看它如何处理系统状态变化信息。最后，我们将检查 CNeuronMultiModel 多模型全连接层，判定它如何解释跨模型的状态变化。

进行此分析将帮助我们判定在模型架构的哪一层丢失了系统状态变化相关信息，以及哪些层可以优化或修改，从而提高模型适应环境不断变化的性能。